Java applications and Gatekeeper

This post is the first in a series of articles about Java deployment on OS X. Future articles will cover the OS X App Store, applet support, and Web Start.

OS X 10.8 (Mountain Lion) is expected to arrive any day now, and one of its features that will have an impact on everyone is Gatekeeper. In this post we want to answer some of the questions we've been getting from developers who want to know what's going on with Java in Mountain Lion, and want to create natively bundled applications with Java 7.

Question 1: "Let's say I have a legacy application that relies on Apple's Java 6. This app can be downloaded from my website on a disk image (.dmg). In Mountain Lion, will I be able to rely on there being a JRE pre-installed by Apple? If not, what will happen?"

Answer: The user experience will be identical to that of OS X 10.7. Java is not pre-installed on 10.8, so the user will be prompted to install Java 6, and the application will then be started. Read on, though, because no matter what version of Java you depend on you will be affected by Gatekeeper.

Question 2: "I have updated my app to take advantage of Oracle's Java 7 JRE. What will I need to do to ship a working app without the end user having to jump through a bunch of hoops?"

Answer:  If you used javafxpackager or appbundler to build your application, you are 99% of the way there. All you have to do now is prepare your application for OS X 10.8 Gatekeeper. If you haven't done so already, I strongly suggest that you read up on Gatekeeper and Developer IDs.

The TL;DR version of that document, is that once you have your Developer ID certificate, signing your bundled application for Gatekeeper is as easy as this line:

 % codesign -s "Developer ID Application" ExampleApp.app

Gatekeeper has nothing to do with the OS X App Store, so none of the restrictions imposed on applications distributed through the store that you may have read about apply to your application. Gatekeeper also makes no attempt to ensure the integrity of your application as signing for applet or Web Start deployment does. Instead, it's sole purpose is to indicate that the developer of the application is a known entity.

This means that if you want your application to rely on a shared runtime you can. We still believe bundling the JRE with your application is your best choice, but there is nothing in the OS that forces you to do so. 

'Take advantage of the Java 7 JRE' is pretty broad, so let's break it down with some examples. Keep in mind that by default, Gatekeeper is set to only allow applications downloaded from the OS X App Store or applications from identified developers, so these scenarios are for a user that has just installed Mountain Lion. All of these examples assume your application was built with javafxpackager or the appbundler ant task.

  • If the app is:
    • bundled with Java 7
    • signed with an Apple Developer ID

then the application will launch without any user intervention on 10.7 and 10.8. This combination will give your users the best possible experience.

  • If the app is:
    • NOT bundled with Java 7
    • signed with a Developer ID
    • and the Java runtime is installed

then the same behavior described in the first case applies. Unlike the App Store, there is no restriction on applications relying on third-party installations like Java.

  • If the app is:
    • bundled with a JRE
    • NOT signed with a Developer ID
then Gatekeeper will kick in and block the application from being launched. The user will then have to control-click the application and choose 'Open'. Note that this is no different than if you had built your application with Objective-C/C/C++ -- Java has nothing to do with it.
  • If the app is:
    • NOT bundled with a JRE
    • NOT signed with a Developer ID
    • and the Java runtime is installed
then the same behavior described in the third example applies. 
  • If the app is:
    • NOT bundled with a JRE
    • and the Java runtime is NOT installed

then an alert is shown that directs the user to java.com to get the Java runtime. Signing with a Developer ID won't help you here.

We hope that answers all of your questions about Gatekeeper, but as always, feel free to post your comments and questions. 

Edit: Gatekeeper does not apply to command-line tools like java, javac, javah and so on. When you install the JDK nothing extra needs to be done if you plan to use it to run a server, Maven, or any similar tool.

Comments:

Thanks for this. Once small nit: you don't cover the case where the app is signed, the JRE isn't bundled and the JRE isn't present.

Posted by mo on July 26, 2012 at 05:52 PM PDT #

one other note: java 7 for osx is not available on java.com. probably not the right place to point this out, but i wanted to anyways.

otherwise, thanks!

Posted by guest on July 29, 2012 at 07:57 PM PDT #

Does the codesign utility exist on other platform than MacOS? If yes, where can I find it or how can I reproduce its behaviour? My all build process is automated on a Linux machine and I really don't want to have to play with a MacOS machine.

Posted by guest on September 11, 2012 at 09:50 AM PDT #

I can't seem to reply directly to individual comments, so I'll answer all of these questions here.

If there is no JRE bundled and no JRE is installed the user will be shown an alert telling them that they need to go get a Java runtime. As of this writing, java.com now supports OS X so they will be prompted to download and install the latest runtime.

'codesign' does not exist on any other platform that I'm aware of. I see some questions about it on StackOverflow, but all of them seem to conclude with 'get a Mac Mini'.

Posted by Scott K. on September 18, 2012 at 09:41 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

JoeM

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today