We’ve started a new project on Java.net to support creating bundled applications from your Java JARs and other resources. Find it here on java.net. It’s pretty small right now, as we are starting with Mac OS X, but we plan to expand to other platforms as well, and support JavaFx’s packaging and launching tools too.

Why isn’t this part of OpenJDK? Well, mainly because this project isn’t really tied to a specific JDK version. We will establish Java 7 as the base supported version, but expect it to work with little or no modification on Java 8 and 9.

There is some code for Mac OS X launchers in OpenJDK, but we will be moving that code to this project and removing it from the tree.

Lately there’s been a lot of discussion on Apple’s Java-Dev mailing list about bundled application support. I started to reply to a message, but it quickly turned into something that needed a blog post.

Before I start here, please remember that I’m speaking as an Oracle person now, so all of the disclaimers about not relying on this as future guidance or considering this as a commitment to do anything, etc. apply.

Starting with 7u6, we are going to have a system-wide JRE that will be used for Java applets, Java Web Start, and JAR files. It will use Sparkle to self-update, and in general, try to be as good an end-user experience as we can make it. Think about how Adobe Flash and AIR runtimes are updated, and you should have a good idea of what it will be like for the user. It’s not a perfect analogy, and we’re not going to just copy it, but keep that idea in mind.

We are also working on tooling and a launcher stub that will find a bundled JRE and use it if it’s there, and if not, will then look for the system-wide JRE and use that if available. If no Java is available, right now we’ll just let the user know they need to get Java. It will also support code signing for compatibility with Gatekeeper and the App Store. This launcher support code is all open-source, and should be public within the next week or so. And, because you presumably don’t develop a Java application for one platform, we want to support deployment for Windows and Linux, too, as a long-term goal of the project.

At this point you may be asking “doesn’t this contradict Mike Swingler, when he says you have to bundle the JRE?”, and I’m saying no, it doesn’t. We still believe that your best choice will be bundling a JRE with your application, because that way you have control over the quality of your application. Consider the scenario where the system JRE is updated and your app now breaks, or suddenly has a subtle but critical bug. Your users will come to you to complain, and not Oracle.

But because this is open source, and because it’s becoming abundantly clear that bundling a JRE is not a solution for everyone, we are not going to block apps from using the JRE for applications. I don’t want us to waste time blocking out what we know is going to happen anyway. That’s why we are supporting it in the launcher project. Of course, if you do adopt this, you are accepting the risk that a newer JRE will break your application, and that you will push out a new release on a timetable that will suit your users. And, of course, you can’t put your app in the App Store. But if that’s okay with you, go for it.

Okay, now you have an idea of what we are doing; here is what we are NOT doing:

We are NOT going to support multiple system-level JREs. This was a horrible mess with Apple, and we are not going to repeat the same mistakes at Oracle. If support for an older version of the JRE is necessary for your application you must bundle the JRE with your app.

We are not going to support applications that rely on loading a JDK from /Library/Java/JavaVirtualMachines or ~/Library/Java/JavaVirtualMachines. If you need JDK-level functionality in your application you can bundle a JDK.

Note that I am NOT saying you can’t use a JDK that’s installed. If you have an IDE or other developer tool, you would want to let the user run code that they are developing in that JDK — that’s fine. What we do not want is to force end users to install a JDK just to run an applications.

After three years of wandering I’m returning to my roots. Next Tuesday is my first day at Oracle, where I’ll be the technical lead on the Mac OS X port of OpenJDK for Oracle. This may sound like I’m staging a coup, but I’m not going to be taking anything away from Mike Swingler, Bino George, and everyone else who has been hard at work on the core of the Mac port. I will be starting on the non-open parts of the JDK, which means the Java Plugin and Web Start, and then looking into bundled application support.

