If I comment out the exports
JAVA_HOME
ANT_HOME
CATALINA_HOME
GROOVY_HOME
in every other possible combination (15 total) the Terminal launch
fails
That's pretty interesting.
Here's the next experiment:
Assign nonsense values to the env-vars.
Either in .bash_profile or using the env-var command-line, set each
env-var to a nonsense or useless value, then run the 'open ...'
command. For example, with all 4 vars set from .bash_profile, try
the following command in Terminal:
GROOVY_HOME="/no/such/thing" open "/Applications/NetBeans/NetBeans
6.1.app"
CATALINA_HOME="/no/such/thing" open "/Applications/NetBeans/NetBeans
6.1.app"
ANT_HOME="/no/such/thing" open "/Applications/NetBeans/NetBeans 6.1.app"
I'm curious what the results will be, but it's incidental to the next
experiment.
The experiment after the above is:
Modify NB.app's bundle so Finder can launch it.
You can preset env-vars in the app-bundle's Info.plist. The
following assumes you're using "Property List Editor.app" from the
Xcode Tools distro.
In Finder, contextual-click on NB.app and choose "Show Package
Contents". In the Contents folder, open Info.plist. (Oh yeah, make
a backup of Info.plist first, somewhere outside of NB.app.)
In the PList Editor, create a key named LSEnvironment. Set its type
to dictionary.
Next, create a new child key of LSEnvironment. Set its name to
ANT_HOME. Leave its type as string. Set its value to /usr/share/ant.
Repeat with the other 3 keys, making siblings of ANT_HOME, and
assigning values identical to the respective values in .bash_profile,
but without any quoting.
Save the Info.plist.
Next, you have to let Finder know that the app's Info.plist changed.
The easiest way to do that is to create a New Folder adjacent to the
Contents folder inside NB.app, then delete that folder. (This
changes the modified-date on NB.app, which Finder sees, and then
updates LaunchServices accordingly.)
If you then double-click NB.app in Finder, the LSEnvironment
variables should be set in the environment, so NB.app should now
launch from the Finder.
By the way, to test whether the addition of LSEnvironment fixes the
problem, you should REMOVE the arch -i386 stuff fromthe 'nbexec'
script. Otherwise you can't tell whether it's LSEnvironment that's
making it work or it's arch -i386.
(The rationale for using LSEnvironment is it's simpler to tell users
who have this problem what to add to Info.plist, as compared to
modifying a shell file deep in the bowels of NB.app.)
Definitely seems like a 32 vs. 64-bit mode problem of some sort.
But what
kind and why (again, I can find no explicit setting of 64-bit mode).
My guess is there's a subtle bug in the 64-bit version of Apple's
native code for the 'java' executable residing in the JavaVM.framework.
Under normal circumstances, a 64-bit capable CPU will first look for
a 64-bit executable in a Universal Binary file. If it finds one, it
executes that. If it doesn't find one, it next looks for a 32-bit
executable that corresponds to its 32-bit architecture (i386 when the
CPU is x86-64 capable). This is all done like this for EVERY
executable, and only the 'arch' command will modify it.
The /usr/bin/java executable does not have a 64-bit executable in it,
so it's command-line parsing works, and -d32 or -d64 works. The
'java' executable in the JavaVM.framework, however, DOES have a 64-
bit executable in it, so it can't get off the ground, even if the -
d32 option is given on the command-line.
Because the crash happens so early, and is apparently triggered by 25
or more command-line args, I think there's either a source-level bug
(programmer FU) or a code-generating bug (compiler FU) in the 64-bit
version of the native code. My guess is that it's somewhere in the
parsing of command-line args, or perhaps in the correlation between
parsing args and looking at env-vars, since presetting certain env-
vars seems to avoid the problem.
It could also be in the JVM's invocation API, because the command-
line parser is probably not much more than a thin layer on top of the
JNI Invocation API.
It could also be a library bug, such as in getopt(), assuming that
native option-parsing uses getopt().
Other than that, and the correlation between command-line args and
certain env-vars, it's just wild-ass guessing as to what the cause
is. However, the fact that these env-vars make it work is a big
clue. Another big clue is that the 32-bit executable in the
Universal Binary doesn't exhibit the problem.
Anyway, these experiments have illuminated some of the areas where
the problem might be, and I think it should be filed with Apple (and
the work-arounds filed with NetBeans).
The one thing this hasn't shown is exactly what leads to the crash in
the first place. That is, why doesn't EVERY user of a 64-bit-capable
Intel-based Mac see this problem? Why only SOME users? And what
happens that leads to only THOSE users seeing the problem? I think
the answer to those will only come after the bug itself is
replicated, found, and characterized. The difficulty in replicating
it won't make it easy for Apple to find the problem, so I won't be
expecting a quick official fix.
Mercifully, the arch -i386 change (or maybe LSEnvironment) appears to
be a work-around that won't break anything when Apple does fix it.
arch -i386 is probably better for NB's developers, but LSEnvironment
(if it works) is probably better for everyday NB users.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
