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

Maybe it's me

[Anonymous Coward]

"Many Mac users have been upset that Apple has not made Java 6 available on the platform."

I'd have thought not having Java infecting your machine would be a huge advantage myself. Not having .Net is another.

Re:

[Anonymous Coward]

The only Mac users I know that even noticed are Java developers.

Re:Maybe it's me

[AmaDaden (794446)]

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 [wikipedia.org] Anyone would be happy if their programs were faster, better looking and more responsive.

Re:Maybe it's me

[nostriluu (138310)]

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/ [mobits.com]). 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.

Re:

[nostriluu (138310)]

They are two different things. uTorrent is, well, a micro client implementation, whereas Azureus is meant to be a be-all, end-all client implementation. You could make a minimal torrent implementation in Java as well.

Re:

[AmaDaden (794446)]

It seems simple but it gets very messy very quickly. They started out doing that. http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org]. AWT [wikipedia.org] would use what ever GUI system was native to the OS. The result was the Java app looked like it fit right in. But it was a mess. From Java 1.0 to Java 1.1 they tried to fix it but it still did not help. So with Java 1.2 they said fuck it all and just made Swing [wikipedia.org]. Swing still kinda sucks but it's way better then AWT was.

Re:Maybe it's me

[FatherOfONe (515801)]

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:

[AmaDaden (794446)]

Sun take that code and open source it as well.

Your behind by a few months.
http://open.itworld.com/4915/070508opsjava/page_1.html [itworld.com]
Here is a summery for people to lazy to click on the link from http://en.wikipedia.org/wiki/Java_(programming_language) [wikipedia.org]

On 13 November 2006, Sun released much of Java as free software under the terms of the GNU General Public License (GPL). On 8 May 2007 Sun finished the process, making all of Java's core code open source, aside from a small portion of code to which Sun did no

Re:

[jilles (20976)]

By design that is not possible. But you might run into an exploitable bug in the native code of the vm that allows people to bypass security measures. This is true for any native software on your system. These exploits are getting pretty rare in Java though and I can't actually recall any major Java related exploits in recent years. There have been security related patches of course from Sun and most of them for good reasons. Additionally, you could install a Java application with bugs that are exploitable

Not Open JDK based

[bafio (879076)]

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"

Re:Not Open JDK based

[Anonymous Coward]

Correct. It'll based off OpenJDK as soon as we've got the project instantiated within the porters group in OpenJDK.

The porters group should be created this week, I hope, and then it shouldn't take long to get the BSD port into OpenJDK, and after that Landon's work.

cheers,
dalibor topic

What's the big deal about jruby?

[happyemoticon (543015)]

Am I the only one who thinks it's weird to run an interpreted language inside of a virtual machine? Would there be any application to it, aside from rewriting overly-verbose Java code in a more concise language?

Re:

[OptimusPaul (940627)]

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:

[FranTaylor (164577)]

Oh, that's an easy one. Take advantage of the garbage collection and the JIT compiler. Why write your own when you can use what already exists?

De gustibus non est disputandem.

Re:

[wandazulu (265281)]

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

Re:What's the big deal about jruby?

[TheNarrator (200498)]

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.

Re:What's the big deal about jruby?

[ClassMyAss (976281)]

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

Re:

[cmburns69 (169686)]

Java is not particularly concerned with being the fastest language on the block. They're more concerned with being fast enough. Java is not suitable for things where every ounce of performance is necessary. They are also moving closer and closer to being truly write/compile once, run anywhere.

Java is for business applications where performance is nice, but not critical.

But of course, they will market any performance gains, as that's just icing on the cake.

Re:What's the big deal about jruby?

[0xABADC0DA (867955)]

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:

* 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. .. and so on.

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.

Re:

[ndykman (659315)]

Firstly, I think your conclusion that "Java is much faster than C#" is very difficult to support. Of course, there are lies, damn lies, statistics and benchmarks, but the overall picture I see is that the performance of C# is in fact quite competitive with Java in terms of runtime performance.

As for some of the decisions, they are not just about pure speed. There are more considerations.

Value types: This allows the choice of the best semantic match is. Also, this does help with native interoperability

Re:

[0xABADC0DA (867955)]

Firstly, I think your conclusion that "Java is much faster than C#" is very difficult to support ... but the overall picture I see is that the performance of C# is in fact quite competitive with Java in terms of runtime performance.

You can't post benchmarks of C#, macro or micro... enough said. Actual performance of CLR has to be hidden from view.

Value types: [...] Also, the complexity cost you note is small, as even Java still has value types. If you have to deal with both, then adding in structs isn't that costly, from a language and runtime view.

You'd think... but in Java the bytecode specifically indicates each value type whereas the CLR does not (since there can be any number of value types). The cost of this to CLR is HUGE because makes it not interpretable and also very difficult to optimize... the CLR has to determine types for all values whereas the JVM has the actual type built right into the code. I can't stress enough h

Re:

[ClassMyAss (976281)]

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.

And this is definitely a good thing. However, it is being touted as if it's the solution to the entire heavyweight object problem. It is not - plain and simple, objects are too bloated to use if you need to shuffle around and process large amounts of data. If I want to store a list of half a million vectors and do some geometry with them, in Java the only rea

