Open JDK has a lot to answer for(bluetrainsoftware.blogspot.com)
bluetrainsoftware.blogspot.com
Open JDK has a lot to answer for
http://bluetrainsoftware.blogspot.com/2009/09/open-jdk-has-lot-to-answer-for.html
7 comments
I, for one, am quite happy to see Java take a back seat. It isn't the ideal language to driving the future of the JVM. It's Scala, and Clojure, and Groovy, and JRuby, and and and so many others that should be the driving forces behind the JVM. Java can only benefit from those as C# has benefited from the DLR and F#. As long as they don't let it atrophy into nothingness.
Java isn't becoming irrelevant because Sun is neglecting it or plans to neglect it. Java is becoming irrelevant because even though it's a great tool, the community represents many of the things that passionate developers have come to hate. Technology is progressing. Hardware is getting faster, virtual machines are getting smarter. The original focus of Java, productivity and simplicity, is now being found elsewhere.
It also hasn't helped that Sun continued to do everything possible to make Java hard to get for end users, and to completely and hopelessly break Java on client systems. Java is relegated to server apps and cellphones now, neither of which have as strong a requirement on "write once, run anywhere". Other languages are closing fast on Java on server code and I've yet to see a mobile java app that was as good as a natively compiled app.
Java is no longer "write once, run anywhere" anyways. It's more like "write once, run anywhere that has the exact matching JRE with all the right updates, and the correct version of the JRE w/r to being either some standard runtime, or Java SE, ME, EE, ER or whatever the various versions are now."
Add to that a completely opaque and overly complicated VM distribution channel for end users, forced downloads of unrelated software and toolbars, constant barrage of update tooltips, a completely hosed standard library for developers of desktop/client apps, and a general failure to improve the language with age or listen to the community about language requirements and you have the makings of a dying language.
We have to beg our developers to even think about using Java even for server apps because the standard library and restrictive syntax is so lobotomizing to users of other languages.
Java is no longer "write once, run anywhere" anyways. It's more like "write once, run anywhere that has the exact matching JRE with all the right updates, and the correct version of the JRE w/r to being either some standard runtime, or Java SE, ME, EE, ER or whatever the various versions are now."
Add to that a completely opaque and overly complicated VM distribution channel for end users, forced downloads of unrelated software and toolbars, constant barrage of update tooltips, a completely hosed standard library for developers of desktop/client apps, and a general failure to improve the language with age or listen to the community about language requirements and you have the makings of a dying language.
We have to beg our developers to even think about using Java even for server apps because the standard library and restrictive syntax is so lobotomizing to users of other languages.
Exactly right.
It'd been awhile since I downloaded Java, and I hadn't known about the Great SE/ME/EE switchover™ at the time. I literally stared at their web pages, navigated all over the place, and I couldn't figure out which version I should have. Sun (excuse me, Oracle) needs a big fat "Download Java 1.7" button, that has everything. They should fire everyone else in their marketing department.
It'd been awhile since I downloaded Java, and I hadn't known about the Great SE/ME/EE switchover™ at the time. I literally stared at their web pages, navigated all over the place, and I couldn't figure out which version I should have. Sun (excuse me, Oracle) needs a big fat "Download Java 1.7" button, that has everything. They should fire everyone else in their marketing department.
Oh, it's miserable. If they can't even explain what differentiates one from the ta' other, they shouldn't have the options.
They also have too many things called "Java" that are really unrelated technologies. Is Java on the server side (say JSP) the same as a Java client app? Outside of similarities of language and libraries not really. All of the frameworks are really different things. The language and the VM are different things (both called Java). The entire platform is called Java.
In my view, Java should purely be a "kind of technology" or perhaps a "particular software development pipeline/toolchain". Namely, Code in some language that is compiled to bytecode designed to run in Sun's(Oracle's) VM technology.
So instead of just packing in different kinds of cruft and slapping an obscure two letter appendix to the title, they should really call them entirely different things.
Sun/Oracle Client VM
Sun/Oracle Mobile VM
Sun/Oracle Server VM
Sun/Oracle IDE/Compiler/Libraries
There's no sense in packaging it up and calling that package "Java 7 SE R43" or 1.7 or whatever insane marketing logic non-standard version scheme they're using now.
End users download Sun/Oracle Client VM. Period.
Server admins download Sun/Oracle Server VM. Period.
Mobile VM shouldn't even be a download, it should just be included on all phones that can run it (like it basically is now anyways).
Developers download The IDE/Compiler/and Language Libraries. Heck, they compiler and library toolchain should really just come with the branded IDE.
The VMs don't really change that much. The standard library shouldn't change that much (if the Java team could ever get their act together and write reasonable interfaces to common things like I/O and hurry up and deprecate bad design decisions). And the class libraries for Client VMs and Server VMs are ultimately very different anyways.
The names should be clear and make sense. SE/EE/ME/whatever doesn't help anybody. Client VM, Server VM, Mobile VM does. It used to be this simple, but then they let the monkeys in to the packaging process.
They also have too many things called "Java" that are really unrelated technologies. Is Java on the server side (say JSP) the same as a Java client app? Outside of similarities of language and libraries not really. All of the frameworks are really different things. The language and the VM are different things (both called Java). The entire platform is called Java.
In my view, Java should purely be a "kind of technology" or perhaps a "particular software development pipeline/toolchain". Namely, Code in some language that is compiled to bytecode designed to run in Sun's(Oracle's) VM technology.
So instead of just packing in different kinds of cruft and slapping an obscure two letter appendix to the title, they should really call them entirely different things.
Sun/Oracle Client VM
Sun/Oracle Mobile VM
Sun/Oracle Server VM
Sun/Oracle IDE/Compiler/Libraries
There's no sense in packaging it up and calling that package "Java 7 SE R43" or 1.7 or whatever insane marketing logic non-standard version scheme they're using now.
End users download Sun/Oracle Client VM. Period.
Server admins download Sun/Oracle Server VM. Period.
Mobile VM shouldn't even be a download, it should just be included on all phones that can run it (like it basically is now anyways).
Developers download The IDE/Compiler/and Language Libraries. Heck, they compiler and library toolchain should really just come with the branded IDE.
The VMs don't really change that much. The standard library shouldn't change that much (if the Java team could ever get their act together and write reasonable interfaces to common things like I/O and hurry up and deprecate bad design decisions). And the class libraries for Client VMs and Server VMs are ultimately very different anyways.
The names should be clear and make sense. SE/EE/ME/whatever doesn't help anybody. Client VM, Server VM, Mobile VM does. It used to be this simple, but then they let the monkeys in to the packaging process.
You should use "JVM". But other than that you should get a job as Sun's marketing department.
He seems to be saying that Sun's stance will be let the Open JDK develop, and roll that into the official package.
I thought this would be good news. Sun has a shaky future and a lot of people use Java. The more control of it the community has the better.
I thought this would be good news. Sun has a shaky future and a lot of people use Java. The more control of it the community has the better.