I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines.
First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?
Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was available other than GCJ so GCJ AOT bits MUST be present." This presents a problem for the package in question, because it consists of annotations only. They are Java 1.5 annotations, so the GCJ in F7 can produce the needed class files. But there is no actual code to compile, so there is nothing for the GCJ AOT bits to do. Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?
References: [1] This is one of the last two prerequisites for findbugs [2]. The other is 285551. [2] http://findbugs.sourceforge.net/
On Mon, 2008-04-14 at 15:35 -0600, Jerry James wrote:
I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines.
First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?
It contains directories you install into, including /usr/share/java.
Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was available other than GCJ so GCJ AOT bits MUST be present." This presents a problem for the package in question, because it consists of annotations only. They are Java 1.5 annotations, so the GCJ in F7 can produce the needed class files. But there is no actual code to compile, so there is nothing for the GCJ AOT bits to do. Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?
I'd say you can safely ignore this and do what your common sense advises you to do. But I might be wrong :)
Le Lun 14 avril 2008 23:35, Jerry James a écrit :
I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines.
First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?
You need at least the standard java directories and the associated rpm macros. They're provided by jpp-utils
On Tue, Apr 15, 2008 at 1:28 AM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
You need at least the standard java directories and the associated rpm macros. They're provided by jpp-utils
Thanks to you and Lubomir for answering this question.
Jerry James wrote:
I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines.
First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?
Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was available other than GCJ so GCJ AOT bits MUST be present." This presents a problem for the package in question, because it consists of annotations only. They are Java 1.5 annotations, so the GCJ in F7 can produce the needed class files. But there is no actual code to compile, so there is nothing for the GCJ AOT bits to do. Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?
Amazing -- I never even imagined that such a thing as an annotation-only package might exist! The guidelines are intended to allow reasonable people to interpret them sensibly. In this case, AOT-compiling wouldn't hurt but wouldn't be of much benefit, so I don't think it matters.
Andrew.
Andrew Haley wrote:
Jerry James wrote:
I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines.
First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?
Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was available other than GCJ so GCJ AOT bits MUST be present." This presents a problem for the package in question, because it consists of annotations only. They are Java 1.5 annotations, so the GCJ in F7 can produce the needed class files. But there is no actual code to compile, so there is nothing for the GCJ AOT bits to do. Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?
Amazing -- I never even imagined that such a thing as an annotation-only package might exist! The guidelines are intended to allow reasonable people to interpret them sensibly. In this case, AOT-compiling wouldn't hurt but wouldn't be of much benefit, so I don't think it matters.
Andrew, if you could propose some wording changes to the Guidelines for this it would be most appreciated. Knowing what an annotation is and that this is a sensible tactic will help reviewers who are unfamiliar with java to review packages of interest to all.
-Toshio
Toshio Kuratomi wrote:
Andrew Haley wrote:
Jerry James wrote:
I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines.
First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?
Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was available other than GCJ so GCJ AOT bits MUST be present." This presents a problem for the package in question, because it consists of annotations only. They are Java 1.5 annotations, so the GCJ in F7 can produce the needed class files. But there is no actual code to compile, so there is nothing for the GCJ AOT bits to do. Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?
Amazing -- I never even imagined that such a thing as an annotation-only package might exist! The guidelines are intended to allow reasonable people to interpret them sensibly. In this case, AOT-compiling wouldn't hurt but wouldn't be of much benefit, so I don't think it matters.
Andrew, if you could propose some wording changes to the Guidelines for this it would be most appreciated.
OK.
"In some rare cases Java packages might not contain any executable code whatsoever, so AOT-compiling for gcj would not be required. An example of such a package would be one that contained only annotations."
Andrew.
On Wed, Apr 16, 2008 at 11:32 AM, Andrew Haley aph@redhat.com wrote:
"In some rare cases Java packages might not contain any executable code whatsoever, so AOT-compiling for gcj would not be required. An example of such a package would be one that contained only annotations."
Perhaps "annotation definitions" would be a bit more precise.
Jerry James wrote:
On Wed, Apr 16, 2008 at 11:32 AM, Andrew Haley aph@redhat.com wrote:
"In some rare cases Java packages might not contain any executable code whatsoever, so AOT-compiling for gcj would not be required. An example of such a package would be one that contained only annotations."
Perhaps "annotation definitions" would be a bit more precise.
Ok. I don't think it matters much.
ANdrew.
Andrew Haley wrote:
Jerry James wrote:
On Wed, Apr 16, 2008 at 11:32 AM, Andrew Haley aph@redhat.com wrote:
"In some rare cases Java packages might not contain any executable code whatsoever, so AOT-compiling for gcj would not be required. An example of such a package would be one that contained only annotations."
Perhaps "annotation definitions" would be a bit more precise.
Ok. I don't think it matters much.
GCJ Guidelines have been clarified by adding this paragraph.
-Toshio
On Tue, Apr 15, 2008 at 3:56 AM, Andrew Haley aph@redhat.com wrote:
Amazing -- I never even imagined that such a thing as an annotation-only package might exist! The guidelines are intended to allow reasonable people to interpret them sensibly. In this case, AOT-compiling wouldn't hurt but wouldn't be of much benefit, so I don't think it matters.
Okay, thanks. For what it's worth, since the last time I checked, findbugs has picked up another external dependency, on yet another annotation-only package. Take a look here:
http://jsr-305.googlecode.com/
I'll work on getting it packaged up. My initial attempt at building this code triggered a null pointer exception in javadoc!
On Tue, 2008-04-15 at 23:39 +0200, Matej Cepl wrote:
On 2008-04-14, 21:35 GMT, Jerry James wrote:
Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?
Or ugly solution -- wait two months ;-) Then all supported Fedoras will have JDK.
No, I am not serious.
Why not? Getting rid of legacy cruft sounds like an brilliantly elegant solution to me. But probably not applicable here, as GCJ doesn't really fall into that category, given it still outperforms OpenJDK by the factor of 10 on ppc.
Lubomir Kundrak wrote:
Why not? Getting rid of legacy cruft sounds like an brilliantly elegant solution to me. But probably not applicable here, as GCJ doesn't really fall into that category, given it still outperforms OpenJDK by the factor of 10 on ppc.
If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?
On Tue, 2008-04-15 at 17:53 -0500, Les Mikesell wrote:
If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?
GCJ runs Eclipse, which is a pretty important tool to a lot of people.
Jesse Keating wrote:
On Tue, 2008-04-15 at 17:53 -0500, Les Mikesell wrote:
If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?
GCJ runs Eclipse, which is a pretty important tool to a lot of people.
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.
Jesse Keating wrote:
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.
Well Fedora not including Sun Java was cited as one the major reasons why Sun choose to open source Java and specifically under GPL
http://www.linuxjournal.com/article/9624
As to the amount of effort that took for Eclipse to run under GCJ
http://www.linuxjournal.com/article/7413
Rahul
Jesse Keating wrote:
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.
It's not a moot point to users who do have the option to install Sun Java even though it has been made more difficult than necessary on fedora. They need to decide which is likely to be more difficult (or more productive) - installing sun java or making an arbitrary application work with something fedora ships.
Le Mer 16 avril 2008 01:12, Jesse Keating a écrit :
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.
Sure, that was a good argument for pushing gcj in the past. The question is should we focus on gcj or openjdk/icedtea now.
Nicolas Mailhot wrote:
Le Mer 16 avril 2008 01:12, Jesse Keating a écrit :
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
I'll note that the early hacks to make Eclipse run on gcj were removed when gcj was fixed. Most of the time spent making Eclipse work on gcj was on the gcj side, not changes to Eclipse.
I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.
Sure, that was a good argument for pushing gcj in the past. The question is should we focus on gcj or openjdk/icedtea now.
Well, I don't know what you are focussing on, but my team is working on porting OpenJDK, improving its performance where needed, and at the same time keeping gcj running on those targets where it's useful. I don't think there is any other course of action that makes sense.
Andrew.
On Wed, 2008-04-16 at 09:10 +0200, Nicolas Mailhot wrote:
Le Mer 16 avril 2008 01:12, Jesse Keating a écrit :
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.
Sure, that was a good argument for pushing gcj in the past. The question is should we focus on gcj or openjdk/icedtea now.
IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed. Thus in an open source environment, Java bytecode has little reason to exist. If we're going to *distribute* compiled code, it may as well be nice fast native code.
Yes I know what you're going to say, lots of languages, such as Python do bytecode as well. But they do it as a backend implementation detail, with no guarantee of stability and stored on disk only as a performance optimization, rather than an intentional mechanism for source code obfuscation. IMO we, the open source community, should shun Java bytecode.
Callum Lerwick wrote:
Sure, that was a good argument for pushing gcj in the past. The question is should we focus on gcj or openjdk/icedtea now.
IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed. Thus in an open source environment, Java bytecode has little reason to exist.
Errr, what about applet downloads and RMI, neither of which requires similar architecture or compiling capability at the other end? Are you sure you are talking about something that even resembles java?
If we're going to *distribute* compiled code, it may as well be nice fast native code.
Yes I know what you're going to say, lots of languages, such as Python do bytecode as well. But they do it as a backend implementation detail, with no guarantee of stability and stored on disk only as a performance optimization, rather than an intentional mechanism for source code obfuscation. IMO we, the open source community, should shun Java bytecode.
It would be better to ship something that follows the spec, or call it something other than java.
On Mon, 2008-04-28 at 00:50 -0500, Les Mikesell wrote:
Callum Lerwick wrote:
Sure, that was a good argument for pushing gcj in the past. The question is should we focus on gcj or openjdk/icedtea now.
IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed. Thus in an open source environment, Java bytecode has little reason to exist.
Errr, what about applet downloads and RMI, neither of which requires similar architecture or compiling capability at the other end? Are you sure you are talking about something that even resembles java?
You distribute source code, and "JIT" compile it direct from source code, yes. Just like Python or Perl or PHP or Javascript...
And yes, Java wasn't designed for this from the start, so the existing compiler is too slow and heavyweight for this. This may even be impossible. But the interpreted language space is pretty well covered already anyway.
If we're going to *distribute* compiled code, it may as well be nice fast native code.
Yes I know what you're going to say, lots of languages, such as Python do bytecode as well. But they do it as a backend implementation detail, with no guarantee of stability and stored on disk only as a performance optimization, rather than an intentional mechanism for source code obfuscation. IMO we, the open source community, should shun Java bytecode.
It would be better to ship something that follows the spec, or call it something other than java.
If that's what it takes.
I guess what my point is here, is Java, in Sun's implementation, has chosen to stand half-way between a native-compiled language and an interpreted language. Which has resulted in it being mediocre at either and ultimately just serves to inherit the disadvantages of AOT compilation with none of the advantage (speed). If it continues on its current path, it's just going to be eclipsed (heh) by Python on the interpreted side of things and by C# (and continued use of C++ and C) in native compilation. In the open source world, that is. The closed source world will gladly continue cranking out Java code as it is the COBOL of the 90+'s...
Pick a side Java, we're at war.
(Note to the international community: That was a Colbert Report reference.)
On Mon, 28 Apr 2008 19:33:05 -0500, Callum Lerwick scripst:
[will be eclipsed] by C# [...] in native compilation.
Ehm, could you elaborate on this a little bit, please? Since when is C# compiling to the native code? Or does it? (I know almost nothing about C#).
Matěj
Callum Lerwick wrote:
Thus in an open source environment, Java bytecode has little reason to exist.
Errr, what about applet downloads and RMI, neither of which requires similar architecture or compiling capability at the other end? Are you sure you are talking about something that even resembles java?
You distribute source code, and "JIT" compile it direct from source code, yes. Just like Python or Perl or PHP or Javascript...
And yes, Java wasn't designed for this from the start, so the existing compiler is too slow and heavyweight for this. This may even be impossible. But the interpreted language space is pretty well covered already anyway.
Please let me know when you've installed this mythical applet source compiler on all the computers and phones in the world and then we can continue the conversation about equivalent capabilities.
I guess what my point is here, is Java, in Sun's implementation, has chosen to stand half-way between a native-compiled language and an interpreted language.
And with very good reasons, applets and RMI being fairly obvious along with things like cached jsp pages.
Which has resulted in it being mediocre at either and ultimately just serves to inherit the disadvantages of AOT compilation with none of the advantage (speed).
The main speed issue is loading the JVM which might happen once in several months in a server environment and should be handled by the disk cache and shared text in environments where it is reloaded often enough to matter.
If it continues on its current path, it's just going to be eclipsed (heh) by Python on the interpreted side of things and by C# (and continued use of C++ and C) in native compilation.
Except those don't have the same capabilities for remote execution.
In the open source world, that is. The closed source world will gladly continue cranking out Java code as it is the COBOL of the 90+'s...
I think you are missing a fairly vast library of available open source java code.
Les Mikesell wrote:
Callum Lerwick wrote:
The closed source world will gladly continue cranking out Java code as it is the COBOL of the 90+'s...
I think you are missing a fairly vast library of available open source java code.
I think you've been trolled. "COBOL of the 90+'s" is a clue.
Andrew.
2008/4/27 Callum Lerwick seg@haxxed.com:
IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed.
No. Even originally, that isn't true. Having separate source and binary formats gives you a lot of flexibility; for example you can compile source code that uses new features into an older bytecode in a compatibility mode.
If you think the reason it's still around is just obfuscation, try using a modern decompiler.
Thus in an open source environment, Java bytecode has little reason to exist. If we're going to *distribute* compiled code, it may as well be nice fast native code.
1) Hotspot does a fine job of creating native code. 2) There are a *ton* of languages other than Java that run on top of the JVM that compile to bytecode. JRuby, to name one. 3) It's simply not worth trying to go against the grain of the entire Java community here.
On Mon, 2008-04-28 at 09:01 -0400, Colin Walters wrote:
2008/4/27 Callum Lerwick seg@haxxed.com:
IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed.
No. Even originally, that isn't true.
You don't honestly believe that, do you?
Having separate source and binary formats gives you a lot of flexibility; for example you can compile source code that uses new features into an older bytecode in a compatibility mode.
... Which is completely moot if you're not distributing bytecode in the first place.
If you think the reason it's still around is just obfuscation, try using a modern decompiler.
Decompilers don't bring back comments or documentation. And commercial joints protective of their source inevitably use a post-processor to obfuscate class and method names (and possibly even more evil things) as well:
http://www.google.com/search?q=java+bytecode+obfuscator
Technically, you can de-compile native binaries too. They're reverse-engineered all the time.
Thus in an open source environment, Java bytecode has little reason to exist. If we're going to *distribute* compiled code, it may as well be nice fast native code.
- Hotspot does a fine job of creating native code.
Unless it's somehow faster than AOT-compiled native code, that's a non-argument.
- There are a *ton* of languages other than Java that run on top of
the JVM that compile to bytecode. JRuby, to name one.
Which are all as equally pointless as Java itself. My argument applies to them as well.
- It's simply not worth trying to go against the grain of the entire
Java community here.
You're absolutely right. The FLOSS community standing up for itself and going against the grain of closed source software? What the hell was I thinking...
I rescind my argument.
2008/4/28 Callum Lerwick seg@haxxed.com:
On Mon, 2008-04-28 at 09:01 -0400, Colin Walters wrote:
2008/4/27 Callum Lerwick seg@haxxed.com:
IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed.
No. Even originally, that isn't true.
You don't honestly believe that, do you?
I do, in fact.
I think this crusade against bytecode that you're talking about is largely at best a waste of time and resources. If you have reliable benchmarks for specific real-world programs shipped in Fedora (i.e. not synthetic benchmarks) where AOT compilation (be that via GCJ or Hotspot's) is better, it might make sense to do so for those programs.
On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote:
Jesse Keating wrote:
On Tue, 2008-04-15 at 17:53 -0500, Les Mikesell wrote:
If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?
GCJ runs Eclipse, which is a pretty important tool to a lot of people.
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
We don't carry any patches to the Eclipse SDK to build/run with gcj.
Andrew
"Andrew" == Andrew Overholt overholt@redhat.com writes:
Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?
Andrew> We don't carry any patches to the Eclipse SDK to build/run Andrew> with gcj.
Yeah, but unfortunately all that means is that the man-hours went into gcj, not Eclipse.
How hard it is to bring up a random java program under gcj depends on the program. Some programs do bad things (use of com.sun.* is a typical problem, for instance) and are difficult. Some programs are well-behaved and don't use the few packages gcj does not support, and are easy. Unless you're an expert on both the package and gcj it is hard to predict the amount of effort without trying it.
Tom
On Tue, 2008-04-15 at 17:53 -0500, Les Mikesell wrote:
Lubomir Kundrak wrote:
Why not? Getting rid of legacy cruft sounds like an brilliantly elegant solution to me. But probably not applicable here, as GCJ doesn't really fall into that category, given it still outperforms OpenJDK by the factor of 10 on ppc.
If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?
The "benchmark" I used was compiling OpenJDK itself on ppc.
Lubomir Kundrak wrote:
On Tue, 2008-04-15 at 17:53 -0500, Les Mikesell wrote:
Lubomir Kundrak wrote:
Why not? Getting rid of legacy cruft sounds like an brilliantly elegant solution to me. But probably not applicable here, as GCJ doesn't really fall into that category, given it still outperforms OpenJDK by the factor of 10 on ppc.
If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?
The "benchmark" I used was compiling OpenJDK itself on ppc.
The speed ratio between gcj's interpreter and OpenJDK's C++ interpreter varies depending on the load, but always seems to be in favour of gcj by a ratio of at least 1.6. gcj precompilation improves that a lot, as you might expect, and the code I've tried runs about 10 times faster when precompiled on gcj than on OpenJDK's C++ interpreter. We're working on improving OpenJDK's performance on ppc and other Fedora arches.
Andrew.
Lubomir Kundrak wrote:
Or ugly solution -- wait two months ;-) Then all supported Fedoras will have JDK.
No, I am not serious.
Why not? Getting rid of legacy cruft sounds like an brilliantly elegant solution to me. But probably not applicable here, as GCJ doesn't really fall into that category, given it still outperforms OpenJDK by the factor of 10 on ppc.
There's a deeper issue. Projects like ours ours (Frysk) used gcj and related technology from the ground up. When Frysk was (and still is) being developed we used a lot of the newer/faster/better implementations of specific Java technologies that gcj brought with it, like CNI over JNI.
Now moving onto the brave new future things have changed. But that still requires specific tasks to be completed before the move from gcj -> IcedTea. The largest is converting CNI code to JNI code in projects that choose to use CNI. It's happening, but it takes times.
Regards
Phil
"Phil" == Phil Muldoon pmuldoon@redhat.com writes:
Phil> Now moving onto the brave new future things have changed. But Phil> that still requires specific tasks to be completed before the Phil> move from gcj -> IcedTea. The largest is converting CNI code to Phil> JNI code in projects that choose to use CNI. It's happening, but Phil> it takes times.
I think this is a different issue. A program like frysk that was written using gcj features will depend on gcj... but the question AIUI is what to do about pure java packages.
Tom
-
Andrew Haley -
Andrew Overholt -
Callum Lerwick -
Colin Walters -
Jerry James -
Jesse Keating -
Les Mikesell -
Lubomir Kundrak -
Matej Cepl -
Nicolas Mailhot -
Phil Muldoon -
Rahul Sundaram -
Tom Tromey -
Toshio Kuratomi