.app won't start

[Former user]

Original issue 386 created by johanneswies... on 2014-01-28T09:55:01.000Z:

What steps will reproduce the problem?

1. Use a Mac with Mac OS 10.9.1 and Java Standard Edition Version 7 Update 51 (Build 1.7.0_51-b13)
2. Download Okapi version okapi-apps_cocoa-macosx-x86_64_0.24.zip at https://bintray.com/okapi/Distribution/Okapi_Applications
3. Unzip file and place the resulting folder into your programs folder on your Mac
4. Double click Rainbow (make sure you have decreased your security to allow installation of programs from unverified developers).
   => The Rainbow icon will show up for a second in Mac OSs Doc and then vanishes - no way to start the app.

What is the expected output? What do you see instead?
I would like to run Rainbow

What version of the product are you using? On what operating system?
okapi-apps_cocoa-macosx-x86_64_0.24
Mac with Mac OS 10.9.1
Java Standard Edition Version 7 Update 51 (Build 1.7.0_51-b13)

Please provide any additional information below.

[Former user]

Comment 1. originally posted by @ysavourel on 2014-01-28T20:50:28.000Z:

Open a terminal window and try running the following:
/Applications/okapi-apps_cocoa-macosx-x86_64_0.24/Rainbow.app/Contents/MacOS/rainbow.sh

Do you get any output in the console? If so, paste it in.

[Former user]

Comment 2. originally posted by johanneswies... on 2014-01-28T21:17:52.000Z:

Hi,
thanks so much for your response. Please find the output at the end of this message.
I have also tested it with version M23 and this works fine: both double clicking on the Rainbow App icon as well as running the shell script will run the app as expected.
Do let me know if you need further info.
Thanks again for your help!
______________________________________________________________
Last login: Tue Jan 28 22:01:11 on ttys000
johannes:~ johanneswiesheu$ /Applications/okapi-apps_cocoa-macosx-x86_64_0.24/Rainbow.app/Contents/MacOS/rainbow.sh
Exception in thread "Thread-1" java.lang.UnsupportedClassVersionError: net/sf/okapi/applications/rainbow/Main : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
johannes:~ johanneswiesheu$ /Applications/okapi-apps_cocoa-macosx-x86_64_0.23/Rainbow.app/Contents/MacOS/rainbow.sh
johannes:~ johanneswiesheu$

[Former user]

Comment 3. originally posted by @ysavourel on 2014-01-28T21:53:07.000Z:

Ok, it looks like even though you have Java 1.7 installed, your system is still trying to use Java 1.6. You can confirm this by typing "java -version" in your terminal window.

I believe the right way to fix this is to open the Java Control Panel (in System Preferences), click on the "Java" tab, click the "View" button, and then make sure that Java 1.7 is selected as the runtime environment.

[Former user]

Comment 4. originally posted by johanneswies... on 2014-01-29T09:50:28.000Z:

You are quite right.

java -version returns:
Last login: Tue Jan 28 22:06:06 on ttys000
Johannes:~ johanneswiesheu$ java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
Johannes:~ johanneswiesheu$

See screen attached to see what the Java Preference pane displays. Same thing when querying Java in Terminal:

Johannes:~ johanneswiesheu$ /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Johannes:~ johanneswiesheu$

It believe this is related to Mac OS Mavericks which somehow sticks to the older Java version (maintained by Apple).

[Former user]

Comment 5. originally posted by @ysavourel on 2014-01-29T17:51:37.000Z:

The situation with Java on the Mac is a mess right now. I think if you're like me, you'll find that the old Java 1.6 is in /Library/Java/Home/, while Java 1.7 is in /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home. /Library/Java/Home is actually a symlink to /System/Library/Frameworks/JavaVM.framework/Home or something similar.

I don't exactly remember how I fixed this -- my environment is a little funny because of my development work. I believe I ended up setting JAVA_HOME in my ~/.bash_profile to point to Java 1.7, and then updating my path to use that. However, there may have been another step.

[Former user]

Comment 6. originally posted by @ysavourel on 2014-01-29T21:47:12.000Z:

Maybe some info on the posts linked below can help:
https://groups.google.com/forum/#!topic/mac-for-translators/xcIQ-zm-aEM

[Former user]

Comment 7. originally posted by @ysavourel on 2014-01-29T22:58:20.000Z:

I think one outcome of this issue should be to document the Java procedure on the mac somewhere on the wiki. I suspect a lot of Mac users will have trouble with upgrade issues, because it's not obvious what is going wrong. I was talking to Kevin and found out he had never actually installed the M24 tools -- he had tried it briefly, run into the same issue, and then put it aside.

[Former user]

Comment 8. originally posted by @ysavourel on 2014-01-30T10:14:01.000Z:

+1 in documenting this in the wiki (and in the readme).
But is there a working solution?

[Former user]

Comment 9. originally posted by paolo.tramann... on 2014-06-18T10:11:15.000Z:

I have the same issue with Mac Mountain Lion (10.8.5). The Java preference pane shows v1.7.0_60 is installed, while the Terminal says it is v1.6.0_65.

Do you suggest to install Java v1.8? Or, is it a way to force Rainbow to use v1.7 instead of 1.6 by changing something in some preference list?

Paolo

[Former user]

Comment 10. originally posted by @ysavourel on 2014-06-18T10:32:07.000Z:

I'm no Mac user, so I don't know for sure how this works, but I think you can have several version of Java installed and decide which one to use.

Maybe this article may help:
https://groups.google.com/forum/#!topic/mac-for-translators/C0ALu6Qs6Bk

[Former user]

Comment 11. originally posted by paolo.tramann... on 2014-06-18T13:45:29.000Z:

Yves, thank you very much for your hints. By reading the post you linked, it seems the standard Oracle installer for Java 8 only installed the internet plugin in my system. The same did the beta installer for Java JRE 8. I could not find and log explaining why.

I'll try with the beta installer for Java 8 JDK, and see what happens.

[Former user]

Comment 12. originally posted by paolo.tramann... on 2014-06-18T14:09:31.000Z:

I see the issue with Java > 6 is a recurring and unresolved issue on the Mac. Sounds like a forbidden technology on the Mac. So, I have a dumb question: is there a way to let the Okapi Framework run on Java VM 6?

[Former user]

Comment 13. originally posted by @ysavourel on 2014-06-18T14:34:02.000Z:

You can run any version of the Okapi tools before M24 with Java 6.

We switched to Java 7 because various reasons, one main among them being that Java 6 is not supported anymore since a while (e.g. no more security updates).

[Former user]

Comment 14. originally posted by paolo.tramann... on 2014-06-18T20:19:07.000Z:

Thank you. Probably, Mac users should use version M23, and continue looking for a solution for Java from Oracle and Apple.

[Former user]

Comment 15. originally posted by [e-mail] on 2014-07-18T09:54:42.000Z:

Did someone have a look at Java behavior under the upcoming Mac OS 10.10 (Yosemite)?

[Former user]

Comment 16. originally posted by @ysavourel on 2014-07-31T23:42:03.000Z:

I've been looking into this recently. It is definitely possible to get M24+ to run with Java 1.7 on a Mac, because I've done it. But my machine configuration is a bit eccentric from all the developer stuff on it (including 4 or 5 different versions of Java), so I'm not exactly sure what I've done, and I need to mess around with some other machines with regular installs to work out the right set of steps.

Based on what Rainbow shows in the About menu when I show it, it looks like it's pulling the JVM from /usr/libexec/java_home. I think if you install a 1.7+ JRE/JDK from Oracle, you can use this tool to select the default JVM for regular (non-browser use). However, I have to try this.

Incidentally, the Java Control Panel in Settings seems to be useless for this purpose -- it only manages the version used for browser plugins.

If you launch Rainbow (or another tool) explicitly from the terminal, as in
/Applications/okapi-apps_cocoa-macosx-x86_64_0.24/Rainbow.app/Contents/MacOS/rainbow.sh

it inherits the shell settings and path from that terminal. So you you can run Rainbow with an arbitrary JVM by setting the PATH variable in your .profile or .bash_profile. This is a viable workaround, but it doesn't solve launching Rainbow directly from the Finder.

(One final note -- since Ocelot uses a JavaApplicationStub instead of a shell wrapper, it appears that it uses a completely different mechanism! Ocelot still runs on 1.6, though.)

[Former user]

Comment 17. originally posted by KFLi... on 2014-08-04T20:34:44.000Z:

I know this is a Mac issue but itreminds me of an issue I had on Windows 7 where I could not get the system to pick up the Java version specified by my %JAVA_HOME% variable. Which in turn was added to the path with %JAVA_HOME%\bin. Turns out the path reference to %SystemRoot%\system32 caused it the problem. There are java executables in system32. Once it finds those it stops scanning the path. The solution was to move %JAVA_HOME%\bin to the front of the path to make sure it's picked up.
Try updating the path with the correct order and see if that works.

