Re: Class Loader Oddity???

bsd5tu1 wrote:

  

.....
    

java -classpath .:.\abc.jar -jar launcher.jar

the launch will not work.
    

I find it hard to believe those are the exact Windows command-lines.
  

Your examples show a ":" as the separator between classpath elements, but
on Windows the path-separator is ";".  As evidence, write a Java test
programs to print the "path.separator" System property, or the static value
of java.io.File.pathSeparator.

If you HAVE pasted the exact command-lines above, then I'm baffled.

Or maybe not.

The reference for the 'java' command (man page):
  <http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html>
  

says this about the -jar option:
  When you use this option, the JAR file is the source of all user classes,
  and other user class path settings are ignored.
  

Based on this, the -classpath arg should be ignored.  I can't speak for
Windows, but in my experience on Mac OS X, it DOES get ignored, and this
can easily be verified (see ListClassLoaders below).

So the apparent fact that it's NOT getting ignored on Windows is more
baffling than the apparent fact that ":" appears to be working as
path-separator.
  

If I encountered this mystery on Mac OS X, I'd try this command-line:
  java -jar /full/path/to/launcher.jar
and not mess around with -classpath.  At least it's consistent with the
documentation for the -jar option.  Translating that to the correct Windows
absolute pathname is left as an exercise for the reader.


  

The only explanation I can think of is that your "convert pathname to URL"
procdure isn't really working correctly under Windows, so your launcher is
actually malfunctioning.  However, rather than simply failing, presetting
-classpath with an absolute pathname somehow acts as a kind of safety net
to prevent it from failing utterly.  That's just a guess, because we don't
have any launcher source code, and the launcher code seems to be at the
crux of this.

You may want to investigate what your launcher's URLClassLoaders are really
seeing with the ListClassLoaders diagnostic tool I posted a while ago
  <http://lists.apple.com/archives/java-dev/2006/May/msg00274.html>

  

And also print the value of the "user.dir" property, since that's pivotal
for the correct interpretation of relative pathnames.

Or since the problem only occurs on Windows, maybe you should post your
question on a list or forum for Java on Windows.  Don't be surprised if
they ask to see the launcher code.


  

My question is whether we've stumbled on some type of a fluke or not. If
you read the docs for classpaths, it implies to me that the FULL classpath
setting (like the way it's done in Windows) is the correct way, and yet 3
OSes (OS X, Linux, Solaris) seem to be able to reference the jarred library
with respect to their own jar files.
    

You'll have to specify which "docs for classpaths" you read.
  

Also notice: all 3 OS'es have "/" as the separator between pathname
elements, and ":" as separator between classpath elements.  Windows
doesn't.  That simple syntax difference raises the possibility of a simple
syntactical error somewhere in your launcher.

  

A long time ago I did some work on VMS systems (the Father of Windoze) and
I seem to remember at the time the same sort of absolute referencing of
names, and I also remember way back then how dumb I thought it was that the
operating system couldn't handle relative references. Is this what we're
seeing here?
    

Evidence against that hypothesis:
  Windows has a "current directory" and supports relative pathnames.

  -- 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