Re: [Sablevm-developer] Re: Compile issue

[Brent F. <bfu...@de...>]

On Sun, Dec 03, 2000 at 04:23:56PM -0500, Etienne M. Gagnon wrote:
> Hi Brent.
> 
> Brent Fulgham wrote:
> > Ack!  So I have.  Attaching now.
> 
> The patch looks OK.  (It's definitely not what I would keep in the final
> optimized version of SableVM, but it looks operational).
> 
> Now, we have the choice of either using it, or fixing --class-path using
> an application class loader (which is the right way to implement the
> whole thing).
> 

I think we should probably just leave the patch out of sablevm and move
directly to the class-loader.  The reason I say this is that unless we
want the ability to have multiple possible paths to the "base-classes"
and "base-libraries", there's not need for the performance hit of all
that copying and string manipulation.

> Would you like to work on the application class loader?
> 
Yes!  Can you point me towards any references on how it should work?
For example, I could possibly look at Kaffe's or Japhar's implementation
for hints since their licenses are GPL/LGPL.  Or are we approaching it in a
different fashion?  I don't know much about the innards of Kaffe.

> I would still consider your patch, in the short term, as it can be
> convenient for testing.
> 
> What do you think?
>
As I mentioned, it might be better to leave it out since it will encourage
me to actually implement the class loader ;-)  For now, it is convenient
enough for testing to just put the classes into base-class-path.

> > Right -- I don't think this patch handles all such cases properly,
> > since it adds an extra '/' to the patch.  This is, of course,
> > easy to fix.  Although in practice I think the use of
> > "[...]sablepath/classes//" just happens to work on most systems.
> 
> In fact, if we really want to be system independent, we need to use
> system properties for this.  All this is best done in Java, using an
> application class loader.
>

Sounds good to me.  Is it a goal to have SableVM compile under, for
example, Windows using Borland or Microsoft's compiler?  The VM code
looks like it makes use of some GNU C extensions.

> > Right -- with compile-time option so we don't always have to
> > pass it as a boot parameter.  Then --class-path would direct the
> > loader to our standard set of paths for classes.
> 
> Hmmmm, why not in "/etc" (this path would be a compile time constant, as
> I already do with the license files).  I would very much like sablevm to
> use configuration files, instead of environment variables, to find its
> default boot paths.  Much cleaner.
> 

Yes.  And easy to do.  We would want to retain the command-line parsing
to allow user-override.  So we just add some code to parse a simple
configuration file of "tag = value" pairs:

boot-class-path = /usr/lib/sablepath/classes
boot-library-path = /usr/lib/sablepath
class-path = /usr/share/java

What do you think?  I could code this up relatively quickly.  But
the class-loader will take more time while I research how it should
work.

-Brent