From volker.simonis at gmail.com Fri Feb 1 02:01:20 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Feb 2013 11:01:20 +0100 Subject: PowerPC/AIX Port successfully passed the Java SE 7 TCK on Linux and AIX Message-ID: During the last weeks we worked hard to stabilize our port and yesterday it successfully passed all the Java SE 7 Test Compatibility Kit (TCK) tests on SLES 11.1 Linux/PPC64 and AIX 5.3/PPC64. This means that the port is now fully compliant with the Java SE 7 specification on the named platforms. Regards, Volker From mark.reinhold at oracle.com Fri Feb 1 02:11:37 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 1 Feb 2013 11:11:37 +0100 (CET) Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 Message-ID: <20130201101137.21589C0B@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/175 - Mark From david.holmes at oracle.com Fri Feb 1 03:15:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 21:15:02 +1000 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <20130201101137.21589C0B@eggemoggin.niobe.net> References: <20130201101137.21589C0B@eggemoggin.niobe.net> Message-ID: <510BA3B6.9090002@oracle.com> On 1/02/2013 8:11 PM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/175 I'm forced to send this to porters-dev but I do not subscribe to that list (so it will probably get held up). Given the way the JEP tasks have been split it would seem much more appropriate to me for discussions to occur on hotspot-dev and core-libs-dev as this, as the JEP says, is about the integration effort not the porting effort. That said this is also relevant to jdk8-dev, also cc'd, as it affects all JDK 8 development. I have trouble seeing how such a large effort can be assimilated within the timeframes of the Java 8 schedule. David > - Mark From volker.simonis at gmail.com Fri Feb 1 04:11:44 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Feb 2013 13:11:44 +0100 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <20130201101137.21589C0B@eggemoggin.niobe.net> References: <20130201101137.21589C0B@eggemoggin.niobe.net> Message-ID: Thank you Mark, that was really fast! Are you sleepless in Brussels:) On Fri, Feb 1, 2013 at 11:11 AM, wrote: > Posted: http://openjdk.java.net/jeps/175 > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130201/448ed9a3/attachment.html From volker.simonis at gmail.com Fri Feb 1 05:57:22 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Feb 2013 14:57:22 +0100 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <510BA3B6.9090002@oracle.com> References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> Message-ID: On Fri, Feb 1, 2013 at 12:15 PM, David Holmes wrote: > On 1/02/2013 8:11 PM, mark.reinhold at oracle.com wrote: > >> Posted: http://openjdk.java.net/jeps/**175 >> > > I'm forced to send this to porters-dev but I do not subscribe to that list > (so it will probably get held up). > > Given the way the JEP tasks have been split it would seem much more > appropriate to me for discussions to occur on hotspot-dev and core-libs-dev > as this, as the JEP says, is about the integration effort not the porting > effort. > Yes, I agree. I just wanted to wait until the JEP was published before posting it to the appropriate lists > > That said this is also relevant to jdk8-dev, also cc'd, as it affects all > JDK 8 development. I have trouble seeing how such a large effort can be > assimilated within the timeframes of the Java 8 schedule. > > As previously discussed on porters-dev the current target is not the first JDK 8 release but rather the first non-security update (i.e. something like JDK 8u2) Regards, Volker David > > - Mark >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130201/c3d65cbb/attachment.html From spoole at linux.vnet.ibm.com Fri Feb 1 08:22:57 2013 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Fri, 1 Feb 2013 16:22:57 +0000 Subject: PowerPC/AIX Port successfully passed the Java SE 7 TCK on Linux and AIX In-Reply-To: References: Message-ID: Jolly Good! - fantastic news. On 1 Feb 2013, at 10:01, Volker Simonis wrote: > During the last weeks we worked hard to stabilize our port and yesterday > it successfully passed all the Java SE 7 Test Compatibility Kit (TCK) tests > on SLES 11.1 Linux/PPC64 and AIX 5.3/PPC64. This means that the port is > now fully compliant with the Java SE 7 specification on the named platforms. > > Regards, > Volker > From volker.simonis at gmail.com Sat Feb 2 03:03:48 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 2 Feb 2013 12:03:48 +0100 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <510C135D.4020105@oracle.com> References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> Message-ID: On Fri, Feb 1, 2013 at 8:11 PM, Phil Race wrote: > As previously discussed on porters-dev the current target is not the first >> JDK 8 release but rather the first non-security update (i.e. something >> like >> JDK 8u2) >> > > Given the scale and timing, isn't JDK 9 a more appropriate target ? > The goal of a JDK 8 update 2, *should* be stabilisation, and this sounds > rather the opposite. > It also introduces logistic issues like ramping up infrastructure which in > my experience > can't solved all that quickly. > > Well, the MacOS X port made it into 7u4 and we're of course keen to do it better:) What do you mean with "ramping up infrastructure": - hardware resources (like test/build infrastructure)? - human resources within Oracle? - human resources within IBM/SAP? I think we have most of these allocated (except the Oracle part which I can not speak about:) -phil. > > > On 2/1/2013 5:57 AM, Volker Simonis wrote: > >> On Fri, Feb 1, 2013 at 12:15 PM, David Holmes ** >> wrote: >> >> On 1/02/2013 8:11 PM, mark.reinhold at oracle.com wrote: >>> >>> Posted: http://openjdk.java.net/jeps/****175 >>>> > >>>> >>>> I'm forced to send this to porters-dev but I do not subscribe to that >>> list >>> (so it will probably get held up). >>> >>> Given the way the JEP tasks have been split it would seem much more >>> appropriate to me for discussions to occur on hotspot-dev and >>> core-libs-dev >>> as this, as the JEP says, is about the integration effort not the porting >>> effort. >>> >>> Yes, I agree. I just wanted to wait until the JEP was published before >> posting it to the appropriate lists >> >> >> That said this is also relevant to jdk8-dev, also cc'd, as it affects all >>> JDK 8 development. I have trouble seeing how such a large effort can be >>> assimilated within the timeframes of the Java 8 schedule. >>> >>> >>> As previously discussed on porters-dev the current target is not the >> first >> JDK 8 release but rather the first non-security update (i.e. something >> like >> JDK 8u2) >> >> Regards, >> Volker >> >> David >> >>> - Mark >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130202/8cd8437a/attachment.html From david.holmes at oracle.com Sat Feb 2 04:42:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 22:42:42 +1000 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> Message-ID: <510D09C2.5090306@oracle.com> On 2/02/2013 9:03 PM, Volker Simonis wrote: > On Fri, Feb 1, 2013 at 8:11 PM, Phil Race > wrote: > > As previously discussed on porters-dev the current target is not the first > JDK 8 release but rather the first non-security update (i.e. > something like JDK 8u2) > > Given the scale and timing, isn't JDK 9 a more appropriate target ? > The goal of a JDK 8 update 2, *should* be stabilisation, and this > sounds rather the opposite. > It also introduces logistic issues like ramping up infrastructure > which in my experience can't solved all that quickly. > > Well, the MacOS X port made it into 7u4 and we're of course keen to do > it better:) That's probably not likely. The first update is generally intended to be a stabilization update (bug fixes only) as 7u2 was. So 8u4 seems the more likely target. Certainly I would like to see this come about well before Java 9 though. That said the simple logistics of repository management means the integration may not be able to start for some time. Until there is a forked forest where these changes can be integrated without affecting earlier updates (unduly) then it can't start. Historically that would not happen until after 8u2 has been frozen, but that might not leave enough time till 8u4. There may be some changes needed to how the 8u project is setup and handled. And I guess the 8u project needs to come into existence first as well. I think the "risks" are a little under-stated. You have changed shared code and that potentially impacts all platforms (unless you have only added new functions unused on existing platforms?). There is also the matter of the "elephant in the room" - the existing proprietary PPC port that Oracle has for Java SE Embedded. Someone (from Oracle of course) will have to see how the proposed structure of the new port will impact the existing closed port. It might be a non-issue, or a major issue - most likely somewhere in between. I am also hoping that this will not simply be a copy'n'modify port as we have seen in the past. The proliferation of platform ifdefs in shared code is truly horrendous; as is the duplication across the purportedly platform-specific code. This problem wasn't addressed for the Mac port but in my opinion (and that is all it is) it needs to be before the community accepts any further ports. I'd also like to understand the proposed maintenance model going forward. We (in Oracle) already have to accommodate our closed ports when they are affected by changes to common code that requires per-platform changes as well. Who will be providing the changes needed for aix-ppc? And how will that happen? Again I think the big picture issues need to discussed on jdk8-dev (or perhaps it is time to start jdk8u-dev?) before getting into changeset specifics for hotspot and core-libs. Thanks, David ----- > What do you mean with "ramping up infrastructure": > - hardware resources (like test/build infrastructure)? > - human resources within Oracle? > - human resources within IBM/SAP? > > I think we have most of these allocated (except the Oracle part which I > can not speak about:) > > > -phil. > > > On 2/1/2013 5:57 AM, Volker Simonis wrote: > > On Fri, Feb 1, 2013 at 12:15 PM, David Holmes > >__wrote: > > On 1/02/2013 8:11 PM, mark.reinhold at oracle.com > wrote: > > Posted: http://openjdk.java.net/jeps/*__*175 > > > > I'm forced to send this to porters-dev but I do not > subscribe to that list > (so it will probably get held up). > > Given the way the JEP tasks have been split it would seem > much more > appropriate to me for discussions to occur on hotspot-dev > and core-libs-dev > as this, as the JEP says, is about the integration effort > not the porting > effort. > > Yes, I agree. I just wanted to wait until the JEP was published > before > posting it to the appropriate lists > > > That said this is also relevant to jdk8-dev, also cc'd, as > it affects all > JDK 8 development. I have trouble seeing how such a large > effort can be > assimilated within the timeframes of the Java 8 schedule. > > > As previously discussed on porters-dev the current target is not > the first > JDK 8 release but rather the first non-security update (i.e. > something like > JDK 8u2) > > Regards, > Volker > > David > > - Mark > > > From mark.reinhold at oracle.com Mon Feb 4 00:22:48 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 04 Feb 2013 09:22:48 +0100 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: david.holmes@oracle.com; Sat, 02 Feb 2013 22:42:42 +1000; <510D09C2.5090306@oracle.com> Message-ID: <20130204082248.97A86E5C@eggemoggin.niobe.net> 2013/2/2 13:42 +0100, david.holmes at oracle.com: > ... > > I think the "risks" are a little under-stated. You have changed shared code and > that potentially impacts all platforms (unless you have only added new > functions unused on existing platforms?). There is also the matter of the > "elephant in the room" - the existing proprietary PPC port that Oracle has for > Java SE Embedded. Someone (from Oracle of course) will have to see how the > proposed structure of the new port will impact the existing closed port. It > might be a non-issue, or a major issue - most likely somewhere in between. Either way, issues with a proprietary port that's downstream of OpenJDK are for the maintainers of that port to solve, regardless of whether the maintainers work for Oracle. The existence of a proprietary port cannot hold back the contribution of an open port. > I am also hoping that this will not simply be a copy'n'modify port as we have > seen in the past. The proliferation of platform ifdefs in shared code is truly > horrendous; as is the duplication across the purportedly platform-specific > code. This problem wasn't addressed for the Mac port but in my opinion (and > that is all it is) it needs to be before the community accepts any further > ports. I think it'd be a fine thing for that code to be refactored and cleaned up, but I don't see that as a prerequisite for a new port coming in. > I'd also like to understand the proposed maintenance model going forward. We > (in Oracle) already have to accommodate our closed ports when they are affected > by changes to common code that requires per-platform changes as well. Who will > be providing the changes needed for aix-ppc? And how will that happen? Every port needs a documented set of maintainers, and it's up to the maintainers to track changes in shared code. If a port stops being maintained and rots for a significant period of time then it's likely to be removed. This is how similar long-lived projects (e.g., GCC) work. Now that a port that's to be maintained by non-Oracle developers is being proposed, I will soon propose a formal policy along these lines. - Mark From david.holmes at oracle.com Mon Feb 4 00:42:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Feb 2013 18:42:10 +1000 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <20130204082248.97A86E5C@eggemoggin.niobe.net> References: <20130204082248.97A86E5C@eggemoggin.niobe.net> Message-ID: <510F7462.5040006@oracle.com> Hi Mark, On 4/02/2013 6:22 PM, mark.reinhold at oracle.com wrote: > 2013/2/2 13:42 +0100, david.holmes at oracle.com: >> ... >> >> I think the "risks" are a little under-stated. You have changed shared code and >> that potentially impacts all platforms (unless you have only added new >> functions unused on existing platforms?). There is also the matter of the >> "elephant in the room" - the existing proprietary PPC port that Oracle has for >> Java SE Embedded. Someone (from Oracle of course) will have to see how the >> proposed structure of the new port will impact the existing closed port. It >> might be a non-issue, or a major issue - most likely somewhere in between. > > Either way, issues with a proprietary port that's downstream of OpenJDK > are for the maintainers of that port to solve, regardless of whether the > maintainers work for Oracle. The existence of a proprietary port cannot > hold back the contribution of an open port. Ok. > >> I am also hoping that this will not simply be a copy'n'modify port as we have >> seen in the past. The proliferation of platform ifdefs in shared code is truly >> horrendous; as is the duplication across the purportedly platform-specific >> code. This problem wasn't addressed for the Mac port but in my opinion (and >> that is all it is) it needs to be before the community accepts any further >> ports. > > I think it'd be a fine thing for that code to be refactored and cleaned > up, but I don't see that as a prerequisite for a new port coming in. The code base will be unmanageable if we keep doing this copy'n'modify approach to porting, and the more ports we add the more impractical it becomes to try and retrofit a cleaner porting architecture. The OSX/bsd port is still causing us "indigestion". >> I'd also like to understand the proposed maintenance model going forward. We >> (in Oracle) already have to accommodate our closed ports when they are affected >> by changes to common code that requires per-platform changes as well. Who will >> be providing the changes needed for aix-ppc? And how will that happen? > > Every port needs a documented set of maintainers, and it's up to the > maintainers to track changes in shared code. If a port stops being > maintained and rots for a significant period of time then it's likely to > be removed. This is how similar long-lived projects (e.g., GCC) work. Even if there are designated maintainers there is still a matter of how things will proceed. If someone is changing shared code who has the responsibility for making sure every port is accounted for? Do we have to coordinate things so that no changes are made until all changes are ready? Or do we allow things to break until the designated maintainers catch up? > Now that a port that's to be maintained by non-Oracle developers is being > proposed, I will soon propose a formal policy along these lines. That would be good to see. Thanks, David > - Mark From volker.simonis at gmail.com Mon Feb 4 02:50:29 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Feb 2013 11:50:29 +0100 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <510D09C2.5090306@oracle.com> References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> <510D09C2.5090306@oracle.com> Message-ID: On Sat, Feb 2, 2013 at 1:42 PM, David Holmes wrote: > On 2/02/2013 9:03 PM, Volker Simonis wrote: > >> On Fri, Feb 1, 2013 at 8:11 PM, Phil Race > > wrote: >> >> As previously discussed on porters-dev the current target is not the first >> JDK 8 release but rather the first non-security update (i.e. >> something like JDK 8u2) >> >> Given the scale and timing, isn't JDK 9 a more appropriate target ? >> The goal of a JDK 8 update 2, *should* be stabilisation, and this >> sounds rather the opposite. >> It also introduces logistic issues like ramping up infrastructure >> which in my experience can't solved all that quickly. >> >> Well, the MacOS X port made it into 7u4 and we're of course keen to do >> it better:) >> > > That's probably not likely. The first update is generally intended to be a > stabilization update (bug fixes only) as 7u2 was. So 8u4 seems the more > likely target. Certainly I would like to see this come about well before > Java 9 though. > > That said the simple logistics of repository management means the > integration may not be able to start for some time. Until there is a forked > forest where these changes can be integrated without affecting earlier > updates (unduly) then it can't start. Historically that would not happen > until after 8u2 has been frozen, but that might not leave enough time till > 8u4. There may be some changes needed to how the 8u project is setup and > handled. And I guess the 8u project needs to come into existence first as > well. > > The plan is to bring our port within our porting repository up to the current jdk8 tip revision within the next two month or so and keep it there (i.e. synchronize it weekly). I think this will allow us to do most of the review work in the jdk8 or jdk8u-dev repository (whichever my be available at that time) and then back-port the changes to the appropriate 8uX repository once they are created (much like this is done now for 7u). > I think the "risks" are a little under-stated. You have changed shared > code and that potentially impacts all platforms (unless you have only added > new functions unused on existing platforms?). There is also the matter of > the "elephant in the room" - the existing proprietary PPC port that Oracle > has for Java SE Embedded. Someone (from Oracle of course) will have to see > how the proposed structure of the new port will impact the existing closed > port. It might be a non-issue, or a major issue - most likely somewhere in > between. > I am also hoping that this will not simply be a copy'n'modify port as we > have seen in the past. The proliferation of platform ifdefs in shared code > is truly horrendous; as is the duplication across the purportedly > platform-specific code. This problem wasn't addressed for the Mac port but > in my opinion (and that is all it is) it needs to be before the community > accepts any further ports. > > That would be nice but that is not and can not be the focus of this port. It would also have a much bigger impact on all the currently supported platforms than doing it in the way how all the other ports have been done until now. That said, we would warmly welcome any initiative (maybe a JEP) for refactoring the class library to make it more portable. JDK9 may probably be the appropriate target for such a project. > I'd also like to understand the proposed maintenance model going forward. > We (in Oracle) already have to accommodate our closed ports when they are > affected by changes to common code that requires per-platform changes as > well. Who will be providing the changes needed for aix-ppc? And how will > that happen? > > The changesets will of course be provided by us (IBM and SAP). How this will happen is up to the OpenJDK cummunity and Oracle. Mark promised to propose a formal policy for how this may look like. > Again I think the big picture issues need to discussed on jdk8-dev (or > perhaps it is time to start jdk8u-dev?) before getting into changeset > specifics for hotspot and core-libs. > > Thanks, > David > ----- > > > What do you mean with "ramping up infrastructure": >> - hardware resources (like test/build infrastructure)? >> - human resources within Oracle? >> - human resources within IBM/SAP? >> >> I think we have most of these allocated (except the Oracle part which I >> can not speak about:) >> >> >> -phil. >> >> >> On 2/1/2013 5:57 AM, Volker Simonis wrote: >> >> On Fri, Feb 1, 2013 at 12:15 PM, David Holmes >> >> >>__wrote: >> >> >> On 1/02/2013 8:11 PM, mark.reinhold at oracle.com >> > >> wrote: >> >> Posted: http://openjdk.java.net/jeps/***__*175 >> >> > >> >> >> >> >> >> I'm forced to send this to porters-dev but I do not >> subscribe to that list >> (so it will probably get held up). >> >> Given the way the JEP tasks have been split it would seem >> much more >> appropriate to me for discussions to occur on hotspot-dev >> and core-libs-dev >> as this, as the JEP says, is about the integration effort >> not the porting >> effort. >> >> Yes, I agree. I just wanted to wait until the JEP was published >> before >> posting it to the appropriate lists >> >> >> That said this is also relevant to jdk8-dev, also cc'd, as >> it affects all >> JDK 8 development. I have trouble seeing how such a large >> effort can be >> assimilated within the timeframes of the Java 8 schedule. >> >> >> As previously discussed on porters-dev the current target is not >> the first >> JDK 8 release but rather the first non-security update (i.e. >> something like >> JDK 8u2) >> >> Regards, >> Volker >> >> David >> >> - Mark >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130204/ae10474a/attachment.html From david.holmes at oracle.com Mon Feb 4 03:39:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Feb 2013 21:39:08 +1000 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> <510D09C2.5090306@oracle.com> Message-ID: <510F9DDC.1020401@oracle.com> On 4/02/2013 8:50 PM, Volker Simonis wrote: > On Sat, Feb 2, 2013 at 1:42 PM, David Holmes I am also hoping that this will not simply be a copy'n'modify port > as we have seen in the past. The proliferation of platform ifdefs in > shared code is truly horrendous; as is the duplication across the > purportedly platform-specific code. This problem wasn't addressed > for the Mac port but in my opinion (and that is all it is) it needs > to be before the community accepts any further ports. > > That would be nice but that is not and can not be the focus of this > port. It would also have a much bigger impact on all the currently > supported platforms than doing it in the way how all the other ports > have been done until now. I had thought that when this was proposed the issue of not doing a simple copy'n'modify, and the need for an improved architecture to allow ease of porting was raised. But it seems my recollection was incorrect. My apologies for that. It is of course not reasonable to expect this as the port is completed. That said I still have grave concerns about the maintainability of the codebase due to the excessive use of platform ifdefs in "shared" code, and the excessive duplication in "platform specific" code. And that each new port makes it that much harder to instigate such changes. I feel with this port we will have reached a point now where it is almost impossible to fix this. It would take significant resources to refactor the code etc, dealing with all the existing platforms, while at the same time trying to evolve the platform to Java 9. David ----- > > That said, we would warmly welcome any initiative (maybe a JEP) for > refactoring the class library to make it more portable. JDK9 may > probably be the appropriate target for such a project. > > I'd also like to understand the proposed maintenance model going > forward. We (in Oracle) already have to accommodate our closed ports > when they are affected by changes to common code that requires > per-platform changes as well. Who will be providing the changes > needed for aix-ppc? And how will that happen? > > > The changesets will of course be provided by us (IBM and SAP). How this > will happen is up to the OpenJDK cummunity and Oracle. Mark promised to > propose a formal policy for how this may look like. > > Again I think the big picture issues need to discussed on jdk8-dev > (or perhaps it is time to start jdk8u-dev?) before getting into > changeset specifics for hotspot and core-libs. > > Thanks, > David > ----- > > > What do you mean with "ramping up infrastructure": > - hardware resources (like test/build infrastructure)? > - human resources within Oracle? > - human resources within IBM/SAP? > > I think we have most of these allocated (except the Oracle part > which I > can not speak about:) > > > -phil. > > > On 2/1/2013 5:57 AM, Volker Simonis wrote: > > On Fri, Feb 1, 2013 at 12:15 PM, David Holmes > > >>__wrote: > > > On 1/02/2013 8:11 PM, mark.reinhold at oracle.com > > > wrote: > > Posted: http://openjdk.java.net/jeps/*____*175 > > > > > >> > > I'm forced to send this to porters-dev but I do not > subscribe to that list > (so it will probably get held up). > > Given the way the JEP tasks have been split it > would seem > much more > appropriate to me for discussions to occur on > hotspot-dev > and core-libs-dev > as this, as the JEP says, is about the integration > effort > not the porting > effort. > > Yes, I agree. I just wanted to wait until the JEP was > published > before > posting it to the appropriate lists > > > That said this is also relevant to jdk8-dev, also > cc'd, as > it affects all > JDK 8 development. I have trouble seeing how such a > large > effort can be > assimilated within the timeframes of the Java 8 > schedule. > > > As previously discussed on porters-dev the current > target is not > the first > JDK 8 release but rather the first non-security update > (i.e. > something like > JDK 8u2) > > Regards, > Volker > > David > > - Mark > > > > From volker.simonis at gmail.com Mon Feb 4 05:40:03 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Feb 2013 14:40:03 +0100 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <510F0ED4.4020804@oracle.com> References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> <510F0ED4.4020804@oracle.com> Message-ID: On Mon, Feb 4, 2013 at 2:28 AM, Phil Race wrote: > On 2/2/13 3:03 AM, Volker Simonis wrote: > > > > On Fri, Feb 1, 2013 at 8:11 PM, Phil Race wrote: > >> As previously discussed on porters-dev the current target is not the >>> first >>> JDK 8 release but rather the first non-security update (i.e. something >>> like >>> JDK 8u2) >>> >> >> Given the scale and timing, isn't JDK 9 a more appropriate target ? >> The goal of a JDK 8 update 2, *should* be stabilisation, and this sounds >> rather the opposite. >> It also introduces logistic issues like ramping up infrastructure which >> in my experience >> can't solved all that quickly. >> >> > Well, the MacOS X port made it into 7u4 and we're of course keen to do > it better:) > > > OSX was a major investment on a lot of fronts. People (dev, sqe, pm) were > diverted > away from other projects and it was being worked on by Oracle engineers in > the os x project > for a *long* time before it was integrated. > All this might have been said just as well about our ports. IBM and SAP is investing since long time a lot of resources into these ports. And we are ready to do more. We just need the opportunity to do it! > Even then it was rough and close. > And 7u4 was only a developer release. Full support wasn't even claimed > then. > > So when you even mention the osx port, even with a claim it won't be as > bad, > my internal alarm bells start ringing enough to think the actual impact > needs > to be assessed. > > And there was a time imperative driving that. I'm not sure what the > imperative is here. > > I would say time as well. As stated above, we have these ports since long time and it took as tremendous efforts until we could contribute them to the OpenJDK. We want them in the main branch as fast as possible to avoid the burden to maintain and support yet another codeline. > > What do you mean with "ramping up infrastructure": > - hardware resources (like test/build infrastructure)? > - human resources within Oracle? > - human resources within IBM/SAP? > > I think we have most of these allocated (except the Oracle part which I > can not speak about:) > > I mean Oracle since your JEP is clear resources are needed where it says > > > We therefore think this JEP needs funding not only from IBM and SAP > > but also from Oracle, in particular so that Oracle engineers in the > HotSpot > >and Core Libraries Groups can assist in this effort. > > -phil. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130204/b20f4733/attachment.html From christian.thalinger at oracle.com Mon Feb 4 20:10:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 4 Feb 2013 20:10:46 -0800 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <510F7462.5040006@oracle.com> References: <20130204082248.97A86E5C@eggemoggin.niobe.net> <510F7462.5040006@oracle.com> Message-ID: <68396225-36FF-470D-A138-3365835B52DD@oracle.com> On Feb 4, 2013, at 12:42 AM, David Holmes wrote: > Hi Mark, > > On 4/02/2013 6:22 PM, mark.reinhold at oracle.com wrote: >> 2013/2/2 13:42 +0100, david.holmes at oracle.com: >>> ... >>> >>> I think the "risks" are a little under-stated. You have changed shared code and >>> that potentially impacts all platforms (unless you have only added new >>> functions unused on existing platforms?). There is also the matter of the >>> "elephant in the room" - the existing proprietary PPC port that Oracle has for >>> Java SE Embedded. Someone (from Oracle of course) will have to see how the >>> proposed structure of the new port will impact the existing closed port. It >>> might be a non-issue, or a major issue - most likely somewhere in between. >> >> Either way, issues with a proprietary port that's downstream of OpenJDK >> are for the maintainers of that port to solve, regardless of whether the >> maintainers work for Oracle. The existence of a proprietary port cannot >> hold back the contribution of an open port. > > Ok. > >> >>> I am also hoping that this will not simply be a copy'n'modify port as we have >>> seen in the past. The proliferation of platform ifdefs in shared code is truly >>> horrendous; as is the duplication across the purportedly platform-specific >>> code. This problem wasn't addressed for the Mac port but in my opinion (and >>> that is all it is) it needs to be before the community accepts any further >>> ports. >> >> I think it'd be a fine thing for that code to be refactored and cleaned >> up, but I don't see that as a prerequisite for a new port coming in. > > The code base will be unmanageable if we keep doing this copy'n'modify approach to porting, and the more ports we add the more impractical it becomes to try and retrofit a cleaner porting architecture. The OSX/bsd port is still causing us "indigestion". > >>> I'd also like to understand the proposed maintenance model going forward. We >>> (in Oracle) already have to accommodate our closed ports when they are affected >>> by changes to common code that requires per-platform changes as well. Who will >>> be providing the changes needed for aix-ppc? And how will that happen? >> >> Every port needs a documented set of maintainers, and it's up to the >> maintainers to track changes in shared code. If a port stops being >> maintained and rots for a significant period of time then it's likely to >> be removed. This is how similar long-lived projects (e.g., GCC) work. > > Even if there are designated maintainers there is still a matter of how things will proceed. If someone is changing shared code who has the responsibility for making sure every port is accounted for? Do we have to coordinate things so that no changes are made until all changes are ready? Or do we allow things to break until the designated maintainers catch up? It would be desirable to have an integration build and testing system that includes all platforms which are supported by OpenJDK. Ideally this would be an open system where OpenJDK members (other companies than Oracle) could add their machines for the platforms they care about. -- Chris > >> Now that a port that's to be maintained by non-Oracle developers is being >> proposed, I will soon propose a formal policy along these lines. > > That would be good to see. > > Thanks, > David > >> - Mark From spoole at linux.vnet.ibm.com Tue Feb 5 04:06:03 2013 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 5 Feb 2013 12:06:03 +0000 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <510F9DDC.1020401@oracle.com> References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> <510D09C2.5090306@oracle.com> <510F9DDC.1020401@oracle.com> Message-ID: <708A00A0-3747-4C25-9BAE-B7014F5ADB63@linux.vnet.ibm.com> On 4 Feb 2013, at 11:39, David Holmes wrote: > On 4/02/2013 8:50 PM, Volker Simonis wrote: >> On Sat, Feb 2, 2013 at 1:42 PM, David Holmes > I am also hoping that this will not simply be a copy'n'modify port >> as we have seen in the past. The proliferation of platform ifdefs in >> shared code is truly horrendous; as is the duplication across the >> purportedly platform-specific code. This problem wasn't addressed >> for the Mac port but in my opinion (and that is all it is) it needs >> to be before the community accepts any further ports. >> >> That would be nice but that is not and can not be the focus of this >> port. It would also have a much bigger impact on all the currently >> supported platforms than doing it in the way how all the other ports >> have been done until now. > > I had thought that when this was proposed the issue of not doing a simple copy'n'modify, and the need for an improved architecture to allow ease of porting was raised. But it seems my recollection was incorrect. > > My apologies for that. It is of course not reasonable to expect this as the port is completed. > > That said I still have grave concerns about the maintainability of the codebase due to the excessive use of platform ifdefs in "shared" code, and the excessive duplication in "platform specific" code. And that each new port makes it that much harder to instigate such changes. I feel with this port we will have reached a point now where it is almost impossible to fix this. It would take significant resources to refactor the code etc, dealing with all the existing platforms, while at the same time trying to evolve the platform to Java 9. I agree we do need to tackle the refactoring problem - I just wanted to keep it a separate concern and not made a precondition for this JEP - which I think we all agree on? I am more than happy to help with the refactoring necessary in JDK8 proper over time. Given that there will be an ARM64 port following on along later we do need to start soon! > > David > ----- > >> >> That said, we would warmly welcome any initiative (maybe a JEP) for >> refactoring the class library to make it more portable. JDK9 may >> probably be the appropriate target for such a project. >> >> I'd also like to understand the proposed maintenance model going >> forward. We (in Oracle) already have to accommodate our closed ports >> when they are affected by changes to common code that requires >> per-platform changes as well. Who will be providing the changes >> needed for aix-ppc? And how will that happen? >> >> >> The changesets will of course be provided by us (IBM and SAP). How this >> will happen is up to the OpenJDK cummunity and Oracle. Mark promised to >> propose a formal policy for how this may look like. >> >> Again I think the big picture issues need to discussed on jdk8-dev >> (or perhaps it is time to start jdk8u-dev?) before getting into >> changeset specifics for hotspot and core-libs. >> >> Thanks, >> David >> ----- >> >> >> What do you mean with "ramping up infrastructure": >> - hardware resources (like test/build infrastructure)? >> - human resources within Oracle? >> - human resources within IBM/SAP? >> >> I think we have most of these allocated (except the Oracle part >> which I >> can not speak about:) >> >> >> -phil. >> >> >> On 2/1/2013 5:57 AM, Volker Simonis wrote: >> >> On Fri, Feb 1, 2013 at 12:15 PM, David Holmes >> >> > >>__wrote: >> >> >> On 1/02/2013 8:11 PM, mark.reinhold at oracle.com >> >> > > wrote: >> >> Posted: http://openjdk.java.net/jeps/*____*175 >> >> > >> >> >> > >> >> >> I'm forced to send this to porters-dev but I do not >> subscribe to that list >> (so it will probably get held up). >> >> Given the way the JEP tasks have been split it >> would seem >> much more >> appropriate to me for discussions to occur on >> hotspot-dev >> and core-libs-dev >> as this, as the JEP says, is about the integration >> effort >> not the porting >> effort. >> >> Yes, I agree. I just wanted to wait until the JEP was >> published >> before >> posting it to the appropriate lists >> >> >> That said this is also relevant to jdk8-dev, also >> cc'd, as >> it affects all >> JDK 8 development. I have trouble seeing how such a >> large >> effort can be >> assimilated within the timeframes of the Java 8 >> schedule. >> >> >> As previously discussed on porters-dev the current >> target is not >> the first >> JDK 8 release but rather the first non-security update >> (i.e. >> something like >> JDK 8u2) >> >> Regards, >> Volker >> >> David >> >> - Mark >> >> >> >> > From Alan.Bateman at oracle.com Tue Feb 5 06:53:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Feb 2013 14:53:37 +0000 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: <708A00A0-3747-4C25-9BAE-B7014F5ADB63@linux.vnet.ibm.com> References: <20130201101137.21589C0B@eggemoggin.niobe.net> <510BA3B6.9090002@oracle.com> <510C135D.4020105@oracle.com> <510D09C2.5090306@oracle.com> <510F9DDC.1020401@oracle.com> <708A00A0-3747-4C25-9BAE-B7014F5ADB63@linux.vnet.ibm.com> Message-ID: <51111CF1.6030405@oracle.com> On 05/02/2013 12:06, Steve Poole wrote: > : > I agree we do need to tackle the refactoring problem - I just wanted to keep it a separate concern and not made a precondition for this JEP - which I think we all agree on? I am more than happy to help with the refactoring necessary in JDK8 proper over time. Given that there will be an ARM64 port following on along later we do need to start soon! > > One thing that might help is that when you have it moved to jdk8 and moved to the new build, is to send out a first webrev so that folks have some idea as to what might be coming. I will guess that a cursory look from a few people in specific areas might provide some initial feedback that could make things a bit easier. I could imagine getting feedback on where AIX or ppc64 specific code should reside, I could also imagine that some of the proposed change will trigger ideas on refactoring to make it easier to integrate. Although it can't be a prerequisite for this, I assume the AIX port is going to be a reminder that we need to something about jdk/src/solaris. I also think it will be reminder that with the new configure-based build that we should be thinking about moving (over the long term) to more of a capabilities based build. -Alan From christian.thalinger at oracle.com Thu Feb 7 08:45:42 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Feb 2013 08:45:42 -0800 Subject: JEP 175: Integrate PowerPC/AIX Port into JDK 8 In-Reply-To: References: <20130204082248.97A86E5C@eggemoggin.niobe.net> <510F7462.5040006@oracle.com> <68396225-36FF-470D-A138-3365835B52DD@oracle.com> Message-ID: <8186E970-2DAC-406E-885B-95C9FAB7CFF2@oracle.com> On Feb 4, 2013, at 8:18 PM, Martijn Verburg wrote: > Hi Christian, > > This was discussed at FOSDEM (and in the months leading up to it). We are going to start a prototype for this idea in the LJC and gather requirements, look at security implications etc. Oh, that's great! I should have gone this year then :-) -- Chris > > We are still in the process of securing finding for some hosting etc but will get started shorty after. > > Cheers, > Martijn > > On Tuesday, 5 February 2013, Christian Thalinger wrote: >> >> On Feb 4, 2013, at 12:42 AM, David Holmes wrote: >> >> > Hi Mark, >> > >> > On 4/02/2013 6:22 PM, mark.reinhold at oracle.com wrote: >> >> 2013/2/2 13:42 +0100, david.holmes at oracle.com: >> >>> ... >> >>> >> >>> I think the "risks" are a little under-stated. You have changed shared code and >> >>> that potentially impacts all platforms (unless you have only added new >> >>> functions unused on existing platforms?). There is also the matter of the >> >>> "elephant in the room" - the existing proprietary PPC port that Oracle has for >> >>> Java SE Embedded. Someone (from Oracle of course) will have to see how the >> >>> proposed structure of the new port will impact the existing closed port. It >> >>> might be a non-issue, or a major issue - most likely somewhere in between. >> >> >> >> Either way, issues with a proprietary port that's downstream of OpenJDK >> >> are for the maintainers of that port to solve, regardless of whether the >> >> maintainers work for Oracle. The existence of a proprietary port cannot >> >> hold back the contribution of an open port. >> > >> > Ok. >> > >> >> >> >>> I am also hoping that this will not simply be a copy'n'modify port as we have >> >>> seen in the past. The proliferation of platform ifdefs in shared code is truly >> >>> horrendous; as is the duplication across the purportedly platform-specific >> >>> code. This problem wasn't addressed for the Mac port but in my opinion (and >> >>> that is all it is) it needs to be before the community accepts any further >> >>> ports. >> >> >> >> I think it'd be a fine thing for that code to be refactored and cleaned >> >> up, but I don't see that as a prerequisite for a new port coming in. >> > >> > The code base will be unmanageable if we keep doing this copy'n'modify approach to porting, and the more ports we add the more impractical it becomes to try and retrofit a cleaner porting architecture. The OSX/bsd port is still causing us "indigestion". >> > >> >>> I'd also like to understand the proposed maintenance model going forward. We >> >>> (in Oracle) already have to accommodate our closed ports when they are affected >> >>> by changes to common code that requires per-platform changes as well. Who will >> >>> be providing the changes needed for aix-ppc? And how will that happen? >> >> >> >> Every port needs a documented set of maintainers, and it's up to the >> >> maintainers to track changes in shared code. If a port stops being >> >> maintained and rots for a significant period of time then it's likely to >> >> be removed. This is how similar long-lived projects (e.g., GCC) work. >> > >> > Even if there are designated maintainers there is still a matter of how things will proceed. If someone is changing shared code who has the responsibility for making sure every port is accounted for? Do we have to coordinate things so that no changes are made until all changes are ready? Or do we allow things to break until the designated maintainers catch up? >> >> It would be desirable to have an integration build and testing system that includes all platforms which are supported by OpenJDK. Ideally this would be an open system where OpenJDK members (other companies than Oracle) could add their machines for the platforms they care about. >> >> -- Chris >> >> > >> >> Now that a port that's to be maintained by non-Oracle developers is being >> >> proposed, I will soon propose a formal policy along these lines. >> > >> > That would be good to see. >> > >> > Thanks, >> > David >> > >> >> - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130207/a5968e0d/attachment.html From xueming.shen at oracle.com Thu Feb 7 10:31:54 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Feb 2013 10:31:54 -0800 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. Message-ID: <5113F31A.3080704@oracle.com> Hi, 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. Webrev: http://cr.openjdk.java.net/~sherman/8007572/ Note: JDK/JRE has been using the time zone data at /lib/zi for j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own time zone data file/format lib/tzdb.jar to provide the time zone data support for its new java.time date-time classes. So we now have two different time zone data files in different formats (though from the same time zone data source, Olson tz data, now the IANA Time Zone Datebase) to support two sets of date-time APIs (java.util date-time classes and java.time date-time classes) in one JDK/JRE, which definitely will add the maintenance burden going forward, given the fact that we will have to update/distribute the latest tzdb data in JDK/JRE periodically [2]. Also the current way the time-zone data is being distributed/installed (at /lib.zi, as individual file for each time zone) has been a footprint concern for some configurations, especially the small embedded environment. The JEP151 [3] was originally submitted to propose to store the time-zone data more efficiently into a single compressed file. The JEP 151 has been withdrawn since, with the assumption that JDK 8 may replace the "zi" data with the much smaller JSR310 tzdb data file. As indicated in JEP151, current installed "zi" directory probably takes up 1M of disk-space with the 0.5k default file-system-block-size. Even with the proposed "store in one single compressed file" approach, it will still take about 250K space for all tzdb data in "zi" directory. JSR310 tzdb data file however is much smaller. It is around 40K for compressed and 100k uncompressed, for the same tz data. The proposed change is to share the JSR310 time zone data tzdb.jar with j.u.TimeZone by converting the JSR310 tzdb data completely (bits to bits compatible) at runtime into the internal data structure that j.u.TimeZone needs for its time zone data functionality/needs. Thanks! -Sherman [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 [2] http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html [3] http://openjdk.java.net/jeps/151 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130207/77d8e605/attachment.html From mark.reinhold at oracle.com Tue Feb 12 08:16:41 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 12 Feb 2013 08:16:41 -0800 Subject: New CPU & OS Platform System Properties Updated In-Reply-To: bob.vandette@oracle.com; Wed, 23 Jan 2013 13:00:07 EST; Message-ID: <20130212161641.8350CE7E@eggemoggin.niobe.net> (cleaning up old threads ...) 2013/1/23 10:00 -0800, bob.vandette at oracle.com: > On Jan 23, 2013, at 11:38 AM, mark.reinhold at oracle.com wrote: >> 2013/1/10 10:59 -0800, bob.vandette at oracle.com: >>> Thanks for all the input. Here's an update to the proposal based on the >>> feedback I've received so far. >>> >>> OS.ARCH ADDITIONS >>> ----------------------------- >>> >>> ... >>> >>> The only remaining problem is that of ABI. For this I propose the >>> addition of a single new property. >>> >>> os.arch.abi >> >> This makes sense, but since you're not proposing to add this new property >> to the Platform Specification [1] its name should start with "jdk." or >> "sun.". Current convention would be to use "jdk.", but given that the >> names of existing closely-related properties already start with "sun." >> (sun.arch.data.model, etc.), this new property should be named >> "sun.arch.abi". > > Ok, I can live with sun.arch.abi. It's a shame we can't easily move these > to oracle.arch.* but that's for another CCC. Even if we could, we'd never rename these to oracle.arch.*. They are in no way Oracle-specific. >> Will this property be defined for regular Linux, Mac OS, or Windows >> builds? > > I was not planning on adding this property for any platform where the > abi does not vary within the same cpu family or where ABI changes are > already covered by previously available properties. For example, > there's no need to distinguish 32 and 64 bit x86 ABIs since we have an > endian property that provides that distinction. Okay. >>> OS.NAME ADDITIONS >>> ----------------------------- >>> >>> My proposal below for os.name stands with the exception of Apple >>> platforms. For iPhone and iPad Java implementations, we will be >>> setting os.name to "iOS" since Apple informed me that there is really >>> no concrete specified relationship between OSX and iOS. They are two >>> very distinct OS platforms and should be treated as such. >>> >>> I would still like to propose os.variant and os.variant.version for >>> Android. >> >> I don't think it makes sense to describe Android as a variant of Linux. >> Sure, it's built on top of a Linux kernel, but the rest of the >> environment is vastly different from the typical Linux distro where >> "os.name" currently has the value "Linux". >> >> In short form, Linux : Android :: Mac OS : iOS. >> >> The "os.name" property should have the value "Android" on Android >> devices, and "os.version" should be the Android version number. >> >> Given that, I don't see a compelling need to introduce "os.variant" >> properties at this time. > > Here's the justifications that I have to support this addition: > > 1. It would avoid adding a lot of " || os.name == "Android" in several > places in the JDK and application sources where the code currently > check for "Linux" resulting in faster execution and less maintenance. Saving a few lines of code and a few conditional tests in the JDK source code really doesn't buy much. As to application code, I think calling Android a "Linux" will actually require existing code to change if and when it's run on the JDK in an Android environment. Code that tests the value of os.name in order to construct a string that's then passed to Runtime.exec on a real Linux system will not work on Android -- it will have to be augmented also to test os.variant, and to do something else. > 2. OpenJDK community feedback. Mike Swingler from Apple agrees with my > position that Android is a variant. I respectfully disagree. Android is based on a Linux kernel but the userland is entirely different. The name of the property is "os.name", not "kernel.name". > 3. Google sets the os.name == Linux for Android platforms, not "Android". That's their mistake. > 4. os.name is the operating system and not the specific platform. > Android is built on top of a compatible implementation of Linux. We > don't set os.name to ubuntu or debian for those platforms so I don't > think we should equate Android to os.name. You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with Android. That's incorrect. The only thing all these systems have in common is the Linux kernel. The userlands of Ubuntu, Debian, RHEL, and Fedora are (roughly) compatible with each other. The userland of Android is not. I still don't see a compelling need to introduce an "os.variant" property. - Mark From dmitry.samersoff at oracle.com Tue Feb 12 08:35:44 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Feb 2013 20:35:44 +0400 Subject: New CPU & OS Platform System Properties Updated In-Reply-To: <20130212161641.8350CE7E@eggemoggin.niobe.net> References: <20130212161641.8350CE7E@eggemoggin.niobe.net> Message-ID: <511A6F60.9050603@oracle.com> Mark, Unfortunately, the problem is harder than it should be. If you write gui-less program in plain C it's just linux-arm program with minimal difference. But gui and high level api is of course absolutely different. So final decision depends mostly to the way Java customers will use this flag. -Dmitry On 2013-02-12 20:16, mark.reinhold at oracle.com wrote: > (cleaning up old threads ...) > > 2013/1/23 10:00 -0800, bob.vandette at oracle.com: >> On Jan 23, 2013, at 11:38 AM, mark.reinhold at oracle.com wrote: >>> 2013/1/10 10:59 -0800, bob.vandette at oracle.com: >>>> Thanks for all the input. Here's an update to the proposal based on the >>>> feedback I've received so far. >>>> >>>> OS.ARCH ADDITIONS >>>> ----------------------------- >>>> >>>> ... >>>> >>>> The only remaining problem is that of ABI. For this I propose the >>>> addition of a single new property. >>>> >>>> os.arch.abi >>> >>> This makes sense, but since you're not proposing to add this new property >>> to the Platform Specification [1] its name should start with "jdk." or >>> "sun.". Current convention would be to use "jdk.", but given that the >>> names of existing closely-related properties already start with "sun." >>> (sun.arch.data.model, etc.), this new property should be named >>> "sun.arch.abi". >> >> Ok, I can live with sun.arch.abi. It's a shame we can't easily move these >> to oracle.arch.* but that's for another CCC. > > Even if we could, we'd never rename these to oracle.arch.*. They are in > no way Oracle-specific. > >>> Will this property be defined for regular Linux, Mac OS, or Windows >>> builds? >> >> I was not planning on adding this property for any platform where the >> abi does not vary within the same cpu family or where ABI changes are >> already covered by previously available properties. For example, >> there's no need to distinguish 32 and 64 bit x86 ABIs since we have an >> endian property that provides that distinction. > > Okay. > >>>> OS.NAME ADDITIONS >>>> ----------------------------- >>>> >>>> My proposal below for os.name stands with the exception of Apple >>>> platforms. For iPhone and iPad Java implementations, we will be >>>> setting os.name to "iOS" since Apple informed me that there is really >>>> no concrete specified relationship between OSX and iOS. They are two >>>> very distinct OS platforms and should be treated as such. >>>> >>>> I would still like to propose os.variant and os.variant.version for >>>> Android. >>> >>> I don't think it makes sense to describe Android as a variant of Linux. >>> Sure, it's built on top of a Linux kernel, but the rest of the >>> environment is vastly different from the typical Linux distro where >>> "os.name" currently has the value "Linux". >>> >>> In short form, Linux : Android :: Mac OS : iOS. >>> >>> The "os.name" property should have the value "Android" on Android >>> devices, and "os.version" should be the Android version number. >>> >>> Given that, I don't see a compelling need to introduce "os.variant" >>> properties at this time. >> >> Here's the justifications that I have to support this addition: >> >> 1. It would avoid adding a lot of " || os.name == "Android" in several >> places in the JDK and application sources where the code currently >> check for "Linux" resulting in faster execution and less maintenance. > > Saving a few lines of code and a few conditional tests in the JDK source > code really doesn't buy much. > > As to application code, I think calling Android a "Linux" will actually > require existing code to change if and when it's run on the JDK in an > Android environment. Code that tests the value of os.name in order to > construct a string that's then passed to Runtime.exec on a real Linux > system will not work on Android -- it will have to be augmented also to > test os.variant, and to do something else. > >> 2. OpenJDK community feedback. Mike Swingler from Apple agrees with my >> position that Android is a variant. > > I respectfully disagree. Android is based on a Linux kernel but the > userland is entirely different. The name of the property is "os.name", > not "kernel.name". > >> 3. Google sets the os.name == Linux for Android platforms, not "Android". > > That's their mistake. > >> 4. os.name is the operating system and not the specific platform. >> Android is built on top of a compatible implementation of Linux. We >> don't set os.name to ubuntu or debian for those platforms so I don't >> think we should equate Android to os.name. > > You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with > Android. That's incorrect. The only thing all these systems have in > common is the Linux kernel. The userlands of Ubuntu, Debian, RHEL, and > Fedora are (roughly) compatible with each other. The userland of Android > is not. > > I still don't see a compelling need to introduce an "os.variant" > property. > > - Mark > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From swingler at apple.com Tue Feb 12 08:47:10 2013 From: swingler at apple.com (Mike Swingler) Date: Tue, 12 Feb 2013 08:47:10 -0800 Subject: New CPU & OS Platform System Properties Updated In-Reply-To: <20130212161641.8350CE7E@eggemoggin.niobe.net> References: <20130212161641.8350CE7E@eggemoggin.niobe.net> Message-ID: <4276C60D-D8C0-45D3-9B42-700B6FBEED87@apple.com> On Feb 12, 2013, at 8:16 AM, mark.reinhold at oracle.com wrote: >> 2. OpenJDK community feedback. Mike Swingler from Apple agrees with my >> position that Android is a variant. > > I respectfully disagree. Android is based on a Linux kernel but the > userland is entirely different. The name of the property is "os.name", > not "kernel.name". To be clear, I only mentioned that the "os.variant" scheme only made more sense for Linux than claiming that iOS is variant of OS X. My point was also predicated on ensuring that "os.version" would be linked to the Linux kernel version. I only asserted strongly that the variant scheme made no sense for iOS vs. OS X, and only conceded that it might make sense for Android vs. Linux. Regards, Mike Swingler Apple Inc. From bob.vandette at oracle.com Tue Feb 12 08:52:20 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 12 Feb 2013 11:52:20 -0500 Subject: New CPU & OS Platform System Properties Updated In-Reply-To: <20130212161641.8350CE7E@eggemoggin.niobe.net> References: <20130212161641.8350CE7E@eggemoggin.niobe.net> Message-ID: <83BFC098-3C7C-41E8-AE67-0681A53E97D9@oracle.com> I've withdrawn my request to add a new os.variant. We'll just set os.name to Android. I will use sun.arch.abi to identify platform specific ABI differences. Bob. On Feb 12, 2013, at 11:16 AM, mark.reinhold at oracle.com wrote: > (cleaning up old threads ...) > > 2013/1/23 10:00 -0800, bob.vandette at oracle.com: >> On Jan 23, 2013, at 11:38 AM, mark.reinhold at oracle.com wrote: >>> 2013/1/10 10:59 -0800, bob.vandette at oracle.com: >>>> Thanks for all the input. Here's an update to the proposal based on the >>>> feedback I've received so far. >>>> >>>> OS.ARCH ADDITIONS >>>> ----------------------------- >>>> >>>> ... >>>> >>>> The only remaining problem is that of ABI. For this I propose the >>>> addition of a single new property. >>>> >>>> os.arch.abi >>> >>> This makes sense, but since you're not proposing to add this new property >>> to the Platform Specification [1] its name should start with "jdk." or >>> "sun.". Current convention would be to use "jdk.", but given that the >>> names of existing closely-related properties already start with "sun." >>> (sun.arch.data.model, etc.), this new property should be named >>> "sun.arch.abi". >> >> Ok, I can live with sun.arch.abi. It's a shame we can't easily move these >> to oracle.arch.* but that's for another CCC. > > Even if we could, we'd never rename these to oracle.arch.*. They are in > no way Oracle-specific. > >>> Will this property be defined for regular Linux, Mac OS, or Windows >>> builds? >> >> I was not planning on adding this property for any platform where the >> abi does not vary within the same cpu family or where ABI changes are >> already covered by previously available properties. For example, >> there's no need to distinguish 32 and 64 bit x86 ABIs since we have an >> endian property that provides that distinction. > > Okay. > >>>> OS.NAME ADDITIONS >>>> ----------------------------- >>>> >>>> My proposal below for os.name stands with the exception of Apple >>>> platforms. For iPhone and iPad Java implementations, we will be >>>> setting os.name to "iOS" since Apple informed me that there is really >>>> no concrete specified relationship between OSX and iOS. They are two >>>> very distinct OS platforms and should be treated as such. >>>> >>>> I would still like to propose os.variant and os.variant.version for >>>> Android. >>> >>> I don't think it makes sense to describe Android as a variant of Linux. >>> Sure, it's built on top of a Linux kernel, but the rest of the >>> environment is vastly different from the typical Linux distro where >>> "os.name" currently has the value "Linux". >>> >>> In short form, Linux : Android :: Mac OS : iOS. >>> >>> The "os.name" property should have the value "Android" on Android >>> devices, and "os.version" should be the Android version number. >>> >>> Given that, I don't see a compelling need to introduce "os.variant" >>> properties at this time. >> >> Here's the justifications that I have to support this addition: >> >> 1. It would avoid adding a lot of " || os.name == "Android" in several >> places in the JDK and application sources where the code currently >> check for "Linux" resulting in faster execution and less maintenance. > > Saving a few lines of code and a few conditional tests in the JDK source > code really doesn't buy much. > > As to application code, I think calling Android a "Linux" will actually > require existing code to change if and when it's run on the JDK in an > Android environment. Code that tests the value of os.name in order to > construct a string that's then passed to Runtime.exec on a real Linux > system will not work on Android -- it will have to be augmented also to > test os.variant, and to do something else. > >> 2. OpenJDK community feedback. Mike Swingler from Apple agrees with my >> position that Android is a variant. > > I respectfully disagree. Android is based on a Linux kernel but the > userland is entirely different. The name of the property is "os.name", > not "kernel.name". > >> 3. Google sets the os.name == Linux for Android platforms, not "Android". > > That's their mistake. > >> 4. os.name is the operating system and not the specific platform. >> Android is built on top of a compatible implementation of Linux. We >> don't set os.name to ubuntu or debian for those platforms so I don't >> think we should equate Android to os.name. > > You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with > Android. That's incorrect. The only thing all these systems have in > common is the Linux kernel. The userlands of Ubuntu, Debian, RHEL, and > Fedora are (roughly) compatible with each other. The userland of Android > is not. > > I still don't see a compelling need to introduce an "os.variant" > property. > > - Mark