Bug 204251 - jikes should provide javac alternative
Summary: jikes should provide javac alternative
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: jikes
Version: 5
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-27 19:20 UTC by Paul Jenner
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-02 14:20:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Paul Jenner 2006-08-27 19:20:46 UTC
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.

Comment 1 Ville Skyttä 2006-08-27 20:00:02 UTC
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.

Comment 2 Fernando Nasser 2006-08-28 13:09:09 UTC
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.

Comment 3 Thomas Fitzsimmons 2006-08-29 01:21:42 UTC
Why would you want to use jikes given that ecj is included in Fedora Core?

Comment 4 Paul Jenner 2006-08-29 08:35:08 UTC
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.

Comment 5 Thomas Fitzsimmons 2006-08-29 15:02:55 UTC
(In reply to comment #4)
> True - but then why package jikes in FE at all? :-)

Agreed, I think it should be removed :-)


Comment 6 Ville Skyttä 2006-09-02 14:20:36 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.