From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MwhEd-0004zN-SB for garchives@archives.gentoo.org; Sat, 10 Oct 2009 19:04:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E8A2E07C9; Sat, 10 Oct 2009 19:04:07 +0000 (UTC) Received: from mailfilter44.ihug.co.nz (mailfilter44.ihug.co.nz [203.109.136.44]) by pigeon.gentoo.org (Postfix) with ESMTP id BB26CE07C9 for ; Sat, 10 Oct 2009 19:04:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAH930Ep2Xa5P/2dsb2JhbACBUtYThC0EgViGCA X-IronPort-AV: E=Sophos;i="4.44,538,1249214400"; d="scan'208";a="137943157" Received: from 118-93-174-79.dsl.dyn.ihug.co.nz (HELO linux.localnet) ([118.93.174.79]) by smtp.mailfilter6.ihug.co.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Oct 2009 08:04:05 +1300 From: Alistair Bush Organization: Gentoo Linux To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] RFC: JDK version handling in the future Date: Sun, 11 Oct 2009 08:04:19 +1300 User-Agent: KMail/1.12.1 (Linux/2.6.31-gentoo; KDE/4.3.1; x86_64; ; ) References: <4AD0667F.8070600@gentoo.org> In-Reply-To: <4AD0667F.8070600@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200910110804.19321.ali_bush@gentoo.org> X-Archives-Salt: c22156b9-e510-4596-a479-ea38244c949b X-Archives-Hash: 628d78a776a43fae81c69f6fff6f29df > Inspired by the recent ruby version handling post on gentoo-dev I came > up with this scheme to handle JDK versions in the future: While we are at it, could we consider the implications of jigsaw? And possibly start working in the hooks to support that functionality. For anyone why doesn't know jigsaw is the modularisation of java. Read http://openjdk.java.net/projects/jigsaw/ It seems to be based off debians version policy. see http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > > 1. Have a JAVA_VERSION USE_EXPAND variable containing: "java5 java6" or > any JDK versions supported at that time. > > 2. The minimum flag that is on is used for the JDK version to emerge > things. Just setting -source is not in reality making things run with > the target, it just makes the bytecode usable for older JDKs. > > 3. When depending on something java the eclasses will automatically pull > in libraries targeting the right JDK using EAPI 2 use dependencies. > > Benefits: > - You can compile everything to the highest byte code available > - Simpler maintenance and marginally faster emerges when build.xml files > don't always need to be rewritten. > - Solve bug 161622 (java-config should look into the deptree when > deciding wich vm to use) > > If this seem sane, it's best to rewrite the eclasses at the same time to > delete all the cruft that we have collected over time like the different > rewriter implementations. > > Regards, > Petteri >