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
On Thu, Apr 12, 2001 at 02:06:33PM -0400, Jeff Sturm wrote:
> However I like the idea of a Class-path: entry in the MANIFEST, to list
> dependencies by name. If an application is built as a .jar, it can have a
> Class-path: too. Then the linking mechanism is similar to ELF shared
> objects, and c
Jeff Sturm wrote:
> On 11 Apr 2001, Per Bothner wrote:
> > > The 'add everything' approach only invites DLL hell.
> >
> > Well, first this is what Sun does, at least to some extent, with the
> > "extensions" mechanism.
>
> If I understand this extension mechanism correctly, the class loader can
>
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote:
> That is fine for nicely-packaged libraries and applications. However,
> I'm concerned about a random Java programmer who should not have to
> manually fiddle with their classpath. Such programmers should be able
> to write Java code w
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'
On Thu, Apr 12, 2001 at 02:06:33PM -0400, Jeff Sturm wrote:
> However I like the idea of a Class-path: entry in the MANIFEST, to list
> dependencies by name. If an application is built as a .jar, it can have a
> Class-path: too. Then the linking mechanism is similar to ELF shared
> objects, and
Jeff Sturm wrote:
> On 11 Apr 2001, Per Bothner wrote:
> > > The 'add everything' approach only invites DLL hell.
> >
> > Well, first this is what Sun does, at least to some extent, with the
> > "extensions" mechanism.
>
> If I understand this extension mechanism correctly, the class loader can
>
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote:
> That is fine for nicely-packaged libraries and applications. However,
> I'm concerned about a random Java programmer who should not have to
> manually fiddle with their classpath. Such programmers should be able
> to write Java code
> (As I'm reading this thread I'm debugging a classpath with 118 entries.
> It is a terrible mess, and the application is extremely slow to load.
Have you tried changing the classpath around so that the more commonly
needed classes appear earlier in the path?
- Joe
> Just to complicate the situation
>
> Any script that builds a PATHS,CLASSPATH, must also consider stripping
> conflicts from them.
Well, each JVM on the system could have a script that builds the classpath
that it needs. That would be the first thing in the actual classpath passed
to the JVM
On 11 Apr 2001, Per Bothner wrote:
> > The 'add everything' approach only invites DLL hell.
>
> Well, first this is what Sun does, at least to some extent, with the
> "extensions" mechanism.
If I understand this extension mechanism correctly, the class loader can
potentially search the entire e
> (As I'm reading this thread I'm debugging a classpath with 118 entries.
> It is a terrible mess, and the application is extremely slow to load.
Have you tried changing the classpath around so that the more commonly
needed classes appear earlier in the path?
- Joe
--
To UNSUBSCRIBE, email
> Just to complicate the situation
>
> Any script that builds a PATHS,CLASSPATH, must also consider stripping
> conflicts from them.
Well, each JVM on the system could have a script that builds the classpath
that it needs. That would be the first thing in the actual classpath passed
to the JV
On 11 Apr 2001, Per Bothner wrote:
> > The 'add everything' approach only invites DLL hell.
>
> Well, first this is what Sun does, at least to some extent, with the
> "extensions" mechanism.
If I understand this extension mechanism correctly, the class loader can
potentially search the entire
Just to complicate the situation
Any script that builds a PATHS,CLASSPATH, must also consider stripping
conflicts from them.
On my system, I have a set of use scripts, with which I can say:
use jdk -v 1.2
use jaxp
use jmx -v 1.0
If later I decide to do a
use jmx -v 1.0
then the old
Just to complicate the situation
Any script that builds a PATHS,CLASSPATH, must also consider stripping
conflicts from them.
On my system, I have a set of use scripts, with which I can say:
use jdk -v 1.2
use jaxp
use jmx -v 1.0
If later I decide to do a
use jmx -v 1.0
t
17 matches
Mail list logo
