Re: test if there is a gain
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,
> davidw@dedasys.com (David N. Welton) wrote:
>
> Hi David,
>
> > "Michael Koch" <konqueror@gmx.de> 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/
Reply to: