search

computerline1z / okapi

Automatically exported from code.google.com/p/okapi
0 stars 0 forks source link

.app won't start #386

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by johannes...@gmail.com on 28 Jan 2014 at 9:55

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tingley on 28 Jan 2014 at 8:50

GoogleCodeExporter commented 9 years ago 
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/rai
nbow.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/rai
nbow.sh
johannes:~ johanneswiesheu$

Original comment by johannes...@gmail.com on 28 Jan 2014 at 9:17

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tingley on 28 Jan 2014 at 9:53

GoogleCodeExporter commented 9 years ago 
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).

Original comment by johannes...@gmail.com on 29 Jan 2014 at 9:50

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tingley on 29 Jan 2014 at 5:51

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

Original comment by yves.sav...@gmail.com on 29 Jan 2014 at 9:47

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tingley on 29 Jan 2014 at 10:58

GoogleCodeExporter commented 9 years ago 
+1 in documenting this in the wiki (and in the readme).
But is there a working solution?

Original comment by yves.sav...@gmail.com on 30 Jan 2014 at 10:14

GoogleCodeExporter commented 9 years ago 
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

Original comment by paolo.tr...@gmail.com on 18 Jun 2014 at 10:11

GoogleCodeExporter commented 9 years ago 
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

Original comment by yves.sav...@gmail.com on 18 Jun 2014 at 10:32

GoogleCodeExporter commented 9 years ago 
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.

Original comment by paolo.tr...@gmail.com on 18 Jun 2014 at 1:45

GoogleCodeExporter commented 9 years ago 
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?

Original comment by paolo.tr...@gmail.com on 18 Jun 2014 at 2:09

GoogleCodeExporter commented 9 years ago 
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).

Original comment by yves.sav...@gmail.com on 18 Jun 2014 at 2:34

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

Original comment by paolo.tr...@gmail.com on 18 Jun 2014 at 8:19

GoogleCodeExporter commented 9 years ago 
Did someone have a look at Java behavior under the upcoming Mac OS 10.10 
(Yosemite)?

Original comment by jwies...@smartadserver.com on 18 Jul 2014 at 9:54

GoogleCodeExporter commented 9 years ago 
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.)

Original comment by tingley on 31 Jul 2014 at 11:42

GoogleCodeExporter commented 9 years ago 
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

Original comment by KFLi...@gmail.com on 4 Aug 2014 at 8:34

GoogleCodeExporter commented 9 years ago 
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.

Original comment by aa...@madlon-kay.com on 6 Sep 2014 at 9:49

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tingley on 6 Sep 2014 at 5:20

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tingley on 6 Sep 2014 at 5:23

GoogleCodeExporter commented 9 years ago 
@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.

Original comment by aa...@madlon-kay.com on 8 Sep 2014 at 5:04

GoogleCodeExporter commented 9 years ago 
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.

Original comment by per.fisc...@gmail.com on 16 Jan 2015 at 2:44

GoogleCodeExporter commented 9 years ago

Original comment by yves.sav...@gmail.com on 16 Jan 2015 at 4:07

GoogleCodeExporter commented 9 years ago 
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.

Original comment by Volvo.Vi...@gmail.com on 12 Mar 2015 at 6:39

GoogleCodeExporter commented 9 years ago 
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.

Original comment by aa...@ripplex.com on 13 Mar 2015 at 8:12

GoogleCodeExporter commented 9 years ago 
(So I didn't come up with it; I used Chase's solution. Oops.)

Original comment by aa...@ripplex.com on 13 Mar 2015 at 8:16

GoogleCodeExporter commented 9 years ago 
Just since this is becoming a good record of this problem and related issues, a 
followup on Aaron's 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.

Original comment by tingley on 13 Mar 2015 at 4:55