On Thu, Apr 28, 2005 at 11:42:45AM +0200, Arnaud Vandyck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (spring cleaning in my mailboxes... ;-)) > > 29 Mar 2005 21:35:23 +0200, > [EMAIL PROTECTED] (David N. Welton) wrote: > > Hi David, > > > "Michael Koch" <[EMAIL PROTECTED]> writes: > > Hi Michael, > > >> I see no reason to imidiately switch everything to eclipse-ecj and > >> gcc-4.0 when it hits debian. We live from freedom of choice and mono > >> cultures are bad. > > Which java compilers do we use? > > 1� Most packages use jikes; > 2� Some packages (very few) in contrib uses non-free javac, but a lot of > packages in contrib also uses jikes; > 3� Less then 10 packages uses gcj > > So moving from jikes to ecj is not a problem for me ;-) > > I'll discuss of the gcj-4.0 native problem later. > > > We've talked about this some before, but I'll put in my two cents here > > for "choice is ok, but sometimes too much choice is bad". The > > difficult thing is defining "too much choice". People are often > > worried about choices, especially in cases where a "wrong" choice > > might cost them invested time or money. And they are even more > > worried when they don't have the tools or knowledge to evaluate that > > choice as well as an expert could. > > > > One of the reasons Ubuntu has been successful, IMO, is that there are > > fewer choices to make. Experts have made them for you - although if > > you are an expert yourself, of course you can 'fix' any changes that > > you don't care for. > > Ubuntu has been successful for a lot of reasons, I don't think fewer > choices was one of the reasons. Also, what is an expert and how can I > trust them? I can give you the name of five or four expert reading this > list and they'll tell you five different very good free JVM ;-) > > About the native choice: > - ------------------------ > > I'm very sorry to read this thread so late. When I saw it I was busy and > was thinking: Whoaw too complicated to read after a day at work! ;-) > Well, that's my fault. > > As Michael pointed out, we first need to have benchmarks to know if > there are real advantages to compile things to native. Also, we could > make choice: do we need to build the libs and the apps? only the apps? > Which one? Is it more important to build ant then tomcat? gjdoc then > eclipse? I don't know. > > When we (Stefan Gybas and I) met Tom Tromey back in FOSDEM in 2003, we > talked with him after his presentation of gcj and we were really > impressed. We really would like to have this in Debian as soon as > possible. He told us to wait for the compatibility ABI (I think this is > now done with gcj-4.0). Now that it is done, we have to think about > several problems: the first is the gain (as Michael pointed), the second > is that when running a native java application, you can relay on a > unique VM (that's also the choice problem Michael pointed out).
Its most likely that the BC-ABI will slightly change for gcj-4.1 but hopefully stable afterwards. > Choosing a single compiler is not really a problem IMHO because we build > the packages from sources and it's very easy to change the compiler and > rebuild the package. Also, we have only one gcc! ;-) > > But choosing the VM when there are a lot of different ones is not a good > thing for our users. I said when there are a lot of different ones > because we have a single perl interpreter, a single python > interpreter... but a lot of shells. > > If we choose to build java packages to native, they will relay *only* on > gcj. Let's hope it'll never have RC bugs! The important thing is to keep > to ship the bytecode and when we'll have some benchmarks or some > positive feedbacks, we'll try to maybe add cdbs template or create an > 'ant task'. That would be good to have and it has to be "mentioned" in the java policy. The policy update is our biggest problem nowadays as I see it It is totally out of date and needs to to be completely redone for after-sarge anyway. I will try to start something with it soon. Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
