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 integrates their Java into the OS, but a standalone JDK exists within its own directory tree and doesn't interfere with anything else. I have 4 different JDKs installed on my machines and they don't interfere with each other or the resident JDK.
Apple does provide, and always has, Java for OS X. It has always been an integrated application environment, hence the collective 'Huh?" when Java 6 didn't show up with Leopard.
http://www.kernelthread.com/mac/osx/arch.html
"I use a Mac because I'm just better than you are."
JRuby is actually faster on a lot of benchmarks now then straight C Ruby (see the link in the above article to the blog post). This is because Jruby turns ruby into Java bytecode. Java's JIT can do lots of special runtime optimizations to the compiled bytecode that C Ruby can't. With each version, the JVM has been getting better and better at doing these optimizations. It's nice because if I wrote a program in C it would always be the same speed unless I upgraded the hardware. With Java the software just gets faster and faster with each version because the JVM gets smarter.
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.
Yes, the JIT compiler is written in C, but you are wrong that a better optimizing C compiler could beat a really good JIT. The whole point of JIT is that it can use current information about how a program is running and do things like arrange objects in memory to increase the cache hit rate. The best C compiler in the world just doesn't have the amount of information available that it would need to do things like this.
That's not to say this all currently works in practice, though. Sun has been telling everyone for the past five years that the JVMs are so robust and intelligent that you don't need lightweight objects to do fast computation (for things like vector math), that you can just use plain old Java objects and the JVM will figure out how to optimize these, and anybody that's ever actually programmed some physics or graphics in Java knows that those claims are still crap. (Though I'm told this version of Java is much better about this stuff, to be fair)
However, failures in implementation aside, there are very good arguments that suggest that as we go forward, JIT compilers will eventually overtake statically compiled code when it comes to speed. IMO the current Java 6 JVM is a pretty good first step towards this ideal JIT compiler; maybe I'd qualify it as a very early alpha version of The Real Thing. Certainly much more of an improvement than the past few versions. It's unfortunate, however, that Sun continues to pretend that they've already got it all figured out and running smoothly, when there is obviously so much more work to do. It's also quite irksome that they ignore most performance-related RFEs, simply promising that the magical JIT will fix everything in the next version...
JRuby itself uses only about as much memory as Ruby does for most apps we test. But we do pay a one-time cost for the JVM itself, which adds 25-30MB to the process. However on a server deploying Rails, this is insignificant compared to the memory eaten up by Ruby runtimes, and we're smaller there by most measurements.
Startup...yeah, it's an issue. But JRuby 1.1 will ship with Nailgun as part of the release, which enables you to run JRuby in a background persistent process and execute command-line scripts with startup times in the hundredths of a second range. Quite acceptable.
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.