Re:

[setagllib (753300)]

Quite the opposite - at least with C you have absolute 100% control of the code you're running until you reach actual system calls, and then the kernel might allow you to make modules to extend those too. Since the very best the JVM can do is make C-like code, doing it yourself will make it faster.

The cost is having to do all of the intelligent JVM-like optimization manually, which means you'll spend years micro-optimizing C code instead of macro-optimizing Java code or moving on to new features or another

Re:

[jilles (20976)]

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 w

Re:What's the big deal about jruby?

[Headius (5562)]

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.

Re:What's the big deal about jruby?

[Surt (22457)]

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.

Re:What's the big deal about jruby?

[Gr8Apes (679165)]

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.

Re:What's the big deal about jruby?

[MBCook (132727)]

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.

I can't wait

[Anonymous Coward]

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

Clueless

[FranTaylor (164577)]

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.

Why Apple?

[Orange Crush (934731)]

Many Mac users have been upset that Apple has not made Java 6 available

Shouldn't they be upset at Sun? Why is Apple getting the flack?

Re:Why Apple?

[scheme (19778)]

Many Mac users have been upset that Apple has not made Java 6 available

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.

Re:

[teh kurisu (701097)]

Because Apple provide Java on Mac OS, not Sun. Remember how Microsoft provided the Windows version of Java, before Sun got pissed off with what they were doing with it and demanded it back? Same thing here, only Sun haven't got pissed off yet (hopefully soon!).

Can't be bothered looking for anything to back up what I've just said, but go to http://java.sun.com/ [sun.com] and look for any Mac OS X download. There aren't any.

Re:Why Apple?

[el_chupanegre (1052384)]

Shouldn't they be upset at Sun? Why is Apple getting the flack?

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.

Re:

[LizardKing (5245)]

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

Re:Why Apple?

[kwolf22 (825499)]

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

Because Java is more integrated with system

[SuperKendall (25149)]

As others have noted, Java on the Mac is handled more by Apple than by Sun.

But there are good reasons for this - Java on the Mac is more tightly integrated than with other systems. For example if you load multiple Java apps, you are not getting multiple instances of Java libraries loaded...

There is also a Java-Cocoa integration layer, which though deprecated has to be supported and tested.

It's true that Java ports have lagged behind other platforms, but there are some compensations in return. That said it

Re:Why Apple?

[0racle (667029)]

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

Re:So it's entitlement, then?

[mean pun (717227)]

Strikes me as an indictment of human behavior. Do you praise apple for all of the previous times that they ported java, or condemn them for the one time that they don't?

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.

Who needs Java 6?

[FranTaylor (164577)]

Where are the Java 6 apps out there that make this necessary? Java 6 introduces incompatible changes to JDBC, so new database drivers are necessary.

Okay, developers need it, but why not develop on Linux, which has had Java 6 for some time now?

"Write once, test everywhere"

Re:

[AmaDaden (794446)]

http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org] The main improvements are not what has been added to the language but the improvements that make the whole thing faster. Where I work we recently switched our JSP server from Java 3 to Java 5 and went from having 60% of our pages take under 2 seconds to having 95% of our pages take under 2 seconds. No code changes. Hell, I don't even think we recompiled it. With Java you need to keep in mind that things like memory management that Java does on it's own can a

Java whiners

[revscat (35618)]

(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 [javalobby.org] 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.

Re:Java whiners

[Knara (9377)]

You forgot 3) "switch to an operating system where your development tools aren't beholden to the whims of a single OS+Hardware vendor"

Re:Java whiners

[mgkimsal2 (200677)]

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.

Re:Java whiners

[thomas.galvin (551471)]

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

When I made the switch to Mac, one of the big selling points was Apple's clear statements that "Java was a first-class citizen," and "the Mac is the best Java development environment available." And for a long while, that was true.

Java 6 was released in 2006. Java 5 is from 2004. People aren't crying "we want Java 6 now," they're saying "we'd like your 'first-class' citizen to be updated to something written in the last three years." I don't think that this is unreasonable.

Re:first class what?

[micromuncher (171881)]

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

Re:

[MartinG (52587)]

Then don't use WSAD. It's crap.

I changed to eclipse and everything is blazingly fast.

Re:

[FranTaylor (164577)]

Probably not. This is only good news if you need JDK 6.

Re:

[AmaDaden (794446)]

If the programs know to use the new version of Java it should. Java 6 is faster then Java 5(http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org]). According to some other posts the JDK for OSX is built in. With any luck this JDK will replace that one. There is also a chance that the programs will need to be recompiled to take full advantage of it.

Nope

[apsmith (17989)]

Here's the text from the "release 6" developer preview 1:

Java for Mac OS X 10.4, Release 6 delivers improved reliability and compatibility for Java 2 Platform Standard Edition 5.0 and Java 1.4 on Mac OS X 10.4.10 and later. This release updates J2SE 5.0 to version 1.5.0_13 and Java 1.4 to version 1.4.2_16.

No J2SE 6 there.