[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The problem of core classes for Java compilers (Was: Bug#44462: jikes: jikes does not find core classes



Stephane Bortzmeyer wrote:

> Jikes has a problem with core classes. It can use those of the JDK or
those of
> kaffe (which allows it to stay free) but is is necessary to tell it where
to
> find them.
>
> Which means you cannot compile even the smallest program without setting
> CLASSPATH to indicate where it can find core classes.
> <http://www.research.ibm.com/jikes/jikes.htm#jikespath> directly violates
> Debian policy about environment variables.
>
> Mike Goldman, jikes' maintainer, suggests that Java virtual machines put
the
> core classes in the Java Repository, /usr/share/java/repository. That way,
> jikes will find them.

Just FWIW, I do configure Jikes for Debian to automatically find clases in
the Java Repository.  So if you manually unpack core classes into
/usr/share/java/repository, Jikes will presently find them without any need
for setting environmental variables.

> This was discussed at the beginning of the talk about the Java policy and
> dismissed because of the risk to have two VMs trying to put conflicting
> java.lang.* into /usr/share/java/repository.

I do not know if it is possible to use update-alternatives with a directory,
but this may be a possible solution.

> 1) Follows Mike's suggestion, which would need to change the policy, to
change the VM a bit and to find a way to deal with the conflict mentioned
above.
>
> 2) Make a package of core classes (may be from kaffe's Klasses.jar) and
let jikes depend on it. If this package comes from kaffe's classes, the best
thing would be to have kaffe sources build two packages.
>
> 3) Integrate core classes (may be from kaffe or from GNU's classpath) into
jikes. It would mean incorporating it upstream.

4) Jikes can be modified to search explicitly for the jdk or kaffe classes.
This will make Jikes depend upon one of these packages, and not generically
on java-virtual-machine.  I don't much like this solution, as it will
require Jikes to be modified any time a new jvm becomes available, and
further will cause problems if the jdk or kaffe classes change their
installation location, etc.



Reply to: