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."

Re:What's the big deal about jruby?

[OptimusPaul]

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.

Re:What's the big deal about jruby?

[MBCook]

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.

Re:What's the big deal about jruby?

[wandazulu]

I am using it to write a scriptable Java application. JRuby has saved me literally thousands of hours trying to implement my own pseudo language just to support a simple DSL in the app. And because it's Ruby, I can now do all kinds of things that my own language couldn't do, like loops. When we give the app to users, we tell them it's scriptable, here's the DSL objects, and here's a website on Ruby; you're limited only by your imagination.

Plus it works in Java 5, so I can use it instead of waiting for Apple to release Java6 with its built in JavaScript scripting language (which I don't like nearly as much as Ruby).

Re:Why Apple?

[kwolf22]

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

Re:What's the big deal about jruby?

[Anonymous Coward]

Nothing really prevents you from using a "recompiler" at runtime with a C based executable. For example LLVM [llvm.org].

Re:What's the big deal about jruby?

[jilles]

That's true in theory but in practice most C programmers have no clue about underlying hardware architecture so 100% control amounts to random and arbitrary optimizations (and sometimes dangerous/counter productive) in most cases. The VM that the hardware presents to the compiler is not that different from the bytecode VM Java presents only more complicated, full of legacy features that no longer make sense and implemented in hardware. Underneath the processor translates to its real processor architecture which is probably quite alien to what most programmers are used to.

Also C programmers can only optimize for so many platforms and the optimizations can be different and even conflicting for each one. With a optimizing JIT, you can automatically optimize at run-time and apply any appropriate platform specific optimizations it knows about as well as optimizations that take into account measured performance of the running application. Doing the same in C requires dozens of different binaries and source code level optimizations just to target recent variations of X86 processors. Linux distributions have only recently started defaulting to 586 or 686 code instead of 386 code.

That's why a new compiler architecture is under construction (LLVM) that can do similar run-time optimizations to what Java is doing today. It makes sense to do optimization at run-time, also for C software.

warning 'Java is slow' troll alert in 3..2..1..

[Anonymous Coward]

Most people don't realize that once algorithmic complexity has been taken care of (no, a computer AI won't find -- yet -- a better way to solve 0-1 knapscak than a good DP algo), systems that do modify an executable in real-time will always be faster than whatever a computer programmer could come with in his wildest assembly dreams (and, yup, this comes from an old former assembly language programmer).

This has been shown in, what, the eighties, by HP with their project Dynamo, reordering on the fly assembly instructions to gain speed. You think you can order and pad every single assembly opcode so that you have optimal perfs? Across today's deeply pipelined/parallelized architectures? You can't. It's a fact. A good JIT 'interpreter/compiler/you-name-it' can. It's a fact too.

Major financial project here... We just ported a huge project, running across hundreds of machines, from C++ to Java (Monte Carlo simulations). Major reason? Easier developping environment (easir debugging, easier profiling, easier code coverage, easier testing, easier you-name-it), easier maintenance. Perfs? Slight edge to Java thanks to the JIT.

Java, when done correctly, is blazingly fast and keeps getting faster and faster with each release. You have to be a very blind man not to see that.

But have fun from the top of your ivory tower screaming "Java is so slow"... Poor blind man.

Re:Maybe it's me

[FatherOfONe]

Yeah, and lets add a few more to the list.
No PHP crap. Slow, and it is only for script kiddies.
No Ruby crap. Way too new and it is a fad.
No games... they just cause systems to crash. Who needs cool games.
No C or C++, only that crappy C variant that Apple makes.
Heck, now that I think about it, no programming languages at all. Make it just like they wanted to with the iPhone.

Obviously I am kidding... I own a Mac and run most (not all) of the stuff mentioned above. I game on a console. I do wish that Apple would release their GUI Java stuff under GPL, so people like this guy could get Java 6 with SWING out there ASAP. I would love to do my Java development on my Mac without using Parallels and XP.

Some have suggested that Sun should be the one making a VM for Apple, and I would agree BUT Apple should have come to Sun two years ago and said that they were out of the JVM business and worked with Sun to insure a modern VM was on their platform. It is in both parties interest to see a good JVM on the Macintosh.... Hopefully one that doesn't require a freaking OS upgrade to get the latest version of Java.

Please Apple, finish Java 6 for the Macintosh and then hand the code over to Sun to make Java 7. Sun take that code and open source it as well.

Re:Why Apple?

[LizardKing]

So in other words, Apple definitely did something dumb here, but it's not too hard to see what their motivations were.

The deprecation of the Java-Cocoa libraries is linked to Apple's support for Objective-C. At one point Apple was saying that Objective-C would be gradually replaced by C++ at one extreme and Java at the other. However, they seem to have realised that Objective-C and the tarted up OpenStep libraries are nice enough to work with that no one really wants to use C++, and that Java developers are going to stick to the plain ole JDK for their apps (either through familiarity or not to sacrifice portability).

Re:first class what?

[micromuncher]

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.)

Just tried with Jython

[hotfireball]

I've just tried the same with Jython 2.2.1 and I can confirm, that CPython 2.5.1 is slower around 10% than Java 1.6 + Jython 2.2.1 on my Leopard machine. Damn weird...