Re: Let Jikes (finally) go into testing on its own...

[Andrew Pimlott <andrew@pimlott.net>]

On Fri, Jan 23, 2004 at 12:15:27AM -0600, Adam Majer wrote:
> On Tue, Jan 20, 2004 at 02:00:12PM -0500, Andrew Pimlott wrote:
> > Irrespective of the testing issue, it seems obvious that just as the
> > jikes source package is the wrong place for these wrappers (why
> > should the compiler know about different runtimes?), so are the JVM
> > source packages (why should the runtime know about a compiler?).  It
> > would make much more sense for the JVM packages to register their
> > standard libraries as alternatives (the alternative could either be
> > the library, or perhaps more generally, a file containing a list of
> > library files).  Then jikes as well as any other compiler that is
> > not bundled with its own standard libraries could find them in the
> > same way.  After all, it is silly to implement a solution that works
> > only for jikes.
> 
> So, if someone wants to use jikes with kaffe, they will have to type
> 
> jikes -bootclasspath 'some kaffe paths' hello_world.java

If they absolutely must use kaffe's libs, yes.  If they just type

    jikes hello_world.java

they will get the libs with the highest priority alternative.  (The
symlink might be /usr/share/java/bootlibs, and it could contain a
list of jars, so the jikes wrapper script would do "jikes.real
-bootclasspath @/usr/share/java/bootlibs)

> The point of the java-wrappers is for people to install one of these
> and then simply type:
> 
> javac hello_world.java

I think my suggestion meets this goal.

> Or to have a java package in main compiled with javac and just having
> 
> Build-Depends: jikes-kaffe

If a java package needs jikes and kaffe, it can depend on jikes and
kaffe, and run "jikes -bootclasspath 'some kaffe paths'".  This
seems much cleaner than adding an artificial package for the
combination of jikes and kaffe.

Andrew