I don’t expect to be working by myself on this for long — we still need engineers who know Objective-C and Cocoa and have a good background in Java. Search Oracle’s recruitment site for more details; I’ll add links in the next day or so. We are actively recruiting for these positions, so please don’t hesitate to ask for more information. Candidates who can work in the Santa Clara, CA, office are preferred.

For those of you who have known me over the years, this may not sound like a new challenge, but it is. I’d like to think of it as picking up where I left off rather than returning to an old job. And, hopefully, I will have cool things to write about again as time goes on.

I did some comment pruning today. All were of the ‘I’m trying to reach you…” variety. The easiest way to contact me is to follow/DM me on Twitter, and there’s a link on the right side of the page to let you do just that.

Chris Adamson wrote today about private APIs in the Mac OS X Java AWT. He also links back to James Gosling’s post about Java on the Mac. First, I’ll answer Chris’ main question:

But… is it true? How big a deal are secret APIs in OSX and iOS anyways?

Yes, it’s true that there were (are?) non-public SPIs in the Java AWT. I assume that’s still the case; I’ve been away from that code for close to 3 years now. I’d be really surprised if it wasn’t.

When we switched over to the Cocoa-based AWT for Java 1.4 and later, there were some things that just couldn’t be done without it. Dr. Gosling is correct: supporting Java2D drawing from any thread, while also drawing fast and within the constraints of Cocoa’s main-thread requirements needs some help from CoreGraphics. The other big area I’m most familiar with is support for AWT applications run from a command line. Without getting into too much detail, typing ‘java MyAWTCode’ from a Terminal window violates a whole lot of assumptions about what an application is on Mac OS X, and needs a lot of cooperation between the AWT and the Process Manager to sort it out.

In any event, here’s the thing to remember: at the time we wrote all of that code, the concept of OpenJDK or contributing code back to Sun didn’t even exist. We never thought we were writing code that the public might see some day, and we were part of the OS, anyway, so it should come as no surprise that an internal API was used here and there. This is also why it’s no small task to just hand over the AWT implementation to Oracle and walk away.

Chris also mentions the Cocoa SWT. As he correctly points out, the SWT does not use any private calls, but there are two main differences in the Cocoa SWT and Cocoa AWT: First, everything in the SWT must happen on the main thread. Some graphics code can operate on another thread, but not all of it. Second, the Cocoa SWT was developed in 2008 on Leopard. It’s a different Cocoa/CoreGraphics API now than what we had in 2003-2004. I think that there are some areas where the SWT could use a private API or two to implement features that were lost in the Carbon to Cocoa transition, but generally speaking, no, private APIs aren’t necessary. Experience and hindsight also help, too.

And, with that, you have the answer to the second question: It’s just not that big of a deal today, but in terms of the AWT that’s not the stumbling block. I’m pretty sure that Apple could go back and reimplement those parts that used private APIs, but doing so at this point entails a lot of work for not a lot of benefit.

As for Dr. Gosling’s talk, I think there is a fair amount of revisionist history there that I really don’t want to bother trying to correct, because I’m sure I’ll miss some of the details, too, and in the end, it really doesn’t matter at this point. Apple and Oracle working together on OpenJDK is a good thing for Java, and I wish them well.

I think I will leave it at this, however: ‘secret APIs’ were not the problem. The issues that needed resolving were not going to be settled by a group of engineers from two companies working together. And that, I believe, is the real story of Java on Mac OS X that won’t be told for a very long time.

Well, it’s finally happened. As of April 8, there are no Java sessions at Apple’s WWDC this year. I deliberately put in the weasel phrase ‘as of…’ because the list doesn’t include the “State of the Union” sessions. It also says “View the first set of sessions”, which means there’s still a chance.

I hope there is at least a Java Overview – it would be great to be able to show off the Cocoa SWT work. If you aren’t using it already, now would be a good time to start! Grab a nightly or integration build and, as always, find bugs and file them.

Update: Yes, there will be an overview session (at the very least), and I’m working on a demo of the newness that is Cocoa Eclipse 3.5.