Bugzilla Bug 89711

Jikes requires CLASSPATH to be set and to point to the rt.jar file provided by 
the JDK; this has been removed in the recent "sun-jdk" ebuilds (and maybe in 
other similar JDK ebuilds), so jikes fails.

*** Bug 89713 has been marked as a duplicate of this bug. ***

(Btw, sorry for the dup. report, I submitted the form twice).

please provide the output of packages which fail to emerge, thanks

No package fail in emerging. Jikes fail when running.

In my (auto-fixed) setup, I have:
$ echo $CLASSPATH
/opt/sun-jdk-1.5.0.02/jre/lib/rt.jar:.

And Jikes works like a charm.

Here's a simulated error (I've fixed the problem by hand, so I have to unset CLASSPATH to produce the behaviour):

(unset CLASSPATH; jikes Parser.java)

Found 1 system error:

*** Semantic Error: You need to modify your classpath, sourcepath, bootclasspath, and/or extdirs setup. Jikes could not find package "java.lang" in:
                .

It's like with the very old javac releases, which couln't find the built-in libraries unless CLASSPATH was set to the correct path.

we're not going to do this, it's not very clean to do so and if you want to
compile things with jikes manually you can specifiy the classpath on the
command line. 

This is still a bug, even though we won't clutter the CLASSPATH. What we should
do is provide a wrapper script for Jikes which determines the actual path to
the runtime through java-config.

Created an attachment (id=59012) [edit]
jikes wrapper script

A quick hack for autodetecting the proper bootclasspath at jikes invocation
time. We could replace the /usr/bin/jikes with this script, then rename the ELF
file to /usr/bin/jikes-bin. (Seems like a common enough practice).

Has been tested on blackdown and ibm. Jrockit, sun and kaffe probably needs
some lovin', too.

imho the wrapper script is a good idea, but we should maybe wait until
java-config has an option that can return the path to the runtime foo. :)

IMHO there's no reason why "setting the CLASSPATH in the environment" is 
unclean. Basically, it's required by Jikes (and possibly by other apps) and it's 
done everywhere Jikes is used.

That said, I've no problem if you want to use another solution, but I don't like 
the practice "let's leave this broken until it can be done properly". For myself 
I've already fixed the problem by hand-editing, through it breaks again at JDK 
updates, but I'd like it to work well by default.

Anyhow, what's the problem about Java-config? Fixing it shouldn't take so long, 
right?

broken solutions only make things worse

and it will take as long until its done, if you want to be a jackass go 
somewhere else, or come with some patches

and it has been done as part of a bigger change that is planned and we are still 
working on

instead of doing a wrapper,  isn't better to add a jikes eclass to do that? 

I see no benefit / sense in making a jikes eclass.

It is also worth noting that the jikes that lives in axxo-overlay does provide a
jikes wrapper.

Fixed with the new Java system.