On May 12, 2006, at 9:21 AM, Greg Guerin kindly offered this insight: The posting on Java-dev says that the bootclasspath should be specified during compilation, using the -bootclasspath option to 'javac'. That's a completely different thing than specifying -Xbootclasspath for the executable. The latter is almost certainly fatal, as it tells the 1.5 JVM to use a bootclasspath of 1.4's classes.jar, and isn't even the complete 1.4 bootable classpath, either.
For an explanation of -bootclasspath for compilation, read 'man javac', in the section on cross-compiling and target-compiling. Also refer to the original Java-dev message thread: <http://lists.apple.com/archives/java-dev/2006/Apr/msg00436.html>
To summarize, you're going to need BOTH a -bootclasspath option for the compiler, AND a change to the executable. If you only change the compilation, then your code will be compiled for 1.4 but still be run under 1.5.
Oh kewl, I'm not getting crazier. Many thanks Greg. I neglected to mention that I did see this thread, but when it didn't work any better than the source and target settings I figured I just "wasn't getting it" and started trying things out until it broke differently. Then I guessed (correctly) that I was totally lost.;-)
So, I've fixed it this far (putting the -bootclasspath arg back where it belongs), then started looking around to find where I could possibly change this java invocation for this WO project without forcing everything back into the 1.4 world. 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 ...).
OK, I next stumbled upon an article for dealing with this with WO (basically modify the MacOSClassPath.txt to invoke "/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Commands/java" instead of "java") and gave that a shot. That's when things got really weird; this *seems* to work. My application shows 1.4 being invoked instead of 1.5 and my code reports it's running in 1.4.2_09. Sweet, so I try printing. I get the print dialog and click "Print" ...
[2006-05-12 15:28:24 PDT] <WorkerThread2> <WOWorkerThread id=2 socket=null> Throwable occurred: java.lang.UnsupportedClassVersionError: sun/print/UnixPrintServiceLookup (Unsupported major.minor version 49.0) [2006-05-12 15:28:24 PDT] <WorkerThread2> java.lang.UnsupportedClassVersionError: sun/print/UnixPrintServiceLookup (Unsupported major.minor version 49.0)
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.
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? 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?
I can restore from backup, this isn't a death knell for me yet. But I'd rather learn something and I feel like I'm about to.
Dave Stewart Aqua~Flo Supply (Goleta CA) dstewart at aquaflo dot com
A diplomat is someone who can "tell you where to go" and make you feel happy to be on your way. |