[Sablevm-developer] Re: Compile issue

[Etienne M. G. <eg...@j-...>]

Hi Brent,

I am continuing this thread on the SableVM-Developer list.

Brent Fulgham wrote:
> I've attached a diff for your review.  I wouldn't dare apply this to
> the archive until you look at it.  It's probably pretty inefficient --
> I think with some thought we could probably get rid of some copying.

I think you actually forgot to attach the diff (it happens to me often
too, to forget attachments;-).

> At any rate, my idea was to allow --boot-class-path to accept things
> of the form:
> 
> --boot-class-path=/usr/lib/sablepath/classes:.
> 
> (just like regular ":"-delimited path lists).
> 
> To get this to work, I had to make a few changes, but I think the
> scope of the modifications is relatively small.

If we implement this for --boot-class-path, we must also implement it
for --boot-library-path.  We should also take care of adding a trailing
"/" when necessary, e.g.:

(All of these should be valid)

 --boot-class-path=/usr/lib/sablepath/classes/:./  
 --boot-class-path=/usr/lib/sablepath/classes:./  
 --boot-class-path=/usr/lib/sablepath/classes/:.  
 --boot-class-path=/usr/lib/sablepath/classes:.  

If we want to accept "relative" paths (like "."), we should first
convert them into absolute paths.  I do really dislike the JDK's
vulnerability in this regard (as using a file dialog can change the
current work directory and cause all sorts of problems).

I don't know if it is a good thing, or not, to accept all of these
things in the boot class path (see discussion below).  It might be
sufficient to simply accept a single absolute path.

> One thing I'm not sure of is if "class-path" should be the path
> to the main class archive, the classes I intend to run, or some
> combination.  And how about --boot-class-path?  It seems that the
> class you pass on the command-line must be in the --boot-class-path
> path as well.
> 
> Why do we need two class-paths?

OK.  Let me start by saying that the current implementation of sablevm.c
is wrong.  It shouldn't instantiate the HelloWorld class.  It should,
instead, instantiate a special application class which will use a class
loader to load the HelloWorld class.

By using a class loader, it can retrieve this class from within a .jar
file, or any other location.  The code to do so will be written in Java
(relief for the vm writer;-).

The idea of having 2 kinds of class path is that:
boot-class-path:  This is the path to the standard libraries.
class-path:  This is the path to the user's classes.

Now, it might be interesting, eventually, to allow some boot classes to
be packaged into .jar files, but as I do not want to write .jar reading
code in C, some base classes have to be available directly on the file
system.  If we want to use both, we have to play a few tricks in the vm
to record specially that all these classes are in the same "runtime
package".  So, I would delay the implementation of this to later, when
we know that the normal class-path does implement runtime packages
correctly.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------