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.
Feedback is always welcome, and I also encourage you to join the Mac OS X port mailing list or the Java.net forums.