This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: proposed java install and extensions directory change


On Thu, 2002-02-28 at 11:51, Per Bothner wrote:
> These are some changes I feel it is important to make in gcc 3.1,
> so I'm hoping we can come to agreement quickly.

I am in favour of these changes.  I think, for instance, it will make
using the packages in rhug much easier to use.

> * We agree to follow the proposed Debian Java policy, in that jar
> files should be installed as $(prefix)/share/java/LIBRARY-VERSION.jar.
> (This implies that RHUG and others packages need to be fixed.)

Happily.

> * libgcj.jar is installed in $(prefix)/share/java/libgcj-VERSION.jar,
> instead of $(prefix)/share/libgcj.jar.  VERSION is the gcc version
> number string.

Or some mangling of the string.  For instance, isn't it "3.1
experimental blah blah" right now?
 
> * We define an "extensions directory", which I propose should be
> $prefix/share/java/ext.  Code that installs a library *may*
> add a link from $(prefix)/share/java/ext/LIBRARY.jar to
> $(prefix)/share/java/LIBRARY-VERSION.jar.  Users *may* install
> libraries directly into $(prefix)/share/java/ext, but a Makefile
> or an install script *should* use a link instead.
> 
> * We (try to) get this added to the Debian Java policy.
> 
> * gcj gets an extra --extdirs (and for jdk compatibility -extdirs)
> option.  If a class cannot be found otherwise, gcj searches every
> .jar in in the listed directories.  (I.e. the extension directories
> are search *after* the bootclasspath.)   The flag overrides (rather
> than adds to) the default extension directory $(prefix)/share/java/ext.

So the compiler always searches the extension directory, --extdirs= just
let the user override this?  Does "--extdirs=" mean don't seach
anywhere?

> * The run-time classloader should do the same searching   However,
this
> is not so critical for gcj, assuming .so files have been installed, but
> it is important if .jar files are installed without corresponding .so
> files.

I think this is important, especially if a package has a large number of
resource files you don't want to compile in.

Should there also be a default secondary /usr/local/share/java/ext?

If extdir searches end up being too slow, you can imagine speeding up
the search by having a single property file mapping class names to jar
files, which is refreshed at jar file installation time.

AG
 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]