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"
...for the next OS X update, when this breaks the updating.
People will cry foul on the boards, other people will note that as this isn't an official release, it should have been expected that it'd break the updating.
It'll be fun for the whole family!
One application is to add scripting support to a java app that has an installed base. And Ruby is popular these days so it only makes sense.
Shouldn't they be upset at Sun? Why is Apple getting the flack?
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
Ruby gives you easy scripting without having to use something like Janino to compile and import classes on the fly. Using Java also provides access to all the Java libraries from Ruby (which can be nice) and fixes some of Ruby's issues (I understand that the ruby interpreter is single threaded, for example). There are some good reasons why one might want to do it.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
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.
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.
No J2SE 6 there.
Energy: time to change the picture.
(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.
Apparently, you're not in possession of all the facts. Apple has provided a beta of Java 6 that is now more than a year old. They dropped heavy hints that Leopard would include a release version of Java 6. Despite these promises, Apple has until now not delivered. Is this reason to be angry with Apple? That's a bit strong, but I am disappointed, and I'm certainly not the only one. If Apple don't intend to release a new version after all, it would be nice if they would just say so. If they did, Sun just might jump in and release their own version, who knows.
Obviously, I am happy that some people were enterprising enough not to wait for Apple, and release their own version. Unfortunately, they can't take advantage of all the work Apple has put in their Java release to integrate it better in Mac OS X. And again a little help from Apple would be welcome: if Apple doesn't want to release new versions on their own, it would help if they would at least open up some of their code to help these kinds of third-party implementations.
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.
You have fallen to the Apple PReng machine! In 1995 Apple said the Mac would be the best Java development platform at WWDC. Repeated in 1996. Yes, pre-Jobs/OSX, but subsequently Apple would put ONE developer on Java/JDK ports, a position oddly they found hard to staff (heck, they asked me), and as I understand it, this under-resourcing of Java development has continued to this very day.
(I used the be a MacOS developer by day, and then became a Java developer by day. I continued through Rhapsody development and finally threw in the towel with 10.1.)
/\/\icro/\/\uncher