OS X Yosemite still asks to install JRE 6

[thebiguno]

Hello,

I have recently found this project when researching a problem reported by users, that OSX Yosemite will request the install of JRE 6 when running my application. Your script sounds like it would fix things, however I am still seeing the same issue. Digging further, it appears that OS X is intercepting the app bundle execution even before passing control to your script. (To verify this, I added a line 'echo "foo" > "~/bar.txt"', and it doesn't appear when double clicking on the application, but if I run the script directly from the command line, the file appears and the app launches properly).

If I remove the "Java" tag in the Info.plist file, your script is executed (and then complains about a missing main class, as expected). So, it appears to me that OSX is intercepting execution before the JavaApplicationStub is executed, IF there is a "Java" key in the Info.plist.

(For the record, I am using the latest version of JarBundler ant task - 2.3.1 - and it appears to be writing Info.plist in the Apple format. I have installed the latest JRE from Oracle - 8 update 25.)

Have you seen this problem before? Any thoughts on what I can try next? I'm sure that I can get it working by hacking your script plus the Info.plist file, but I would like to keep things as close to normal as possible (for whatever constitutes 'normal' in the ever-changing landscape of Apple / Java relations!)

Any thoughts on this would be greatly appreciated.

Cheers

[thebiguno]

As an update, I did find that if I rename the key "Java" to "JavaX", and then replace every section in your script that refers to key ":Java" with ":JavaX" (i.e. in the section where you find what PList version we are using and where you extract the keys from the Apple version) then it works exactly as it should. So, it is obvious that whatever Mavericks is doing, it is switching on the Java key in Apple formatted Info.plist files to do its thing.

I have my changes integrated into my ant task (I use a 'replace' task to rename the Java key to JavaX, and I have manually changed your script to match), so there is no ongoing maintenance needed. I would consider this to be a successful workaround, as far as 'just getting it done' is concerned. However I would love to hear if others have had this same problem, and how they have resolved it. I can't be alone in this issue, and if there is a better way to do this, I am all ears!

(In case anyone is interested, the project in question that I am doing this for is Buddi - http://buddi.digitalcave.ca/ )

Cheers

[mbtaylor]

@thebiguno, I tried this project out and it didn't work for me - likely I was running into the same problem that you saw. Just to confirm you're not alone! Up till now I haven't found a workaround. I will see if I can get what you suggest working, though it's not easy for me to test stuff since I don't have easy access to any Macs (I'm developing multiplatform code for third parties).

[tofi86]

Wow, thanks for the research, @thebiguno ! I've recently had a bug report with these symptoms, but couldn't reproduce it on Yosemite with Oracle Java 7.

Until now I never had any trouble using my Java stub with Java 7. But if this issue is getting bigger, what possibilities do we have to support both Apple Java 6 and Oracle Java 7/8 with one generic plist file? Another plist structure only for this project / stub file? don't like the idea very much...

I'll definately digg deeper into the stuff in the next couple of weeks. Very busy at the moment.
Solutions and discussion very welcome! 😄

[tofi86]

Note to myself: Feedback from another user with the same issues:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    1.8.0_05, x86_64:   "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home
    1.7.0_51, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home

$ open -a EPUB-Checker
LSOpenURLsWithRole() failed for the application /Applications/EPUB-Checker.app with error -10658.

[RaiMan]

Since I am really happy with this neat solution, because it helped me to bring back the Mac application to my users of SikuliX (http://sikulix.com and https://github.com/RaiMan/SikuliX-2014), I want to talk about my approach, that works with Java 7, 6 and 8 on OS X 10.7 to 10.10.1:

• I started to experiment with the bundlers
• since I create my app from a template with a setup, I do not need them
• I have created an Info.plist based on my experiences with the bundlers and the various relevant docs

This is it:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>en_US</string>
    <key>CFBundleExecutable</key>
    <string>JavaAppLauncher</string>
    <key>CFBundleIconFile</key>
    <string>sikulix.icns</string>
    <key>CFBundleIdentifier</key>
    <string>com.sikulix.SikuliX</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>SikuliX</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleShortVersionString</key>
    <string>1.1.0</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleVersion</key>
    <string>1.1.0</string>
    <key>CFBundleDocumentTypes</key>
    <array>
      <dict>
        <key>CFBundleTypeExtensions</key>
        <array>
          <string>sikuli</string>
          <string>skl</string>
        </array>
        <key>CFBundleTypeIconFile</key>
        <string>sikulixsrc.icns</string>
        <key>CFBundleTypeName</key>
        <string>SikuliX script file</string>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
        <key>LSHandlerRank</key>
        <string>Owner</string>
        <key>LSTypeIsPackage</key>
        <true/>
      </dict>
    </array>
    <key>JVMMainClassName</key>
    <string>org/sikuli/ide/SikuliIDE</string>
    <key>JVMOptions</key>
    <array>
      <string>-Dfile.encoding=UTF-8</string>
      <string>-Dsikulix.asapp</string>
      <string>-Xmx512M</string>
    </array>
    <key>JVMArguments</key>
    <array/>
  </dict>
</plist>

[mbtaylor]

So, yes by avoiding use of the key "Java" it appears to work for all the combinations of OSX and java installations that I've been able to get people to try. I'll probably stick with this, unless I find it's not working in some cases. However if I understand what's going on correctly, using this solution the (renamed) java-specific parts of the Info.plist file aren't doing much useful work - it would probably be cleaner to hard code the details of the java launching code in the "stub" script instead of burying them in the plist file under a custom key and pulling them out again using PlistBuddy.

I'll keep an eye on this project in case a cleaner solution emerges - in any case, thanks for writing something that explains what the application bundle is doing in a way that gives me a chance to work round it!

[thebiguno]

You are probably right that it would be cleaner in a different way; however by renaming Java to JavaX you can keep your existing build scripts the same (in my case, the use of the bundle jar ant task) and just make a single line replacement after the fact. Other than that, there is not really any advantages that I can think of.

[Dylan-M]

From a naive look, this appears to be the exact same issue I solved here. All of the symptoms I encountered matched yours, especially being able to launch from the script via command line but not double clicking the app.

[thebiguno]

Thanks for the comment! However I think that the problem is a bit different... the problem I was experiencing was that the universalJavaApplicationStub program was not even being executed; the OS would just execute the Java program with some default JRE, without referencing my startup program at all. By changing the tag in the .plist file to (or anything other than Java), then the startup script would be executed.

I apologize if I mis-read your issue, though.

Cheers

[Dylan-M]

Well, mine was actually a combination of 2 different issues, the one I linked to, and then also one that Tobias just fixed, but as you say yours does appear to be different. Still, it can't hurt to try a file with both of the fixes for those 2 issues stuck in there. It could be that OSX is doing something funky purely because of the breakage. For example, your echo test I wouldn't consider valid, since I tried the exact same thing and had the exact same result as you, but my fixes "fixed" that as well.

That said, it wouldn't surprise me in the least if Apple did something stupid with Yosemite, since the highest I tested on was Mountain Lion.

[tofi86]

At the moment, I don't have my companies dev mac around with Yosemite and without Java 6, so I'd like you to test the stub file in version 0.8.0 which I released a few minutes ago.

v0.8.0 fixes several issues – one of which is the support for the JVMVersion key which @Dylan-M says would also fix the Yosemite JRE6 issue.
So go, add a JVMVersion key in your Apple style Plist file (with at least 1.6+) and give it a try and report back to me! :)

Cheers,
Tobias

[Dylan-M]

Just for CYA, I hope it fixes it ;)

I haven't yet received any testing results from users of Mavericks or Yosemite on my project though.

[Dylan-M]

And, no sooner did I post the above CYA than I got this response from a user:

Running on Yosemite 10.10.1, Java 8u31
Everything runs smoothly. Thanks for the changes, ralgith!

• GreekFire

[tofi86]

Great! So adding a JVMVersion key

      <key>JVMVersion</key>
      <string>1.6+</string>

and using universalJavaApplicationStub version 0.8.0 should finally fix this. Going to test it tomorrow as well 😎