State of the OpenJDK Project and Java 7
LarsWestergren writes "David Flanagan, the author of Java in a Nutshell, has a nice writeup on the state of the open source development of the next version of Java. The article explains the difference between the JDK7 and the OpenJDK projects and how to join them. Furthermore, it has an overview of the release schedule, proposed language changes and projects of interest. A more technical and in-depth tracking of the language changes and proposed new features can be found at Alex Miller's blog. This is the first in a series, and 'each future installment will provide an update on what's currently happening in the latest builds from the project, along with a deep dive into a new feature or API that's tracking for inclusion in Java 7.'"
Simply happy to have a 'modern' jdk on a modern machine running a modern OS. Very slick stuff. :) Something new again? I call that real progress.
OpenJDK IS the SunJDK, is just that Sun open sourced the SunJDK under GPL with the name OpenJDK, minus some proprietary components that are being replaced by the community.
"I think this line is mostly filler"
The OpenJDK is Sun's JDK, only under the GPLv2 license. Sun's JDK may make the source available, but you are limited as to what you can do with it.
http://www.mhall119.com
Ask Apple. They're the ones that maintain Java for Mac OS X, which is why it's close to impossible to get a recent version of Java for any Mac OS X not released in the last three years.
In the latest JDK6 and JDK7 builds, Swing has been replaced with something that doesn't suck in terms of performance and looks halfway decent-- it's called "Swing" and has the same API as Swing. Seriously, there have been vast improvements in Swing lately, from using hardware acceleration to themes that very closely match native L&F's. I'm not sure what year you last tried Swing, but give it another look.
In the latest JDK7 build, they even fixed the "mixing heavyweight and lightweight" z-order problem, so you can mix native AWT widgets into a lightweight Swing UI.
E pluribus unum
The default "cross platform" look and feel is indeed hideous, which is why most people would enable the native platform look and feel. The native platform look and feels were pretty bad in the past, but in Java 6 they're close to perfect, both on Windows and GTK. As for the cross platform look and feel, the Swing team have been working furiously to produce a modern replacement that will be available in a Java 6 update release early next year. It's called the Nimbus look and feel. Early screenshots available at http://www.galbraiths.org/blog/category/nimbus/ and http://www.jasperpotts.com/blog/category/nimbus/
http://www.mhall119.com
The one problem for java applications is still startup time. I just don't know what can be done about that except preloading java at boot. Which is a waste if you are not running a java app that day.
Actually, Chet Haase recently blogged about the changes being done in this area. Unfortunately many of these quickstart "cheats" are for Windows only, when questioned about this at JavaOne they said they didn't have enough engineering hours to do this for other operating systems but would welcome community contributions to this with open arms.
Linux and other users WILL still benefit from the Java Kernel work by Ethan Nichola's team though, this will be backported to Java 6 as part of the Consumer JRE project.
Being bitter is drinking poison and hoping someone else will die
Try using the GTK+ native l&f. Everything looks very bad and wrong. None of the controls look right. Spacing is off. All the layout is weird. Font rendering looks awful. The select boxes look horrible and don't work properly. Nothing behaves correctly. Hell, even Firefox looks and acts more native than it and Firefox sticks way out and looks hideous compared to a truly native app. This is why I just use the 1993-ish ugly purple default Swing theme.
http://www.mhall119.com
As such, I move to recommend that Java incorporate support for parsing CSV and DAT files into the language.
First of all, Java already has pretty good "language-level" support for XML for short while now - it's called JAXB. Basically, you can say things like "this class, Foo, represents XML tag <foo>" in your code, and use the JAXB Marshaller and Unmarshaller to save and load XML.
And when the CSV files come back, all you need to do is implement String toCsvRow() or String toCsv() in your class and implement a marshaller/unmarshaller that walks your data structure and crunches it into CSV, or back. It's not like CSV would be some sort of rocket science or anything =)
As for mysterious .dat files, Java has had ObjectOutputStream / ObjectInputStream / Serializable for ages for that exact purpose. Producing mysterious binary crap for over a decade now! =)
So you are using a 32-bit browser. The only 64-bit java plugin available for 64-bit browsers is the insecure Blackdown java plugin which is still at version 1.4.2-something. It hasn't been updated in years.
I'm not not licking toads.
The OpenJDK is Sun's JDK, only under the GPLv2 license. Sun's JDK may make the source available, but you are limited as to how you can re-distribute it or derivatives of it.
There, I fixed it for you. -W