| Summary: | Jikes problem with CLASSPATH missing | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | BlaisorBlade <blaisorblade_spam> |
| Component: | [OLD] Development | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | patrizio.bassi |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 92786, 127816 | ||
| Bug Blocks: | |||
| Attachments: | jikes wrapper script | ||
|
Description
BlaisorBlade
2005-04-19 14:11:20 UTC
*** 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 attachment 59012 [details]
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. |
