From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FnNRB-0002ob-Iz for garchives@archives.gentoo.org; Mon, 05 Jun 2006 22:20:42 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k55MJC7e023950; Mon, 5 Jun 2006 22:19:12 GMT Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k55MJAel003446 for ; Mon, 5 Jun 2006 22:19:10 GMT Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k55MJ9uA012161 for ; Mon, 5 Jun 2006 16:19:09 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0E00E01QIB6000@mail-amer.sun.com> (original mail from David.Herron@Sun.COM) for gentoo-java@lists.gentoo.org; Mon, 05 Jun 2006 16:19:09 -0600 (MDT) Received: from [129.145.161.173] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0E00MWTRBWIGC3@mail-amer.sun.com>; Mon, 05 Jun 2006 16:19:08 -0600 (MDT) Date: Mon, 05 Jun 2006 15:19:08 -0700 From: David Herron Subject: Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5? In-reply-to: <44843F50.4020706@seznam.cz> Sender: David.Herron@Sun.COM To: Caster Cc: gentoo-java@lists.gentoo.org Message-id: <4484ADDC.2010105@sun.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h/V5vbXE7omh+btpXiKErg)" References: <44833F92.1020201@seznam.cz> <44843F50.4020706@seznam.cz> User-Agent: Thunderbird 1.5.0.4 (X11/20060516) X-Archives-Salt: 7a572c95-d81a-4d75-9c51-6222876ab133 X-Archives-Hash: 297fc1a74e84ebcca6f20d70d3e2bab5 This is a multi-part message in MIME format. --Boundary_(ID_h/V5vbXE7omh+btpXiKErg) Content-type: text/plain; format=flowed; charset=windows-1252 Content-Transfer-Encoding: 7BIT er... Caster, the bytecode does vary based on the compiler. And the class file format has varied a small amount from release to release with the 1.5 class file format being the most different. This is, as I understand it, the crux of the problem you guys are seeing with adopting 1.5 ... yes? - David Caster wrote: >> Actually, what I was asking was _would_ it work without the overlay? I >> mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a >> potential for trouble. But when it's just marked (whether by laziness or >> whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could >> work. >> > > No idea, how much the dependencies correspond with "would/wouldn't > work". I wouldn't bet on that. The question, why would you so > desperately try to have 1.5 JDK as (generation-1 without migration > overlay) system vm? It can only break things, and gain you nothing. > Somebody correct me if I'm wrong, but the bytecode compiled will be the > same no matter which JDK you use. Any optimisations are done with > run-time JIT compiling, and depends on the VM running the bytecode > (which can be different from the VM used to compile). So, without > migration overlay, you should best follow the java 1.5 faq, have 1.4 as > sytem vm and use whatever vm as user vm. > > Caster > --Boundary_(ID_h/V5vbXE7omh+btpXiKErg) Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k55MJC83023950
er... Caster, the bytecode does vary based on the compiler.=A0 And the class file format has varied a small amount from release to release with the 1.5 class file format being the most different.

This is, as I understand it, the crux of the problem you guys are seeing with adopting 1.5 ... yes?

- David


Caster wrote: 
Actually, what I was asking was _would_ it work withou=
t the overlay? I
mean, if the ebuild is marked =3Dvirtual/jdk-1.4, then I could understand=
 a
potential for trouble. But when it's just marked (whether by laziness or
whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could
work.
    

No idea, how much the dependencies correspond with "would/wouldn't
work". I wouldn't bet on that. The question, why would you so
desperately try to have 1.5 JDK as (generation-1 without migration
overlay) system vm? It can only break things, and gain you nothing.
Somebody correct me if I'm wrong, but the bytecode compiled will be the
same no matter which JDK you use. Any optimisations are done with
run-time JIT compiling, and depends on the VM running the bytecode
(which can be different from the VM used to compile). So, without
migration overlay, you should best follow the java 1.5 faq, have 1.4 as
sytem vm and use whatever vm as user vm.

Caster
--Boundary_(ID_h/V5vbXE7omh+btpXiKErg)-- -- gentoo-java@gentoo.org mailing list