OS X Yosemite still asks to install JRE 6
thebiguno opened this issue · comments
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
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
@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).
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! 😄
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.
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>
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!
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.
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.
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
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.
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
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.
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
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 😎
Well, In my case, on my companies dev machine, the java 7 installation isn't listed in /usr/libexec/java_home -V at all! Therefore the solution to add JVMVersion key and using v0.8.0 doesn't help for me.
If I run the script on the commandlien, the else fallback is used and my apps work well, but starting by double clicking the app icon still fails with the old "JRE 6" message.
Renaming the Plist key Java to something else seems to be the only solution at the moment which works well...
Well, that's odd... something went wonky with your install of /usr/libexec/java_home doesn't list it at all. Maybe installed as a "per user" thing, rather than system wide?
Yep, that's weird....
Installed both JRE 7 and JRE 8 now, but I'm not able to install both versions parallel and neither of them creates an entry in /usr/libexec/java_home. Installed for all users on this machine - this is the only option provided by the Oracle JRE installer. My System is Yosemite 10.10 without(!) Apple Java 6 installed...
At http://apple.stackexchange.com/a/160216 they say, this is because /usr/libexec/java_home only searches for JVM's at the "old" location, not at the new Oracle location.
On the other hand I have Mac systems with Apple JRE 6 and Oracle JRE 7 where both versions are listed in /usr/libexec/java_home... So odd...
Alright, so I installed the JDK 8 now in a last attempt to solve this issue, and here we go:
iMac:~ pagina$ /usr/libexec/java_home -V
Matching Java Virtual Machines (1):
1.8.0_31, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home
However, no "normal" user would install the JDK - they will get pointed to the JRE by Oracle...
Also, this JVM get's picked up by the universalJavaApplicationStub v0.8.0 and can be used to start the application via command line.
However, opening the app by the normal way still fails.
So this issue really seems to be related a 100% to the Java Plist key!
Why o why, Apple... 😞
Actually, per Oracle's own documentation you have to install the JDK for anything other than web usage. That explains a lot though.
Actually, per Oracle's own documentation you have to install the JDK for anything other than web usage. That explains a lot though.
Yes, it does... But most people will only install Java from java.com, so using the standard JRE... :-/
Also, the JDK isn't solving the "old Java 6" problem Apple is fooling us with...
Well, don't even get me started on Apple dropping official support for Java and all the issues that has caused... I don't think you want a half informed tirade [half cause I develop for Apple, but don't own one]
Same thing here. universalJavaApplicationStub runs ok from the command line, but double clicking brings up the pesky "Install Java 6". Only VM installed is Oracle 1.8.31.
Are you guys trying to latest official code? Cause regarding aleth's comment, it should be JVMVersion, not JMVersion. The easiest way to get the correct functionality is to use the latest code instead of hand editing your own. This will prevent simple mistakes such as typos and the like.
Yes, I am using the latest code.
@aleth Okay, your post-reboot functionality is what should be happening for the issue with the current code. Thanks.
@aleth Umm, yeah, you're suppsed to be using 1.7+, not 1.6+. Obviously it'll look for a 1.6 JVM if you tell it that's what version you want.
1.6+ should actually match ANY JVM higher than or equal to 1.6 listed in /usr/libexec/java_home, shouldn't it?
That can't be the problem...
@tofi86 It should, but obviously doesn't. I haven't yet figured out why. It's... flaky. Of course, it should really be your_min_version+ anyway. So if you compile against 1.6, then yes, 1.6 is appropriate I guess. Except for not working right in the detection of course.
@aleth: what does /usr/libexec/java_home -V (capital V) print out in your case?
And what is the result for
/usr/libexec/java_home -v 1.6+
And for
/usr/libexec/java_home -v 1.7+
@aleth I'm guessing you've only installed the "JVM", you have to install the "JDK" for full functionality. As @tofi86 and I discussed above. Only the JDKs include full versions. The Oracle JVMs for Mac only include the "browser plugin" version. And while it'll run Java programs, it doesn't get picked up by Mac correctly.
Not entirely true, Dylan.
The Internet plugin should get picked up by my stub file.
But I think a bug in v0.8.0 prevents it to be picked up in this special case when there are no entries in /usr/libexec/java_home but a JVMVersion string is found...
Will be fixed tomorrow or soon... ;-)
@aleth: alright, this issue should be fixed now in v0.8.1 please test and post a short feedback.
However, this still doesn't solve the nasty "install JRE 6" Apple "bug"...
I'm trying to use this on Yosemite with Oracle JDK 1.8.0_40 stub 0.8.1, and get the "install JRE 6" when launching the app using Finder. When launching from a terminal it works. Seems like the stub is not executed?
Edit: I was using jarbundler.
I too have the same issue with 1.8. I've read the entire thread and still don't know if there is a resolution or not. If so could someone distill this for me.
If you follow my instructions in the second post from this thread, it should work (it does for me and all my users, at least). I don't know if the author has any definite fixes (there seem to be some that say it works with the new version, while others are still having problems). I have not had time to re-investigate the issue, and I have not heard of any users for which my workaround does not fix the issue, so I have no urgency to look into it further.
I realize this is not a definitive post, but I can only say what has worked for my and my software.
Cheers
I'm using jarbundler. How do I get it to output JavaX to the plist file?
I use ant with a 'replace' tag after the Info.plist file is created. See http://git.digitalcave.ca/gitweb/?p=java/ca.digitalcave.buddi.git;a=blob;f=build.xml;h=ded5de33dafcadb2aa517ee57a0eb9ee426d7cd7;hb=HEAD line 149-152 for my ant script.
Cheers
No solution yet within the scope of this project...
Probably I should take the time and create another fork of the jarbundler project for creating JavaX-Keys. However, I'm still struggling a little bit with this solution as we're creating our own environment again instead of being able to use the "standards"... Though the standards don't work, yeah, I know... :-/
IMHO forking jar bundler is not worthwhile... it is a four line addition to an ant script to do this automatically. Does anyone not use ant (or some other automated build script) these days?
I do agree that it would be nice if we didn't need to do this at all, but Apple seems to have effectively prevented that from happening :-(
Alright, this journey finally has come to an end!
Today, I forked Informagens jarbundler (once again) and added an optional boolean argument useJavaXKey. If set to true, the Java dictionary key will no longer be named Java but JavaX.
Example:
<jarbundler
...
stubfile="universalJavaApplicationStub"
usejavaxkey="true"
...
>
You can download the package here: https://github.com/tofi86/Jarbundler/releases/tag/v2.4.0
I also had to change the universalJavaApplicationStub to support the JavaX Plist key, so you have to check out the latest version 0.9 to use it with JarBundler 2.4
Have fun! 😎
Hi,
Tried universalJavaApplicationStub for the first time today after upgrading to 10.11.1 - El Capitan. Seeing the same sort of things. Am not using JarBundler or AppBundler, just plain old javac and jar. As Apple seems to have my app wedged too, thought I'd contribute what I'm seeing in hopes that there's a solution.
Using universalJavaApplicationStub v1.0.1, 2015.11.2
For a check, I have universalJavaApplicationStub printing a "running..." line to a file when it is executed - it's never being called when starting the app via 2x-click.
In all instances below:
Am using Apple Info.plist containing:
<key>JavaX</key>
With only JRE8 installed:
Running /usr/libexec/java_home shows no java.
Running universalJavaApplicationStub via CLI - the app runs as an OS X app.
2x-clicking the App/icon prompts for the legacy Apple Java 6.
With JRE8 and JDK8 installed:
Running /usr/libexec/java_home shows /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home
2x-clicking the App/icon prompts for the legacy Apple Java 6.
Advice/suggestions are greatly appreciated. Thanks.
Working fine for me on El Capitan.
Can you post your full Info.plist file?
Sure! Thanks for asking/helping.
<?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>English</string>
<key>CFBundleExecutable</key>
<string>universalJavaApplicationStub</string>
<key>CFBundleIdentifier</key>
<string>com.mydomain.myapp</string>
<key>CFBundleName</key>
<string>myapp</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleIconFile</key>
<string>myapp</string>
<key>JavaX</key>
<dict>
<key>ClassPath</key>
<array>
<string>$JAVAROOT/myapp.jar</string>
</array>
<key>JVMVersion</key>
<string>1.6+</string>
<key>MainClass</key>
<string>com.mydomain.myapp.Main</string>
<key>SplashFile</key>
<string>$JAVAROOT/myapp.png</string>
<key>Properties</key>
<dict>
<key>apple.laf.useScreenMenuBar</key>
<string>true</string>
</dict>
<key>WorkingDirectory</key>
<string>$APP_PACKAGE/Contents/Resources/Java</string>
</dict>
<key>LSHasLocalizedDisplayName</key>
<true/>
<key>NSHumanReadableCopyright</key>
<string>Copyright (C) 2009-2015 My Name, All Rights Reserved.</string>
</dict>
</plist>
Perhaps your issue is this? :)
JVMVersion
1.6+
Can you post the terminal output of the following four commands, please?
/usr/libexec/java_home -V
/usr/libexec/java_home -v 1.6+
/Library/Java/Home/bin/java -version
/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
@Dylan-M wrote:
Perhaps your issue is this? :)
JVMVersion
1.6+
This shouldn't be a problem if Java 6 or higher is installed. /usr/libexec/java_home -v 1.6+ should always pick up the highest matching JVM available.
Absolutely. Thanks for the help!
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (1):
1.8.0_65, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home
$ /usr/libexec/java_home -v 1.6+
/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home
$ /Library/Java/Home/bin/java -version
-bash: /Library/Java/Home/bin/java: No such file or directory
$ /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
and FWIW:
$ ls /Library/Java/
Extensions JavaVirtualMachines
I cannot find an error in your configuration. This should work fine.
Is the universalJavaApplicationStub file marked as executable?
Is there a console output when you run the stub like this?
$ cd your/app/directory/
$ ./myapp.app/Contents/MacOS/universalJavaApplicationStub
Thank you for confirming the configuration. Yes, the universalJavaApplicationStub is executable. Executing as you indicated resulted in a repeatable system error. The error produced a report that kept pointing to the same area of memory, and gave other indicators that online articles indicated that the memory was suspect. I've Amazoned a #00 phillips screwdriver, and when it arrives I'll see if there is removable RAM that can be swapped / re-seated.
In the meantime, I created a smaller/simpler jar file, and swapped out the larger failing one with the smaller one - and the smaller one starts every time using universalJavaApplicationStub by 2x clicking the application.
Also, I managed to print out to the console the "Java startup command" that universalJavaApplicationStub was executing. Manually executing that exact command, the larger (failing) application started up perfectly. So, another confirmation point that universalJavaApplicationStub is working just fine.
Sadly, I ended up breaking Apple's Java symlinks and other Java magic, enough to the point that this machine is also going to need to be re-imaged.
Tobias, thank you very much for creating universalJavaApplicationStub, and also for supporting those of us who want to use it.
@fubar4 In the future you may want to manage installed versions of Java on Mac using Homebrew + Jenv. In fact, you probably could salvage the existing install by doing this, I know I did.
http://www.codingricky.com/jenv/
Homebrew is a wonderful tool in general, especially for someone like me who is primarily a Linux user and only does a Mac for testing purposes and currently also at work.
@Dylan-M Thanks for those tips. Yes, installing Homebrew was the familiar Linux environment. Jenv didn't help in the present state, as I was unable to add the JDK. That problem is probably addressed below.
@tofi86 After a warm reinstall (reboot, Command-R), the CLI execution of universalJavaApplicationStub produced the exact same error... but, 2x clicking the application started the app using the 1.8 JDK/JRE - and that's what I hoped for. Further, after installing the "Java for OS X" (which added both i386 and x86_64 versions), 2x clicking continued to run the app with the 1.8 JRE. Looks like my system was fubar after all... :)
glad to hear that it's working now for you... :)
Hello, I'm experiencing the same issue of fubar4 :( I had a clean install of El Capitan, without any JRE installed. I downloaded and installed official Oracle JRE 8, but when I double click the app icon, the OS keeps asking me to install Legacy Apple Java 6. My app requires Java 1.7+. I'm available for any further explanation. Thank you for your work!
@albertus82 Is that using the latest version of this script? Since updating from 0.7.0 to 1.0.1, I've not had any issues that are the fault of the script. I have however had some issues with my packaging routines.
@Dylan-M I'm using the last "master" version of the script. I just tried the "develop" version with no luck.
Alberto, my understanding is that there is an Apple binary that always
prompts for the Apple Java, regardless - it is sym-linked from
/usr/bin/java. So, the legacy Apple Java is required, but by specifying
1.7+, the Apple Java 6 won't be used by your app.
-Brett
On Oct 10, 2016 4:44 AM, "Alberto" notifications@github.com wrote:
I'm using last "master" version of the script. I just tried the "develop"
version with no luck.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzO3u2XkjOXHQ0GlplONA2zyFgaEJks5qyhcJgaJpZM4DN7mF
.
@fubar4 Not at all true. I don't have Apple Java installed anywhere on either of my Macs, and all of this works just fine.
@fubar4 @Dylan-M Thank you. I installed Legacy Java 6 and I saw the stub error "No suitable Java version found on your system!" (my app requires 1.7+); consequently I installed JRE 1.8.0_101 and now the application starts fine using universalJavaApplicationStub 1.0.1 (master version). It seems so stupid to have to install the Legacy version, but I don't understand if there's a way to avoid it.
I have a feeling this is related to one of my previous posts: The Oracle JRE for OSX is only intended to be used as a browser plugin. To have full Oracle support on OSX you need to install the JDK instead. It's dumb, but since I'm a developer I have it anyway. I don't see any of the issues you're describing, and I don't have Apple java in any form on my machine.
I restored a clean El Capitan installation and installed only JDK 1.8.0_101, but when I click on the app icon I got always the OS X message that ask me to install Legacy Java 6. I noted that if I launch manually the stub from bash, the application starts. I think that when OS X sees <key>Java</key> in Info.plist or something similar, it opens that modal automatically.
Alberto, You are not alone. I am seeing the same from clean installs of
both El Capitan and Sierra. Though I'm not convinced this is true, the
behavior is as if something is executing /usr/bin/java, which then
prompts for the Apple Java (legacy JDK 1.6).
-Brett
On Mon, Oct 10, 2016 at 7:26 AM, Alberto notifications@github.com wrote:
I restored a clean El Capitan installation and installed only JDK
1.8.0_101, but when I click on the app icon I got always the OS X message
that ask me to install Legacy Java 6. I noted that if I launch manually the
stub from bash, the application starts. I think that when OS X sees
Java in info.plist, opens that modal automatically.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzMAyp7EZnfeZUkuTrMELPZUcoh-sks5qyj0XgaJpZM4DN7mF
.
You've both missed a key instruction if you're still using the Java key.
From the Readme:
Apple prompts for JRE 6 download even before the JavaApplicationStub is executed. This is why we can't intercept at this level and need to replace the Java dictionary by a JavaX dictionary key.
And also from the readme:
<jarbundler
name="Your-App"
shortname="Your Application"
icon="${resources.dir}/icon.icns"
stubfile="${resources.dir}/universalJavaApplicationStub"
useJavaXKey="true"
... >
I downloaded and installed official Oracle JRE 8, but when I double click the app icon, the OS keeps asking me to install Legacy Apple Java 6.
@Dylan-M was a bit faster than me and is absolutely right: When you use the "old" <key>Java</key> OS X will always prompt for legacy Java 6.
You need to use the <key>JavaX</key> e.g. with the new JarBundler version from https://github.com/UltraMixer/JarBundler or you will have to use the Oracle AppBundler to package your app.
As a test, you can manually change the Java key to JavaX in your program's plist to see if it works.
Also, @tofi86: If I haven't thanked you lately, this is me doing so ;) You've made life considerably easier when it comes to OSX packaging.
@Dylan-M: Thanks a lot! Really appreciate your feedback :-)
Also stay tuned for version 1.1 which brings localization of error messages, a better search algorithm for specified Java versions, better support for Oracle JRE plugin 1.8.0_101, etc..
Thank you a lot! Solved adding usejavaxkey="true" in my ant <jarbundler>. I'm sorry for missing that instruction.
@fubar4 probably you can solve in the same manner.
@tofi86 I look forward to the next version; you did a great job, thank you again!
Clearly I've been doing something wrong. I think it is this:
You need to use the JavaX e.g. with the new JarBundler version
from https://github.com/UltraMixer/JarBundler or you will have to use the
Oracle AppBundler to package your app.
I'm not using either the JarBundler or AppBundler. Instead, I have an
Apple PLIST that includes both "JavaX</key" and
"usejavaxkey".
What's special about the bundlers that makes them necessary?
-Brett
On Mon, Oct 10, 2016 at 8:19 AM, Alberto notifications@github.com wrote:
Thank you a lot! Solved adding usejavaxkey="true" in my ant .
I'm sorry for missing that instruction.
@fubar4 https://github.com/fubar4 probably you can solve in the same
manner.
@tofi86 https://github.com/tofi86 I look forward to the next version;
you did a great job, thank you again!—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzE13fHdZe3CD4zm4wOGetFtutYCkks5qyklygaJpZM4DN7mF
.
@fubar4 Well, for one it makes sure to include everything the plist should have. But, I was just using a manually created app until recently. It's all a matter of structure. If you structure it correctly, then it'll work. If you don't... it won't work correctly.
@fubar4 This is my working Info.plist file:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<plist version="1.0">
<dict>
<key>CFBundleName</key>
<string>Earthquake Bulletin</string>
<key>CFBundleShortVersionString</key>
<string>1.0.0</string>
<key>CFBundleAllowMixedLocalizations</key>
<string>false</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleExecutable</key>
<string>universalJavaApplicationStub</string>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleIconFile</key>
<string>earthquake-bulletin.icns</string>
<key>JavaX</key>
<dict>
<key>MainClass</key>
<string>it.albertus.earthquake.EarthquakeBulletin</string>
<key>JVMVersion</key>
<string>1.7+</string>
<key>ClassPath</key>
<array>
<string>$JAVAROOT/earthquake-bulletin.jar</string>
<string>$JAVAROOT/lib\jface-utils-6.0.0.jar</string>
<string>$JAVAROOT/lib\org.eclipse.core.commands_3.7.0.v20150422-0725.jar</string>
<string>$JAVAROOT/lib\org.eclipse.core.jobs_3.7.0.v20150330-2103.jar</string>
<string>$JAVAROOT/lib\org.eclipse.equinox.common_3.7.0.v20150402-1709.jar</string>
<string>$JAVAROOT/lib\org.eclipse.jface_3.11.1.v20160128-1644.jar</string>
<string>$JAVAROOT/lib\org.eclipse.osgi_3.10.102.v20160118-1700.jar</string>
<string>$JAVAROOT/lib\org.eclipse.paho.client.mqttv3-1.1.0.jar</string>
<string>$JAVAROOT/lib\swt-4.5.2-cocoa-macosx-x86_64.jar</string>
</array>
<key>VMOptions</key>
<string>-Xms8m -Xmx32m</string>
<key>StartOnMainThread</key>
<true/>
</dict>
</dict>
</plist>@fubar4 of course you don't have to use one of the bundlers and instead build the Plist file manually.
However, make sure that the structure is in compliance with the JarBundler standard (old Apple standard) or the Oracle standard.
To solve the nasty java 6 dialog, make sure you use the JavaX key!
If you still think that it should work but it doesn't, please post the content of your Plist file here.
Yeah, the only issue I'm having now is getting the "Working Directory" to be set correctly via the PList. Everything else works using JarBundler 3.3.0, including solving every issue referenced in this thread.
@fubar4 looks quite right. and what's the terminal output of /usr/libexec/java_home -V on your system?
@tofi86 That PList was from @albertus82 not @fubar4 heh
confusion... 😕
sorry, then...
Still, for further investigation, please send the contents of your Info.plist file and the terminal output of command /usr/libexec/java_home -V, @fubar4 :)
Interestingly, I posted them both last November.
@Dylan-M seems to be right then (mentioning 1.8+) and now, so I'm guessing
that the suggestion that my Info.plist is fubar is probably correct. :)
$> plutil Info.plist
Info.plist: OK
It looks OK above, but that command was run using a plist without a
"usejavaxkey" key (I don't know if it needs one). The application runs
using JRE 8, but it requires the Apple JDK 6 to be installed. See anything
wrong?
-Brett
-Brett
On Mon, Oct 10, 2016 at 11:16 AM, Tobias Fischer notifications@github.com
wrote:
confusion... 😕
sorry, then...Still, for further investigation, please send the contents of your
Info.plist file and the terminal output of command /usr/libexec/java_home
-V, @fubar4 https://github.com/fubar4 :)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzKUuo3EgKCuTRy_1fWLDmfwfCcs2ks5qynMAgaJpZM4DN7mF
.
Sorry, a difference in what I see today:
brett@mac:~$ find / -type f -name java 2>/dev/null
/Applications/Xcode.app/Contents/Applications/Application
Loader.app/Contents/itms/java/bin/java
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java
/usr/share/file/magic/java
brett@mac:~$ /usr/libexec/java_home -V
Unable to find any JVMs matching version "(null)".
Matching Java Virtual Machines (0):
Default Java Virtual Machines (0):
No Java runtime present, try --request to install.
On Mon, Oct 10, 2016 at 12:00 PM, Brett Lee brettlee.ca@gmail.com wrote:
Interestingly, I posted them both last November.
https://github.com/tofi86/universalJavaApplicationStub/
issues/9#issuecomment-156871570@Dylan-M seems to be right then (mentioning 1.8+) and now, so I'm guessing
that the suggestion that my Info.plist is fubar is probably correct. :)$> plutil Info.plist
Info.plist: OKIt looks OK above, but that command was run using a plist without a
"usejavaxkey" key (I don't know if it needs one). The application runs
using JRE 8, but it requires the Apple JDK 6 to be installed. See anything
wrong?-Brett
-Brett
On Mon, Oct 10, 2016 at 11:16 AM, Tobias Fischer <notifications@github.com
wrote:
confusion... 😕
sorry, then...Still, for further investigation, please send the contents of your
Info.plist file and the terminal output of command /usr/libexec/java_home
-V, @fubar4 https://github.com/fubar4 :)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzKUuo3EgKCuTRy_1fWLDmfwfCcs2ks5qynMAgaJpZM4DN7mF
.
@fubar4 "usejavaxkey" isn't a part of the plist, it's an instruction to AppBundler or JarBundler to use this (Note the JavaX, if that's just Java in your file it'll ask to use Apple Java 1.6):
<key>JavaX</key>
<dict>
<key>MainClass</key>
<string>it.albertus.earthquake.EarthquakeBulletin</string>
<key>JVMVersion</key>
<string>1.7+</string>
<key>ClassPath</key>
<array>
<string>$JAVAROOT/earthquake-bulletin.jar</string>
<string>$JAVAROOT/lib\jface-utils-6.0.0.jar</string>
<string>$JAVAROOT/lib\org.eclipse.core.commands_3.7.0.v20150422-0725.jar</string>
<string>$JAVAROOT/lib\org.eclipse.core.jobs_3.7.0.v20150330-2103.jar</string>
<string>$JAVAROOT/lib\org.eclipse.equinox.common_3.7.0.v20150402-1709.jar</string>
<string>$JAVAROOT/lib\org.eclipse.jface_3.11.1.v20160128-1644.jar</string>
<string>$JAVAROOT/lib\org.eclipse.osgi_3.10.102.v20160118-1700.jar</string>
<string>$JAVAROOT/lib\org.eclipse.paho.client.mqttv3-1.1.0.jar</string>
<string>$JAVAROOT/lib\swt-4.5.2-cocoa-macosx-x86_64.jar</string>
</array>
<key>VMOptions</key>
<string>-Xms8m -Xmx32m</string>
<key>StartOnMainThread</key>
<true/>
</dict>@Dylan-M Thanks so much for your confirmation that the use of "usejavaxkey"
is only in the bundlers. Am still thinking something is wrong with the
plist I posted.
Interestingly, when I run this command, I see the application start up
perfectly with a 1.8 JVM:
$ ./Contents/MacOS/universalJavaApplicationStub
Unable to find any JVMs matching version "1.8+".
But the output (above) has me a bit confused.
Attempting to start the same instance of the application by 2x clicking the
application continues to prompt for the Apple Java 6. Until earlier today,
I thought that prompt was the expected behavior - nice to know there's a
way not to have to install the legacy Java - but what is it...?
-Brett
On Mon, Oct 10, 2016 at 12:25 PM, Dylan Myers notifications@github.com
wrote:
@fubar4 https://github.com/fubar4 "usejavaxkey" isn't a part of the
plist, it's an instruction to AppBundler or JarBundler to use this (Note
the JavaX, if that's just Java in your file it'll ask to use Apple Java
1.6):
JavaX
MainClass
it.albertus.earthquake.EarthquakeBulletin
JVMVersion
1.7+
ClassPath
$JAVAROOT/earthquake-bulletin.jar
$JAVAROOT/lib\jface-utils-6.0.0.jar
$JAVAROOT/lib\org.eclipse.core.commands_3.7.0.
v20150422-0725.jar
$JAVAROOT/lib\org.eclipse.core.jobs_3.7.0.
v20150330-2103.jar
$JAVAROOT/lib\org.eclipse.equinox.common_3.7.0.
v20150402-1709.jar
$JAVAROOT/lib\org.eclipse.jface_3.11.1.v20160128-1644.jar
$JAVAROOT/lib\org.eclipse.osgi_3.10.102.
v20160118-1700.jar
$JAVAROOT/lib\org.eclipse.paho.client.mqttv3-1.1.0.jar
$JAVAROOT/lib\swt-4.5.2-cocoa-macosx-x86_64.jar
VMOptions
-Xms8m -Xmx32m
StartOnMainThread
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzGwW4YkuoPVdakf3O-IUG8Q66irJks5qyoM1gaJpZM4DN7mF
.
@albertus82 - Sorry for missing it - just saw that you had posted a full
Info.plist. Thank you for posting. I made minor edits so that my app
would start, and alas, it still prompted me for Java 6. Still, am very
glad to hear you have it working well for you.
-Brett
On Mon, Oct 10, 2016 at 11:00 AM, Alberto notifications@github.com wrote:
@fubar4 https://github.com/fubar4 This is my working Info.plist file:
CFBundleName Earthquake Bulletin CFBundleShortVersionString 1.0.0 CFBundleAllowMixedLocalizations false CFBundleInfoDictionaryVersion 6.0 CFBundleExecutable universalJavaApplicationStub CFBundleDevelopmentRegion English CFBundlePackageType APPL CFBundleSignature ???? CFBundleIconFile earthquake-bulletin.icns JavaX MainClass it.albertus.earthquake.EarthquakeBulletin JVMVersion 1.7+ ClassPath $JAVAROOT/earthquake-bulletin.jar $JAVAROOT/lib\jface-utils-6.0.0.jar $JAVAROOT/lib\org.eclipse.core.commands_3.7.0.v20150422-0725.jar $JAVAROOT/lib\org.eclipse.core.jobs_3.7.0.v20150330-2103.jar $JAVAROOT/lib\org.eclipse.equinox.common_3.7.0.v20150402-1709.jar $JAVAROOT/lib\org.eclipse.jface_3.11.1.v20160128-1644.jar $JAVAROOT/lib\org.eclipse.osgi_3.10.102.v20160118-1700.jar $JAVAROOT/lib\org.eclipse.paho.client.mqttv3-1.1.0.jar $JAVAROOT/lib\swt-4.5.2-cocoa-macosx-x86_64.jar VMOptions -Xms8m -Xmx32m StartOnMainThread—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzLYSrk1OqYp__Uf6xKxIQoYncDhnks5qym8pgaJpZM4DN7mF
.
@fubar4 At first I couldn't reproduce the issue on my Mac (macOS 10.11 "Sierra"). But then I did some tests with an existing demo app of mine which contained the Java key instead of the JavaX key which triggered the Java 6 dialog. Then I changed the Info.plist file to use the JavaX key and tried running the app again. It failed with the java 6 dialog. This seemed to me like a caching issue with Finder app on Sierra so I renamed the demo app and ran it again with no further changes: App started without any problems...
Can you ty and rename your demo app to exclude caching issues as the root of your problems? Thanks.
Also, for future reference, you can clear all cached data about an app using this command:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /<App Path>/AppName.app
Or, clear all data for your entire app cache using this command:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
Yes, I know my Power User is showing, but I'm hoping this helps others ;)
Hi Tobias, I really appreciate you taking some time to look into this.
Thank you.
I renamed the application and saw the same result - the dreaded prompt for
Apple Java 6. Next, I renamed just the Jar, and started it this time from
the command line; again, the same (dreaded) result. To me, it sure seems
unrelated to universalJavaApplicationStub. Two things that I don't think
should be the problem, but seem worthy of mention, are that I'm compiling
with Java 6, and I'm using code from com.apple.eawt.*.
-Brett
On Tue, Oct 11, 2016 at 10:42 AM, Tobias Fischer notifications@github.com
wrote:
@fubar4 https://github.com/fubar4 At first I couldn't reproduce the
issue on my Mac (macOS 10.11 "Sierra"). But then I did some tests with an
existing demo app of mine which contained the Java key instead of the
JavaX key which triggered the Java 6 dialog. Then I changed the Info.plist
file to use the JavaX key and tried running the app again. It failed with
the java 6 dialog. This seemed to me like a caching issue with Finder app
on Sierra so I renamed the demo app and ran it again with no further
changes: App started without any problems...Can you ty and rename your demo app to exclude caching issues as the root
of your problems? Thanks.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzCWCbaboxVebJ8ZMagyy8shz6Lkrks5qy7xtgaJpZM4DN7mF
.
Having since written that "com.apple.eawt." was not the problem, I'm now
(pretty much) convinced that it *IS the driving factor of why OS X is
demanding the Apple Java 6 install - the required libraries are available
through Apple Java, but to a much lesser degree elsewhere... If this is
true, I now think it is pretty smart to prompt for them. So, I'm of the
mind that universalJavaApplicationStub is not causing any problems, but
instead it is providing Apple OS's with newer Java releases, which is a
great thing to have!
@tofi86 - Adding to what @Dylan-M wrote, I would also like to that you for
your work with universalJavaApplicationStub. So... Thank You !! Without
your work, well, I don't even want to think about it. :)
@Dylan-M https://github.com/Dylan-M - Thank you also for your helpfulness
on this list. Much appreciated!
The application is available at https://www.trustpds.com
On Mon, Oct 10, 2016 at 7:58 AM, Dylan Myers notifications@github.com
wrote:
As a test, you can manually change the Java key to JavaX in your program's
plist to see if it works.Also, @tofi86 https://github.com/tofi86: If I haven't thanked you
lately, this is me doing so ;) You've made life considerably easier when it
comes to OSX packaging.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIBzCT-oqFDwjUB46nxNREV8Be078JKks5qykSGgaJpZM4DN7mF
.