Re: Java 5 and WO problem
Re: Java 5 and WO problem
- Subject: Re: Java 5 and WO problem
- From: Greg Guerin <email@hidden>
- Date: Fri, 12 May 2006 17:45:53 -0700
Dave Stewart wrote:
>Since the thread mentioned QA1474 (thanks for that Matt Drance:), I
>followed that next (basically changing the Java Application Runtime
>Settings back to 1.4; note this should basically force me back into the 1.4
>world anyway if I read that right), but still no love. Yes, I did this for
>both for applications AND applets (WO runs in a browser after all, it's not
>really an applet but when application didn't work ...).
First, I changed the Subject line back to something more sensible than "Re:
Xcode-users Digest, Vol 3, Issue 346".
Second, AFAIK, the "Java Application Runtime Settings" affect what gets put
into an app-bundle's Info.plist (Show Package and check it to see). It
won't affect how applets are run in a browser, and it won't affect other
kinds of "applications", like the JVM version that an "application server"
uses when it deploys wars, ears, etc.
For Safari, the JVM is chosen by Java Preferences.app, nested inside
/Applications/Utilities a couple levels down in J2SE 5.0. There are
separate settings for applets vs. double-clicked jars and app-bundles.
I admit to knowing almost nothing about WO applications or applets, so I
don't know how much of this applies to the WO targets. And since I don't
have the WO tools and frameworks installed, I'm not in a position to
investigate this, find an answer, and then tell you how to fix it, either.
>Huh? But doesn't "Unsupported major.minor version 49.0" mean I've got 1.5
>code running in a 1.4 VM? I've double-checked, the -target and -source drop
>downs still show 1.4 and I've even tried adding them as "Other Java
>Compiler Flags" and to all targets, but still no sanity. Double check,
>clean all targets, delete build folder, rebuild entire project, fix entry
>in MacOSClassPath.txt again, run. Same results.
Don't Panic. Start with this question:
Did you compile a class named sun.print.UnixPrintServiceLookup?
If you didn't, then the -target and -source options couldn't possibly have
an effect, because it isn't a class you compiled (look in your jar). If it
isn't something you compiled, then it's in some library of classes
somewhere, already compiled.
I suggest looking at the detailed transcript of Xcode's build, rather than
randomly firing options in the hopes of hitting something. You can usually
see exactly what each setting's effect has in the transcript, and it's a
lot safer than shotgunning into the darkness.
>Sigh. So I've figured out how to run it in 1.4, but apparently it's still
>building in 1.5. But wait a second, is it really?
Technically, yes it is "building in 1.5". However, you are building FOR
1.4, which is subtly different. Specifically, the 1.5 compiler is still
being used, but by passing it the -target, -bootclasspath, and -source
options, you're telling it to compile for 1.4, which it appears to be doing.
It may seem this is a distinction without a difference, but it may become a
distinction WITH a difference if you happen to pick the wrong option or
setting, and suddenly it seems to go back to 1.5.
>The project RUNS until I
>try to print, that's when the UnsupportedClassVersionError is thrown!
>Shouldn't that error be thrown immediately when 1.5 code is loaded on a 1.4
>VM, or am I missing something else here?
That error will occur when the needed class is loaded. That isn't always
"immediately", because Java classes are loaded only when needed, on demand
(ref: ClassLoader). However, the fact that the *rest* of your code runs
fine, and even identifies the JVM version as 1.4, leads me to think it's
running under 1.4.
Judging by the offending class's package name, my first guess is that some
jar in a Java extension dir has a 1.5-only class, or 1.4's runtime
classpath is somehow being set to include a jar with a 1.5-only class. The
specific class is sun.print.UnixPrintServiceLookup, so that's the one you
need to locate.
To find a class in an extension, try my Whence tool:
<http://lists.apple.com/archives/java-dev/2006/Apr/msg00609.html>
I suggest running it under both the 1.5 'java' command, and a
long-pathname-to-1.4/java invocation. The reason for running it under the
1.5 'java' command is to discover if it's in a normal 1.5-only jar, which
only the 1.5 JVM should know about. If it comes up in a java extensions
dir, though, then that is shared with 1.4 by default.
I also suggest looking very carefully at what your "MacOSClassPath.txt" is
doing, if that's the controlling element. Since I know nothing about WO,
that's a pretty generic suggestion.
Another thing I'd look at is whether anything is referring to
"/Library/Java/Home", because I'll wager that symlink now points into the
1.5 version, not the 1.4 version, in JavaVM.framework. As a result,
anything using that pathname may be suspect.
Within the JVM context, the "java.home" property defaults to the correct
version-specific home (print its value to see this). It's when EXTERNAL
things like command-lines or shell-scripts wish to refer to Java home that
things can get wacky. Those external things typically use an env-var
(JAVA_HOME) or just assume /Library/Java/Home points to the version-correct
home. When that assumption doesn't match the desired JVM version,
confusion ensues.
One thing I'd probably do is dump all the system properties in the Java
application itself, so you can actually see what's being set up and what
the code itself is using. Properties like "java.ext.dirs" and
"java.class.path", along with others, determine where the JVM looks for
classes, and in what order. Rather than guessing or shotgunning, I've
often found the simplest thing is to ask the JVM exactly what it knows, and
then work back from that to figure out how it got it.
Sometimes, if you can come at it from the other direction, i.e. from the
executed command, its environment, etc. that can narrow things down, too.
I've found the 'env' and 'printenv' shell commands useful in this regard.
Finally, since you're targeting WebObjects, you might get more WO-specific
answers by searching the WebObject lists:
<http://lists.apple.com/archives/webobjects-dev/>
or subscribing and asking on webobjects-dev.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden