Slashdot Mirror
Java 6 Available on OSX Thanks to Port of OpenJDK
LarsWestergren writes "Many Mac users have been upset that Apple has not made Java 6 available on the platform. Landon Fuller posts that there is a developer preview release available of Java JDK6 on Mac OSX, Tiger and Leopard. It is based on the BSD port of Sun's Java 6 and is made available under the Java Research License. Charles Nutter posts about impressive JRuby performance gains using Java 6 on his Mac."
"Many Mac users have been upset that Apple has not made Java 6 available on the platform."
.Net is another.
I'd have thought not having Java infecting your machine would be a huge advantage myself. Not having
It is not OpenJDK, but "based on the BSD Port of Sun's Java 6 JDK, and is made available under the Java Research License"
Why would anyone ever use anything but assembly? The rest is all syntactic sugar. Even if you need portability, you need only go as far as c.
More seriously, jruby is faster than cruby, and has nicer syntax than java. You would use it if you wanted to write code in a nice language on platforms where you would otherwise be stuck with java. Virtually anything that processes either plaintext or xml is going to be radically easier to implement in jruby than java, and nearly as fast at runtime.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Shouldn't they be upset at Sun? Why is Apple getting the flack?
Because Apple told Sun not to work on a jdk for mac os x since apple would produce and maintain it.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
Because Apple have shot themselves in the foot with this one. Apple decided they wanted to make Java themselves and offer it through Software Update and all the other Mac niceties. However, Sun releases Java 6 and us Mac Java developers are still waiting. That's why Apple gets the flack and not Sun.
Apple provides their own non-GPL'd Java implementation. Presumably, the core components of this implementation have been licensed from Sun under a non-GPL license that allows Apple to create a platform specific derivative work. I know that Apple distributes J2SE 5.0 with an Apple License that states, "...you may not copy, decompile, reverse engineer, disassemble, modify, or create derivative works of the Apple Software or any part thereof." This protects the proprietary parts of Apple's implementation of Java that link to the rest of their proprietary code. BTW, this situation also means that the GPL Classpath Exception doesn't apply to Apple's Java Implementation.
My feeling is that the Apple/Java vacuum has to do with the fact that Java is now GPL'd. I seem to remember that one of the reasons that Apple chose BSD over Linux for OS X was due to the way GPL'd software is licensed. Think about it... Apple has done A LOT of work to integrate Java into just about every aspect of OS X. Probably, under the GPL, they'd have to cough up a lot of their proprietary integration source code. I think that this is also why there is no official QuickTime Player for Linux. If Apple were to come out and announce that they won't support Java on OS X because of the GPL, it would probably cause much worse press than the present situation (which also sucks, btw).
Since OS X, Apple has been a big supporter of Open Source software - but NOT Free (GPL'd) software. My feeling is that before we see OpenJDK on OS X (or on the iPhone), Apple will have to figure out how their proprietary technologies such as Aqua, QuickTime, etc. will be able to legally integrate with GPL'd Java. Either that, or Apple will cease in-house Java development entirely and give it back to the community - relegating Java it to third party add-on status.
Personally, my fear is that since Apple's Java 6 implementation seemed ready to go - especially for Leopard, Apple pulled their Java 6 implementation because they are unwilling to comply with the terms of the GPL. Keep in mind that Java 5 (Apple's current implementation) is not to be GPL'd. If this is the case, there could be serious implications about the future of Java integration with all of Apple's technologies
There's another reason to run JRuby - the ability to dynamically change a code snippet by users inside a larger application for custom rule engines, as an example.
Java allows it as well, but it's much harder to sandbox dynamically uploaded java code than a scriplet.
The cesspool just got a check and balance.
(Note: I am a Java developer by day.)
There was a huge, huge stink in the Java community when Leopard was released without Java6. Teeth were gnashed, complaints were shouted from the rooftops, great offense was taken. Threads of truly astonishing lengths were generated.
Watching all of this transpire made me incredibly embarrassed of the Java community. (Note: Predictable smart-ass comments can be inserted after the previous sentence.) The hue and cry was simply amazing and, let's face it, immature. "I want Java6 *now* and since it's not there I'm abandoning the Mac as my platform!" In other words: "I'm taking my toys and going home." Very, very few of the complaints were from people who actually depend upon Java6, i.e. are building apps with it. Instead, there was a large sense of entitlement that was unjustified and exhibitied a childish impatience that was amazing to watch, with a strong dose of the usual fanboy/hater streetfight.
*shrug* There were two choices that were much less reactionary: (a) wait for the Apple release Java6 or (b) work on the OpenJDK project. Kudos to Landon for doing this. It's a big start, and will hopefully generate enough interest to move it forward significantly.
Of course, people like to bitch, and neither of those choices fulfills that need.
What's so interesting about it is that Microsoft's copy of Java, C#, was concerned about being the fastest language so they make a lot of hacky choices purely based on what they thought would be fastest. Things like:
.. and so on.
* value types - now java can often automatically put objects on the stack and this makes the complexity cost of value types hardly worth the benefits.
* jit-only - C# thought that a jit would always be used because jit is 'faster', so their bytecode is not able to be interpreted effectively. This prevents the very efficient mixed-mode interpret followed by hotspot compile (for instance, Java can optimize the program using another core while it is running interpreted).
* 'real' generics - C# thought real generics would be faster by avoiding casts, but the complexity cost of following generic instance types prevents many optimizations such as method inlining that now save more time than casts (iirc CLR only inlined single methods less than 32 instructions and only if not overridden, vs Java inlining multiple method calls deep)
* embedded native code - C#'s bare-metal native code interface allows for faster access to small bits of native code, but it locks objects in place in memory a lot more making the gc more complicated.
In all these cases C# chose the way it thought was fastest but this made the CLR very complex. Java chose the way that was simplest but fast enough. And the end result is that Java is much faster than C# and a much simpler implementation.