Description of problem: jikes should provide javac alternative Version-Release number of selected component (if applicable): jikes-1.22-5.fc5 Additional info: jikes should be usable as the system javac compiler through the alternatives system - as user replacement for ecj etc.
I tend to agree, but I think it cannot be currently sanely done. If one sets jikes as the highest priority alternative for javac without any slave alternatives (and the jikes package doesn't contain anything that could be used as the slaves), all slaves of the javac alternative eg. in java-1.4.2-gcj-compat-devel will be just removed without replacement, which would mean that /usr/bin/javadoc, /usr/bin/javah, /usr/bin/jar and /usr/bin/rmic would just disappear. Ccing Thomas and Fernando in case you have some ideas or comments, but unless I've missed something, this will unfortunately probably have to be closed as CANTFIX/DEFERRED.
Jiikes must most certainly work with jar, rmic etc from some other source. Perhaps we could have a jikes-compat package that would require both jikes itself and these other JDK and set the complete set of alternatives. The limitation here is that it would be fixed, i.e., we would have to pick one of the possible sources for these extra bits. Or we could have several jikes-compat, each for one of the possible sources for rmic, jar etc. It would be doable, but who would do it and maintain it? I think this is the biggest problem at the moment. Perhaps it would be easier if one continue to use jikes as today, by directly invoking it instead of the currently set alternative.
Why would you want to use jikes given that ecj is included in Fedora Core?
True - but then why package jikes in FE at all? :-) My point was Fedora (including extras) comes with three alternative java compilers - ecj, gcj and jikes - and an alternatives systems to allow choice of which package providing the same functionality / command is used by default on the local system. It would be nice for those packages to expose their javac capability via alternatives so a user could easily change between them on their system. But it looks like this would not be trivial as the alternatives defined are really runtime environment and development environment, including associated tools, and not simply javac and java commands. Feel free to close as rejected RFE.
(In reply to comment #4) > True - but then why package jikes in FE at all? :-) Agreed, I think it should be removed :-)
Well, thanks for the reality check, it's been more than a little time since I've used jikes myself and the upstream project is pretty much dead, so I've orphaned it -> https://www.redhat.com/archives/fedora-extras-list/2006-September/msg00026.html There are some use cases where jikes can still be useful; if some contributor is in such a situation, maybe it'll have a new maintainer soon and reopen this bug if (s)he's interested in doing something about it. If nobody picks it up, I guess we won't see jikes in FE6.