This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Java libraries and proposal.
- To: Cedric Berger <cedric at wireless-networks dot com>
- Subject: Re: Java libraries and proposal.
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Thu, 12 Apr 2001 20:03:15 -0400 (EDT)
- cc: Per Bothner <per at bothner dot com>, james at netcsi dot com, debian-java at lists dot debian dot org, java at gcc dot gnu dot org
On Thu, 12 Apr 2001, Cedric Berger wrote:
> > If I understand this extension mechanism correctly, the class loader can
> > potentially search the entire extensions directory at runtime. That seems
> > horribly inefficient if that directory can grow to dozens or hundreds of
> > .jar's.
>
> Isn't that an implementation issue?
> What I mean is that " if that directory can grow to dozens or hundreds of
> .jar's", nothing would prevent gcj from, for example, keeping a directory of
> the content of the jar files in some kind of private database for faster startup.
Good point. That is an optimization similar to how ldconfig generates
/etc/ld.so.cache for glibc. But I wonder if the convenience is really
worth the complexity in this case. Or how it would be implemented for
compilers like Sun's javac (since we're not just talking about gcj,
right?).
I'm also afraid of what would happen when two or more .jar's contain
similarly named but incompatible classes. (I spent most of my day today
chasing down exactly that problem in a horrific classpath. At least the
classpath mechanism prescribes a search order. What search order rules
apply to an extensions directory?)
Jeff