Fredrik

[Former user]

Comment 18. originally posted by @amake on 2014-09-06T09:49:48.000Z:

The solution for this issue is to use `java_home` to select an appropriate Java in the "payload" scripts included in each app bundle. There is simply no other reliable way to choose the right Java. I have committed the fix so it should be in the snapshots soon.

Incidentally `java_home` is bundled with OS X (not with Java itself) and hooks into the OS X mechanism for downloading and installing Java if it is not already installed.

Chase: Over at OmegaT we were using JavaApplicationStub for a long time, but it is literally impossible to make it work with Java 1.7 or higher. We had to dump it in favor of the bundled-script approach.

[Former user]

Comment 19. originally posted by @ysavourel on 2014-09-06T17:20:12.000Z:

Thanks Aaron. That's the conclusion I was beginning to get to about JavaApplicationStub, so as usual we're benefiting from OmegaT's previous platform work.

I've al

Your patches look good (to the eye, at least). One thing I'm wondering about is what happens if Java 1.7+ Is simply not installed. (Or if only the plugin is installed, which seems to not be the same thing, and is reflected in the control panel but not in Java home.) It would be nice if the GUI apps were able to do something besides just die silently when this happened. I don't know if we could wedge an applescript one-liner into the bash wrapper to bring up a dialog, or something.

[Former user]

Comment 20. originally posted by @ysavourel on 2014-09-06T17:23:44.000Z:

It looks like we could to a test of the $JAVA value from java_home, and then run

osascript -e 'tell app "System Events" to display alert "Java 1.7 or later must be installed to run Okapi."'

or something similar to alert the user.

[Former user]

Comment 21. originally posted by @amake on 2014-09-08T05:04:03.000Z:

@ Chase that's a good idea. But we should test on e.g. a fresh OS X install first because I have a feeling the OS will send you to Oracle if you request Java 1.7+ when it's not installed.

[Former user]

Comment 22. originally posted by per.fisc... on 2015-01-16T14:44:12.000Z:

I tried a lot of suggestions, bit none of them worked - I'm on 10.10.1 and no matter what I did, default Java version was 1.6

Finally downloaded and installed JDK 7, installed and bingo!
java version "1.7.0_80-ea"
Java(TM) SE Runtime Environment (build 1.7.0_80-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b07, mixed mode)

Now Checkmate runs. Wonderful. Thank you Apple for making this so unnecessarily hard.

[Former user]

Comment 23. originally posted by @ysavourel on 2015-01-16T16:07:11.000Z:

[Former user]

Comment 24. originally posted by Volvo.Villa.Val... on 2015-03-12T18:39:34.000Z:

Confirming that the JDK 7 solution of Jan 16 works for 10.10.2. Am thinking it might be an idea to add this information or something regarding it in the readme file belonging to the OSX download.

[Former user]

Comment 25. originally posted by [e-mail] on 2015-03-13T08:12:57.000Z:

I was able to look into this a bit more today and came up with what I think is a good solution.

OS X's `/usr/libexec/java_home` will prompt the user to visit Oracle if *no* Java is installed (and you pass `--request`). But if you have e.g. Java 1.6 and need 1.7 then there's no way to get this prompt.

Instead we are now offering a similar prompt via AppleScript.

[Former user]

Comment 26. originally posted by [e-mail] on 2015-03-13T08:16:04.000Z:

(So I didn't come up with it; I used Chase's solution. Oops.)

[Former user]

Comment 27. originally posted by @ysavourel on 2015-03-13T16:55:15.000Z:

Just since this is becoming a good record of this problem and related issues, a followup on Aaron's comment (comment 18.) about JavaApplicationStub not working with Java 1.7+ (ie, it only works with the Apple runtimes, not the Oracle ones).

When we moved Ocelot to Java 1.7, I was able to replace JavaApplicationStub with the Oracle appbundler jar, using the maven-antrun-plugin to call it via ant. I then ended up switching to a fork of the appbundler jar that fixes some issues with it (like rendering correctly on retina). You can look at how this was done in https://github.com/vistatec/ocelot/blob/dev/pom.xml (search for 'appbundler') if interested.

[Franci S]

Now it's macOS Sierra, and Java 18. I can run the program in Terminal, but it has no response without the Terminal.