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, 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 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
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
On 4 Apr 2001, Per Bothner wrote:
> Egon Willighagen <[EMAIL PROTECTED]> writes:
>
> > I like the idea of a Perl launcher...
>
> I hate the idea of requiring Perl in order to run Java ...
So gcj has jvgenmain. You can do the same for other VMs-- generate a
small executable that invokes the ma
On 4 Apr 2001, Per Bothner wrote:
> Egon Willighagen <[EMAIL PROTECTED]> writes:
>
> > I like the idea of a Perl launcher...
>
> I hate the idea of requiring Perl in order to run Java ...
So gcj has jvgenmain. You can do the same for other VMs-- generate a
small executable that invokes the m
6 matches
Mail list logo
