“Over the last few years, refactoring — the process of gradually improving a code base by renaming methods and classes, extracting common functionality into new methods and classes, and generally cleaning up the mess inherent in most 1.0 systems — has gained a lot of adherents. Integrated Development Environments (IDEs) like Eclipse and IDEA can now automatically refactor code.” Read the 10 reasons at OnJava.com.
Re: breaking compatibility
Could a JVM for J3EE simply scan the code and if it finds anything it can’t understand (e.g. old or depricated classes, etc), pass it off to an integrated J2EE JVM? Or would that slow things down too much?
I don’t know too much about Java specifically, but it seems to me like there could be some sort of solution for upwards compatibility. What about some sort of “header” of J3 files that would tell it to run in the J3 JVM vs. the J2 JVM?
The JVM could look for the header, and if the header isn’t there, it runs in the J2 JVM.
One thing I never understood about java was the change the designers did from the initial AWT concept to the Swing one. Trying to unify java’s GUI interface look (besides the feeling of roughness it gives compared to modern GUI trends), given the fact that it was mean to run in diferent operating systems instead of making the visual components be rendered acording to the plataform the program was running on, at least to me, doesn’t seem a good idea. I think, this fact has its bit of responsability in the partial rejection of java for desktop application development. One of the things the users dislike the must is an App that doesn’t feet well with the rest of the enviroment visually (unless it was meant to bee so, as winamp and the like).
Java has never been strong on the desktop…AWT sucks to program for…and Swing was until very recently verrrrry verrrrry slowwwww. Plus a 10 meg download for a swing-enabled version of the Java runtime was a tad prohibitive for average users until very recently when broadband finally became widespread.
What did he mean when he said
“Both the new and old I/O APIs still assume that the complete contents of a file can be accessed as a stream (true on Windows and Unix but false on the Mac).”
Don’t know much about macs.
operator overloading. If there’s one attitude I despise it’s removing useful features that have the potential for abuse simply because they have the potential for abuse.
Of course, that’s not to say Java doesn’t already have overloaded operators, it’s simply that you as a programmer cannot overload operators for yourself. There’s +, which allows you to combine Strings/StringBuffers/etc to produce a StringBuffer.
Basically, it’s the whole feel of the language that I despise. The language feels as if it’s created with the assumption that you are a bad programmer who will abuse any language features you can get your hands on, so they try to eliminate the most egregious errors through language syntax.
I don’t know about you, but I’d rather program in a language that trusts me.
One of Java’s core principles (probably #2 after portability) is SECURITY…and for maximum security, Java trusts no-one by default…not even the programmer. This is good b/c all programmers…even the best of us, can make mistakes…personally I don’t see operator overloading as all that crucial…it’d be nice…but Java’s lack of it is hardly a show-stopper…and it’s a small price to pay for a lower learning curve, fewer bugs, and greater consistency
-bytes256
I don’t see operator overloading as all that crucial…it’d be nice…but Java’s lack of it is hardly a show-stopper…
I’d say the fact that they made a special case hack for the use of operator overloading is probably the best case of all for its usefulness. That really can’t help things like BigInteger or any sort of vector manipulation code, which really benefits from operator overloading.
Can you really condone the use of:
(a.add(b.mul(c))).div(d.add(e))
over
(a + b * c) / (d + e)
?
Why did they throw out operator overloading? I don’t think it’s excusable- I can’t see any reason that would make it any advantage of design to leave it out.
For me, I don’t need a Java 3. I’m perfectly content with Java 1 or 2 or 0. Because I don’t need Java, I already have Squeak Smalltalk as my operating system!
Yeah, like I said operator overloading would be nice…but it’s hardly essential…how many languages actually have operator overloading? C++ and…and…ummm
yeah, exactly…like i said, nice, but hardly essential
i personally would love to see operator overloading in Java, but i wouldn’t hold my breath…Sun only updates the core language when they absolutely have to which is very good for stability…on a side note, if you really want operator overloading, write a java preprocessor that converts the operators to the method calls…nobody’s stopping you
-bytes256
>Java has never been strong on the desktop…AWT sucks to
program for…and Swing was until very recently verrrrry verrrrry slowwwww. Plus a 10 meg download for a swing-enabled version of the Java runtime was a tad prohibitive for average users until very recently when broadband finally became widespread.
What version of java are you running in that swing has sped up recently? While Swing might be a great library to program with, it is still too slow to be taken seriously for desktop development.
Actually I was referring to processor speed catching up…on a 1.2 GHz system it finally runs at an acceptable speed…load times still kinda suck though. I really wish that Swing wasn’t just a set of “soft” widgets built on top of AWT…it really should be “hard” widgets written with native code so that it would be faster
What did he mean when he said
“Both the new and old I/O APIs still assume that the complete contents of a file can be accessed as a stream (true on Windows and Unix but false on the Mac).”
Don’t know much about macs.
He was talking about files that have more than one part. The only OS that implements these (AFAIK) is the MacOS with a data fork and a resource fork. The first is the part that most of use know as ‘the’ file (out of ignorance ). The second contains metadata (a text-file can contain information specific to the text-editor in the resource fork, no harm done if you open it with a different one) or information that you want to change without recompiling apps (strings that need to be localized, icons, etc). MacOS X switched to either using a seperate file for the resource fork or just dumping everything in many, many different files. To avoid a nightmare to users, they stuff these things in a folder that OS X handles as if it were one entity. Of course, this has its disadvantages as well (every file wastes some disk space since blocks are allocated per chunk and files are rarely a multiple of these blocks).
Note that NTFS, the native format for Win NT/2000/XP supports multiple streams/forks as well, although it’s never used. In fact, NTFS contains some pretty nifty stuff that MS will absolutely never use out of fear of being innovative. Sigh, well anyway, streams are a nice concept but tend to create problems when you want to move files to other systems. Of course, that’s true for most meta-data other than a 8.3 filename.
What version of java are you running in that swing has sped up recently? While Swing might be a great library to program with, it is still too slow to be taken seriously for desktop development.
Java 1.3.1 on MacOS X, perhaps?
One thing I never understood about java was the change the designers did from the initial AWT concept to the Swing one.
They did that, among other reasons, to help with portability, as the “heavyweight” controls do not behave the same across all of the platforms. Also, it helps to conserve resources when all that the JVM really needs is a BitBlt versus the handles and what not to the native widgets. A finally, there’s an expense incurred jumping in and out of the JVM to native code that’s saved as well.
Of course, the downside is that Java doesn’t keep up with the platform GUI automatically when using Swing. Notorious example for Windows is that the AWT controls respond to the mouse wheel, whereas the Swing widgets do not. (in 1.3, I think they fixed this in 1.4).
Both the new and old I/O APIs still assume that the complete contents of a file can be accessed as a stream (true on Windows and Unix but false on the Mac).
On the Macintosh, specifically Mac OS 9 and below, files consist of two seperate pieces, or forks. The data fork and the resource fork. It was a novel idea at the time it was made. The data fork is simply a stream of bits, whereas the resource fork is (normally) treated as sort of Object Dictionary.
In Java, there is no way to get access to the resource fork using the standard JDK. Of course, there could be additional libraries etc that can be written to provide this access for the Mac, but they’re not part of the base package. Similarly, if you had the JRE on, for example, BeOS, there is no way to access the meta information that the Be file system associates with files.
No doubt, if Windows gets a richer file system that support features similar to what Be did, then some kind of meta information will be made available through Java.
Of course, that’s not to say Java doesn’t already have overloaded operators, it’s simply that you as a programmer cannot overload operators for yourself. There’s +, which allows you to combine Strings/StringBuffers/etc to produce a StringBuffer.
Well, that’s a bit of trickery going on there. In fact, ‘+’ can NOT combine Strings and StringBuffers, at least not as you think they are.
String = String + StringBuffer is really String = String + StringBuffer.toString(). And you can not do StringBuffer = StringBuffer + String.
Overloading operators is an emotional topic, which is its biggest problem as there are arguments both ways regarding operator overloading.
I don’t know about you, but I’d rather program in a language that trusts me.
Then you should scamper on over to comp.lang.lisp and introduce yourself. Common Lisp will give you all the rope you want, and then some.
Can you really condone the use of:
(a.add(b.mul(c))).div(d.add(e))
over
(a + b * c) / (d + e)
I think part of the problem here is that Javas history came from small machines and architectures and is trying to move upwards versus the other way around. This is why the primitives are, well, primitive. It’s why Java can have silent overflow rather than dynamic numeric typing moving your overflow automatically into a bignum.
Common Lisp handles this pretty well, but it can be a battle to make the code work in native unboxed values versus the dynamic types objects.
What version of java are you running in that swing has sped up recently?
Everytime someone mentions Swing performance, someone else will chime in that they’re doing wacky nutty things in Swing and getting great results. So, that seems to me that Swing is fast enough for some, but not fast enough for all. The Swing based IDEs are getting better all the time, and for internal developers, Swing is pretty darn useable.
Swing could do better, for example Apple has put a good amount of time into making Swing work well on OS X. Apple has its own magic JVM that does all sorts of things. Clearly, MS isn’t going to do anything to help Java along.
The bigger problem with Java desktop apps, is simply the installtion burden I think, versus the actual performance of the interface. Internal developers can manage this easier for their companies than for the Internet at large.
Swing allows you to change your look & feel to mimic the platform’s. In fact, I’m sure in the case of OS X, native widgets are used.
If you ever read Apple’s java-dev mailing list, you’ll see that Apple has a Sun engineer on loan to help with Java support. Windows on the other hand, is very Java-hostile. That’s why you won’t see nice, native widgets unless you use something like IBM Eclipse.
personally I don’t see operator overloading as all that crucial…it’d be nice…but Java’s lack of it is hardly a show-stopper.
It usually ain’t a show-stopper if you do regular programming. It is a show-stopper if you are doing some serious calculations. Since I’m not into that, you’ll have to find a mathematician and ask him out (wear defensive clothing!).
> Java has never been strong on the desktop…
I have to agree with this. If there’s one niche that .NET could possibly fill better than Java, this is probably it, or at least on the Win32 platform anyway
Note that NTFS, the native format for Win NT/2000/XP supports multiple streams/forks as well, although it’s never used
Actually it’s used by some 3rd party programs.
InnoculateIT (antivirus from Computer Associates) is one of them.
Not long after Java came out, there were quite a few tools & preprocessors developed that added a few of the C++ no no’s like a limited macro preprocessor. I even vaguely remember maybe op overloading, but its been a few years.
Think about it, C was around for years in stasis, then along comes Bjarne and adds classes & some things. To deliver something, Bell labs gave us Cpp the preprocessor, that just turned the new C++ into plain C. Run a flag up the pole & see who salutes. Quite a few obviously did as the tool vendors were then motivated to merge the 2 tools together & generally improved it.
If the Java community wants to extend Java why not define the extensions you want & create your own Jpp. If loads of people start to use it maybe just maybe Sun will accept it. At least you don’t need Suns permission & its not hugely difficult.
I wanted a version of C++ for doing work on ASICs so I created Vpp, converts one industry ASIC language subset (20% or so) to plain old C, now I can carry on from there. It does the same sort of thing a $25k program does I could never afford. Its in no shape to gpl yet, but one day perhaps. When I 1st got into Java, I tried doing this Vpp with it, but compilers like to use macros so I went the C++ route for raw speed and a simpler design.
The op overloading is part of the thing you need to do to create domain languages, so either Sun relents on this, or the user just accepts horrid syntax, or you create your own specific preprocessor. Lot of work though. But there are quite a few Java parser tools but may be slow going.
just pp
“Yeah, like I said operator overloading would be nice…but it’s hardly essential…how many languages actually have operator overloading? C++ and…and…ummm”
C#
-G
That’s not what the article is about at all … it’s the writer’s 10 top things he’d like to fix in Java.
Nothing about why we need Java … like do we even need Java ?
Great for type-checking, and they make collections way easier to use. Why not add them?
Yeah, like I said operator overloading would be nice…but it’s hardly essential…how many languages actually have operator overloading? C++ and…and…ummm
What’s Java based on again? I forgot… oh right, C++
The same result derived from C++ Templates can be had through polymophism in Java (although at a price in speed).
I love refactoring. Intellij IDEA rocks.
http://www.intellij.com/idea/
> Could a JVM for J3EE simply scan the code and if it
> finds anything it can’t understand (e.g. old or
> depricated classes, etc), pass it off to an integrated
> J2EE JVM? Or would that slow things down too much?
It’s not really possible to do that because of the dynamic way in which classes are loaded in java. For example an app could load something which uses a legacy api long after it started executing.
I remember reading not long ago that the Eclipse IDE had a toolkit for Java called SWT. If I recall correctly, this new widget set was based on native controls and just wrapped them instead of doing all the work like Swing does. Apparently it’s quite responsive, although I haven’t tried it yet. (http://www.eclipse.org/)
>Note that NTFS, the native format for Win NT/2000/XP supports multiple streams/forks as well, although it’s never used
Actually it’s used by some 3rd party programs.
InnoculateIT (antivirus from Computer Associates) is one of them.
Do you know what do they use it for?
The same result derived from C++ Templates can be had through polymophism in Java (although at a price in speed).
Bah, Java needs templates because it can’t do dynamic type identification. Instead, what do you do? You CAST.
I don’t know about you, but in C++ I use templates to wrap functions which take void pointers, just to make code more readable and easier to work with by eliminating all the unnecessary casting.
All the 10 reasons that Java 3.0 is needed were brilliant.
I’d add only one extra… having the inherent ability to compile to native code built into the language/runtime from day one.
If Java were fixed up, it wouldn’t be nearly as fucked as it is today.
Jonathan Schwartz has his work cut out for him. If I were him, I’d take the Java 3.0 list give it to his engineering managers and say “make it so”.
#m