Slashdot Mirror
Java's Greatest Missed Opportunity?
jg21 writes "It looks like Bruce Eckel has hit the nail on the head again. No sooner did he finish stirring debate by writing about the 'departure of the Java hyper-enthusiasts,' previously discussed here on Slashdot, than he now rubs salt in the wound by highlighting in AJAXWorld Magazine how and why Java missed its golden opportunity to become the language undergirding Rich Internet Applications. He comments: 'We must ask why Java applets haven't become ubiquitous on the internet as the client-side standard for RIAs....This is an especially poignant question because Gosling and team justified rushing Java out the door (thus casting in stone many poorly-considered decisions) so that it could enable the internet revolution. That's why the AWT and Applets were thrown in at the last second, reportedly taking a month from conception to completion.'"
... and manually assigning memory to each application with command-line gobbledegook, and retuning every time you wanted to run a different mix of applications?
... now let me see ... ... ah yes, user interfaces that might well look like the same application running on a different platform but that's not what the punter wants - what the punter wants is consistency of user interface across all applications on the one platform he actually uses. It is absolutely of no interest to him at all whatosever that the reason that Bloggit 4.7 doesn't behave remotely like a standard Windows app is that it is carefully designed to behave exactly like Bloggit 4.7 on a MAC!!
... now let me see ... ... ah yes, type safe collections, sane enums, and all the other things we've been used to for decades in C++. Nuff said.
... now let me see ... ... ah yes, lowest common denominator libraries. "You can't do that in Java, because it can't be implemented on Linux/OSX/whatever." Duh!! It's provided natively in Windows for heaven's sake, why can't I have it for my Windows app? (And don't get me started on the various broken non-working "solutions" for sortable JTables when the native control on Windows does exactly what's wanted ...)
Welcome to the Brave New World of Java applications! - any computer with less than many gigabytes of physical RAM is going to involve you in all these contortions if you want to run anything non-trivial written in Java.
What else
What else
What else
Having said which, if clients really insist on paying me to write in Java I'll take the money, being a professional. And years later what do I get? - "er, yes, maybe you did have a point, maybe we should have let you write it in C++". Ho hum.
C is great. C++ is a pile of crap.
Most of these just seem to be you bragging about how great you are compared to everybody else. When I see publically-inspectable coded examples of how great Java and Java frameworks are, maybe I'll start to beleive you. Call it "open source evidence". What I see instead is that it takes 3 times as many Java programmers and 3 times as much code to create and maintain the same thing as would be in PHP, ColdFusion, Python, or Dot.Net. Java programmers don't care if they are inefficient as long as they get a big paycheck. Sun seems to not want you to ever see the database, and builds giant walls around it in the name of "encapsulation" to keep you away from them. Seems Sun wants to steal sells from Oracle. Productivity be damned.
Table-ized A.I.
I'd like to point out that Java's perceived bloat and slow loading times
are no longer true.
I used to stick with C++ for performance reasons, but gradually switched to Java from being involved in one project for several years. It was true that the J2SE was slow to load and run but Sun has definitely improved it over the years. I always had the weekly JDK snapshots automatically installed to get those benefits. There wasn't much of a change from 1.4 to 1.5, but 1.6 saw a huge performance win due to better register allocation. Load times also improved somewhat over releases (or maybe because computers have gotten faster). 1.7 is also in the works, but I haven't seen any significant improvements yet.
I'll go out on a limb to say that Java has pretty much closed the performance gap with C/C++, except for floating point. It can do many optimizations that statically compiled languages can't:
*branch removal/optimization - there are lots of branch conditions that are constant at runtime, but not at compile time, which can be removed or better predicted.
*memory allocation - heap allocation is basically free in Java because the JVM uses copy collection to make the heap contiguous, with allocations occuring at the end of the heap. This is much easier to do in Java because the JVM knows exactly where pointers are and can point them to the new location after doing copy collection.
Try hand optimizing a program in Java - it makes practically no difference.
I'd say such benefits, not to mention better programmer productivity, definitely outweigh the time it takes to do a cold start of the JVM.