Apple's JDK 6 returns to the stage... what's up with that?
Apple has finally releasedan updated developer preview of Java SE 6 for Mac OS X 10.5 Leopard, making it available to all Apple Developer Connection members. A few notes on the release are available on Apple's Java page:
The Java SE 6 release for Leopard is targeted at Java developers. This version of Java for Mac OS X requires an Intel-based Mac capable of running 64-bit applications, including computers with Core 2 Duo processors and any Mac Pro computer. Java SE 6 takes advantage of Leopard's 64-bit capabilities to offer unique performance capabilities for current and future generations of Macs. Please see the release notes included with the Java SE 6 download for additional information about this preview release.
The specifics of the release, including its change/fix list, are part of a release notes document only available to ADC members and therefore technically NDA (even though anyone can join ADC at the free "online" level). Still, there's plenty to discuss with this release only being made available for 10.5 "Leopard" systems (not 10.4 "Tiger" or earlier), and then only on 64-bit Intel systems. PowerPC and 32-bit Intel are out of luck for this release, even though both were supported by the nearly-finished JDK b88 Apple released in late 2006. Those interested to speculate on Apple's development might also wonder if the final version will also be 64-bit only, and what side-effects that might have. To wit, a 64-bit JVM won't run inside a 32-bit process, so what does this mean for applets inside 32-bit browsers? Or is it time for browser makers to offer 64-bit builds for recent Macs?
And what is the future of Java on the Mac platform? For the first time in a long time, there are two completely different JVMs on the Mac: Apple's not-yet-production-quality JDK 6, and Landon Fuller's Soy Latte port of the BSD JDK 6 to Mac OS X, also a work in progress. Which one will go final first? Which will go on to Java 7? Which will work better... or does it even matter? Is the target audience Mac end-users running apps and applets, or Mac-based Java developers writing server side apps that they'll then deploy on Linux, Solaris or Windows (meaning that compiling Java 6 code on the Mac may be more important than actually running it, unit tests notwithstanding)?
At least, this release should diminish some of the rancor over the Java-on-Mac issue, though it's certainly possible the critics still won't be satisfied with Apple's opacity and secrecy, and the fact that their JDK 6 still isn't final more than a year after the official JDK 6 was released.
Now if you'll excuse me, I have to go put JDK 6 on my wife's Mac. She's got a Core 2 Duo (an aftermarket hack I did to her Mac Mini), and I've got dual G5s, meaning her computer can run JDK 6 and mine can't. Enjoy the irony.
Also in Java Today, InfoQ summarizes recent developments around the Direct Web Remoting project in their article DWR: State of the Union. "There is a lot going on in the Direct Web Remoting world. First and foremost is DWR joining the Dojo Foundation, and secondly is that Joe Walker, creator of DWR, has joined SitePen, Ltd. as Director of Support and Development. For DWR users, the move to the Dojo Foundation might cause some anxiety as to the future of the project. Alex Russel has the same concerns, and has reassured the community with the following comment..."
Mark Reinhold has posted Slides from "OpenJDK: The First Year" @ JavaPolis 2007. "I've posted the slides from the talk I presented at JavaPolis 2007last week, OpenJDK: The First Year. The video version will eventually be available online at parleys.com. My thanks to Stephan Janssen and the entire team for putting on another great show, which this year sold out at 3,200 attendees. It was well worth the trip!"
In today's Forums,
hardcode asks about deploying DLLs in Enterprise Application. "I'm working on enterprise application (EAR), which is deployed on Sun Java Application Server 9.1. Modules are run via Web Start. I want my app using some DLLs (jdic from https://jdic.dev.java.net/ ). Where should I add these DLLs to the EAR, and how to make them available for other modules? I have found information that using native code by deployed enterprise application is possible only when this code is placed in RAR module, but I don't know how to create it properly. I only want to have access to DLLs, I don't provide my own native code."
John Clingan updates the ongoing call for GlassFish feedback inCOMMUNITY HELP: GlassFish V3 & Java EE 6 Verifier. "Thanks again for the feedback to date. I don't respond to every comment, but I am tracking them and posting them to the GlassFish V3 Requirements page. How many of you use the verifier in GlassFish? Is it a "nice to have" or has it become a core part of your deployment processes? Is it a differentiating feature for using GlassFish? Does it ease migration from other application servers?"
rranjan08 asks How to make JavaFX libraries a part of local JRE? "I am running an applet (Jukka's example) with JavaFX, but loading all the signed jars and script interpretation all do take some time with JRE 1.6.0_02 that I have on the desktop where I am running the browser. Is there a way to add the JavaFX jars to the JRE on the desktop on which I run the browser and make the applet use the jars from local directory rather than loading all of them on web? If this is not possible, when can one expect a JRE release including JavaFX?"