Michael Rogers wrote:
>I thought about mucking about in the System/Library/ ..., just moving
>the currentJDK to point to 1.4.2 instead of 1.5.0, but I thought that
>might be a Bad Idea.
I don't think it would solve your problem, either.
Referring to one of your earlier posts, you wrote:
>First, when I run JBuilder I now get this error: Exception in thread
>"main" java.lang.NoSuchMethodError: java.awt.Window.isAlwaysOnTop()Z
If the error is NoSuchMethodError for a method introduced in 1.5, then
that's compelling evidence that JBuilder is indeed running under 1.4. Or
1.3. Or anything less than 1.5. If it were running under 1.5, then there
wouldn't even *BE* an error like that.
Based on this evidence, my conclusion is that setting JVMVersion in
Info.plist is having exactly the intended effect:
JBuilder is running under 1.4, as requested.
Which brings us to the pivotal question:
Why is JBuilder calling the 1.5-only method Window.isAlwaysOnTop()?
Given the available information, I can only guess...
My first guess is that JBuilder's installer detects the JVM version, and
installs either 1.5-specific jars or 1.4-friendly jars. When you ran the
installer, it detected 1.5 (because that was the default on your machine at
the time), so installed the 1.5-only jars. Once installed, the app itself
is 1.5-only and simply cannot be induced to run on 1.4. To accomplish
that, you'd have to de-install and then re-install, but first making the
installer run on 1.4, or perhaps doing some other hackery to avoid
identifying the JVM version as 1.5.
I have no idea if JBuilder has an installer or not, nor how the installer
works.
My second guess is that JBuilder.app itself contains dynamically selected
code-bases, and by itself will choose either the 1.4-friendly code-base or
the 1.5-only one. Assuming that's true, then something is somehow
confusing the JVM-identifying algorithm and causing it to believe the JVM
version is 1.5 even though it's really 1.4.
I have no idea if JBuilder does anything like that. Besides, I really
can't imagine how a simple version-identifying algorithm could possibly get
that confused.
My third guess is that some Java code OTHER THAN JBuilder is actually
calling Window.isAlwaysOnTop(), and that's killing JBuilder's startup under
1.4. I have no idea what that code might be, since you didn't provide any
stack-trace that would allow us to see what started this series of
unfortunate events.
My guess for culprits is the usual suspects, such as a Java extension
jar-file in one of these locations:
~/Library/Java/Extensions/
/Library/Java/Extensions/
There's also this location, which is reserved for Apple's use only:
/System/Library/Java/Extensions/
If the problem lies there, then Apple needs to know about it.
To examine this possibility, please post the entire stack-trace for the
NoSuchMethodError, so we can see who initiates this fatal action. If it's
JBuilder, then we know that JBuilder is causing its own death, either by
accident or intent. But if it's something else, ANYTHING else, then
JBuilder is just an innocent murder victim.
The reason I suspect this possibility at all is that other posters have
stated that Borland doesn't recommend JBuilder be run under 1.5.
Assuming that's so, it would be insane for them to have a 1.5-only method
anywhere in their code-base. It would also make both my first two guesses
implausible, because there'd be no reason for Borland to have
version-sensing installers or apps unless they're targeting multiple
versions, which they presumably aren't.
I also find it interesting that the error is a NoSuchMethodError, rather
than a class-version compatibility error. This suggests to me that the
offending class calling Window.isAlwaysOnTop() has been target-compiled to
the 1.4 class-file version. This seems like a tactical mistake by whoever
the developer of that class is, because one of the uses for class-file
versions is to fail early on incompatible JVM's.
>I'm about ready to give up, but I really like JBuilder's GUI editor,
>and it is crossplatform. If anyone has any suggestions as to an ide
>with a cross-platform GUI editor, I could work with that, I suppose.
Assuming you can't find a way to get JBuilder to work under 1.4, exactly
why can't you run JBuilder under 1.5?
A recent post from Apple specifically asked developers to try running under
1.5 and confirm that it works, because when the next rev of Mac OS X Java
comes out, it WILL make J2SE 5.0/1.5 the default:
<http://lists.apple.com/archives/java-dev/2006/Jan/msg00008.html>
Your original problem with launching JBuilder under 1.5 was a problem with
the Crimson JAXP parser, due to a change in package name under 1.5. If
that's the only reason you reverted to 1.4, then you might have more
success by addressing that specific problem, rather than trying to revert
to 1.4, but I'm just guessing. YMMV. See this earlier reply for
suggestions:
<http://lists.apple.com/archives/java-dev/2006/Jan/msg00023.html>
In any case, it seems clear that JBuilder behaves badly when 1.5 is the
default JVM, so the JBuilder folks should probably receive a bug-report
saying that when Apple GM's their next Java rev, JBuilder will quite likely
fail.
-- 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
This email sent to email@hidden
