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."
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"
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.
That does not mean that other people would not benefit from it. Java 6 has a number of performance and GUI improvements. http://en.wikipedia.org/wiki/Java_version_history Anyone would be happy if their programs were faster, better looking and more responsive.
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.
No J2SE 6 there.
Energy: time to change the picture.
I'm not sure the entire issue was that it wasn't released day 1 with Leopard, but that there wasn't any information on it. Had Apple said "we will release a Java6 Q1 2008", people who *do* write Java software would have a target date for when their businesses could do what they needed to. And had Apple said "we will never support Java6 on Leopard or in the future versions of OS X", people could also have made appropriate changes. Instead, Apple had preview releases of Java6, then removed all mention of them and made no mention of Java at all when Leopard was released. When asked about Java plans, Apple has not responded.
It's the not knowing which is causing *most* of the frustration, not the fact that it's not here right now. Sure, some people might be playing the 'taking my toys home' attitude, but I think the issue is bigger than that. People have staked their careers on Java and on Macs, and now there's a disconnect. When your livelihood is at stake, you might get a bit bitchy. When it's being caused by Apple, a company people get very passionate about, you might get a bit more bitchy.
creation science book
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.
Azureus, Limewire, LightZone and Cyberduck are all popular applications written in Java, along with a large number of mobile device apps (see http://mobits.com/jad/). What Java tries to do - generalize the runtime and provide a programming language for all operating environments - is quite a task, and after a decade it has considerable success in some fields. It is really a shame that it has been subject to bad impressions and innumerable political moves that in the end just take away another choice from the end user.
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.