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 1FoEdV-0002J8-WE for garchives@archives.gentoo.org; Thu, 08 Jun 2006 07:08:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k5877SLc012302; Thu, 8 Jun 2006 07:07:28 GMT Received: from mail.spikesource.com (gw1-ss-fe0.spikesource.com [209.10.209.56] (may be forged)) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k5877QMZ008780 for ; Thu, 8 Jun 2006 07:07:27 GMT Received: from [192.168.64.102] ([::ffff:192.168.64.102]) by mail.spikesource.com with esmtp; Thu, 08 Jun 2006 00:07:23 -0700 id 00370CDC.4487CCAB.00007B93 Message-ID: <4487CCC1.5010504@spikesource.com> Date: Thu, 08 Jun 2006 00:07:45 -0700 From: Calvin Austin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1 X-Accept-Language: en-us, en 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 To: David Herron , Caster CC: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5? References: <44833F92.1020201@seznam.cz> <44843F50.4020706@seznam.cz> <4484ADDC.2010105@sun.com> <44854829.4000002@seznam.cz> <448584AA.1040300@sun.com> In-Reply-To: <448584AA.1040300@sun.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: b10ee04b-ac42-463a-9999-d949bd7fda0e X-Archives-Hash: 870a24cda45ef62e07a8209b569e46ab David Herron wrote: > Okay, that helps. > > I'm not a compiler expert but here's a couple factoids: 1) we're > always working to improve performance, 2) the compiler team is always > working on improving the compiler (fix bugs etc), 3) the generated > byte codes can either exhibit certain bugs or performance gains/losses > ... hence, hence I expect/assume the byte codes output to vary > somewhat from release to relase. > > I can't say how much or what specifically that would be. > > - David > > > Caster wrote: > >>Greg Tassone wrote: >> >> >>>I think this statement is a little too broad to be considered correct. >>>The compiler can (and often does) make changes to the resulting binaries >>>that may be VM-level specific (e.g., targeted for a 1.5 VM). Consider >>>the "-target" argument for javac, for example, which "Allow[s] javac to >>>use 1.5 specific features in the libraries and virtual >>>machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ). >>> >>David Herron wrote: >> >> >>>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? >>> >> >>Sorry, I wasn't clear enough. I didn't mean the class file format which >>is indeed different and causes problems. I was trying to ask if there >>are any (the compiled bytecode performance?) gains of using 1.5 compiler >>for 1.4 source (without specifying --source and --target 1.4). This >>source won't use any 1.5 specific features, but you say the bytecode >>still can somehow? >> >>Caster >> >> >> This seems like a long time ago to me, but originally there were major changes planned for the class format in 5.0 that fell through and ultimately resulted in very minor changes to the classfile format. Most of the language changes used existing compatible mechanisms to extend the classfile (attributes) or were essentially compiler generated for you. So in normal use the Java 5 bytecode for vanilla 1.4 source (which is 5 compliant) isn't going to make any difference compared to the jvm improvements like class data sharing in the sun jvm or jvm/jdk class libraries regards calvin -- gentoo-java@gentoo.org mailing list