This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: classpath question
- To: Jeff Sturm <jeff dot sturm at appnet dot com>
- Subject: Re: classpath question
- From: Tom Tromey <tromey at cygnus dot com>
- Date: 13 Sep 2000 19:35:17 -0600
- Cc: "green at cygnus dot com" <green at cygnus dot com>, "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>
- References: <01C01B58.9C2953C0.green@cygnus.com> <39BC4FCA.327AA3C9@appnet.com>
- Reply-To: tromey at cygnus dot com
>>>>> "Jeff" == Jeff Sturm <jeff.sturm@appnet.com> writes:
Jeff> A related issue is the runtime classpath. Should programs
Jeff> compiled by gcj also search /usr/share/gcj at runtime, or should
Jeff> they use the same classpath as the compiler? Right now
Jeff> libgcj.zip doesn't appear in the java.class.path system
Jeff> property; we may have to fix that someday for class resources.
I think for compiled programs it makes the most sense to not have to
ship the .class files with the program. To me that means we should
have a way to compile a property file and put it into the executable.
This subject has come up here before but it hasn't really been
important enough for anybody to implement.
I picture being able to take an executable .jar and compile it to a
standalone executable with one command. That would be convenient.
Jeff> While you're making the change, you might consider renaming to
Jeff> libgcj.jar since .zip really ought to be deprecated.
This will happen when we merge libgcj into the gcc tree. We've
already promised RMS that we will not use zip (since it is non-free).
Unless something comes up we're planning to use fastjar. (This, btw,
is why AG did all the jar-related work he did in the last month or so
-- he's planning ahead.)
Tom