From philipp.kunz at paratix.ch Fri Sep 1 07:28:53 2017 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 1 Sep 2017 09:28:53 +0200 Subject: hello, im a new contributor Message-ID: <5069dcf3-9bf9-444b-8cfe-d2df92cd765e@paratix.ch> Hello everyone I have been developing with Java for around 17 years now and when I encountered some bug I decided to attempt to fix it: https://bugs.openjdk.java.net/browse/JDK-6695402. This also looks like it may not be too big a piece for a first contribution. I read through quite some guides and all kinds of documents but could not yet help myself with the following questions: May I login to jira to add comments to bugs? If so, how would I request or receive credentials? Or are mailing lists preferred? Another question is whether I should apply it to jdk9, but it may be too late now, or to jdk10, and backporting can be considered later. Probably it wouldn't even make much a difference for the patch itself. One more question I have is how or where to find the sources from before migration to mercurial. Because some lines of code I intend to change go back farther and in the history I find only 'initial commit'. With such a history I might be able better to understand why it's there and prevent to make the same mistake again. I guess the appropriate mailing list for above mentioned bug is security-dev. Is it correct that I can send a patch there and just hope for some sponsor to pick it up? Of course I'd be glad if some sponsor would contact me and maybe provide some assistance or if someone would confirm that sending a patch to the mailing list is the right way to find a sponsor. Philipp Kunz From david.holmes at oracle.com Fri Sep 1 07:52:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Sep 2017 17:52:57 +1000 Subject: hello, im a new contributor In-Reply-To: <5069dcf3-9bf9-444b-8cfe-d2df92cd765e@paratix.ch> References: <5069dcf3-9bf9-444b-8cfe-d2df92cd765e@paratix.ch> Message-ID: Hi Phillip, On 1/09/2017 5:28 PM, Philipp Kunz wrote: > Hello everyone > > I have been developing with Java for around 17 years now and when I > encountered some bug I decided to attempt to fix it: > https://bugs.openjdk.java.net/browse/JDK-6695402. This also looks like > it may not be too big a piece for a first contribution. > > I read through quite some guides and all kinds of documents but could > not yet help myself with the following questions: > > May I login to jira to add comments to bugs? If so, how would I request > or receive credentials? Or are mailing lists preferred? You get access to Jira once you become an OpenJDk Author. That also gives you access to cr.openjdk.java.net. Until then you will need to use the appropriate mailing list. > Another question is whether I should apply it to jdk9, but it may be too > late now, or to jdk10, and backporting can be considered later. Probably > it wouldn't even make much a difference for the patch itself. JDK 10. As you note it is too late for 9. > One more question I have is how or where to find the sources from before > migration to mercurial. Because some lines of code I intend to change go > back farther and in the history I find only 'initial commit'. With such > a history I might be able better to understand why it's there and > prevent to make the same mistake again. You can not access sources prior to the OpenJDK sources. Those prior sources are still proprietary to Oracle and not open-sourced. > I guess the appropriate mailing list for above mentioned bug is > security-dev. Is it correct that I can send a patch there and just hope > for some sponsor to pick it up? Of course I'd be glad if some sponsor > would contact me and maybe provide some assistance or if someone would > confirm that sending a patch to the mailing list is the right way to > find a sponsor. Yes security-dev looks like the right mailing list for that bug. Cheers, David > Philipp Kunz From vincent.x.ryan at oracle.com Fri Sep 1 07:58:47 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 1 Sep 2017 08:58:47 +0100 Subject: hello, im a new contributor In-Reply-To: <5069dcf3-9bf9-444b-8cfe-d2df92cd765e@paratix.ch> References: <5069dcf3-9bf9-444b-8cfe-d2df92cd765e@paratix.ch> Message-ID: <43EAAD13-4174-420C-A034-9261C3E9A647@oracle.com> Moved to security-dev > On 1 Sep 2017, at 08:28, Philipp Kunz wrote: > > Hello everyone > > I have been developing with Java for around 17 years now and when I encountered some bug I decided to attempt to fix it: https://bugs.openjdk.java.net/browse/JDK-6695402. This also looks like it may not be too big a piece for a first contribution. > > I read through quite some guides and all kinds of documents but could not yet help myself with the following questions: > > May I login to jira to add comments to bugs? If so, how would I request or receive credentials? Or are mailing lists preferred? > > Another question is whether I should apply it to jdk9, but it may be too late now, or to jdk10, and backporting can be considered later. Probably it wouldn't even make much a difference for the patch itself. > > One more question I have is how or where to find the sources from before migration to mercurial. Because some lines of code I intend to change go back farther and in the history I find only 'initial commit'. With such a history I might be able better to understand why it's there and prevent to make the same mistake again. > > I guess the appropriate mailing list for above mentioned bug is security-dev. Is it correct that I can send a patch there and just hope for some sponsor to pick it up? Of course I'd be glad if some sponsor would contact me and maybe provide some assistance or if someone would confirm that sending a patch to the mailing list is the right way to find a sponsor. > > Philipp Kunz From behrangsa at gmail.com Mon Sep 4 02:20:53 2017 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Mon, 4 Sep 2017 12:20:53 +1000 Subject: Add string interpolation to Java using back-ticks similar to ECMAScript Message-ID: As back-tick is not used in Java at the moment, grammar-wise this should be relatively easy. And the parser can translate such strings to string concat or StringBuilder calls. A simple syntax sugar, but very sweet. Best regards, Behrang Saeedzadeh From david.holmes at oracle.com Mon Sep 4 03:17:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Sep 2017 13:17:16 +1000 Subject: Add string interpolation to Java using back-ticks similar to ECMAScript In-Reply-To: References: Message-ID: <40ae53af-d8c7-0933-b49a-6bbe4f23f7ba@oracle.com> Hi Behrang, The discuss list is for discussing the actual OpenJDK Community, not for technical suggestions or discussions. I suggest compiler-dev may be a place to get some discussion going. Regards, David On 4/09/2017 12:20 PM, Behrang Saeedzadeh wrote: > As back-tick is not used in Java at the moment, grammar-wise this should be > relatively easy. And the parser can translate such strings to string concat > or StringBuilder calls. > > A simple syntax sugar, but very sweet. > > Best regards, > Behrang Saeedzadeh > From benjamin.john.evans at gmail.com Mon Sep 4 04:07:33 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 4 Sep 2017 09:37:33 +0530 Subject: Add string interpolation to Java using back-ticks similar to ECMAScript In-Reply-To: References: Message-ID: Hi Behrang, This topic and suggestion has been extensively discussed over the course of several different Java releases. Before suggesting discussing it again, I recommend that you use your friendly neighbourhood search engine to read the discussion that has occurred on previous occasions. I don't believe that the situation has changed significantly since the last time this was discussed - but perhaps you have a new, compelling reason that has not been thought of during any of the previous discussions. If you do have a good new reason, then I suggest that providing a prototype patch to javac that implements this will be a good way to get people interested in this again. If you have such a patch, then compiler-dev is the place to post it. Thanks, Ben On Mon, Sep 4, 2017 at 7:50 AM, Behrang Saeedzadeh wrote: > As back-tick is not used in Java at the moment, grammar-wise this should be > relatively easy. And the parser can translate such strings to string concat > or StringBuilder calls. > > A simple syntax sugar, but very sweet. > > Best regards, > Behrang Saeedzadeh From martijnverburg at gmail.com Tue Sep 5 18:38:48 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 5 Sep 2017 19:38:48 +0100 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: <20170824141617.454386468@eggemoggin.niobe.net> References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> Message-ID: Hi Mark, Apologies for the radio silence. I was going to suggest edits de-emphasising Oracle's leadership / central role in this group, not because Oracle doesn't deserve to or have the right to lead, but more that I wanted to see the principles of shared vulnerability ownership (across all the vendors) front and center in the proposal. After a careful re-read of the doc I've realised that my impression was plain wrong and that the shared ownership is very much advocated. Thanks again for proposing this important group, it's really good to see! Cheers, Martijn On 24 August 2017 at 22:16, wrote: > 2017/8/24 10:33:41 -0700, martijnverburg at gmail.com: > > Totally applaud this idea! I have some suggested wording changes that > > might be easiest to suggest as a diff or some sort of track changes on > the > > original text. Do you have a preferred mechanism for that type of > feedback? > > If you'd like to propose a patch, I've posted the Markdown source here: > > http://cr.openjdk.java.net/~mr/ojvg/ojvg.md > > - Mark > From mark.reinhold at oracle.com Wed Sep 6 14:49:28 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 6 Sep 2017 07:49:28 -0700 (PDT) Subject: Accelerating the JDK release cadence Message-ID: <20170906144928.13997AA82D@eggemoggin.niobe.net> Over on my blog today I've argued that Java needs to move forward faster. To achieve that I've proposed that the Java SE Platform and the JDK shift from the historical feature-driven release model to a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years: https://mreinhold.org/blog/forward-faster Here are some initial thoughts on how we might implement this proposal here in the OpenJDK Community. Comments and questions about both the proposal and its implementation are welcome on this list. Rather than create a brand new "JDK $N" Release Project every six months, I suggest that we create a single long-running "JDK" Release Project to host the main-line code base and produce the feature releases. Similarly, let's create a single long-running "JDK Updates" Project to produce the update releases, for the most recent feature release and the current long-term support release. Two long-running Projects will save some administrative overhead, and also eliminate the confusion that regularly arises when someone is a Committer to JDK $N but not JDK $N + 1. (We could consider just one long-running Project, but two makes more sense since since the two types of releases will have different policies, content, schedules, and leadership.) The new JDK Project will run a bit differently than the past "JDK $N" Projects: - The main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished. The main line will be Feature Complete [1] at all times. - We'll fork the main line into a release-stabilization branch three months before the GA date of the next feature release. That branch will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 [3] a month later, and then enter the Release Candidate phase [4] a month after that. (Whether the branch is another repository or an actual Mercurial branch is a detail we can figure out later.) - We'll continue to use the JEP Process [5] for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration. The JDK Updates Project will run in much the same way as the past "JDK $N" Updates Projects, though update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Related to this proposal, we at Oracle intend to make a few changes in what we do: - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to make it easier for developers to deploy Java applications to cloud environments. We'll initially publish OpenJDK builds for Linux/x64, followed later by builds for macOS/x64 and Windows/x64. - We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" [7] such as Java Flight Recorder and Mission Control [8], under a click-through binary-code license [9]. Oracle will continue to offer paid support for these builds. - After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable. - Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK. So ... that's a lot of proposed change, and there are (obviously!) many details to work out. Comments? Questions? - Mark [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [2] http://openjdk.java.net/projects/jdk9/rdp-1 [3] http://openjdk.java.net/projects/jdk9/rdp-2 [4] http://openjdk.java.net/projects/jdk9/rc [5] http://openjdk.java.net/jeps/0 [6] http://openjdk.java.net/legal/gplv2+ce.html [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html From gnu.andrew at redhat.com Wed Sep 6 15:31:47 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Sep 2017 16:31:47 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: On 6 September 2017 at 15:49, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) Will these branches (whatever form they take) now be public? With the current 8u project, the stage between a release being forked for stabilization and then released is currently non-public. There are obvious issues there with security fixes, but currently we can only pick up a release at least a month behind because we don't have access to it in a finished form until release. For example, we'll not have access to 8u152 in its final form until late October, so I can't see us being able to release builds based on it until November at the earliest. Incidentally, my vote would be for separate repositories to avoid confusion. My experience of Mercurial branches is they don't work in the same way as in other distributed version control systems, such as git in particular. > > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. So I imagine the use case will be similar to now, where a fix is pushed to the main line first, and then a backport requested in the updates project? I can see that being most relevant for the long-term support release, especially when it gets into its second and third years. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > This is great news! What about open source features that are currently bundled with the Oracle builds, such as JavaFX? > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? >From your blog: "the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year?s March release will be 18.3, and the September long-term support release will be 18.9." How does this interact with the idea of Java 9, 10, etc? Will those be a thing of the past or will we see versions like 9.18.3? How does update versioning fit in with that? > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > [3] http://openjdk.java.net/projects/jdk9/rdp-2 > [4] http://openjdk.java.net/projects/jdk9/rc > [5] http://openjdk.java.net/jeps/0 > [6] http://openjdk.java.net/legal/gplv2+ce.html > [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html > [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html Certainly a lot of food for thought. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From neugens at redhat.com Wed Sep 6 15:39:32 2017 From: neugens at redhat.com (Mario Torre) Date: Wed, 6 Sep 2017 17:39:32 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: On Wed, Sep 6, 2017 at 4:49 PM, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) > > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? This is fantastic news Mark, together with the recent Security group, I really like where this is all going, thanks to you and all the involved people to really pushing to the openness! I'm curious about the model and how it will practically work out, i.e "a new feature release every six months, update releases every quarter, and a long-term support release every three years". Does it means that the long-term support is the equivalent of today jdk7jdk8/jdk9 etc.. while the other will be basically just development version in between with various degree of stability? Or is it the goal that every version will be production ready? Another question is about open sourcing the commercial features. Wow, this is really awesome, kudos! Is that "limited" to the bits that are inside the JDK or are you planning to open source mission control as a whole too? Btw, thanks a lot for releasing the builds and EA binaries under an open license, this came out a few times during our talks at FOSDEM and I'm glad you listened to this feedback. It's exciting times waiting ahead of us. Cheers, Mario From martijnverburg at gmail.com Wed Sep 6 16:00:36 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 6 Sep 2017 17:00:36 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: Hi Mark, This is really welcome news, I suspect you're going to have a very happy X Million developers (the twitter storm is already glowing with positive reaction)! Like Mario I'm also curious about how the release numbering will work. The change to semver in Java 9 was welcome, but did require some tooling changes. As for the open sourcing of items like JFR and Mission Control - that's going to be a huge boost to the ecosystem in terms of debug and performance tuning not to mention everything else, so thank you (and to the other Oracle folks who helped make this decision)! Cheers, Martijn On 6 September 2017 at 16:39, Mario Torre wrote: > On Wed, Sep 6, 2017 at 4:49 PM, wrote: > > Over on my blog today I've argued that Java needs to move forward faster. > > To achieve that I've proposed that the Java SE Platform and the JDK shift > > from the historical feature-driven release model to a strict, time-based > > model with a new feature release every six months, update releases every > > quarter, and a long-term support release every three years: > > > > https://mreinhold.org/blog/forward-faster > > > > Here are some initial thoughts on how we might implement this proposal > > here in the OpenJDK Community. Comments and questions about both the > > proposal and its implementation are welcome on this list. > > > > Rather than create a brand new "JDK $N" Release Project every six months, > > I suggest that we create a single long-running "JDK" Release Project to > > host the main-line code base and produce the feature releases. > Similarly, > > let's create a single long-running "JDK Updates" Project to produce the > > update releases, for the most recent feature release and the current > > long-term support release. > > > > Two long-running Projects will save some administrative overhead, and > also > > eliminate the confusion that regularly arises when someone is a Committer > > to JDK $N but not JDK $N + 1. (We could consider just one long-running > > Project, but two makes more sense since since the two types of releases > > will have different policies, content, schedules, and leadership.) > > > > The new JDK Project will run a bit differently than the past "JDK $N" > > Projects: > > > > - The main development line will always be open but fixes, > enhancements, > > and features will be merged only when they're nearly finished. The > > main line will be Feature Complete [1] at all times. > > > > - We'll fork the main line into a release-stabilization branch three > > months before the GA date of the next feature release. That branch > > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > > [3] a month later, and then enter the Release Candidate phase [4] a > > month after that. (Whether the branch is another repository or an > > actual Mercurial branch is a detail we can figure out later.) > > > > - We'll continue to use the JEP Process [5] for new features and other > > significant changes. The bar to target a JEP to a specific release > > will, however, be higher since the work must be Feature Complete in > > order to go in. Owners of large or risky features will be strongly > > encouraged to split such features up into smaller and safer parts, to > > integrate earlier in the release cycle, and to publish separate lines > > of early-access builds prior to integration. > > > > The JDK Updates Project will run in much the same way as the past "JDK > $N" > > Updates Projects, though update releases will be strictly limited to > fixes > > of security issues, regressions, and bugs in newer features. > > > > Related to this proposal, we at Oracle intend to make a few changes in > > what we do: > > > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > > make it easier for developers to deploy Java applications to cloud > > environments. We'll initially publish OpenJDK builds for Linux/x64, > > followed later by builds for macOS/x64 and Windows/x64. > > > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > > "commercial features" [7] such as Java Flight Recorder and Mission > > Control [8], under a click-through binary-code license [9]. Oracle > > will continue to offer paid support for these builds. > > > > - After JDK 9 we'll open-source the commercial features in order to > > make the OpenJDK builds more attractive to developers and to reduce > > the differences between those builds and the Oracle JDK. This will > > take some time, but the ultimate goal is to make OpenJDK and Oracle > > JDK builds completely interchangeable. > > > > - Finally, for the long term we'll work with other OpenJDK contributors > > to establish an open build-and-test infrastructure. This will make > > it easier to publish early-access builds for features in development, > > and eventually make it possible for the OpenJDK Community itself to > > publish authoritative builds of the JDK. > > > > So ... that's a lot of proposed change, and there are (obviously!) many > > details to work out. Comments? Questions? > > This is fantastic news Mark, together with the recent Security group, > I really like where this is all going, thanks to you and all the > involved people to really pushing to the openness! > > I'm curious about the model and how it will practically work out, i.e > "a new feature release every six months, update releases every > quarter, and a long-term support release every three years". Does it > means that the long-term support is the equivalent of today > jdk7jdk8/jdk9 etc.. while the other will be basically just development > version in between with various degree of stability? Or is it the goal > that every version will be production ready? > > Another question is about open sourcing the commercial features. Wow, > this is really awesome, kudos! Is that "limited" to the bits that are > inside the JDK or are you planning to open source mission control as a > whole too? > > Btw, thanks a lot for releasing the builds and EA binaries under an > open license, this came out a few times during our talks at FOSDEM and > I'm glad you listened to this feedback. > > It's exciting times waiting ahead of us. > > Cheers, > Mario > From gnu.andrew at redhat.com Wed Sep 6 16:58:15 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Sep 2017 17:58:15 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: On 6 September 2017 at 16:39, Mario Torre wrote: snip... > involved people to really pushing to the openness! > > I'm curious about the model and how it will practically work out, i.e > "a new feature release every six months, update releases every > quarter, and a long-term support release every three years". Does it > means that the long-term support is the equivalent of today > jdk7jdk8/jdk9 etc.. while the other will be basically just development > version in between with various degree of stability? Or is it the goal > that every version will be production ready? > My interpretation of this was that it would be something like the Firefox model. As Mark's blog states in more detail, the idea is for all releases to be production ready and, indeed, for the development mainline to be more stable in general, so big features would only go in when they are ready to go out (implying they need to be tested heavily elsewhere) So I see it more as distros like Fedora would pick up every feature release, while something like RHEL would use the long-term support release. I presume update releases would be made available for both; basically the equivalent of the current security releases on the same cycle. So, October 2018 & January 2019 would see just the security update for the long-term support release, 18.9, but April 2019 would see security updates for both 18.9 and 19.3, the next feature release after the long-term release (assuming updates stick to Oracle's product-wide quarterly update cycle). -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From volker.simonis at gmail.com Wed Sep 6 17:07:31 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Sep 2017 19:07:31 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: On Wed, Sep 6, 2017 at 4:49 PM, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) > Hi Mark, this is all very interesting and leaves a lot romm for discussions! If I understand everything correctly, it really reminds me of a proposal I made back in 2013 :) when we discussed the structure of the then new jdk 9 repos [1]: "why don't we create something like http://hg.openjdk.java.net/dev with master, dev, client and hotspot forest beneath it. These forests could live "forever". Any time a new release is ready, we would then clone jdk9, jdk10, etc from dev/master. Wouldn't that be a more natural setup?" So could you please be a little more specific about the vision you have for the repositories of the new "JDK Release Project"? What does "the main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished" really means? 1. Merged from where? From which other code line or repository? 2. Do we have other kind of changes than "fixes, enhancements, and features" ? 3. Currently we have jdk10/jdk10, jdk10/hs and jdk10/client. At least all fixes and enhancements (i.e. 'the daily development stuff') go into one of these repos. In the future, lets say we'll have something like jdk/master, jdk/hs and jdk/client. Will all fixes and enhancements be considered "nearly finished" by default? From my point of view, everything else wouldn't make sense for our "daily work". I understand that bigger "features" (i.e. Jigsaw, Value Types, etc.) would have to be developed in their own, separate repositories until "nearly ready" and only then merged into let's say jdk/master. Is it this what you propose? 4. Having more features being developed in their own repositories (until they are "nearly ready") raises the question, how changes for such features will be reviewed? Currently we only have own repos for quite big features like a new port, Jigsaw or Value Types to name some examples. These "big" features have always been sponsored by OpenJDK groups with their own, special review rules and later, when they have been integrated into the main development repos they had to be reviewed once again under the jdk8/jdk9/hotspot review rules. If we will have much more features being developed in parallel to the main development line, this approach would impose a significant overhead. What do you think? 5. What do you mean by "The main line will be Feature Complete [1] at all times". How can a development line be "feature complete"? Features and JEPs will always be targeted to a specific release so from my understanding only a release-branch can be "feature complete". We can not know beforehand what will be in the next release which will be forked from the development line (and this not only depends on the OpenJDK, but also on the JCP!). > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > a. Targeting for a release X now means a JEP will have to be integrated into the main development line not later than three months before the GA date of X (i.e. before the release-stabilization branch will be forked). That means there's always a 6-month window (between two forks) for bringing new features into the main line right? And during this six month, we can only integrate features into the main line which are targeted for next release, right? b. In other words: every feature which is integrated into the main line in the six month period between the forks of two releases X and Y will be targeted for Y. But again, we can't now all the features which will go into Y after we've forked X (and it would contradict the 'train-model' if we would know). So how could the main line be feature complete at all times? c. For some features, such a model may be OK. But consider a "feature" like G1. It was in hotspot for years, before it became officially supported (i.e. "feature complete"). I don't think we can use such a strong model of "Feature Completeness" for such kind of projects and insist on the fact that the main development line always has to be "feature complete". It would also be hard to split such features into smaller parts which can still be considered features. Any thoughts on this? Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000115.html > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > [3] http://openjdk.java.net/projects/jdk9/rdp-2 > [4] http://openjdk.java.net/projects/jdk9/rc > [5] http://openjdk.java.net/jeps/0 > [6] http://openjdk.java.net/legal/gplv2+ce.html > [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html > [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html From hufeng1987 at gmail.com Wed Sep 6 23:06:46 2017 From: hufeng1987 at gmail.com (zixu mo) Date: Wed, 6 Sep 2017 23:06:46 +0000 (UTC) Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <9F8F6CAC61426010.7686c638-ff18-458d-ade4-b041eb60238c@mail.outlook.com> please move to github . be more open. be more friendly. like c# .net on github . even python now opensource on github. On Thu, Sep 7, 2017 at 1:07 AM +0800, "Volker Simonis" wrote: On Wed, Sep 6, 2017 at 4:49 PM, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) > Hi Mark, this is all very interesting and leaves a lot romm for discussions! If I understand everything correctly, it really reminds me of a proposal I made back in 2013 :) when we discussed the structure of the then new jdk 9 repos [1]: "why don't we create something like http://hg.openjdk.java.net/dev with master, dev, client and hotspot forest beneath it. These forests could live "forever". Any time a new release is ready, we would then clone jdk9, jdk10, etc from dev/master. Wouldn't that be a more natural setup?" So could you please be a little more specific about the vision you have for the repositories of the new "JDK Release Project"? What does "the main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished" really means? 1. Merged from where? From which other code line or repository? 2. Do we have other kind of changes than "fixes, enhancements, and features" ? 3. Currently we have jdk10/jdk10, jdk10/hs and jdk10/client. At least all fixes and enhancements (i.e. 'the daily development stuff') go into one of these repos. In the future, lets say we'll have something like jdk/master, jdk/hs and jdk/client. Will all fixes and enhancements be considered "nearly finished" by default? From my point of view, everything else wouldn't make sense for our "daily work". I understand that bigger "features" (i.e. Jigsaw, Value Types, etc.) would have to be developed in their own, separate repositories until "nearly ready" and only then merged into let's say jdk/master. Is it this what you propose? 4. Having more features being developed in their own repositories (until they are "nearly ready") raises the question, how changes for such features will be reviewed? Currently we only have own repos for quite big features like a new port, Jigsaw or Value Types to name some examples. These "big" features have always been sponsored by OpenJDK groups with their own, special review rules and later, when they have been integrated into the main development repos they had to be reviewed once again under the jdk8/jdk9/hotspot review rules. If we will have much more features being developed in parallel to the main development line, this approach would impose a significant overhead. What do you think? 5. What do you mean by "The main line will be Feature Complete [1] at all times". How can a development line be "feature complete"? Features and JEPs will always be targeted to a specific release so from my understanding only a release-branch can be "feature complete". We can not know beforehand what will be in the next release which will be forked from the development line (and this not only depends on the OpenJDK, but also on the JCP!). > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > a. Targeting for a release X now means a JEP will have to be integrated into the main development line not later than three months before the GA date of X (i.e. before the release-stabilization branch will be forked). That means there's always a 6-month window (between two forks) for bringing new features into the main line right? And during this six month, we can only integrate features into the main line which are targeted for next release, right? b. In other words: every feature which is integrated into the main line in the six month period between the forks of two releases X and Y will be targeted for Y. But again, we can't now all the features which will go into Y after we've forked X (and it would contradict the 'train-model' if we would know). So how could the main line be feature complete at all times? c. For some features, such a model may be OK. But consider a "feature" like G1. It was in hotspot for years, before it became officially supported (i.e. "feature complete"). I don't think we can use such a strong model of "Feature Completeness" for such kind of projects and insist on the fact that the main development line always has to be "feature complete". It would also be hard to split such features into smaller parts which can still be considered features. Any thoughts on this? Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000115.html > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > [3] http://openjdk.java.net/projects/jdk9/rdp-2 > [4] http://openjdk.java.net/projects/jdk9/rc > [5] http://openjdk.java.net/jeps/0 > [6] http://openjdk.java.net/legal/gplv2+ce.html > [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html > [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html From bourges.laurent at gmail.com Thu Sep 7 08:04:30 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 7 Sep 2017 10:04:30 +0200 Subject: Client group consolidation ? In-Reply-To: References: Message-ID: Hi, I wonder what is the current status of the Client consolidation gathering former openjdk groups 2d, awt, sound... and maybe openjfx ? I remember that Phil Race proposed such a big change but as these groups are fragmented with only few active members, I think it is worth to merge them to obtain a larger work team. Of course, it depends on the ByLaws consensus. Laurent From cowwoc at bbs.darktech.org Thu Sep 7 19:04:29 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 7 Sep 2017 12:04:29 -0700 (MST) Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <1504811069478-0.post@n7.nabble.com> While I like the idea of more frequent releases, I see two problems with the proposal in its current form: 1. It takes longer than 6 months for users to expose design problems. Consider tagging new features with @Beta annotations, allowing the breaking of backward compatibility for another year or so, and eventually graduating them to stability by removing the @Beta tags. 2. Every product that has used time-based version numbers has inevitably dropped the approach (the only exception that comes to mind is MS Word). When this happens, the version history is permanently polluted with large version numbers. Instead of hijacking the major.minor version numbers, consider placing this information in the build number (e.g. 9.1.5+2017-11-15) Gili -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-discussion-f67169.html From cowwoc at bbs.darktech.org Thu Sep 7 19:10:18 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 7 Sep 2017 12:10:18 -0700 (MST) Subject: Accelerating the JDK release cadence In-Reply-To: <9F8F6CAC61426010.7686c638-ff18-458d-ade4-b041eb60238c@mail.outlook.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <9F8F6CAC61426010.7686c638-ff18-458d-ade4-b041eb60238c@mail.outlook.com> Message-ID: <1504811418141-0.post@n7.nabble.com> Netroby wrote > please move to github . be more open. be more friendly. like c# .net on > github . even python now opensource on github. -1 for two reasons: 1) Users will file millions of low-quality bug reports. Take a look at the Android bug tracker to see what I mean. 2) Git is harder to use than Mercurial and Github is horribly slow for larger projects. I should know, my employer (who I will not name) uses Github Enterprise and the experience is so frustrating it grinds the development process to a halt. The server is sitting on a very powerful box in AWS so I don't think this problem will be easy to resolve. Gili -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-discussion-f67169.html From jbluettduncan at gmail.com Thu Sep 7 19:12:28 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 7 Sep 2017 20:12:28 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <1504811069478-0.post@n7.nabble.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: > > 2. Every product that has used time-based version numbers has inevitably > dropped the approach (the only exception that comes to mind is MS Word). > When this happens, the version history is permanently polluted with large > version numbers. Instead of hijacking the major.minor version numbers, > consider placing this information in the build number (e.g. > 9.1.5+2017-11-15) Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a time-based version scheme. Cheers, Jonathan On 7 September 2017 at 20:04, cowwoc wrote: > While I like the idea of more frequent releases, I see two problems with > the > proposal in its current form: > > 1. It takes longer than 6 months for users to expose design problems. > Consider tagging new features with @Beta annotations, allowing the breaking > of backward compatibility for another year or so, and eventually graduating > them to stability by removing the @Beta tags. > > 2. Every product that has used time-based version numbers has inevitably > dropped the approach (the only exception that comes to mind is MS Word). > When this happens, the version history is permanently polluted with large > version numbers. Instead of hijacking the major.minor version numbers, > consider placing this information in the build number (e.g. > 9.1.5+2017-11-15) > > Gili > > > > -- > Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General- > discussion-f67169.html > From jbluettduncan at gmail.com Thu Sep 7 19:19:35 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 7 Sep 2017 20:19:35 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: > > ...Github is horribly slow for larger projects. I wonder if you could you point me to a particular open source project on GitHub that suffers from this problem, and explain to me what slows down exactly? I ask as I've worked with large projects like Bazel, and the only slow operations I personally remember having encountered are downloading large Git histories for the first time and importing such projects into IDEs. Cheers, Jonathan On 7 September 2017 at 20:12, Jonathan Bluett-Duncan < jbluettduncan at gmail.com> wrote: > 2. Every product that has used time-based version numbers has inevitably >> dropped the approach (the only exception that comes to mind is MS Word). >> When this happens, the version history is permanently polluted with large >> version numbers. Instead of hijacking the major.minor version numbers, >> consider placing this information in the build number (e.g. >> 9.1.5+2017-11-15) > > > Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a > time-based version scheme. > > Cheers, > Jonathan > > On 7 September 2017 at 20:04, cowwoc wrote: > >> While I like the idea of more frequent releases, I see two problems with >> the >> proposal in its current form: >> >> 1. It takes longer than 6 months for users to expose design problems. >> Consider tagging new features with @Beta annotations, allowing the >> breaking >> of backward compatibility for another year or so, and eventually >> graduating >> them to stability by removing the @Beta tags. >> >> 2. Every product that has used time-based version numbers has inevitably >> dropped the approach (the only exception that comes to mind is MS Word). >> When this happens, the version history is permanently polluted with large >> version numbers. Instead of hijacking the major.minor version numbers, >> consider placing this information in the build number (e.g. >> 9.1.5+2017-11-15) >> >> Gili >> >> >> >> -- >> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-discussion >> -f67169.html >> > > From cowwoc at bbs.darktech.org Thu Sep 7 19:41:15 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 7 Sep 2017 15:41:15 -0400 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: On 2017-09-07 3:12 PM, Jonathan Bluett-Duncan wrote: > > 2. Every product that has used time-based version numbers has > inevitably > dropped the approach (the only exception that comes to mind is MS > Word). > When this happens, the version history is permanently polluted > with large > version numbers. Instead of hijacking the major.minor version numbers, > consider placing this information in the build number (e.g. > 9.1.5+2017-11-15) > > > Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a > time-based version scheme. That's true. But these projects are in the minority. The JDK has changed versioning schemes more often than most projects. I have nothing against a time-based scheme in its own right, but it is extremely annoying to step away from and I am not willing to bet that the JDK will retain this versioning scheme for the rest of time. Gili From cowwoc at bbs.darktech.org Thu Sep 7 19:48:30 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 7 Sep 2017 15:48:30 -0400 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> On 2017-09-07 3:19 PM, Jonathan Bluett-Duncan wrote: > > ...Github is horribly slow for larger projects. > > > I wonder if you could you point me to a particular open source project > on GitHub that suffers from this problem, and explain to me what slows > down exactly? I've never encounted this problem on github.com, only Github Enterprise. I've only ever dealt with smaller projects on github.com and it's possible that the former is better managed than Github Enterprise installations tend to be. In the case of my particular employer, most operations were decently fast, but opening, comments, and merging PRs was extremely slow. This has only gotten slower over time with newer versions of Github Enterprise and as the size of our projects have grown. I think we're more likely to see bugs.openjdk.java.net opened to the public before we'll see the code on Github/Bitbucket. The source-code is already open to the public. The main benefit of moving it to Github/Bitbucket would be to provide 2-way communication in the form of bug reports and PRs. Given Oracle's business model, I don't see that happening any time soon. Gili From john.r.rose at oracle.com Thu Sep 7 20:04:36 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Sep 2017 13:04:36 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: On Sep 7, 2017, at 12:19 PM, Jonathan Bluett-Duncan wrote: > > large projects like Bazel There are many degrees of large. (About 42 in the known universe not counting Planck scale.) Bazel looks like it has a very respectable 12k commits, 8k files, 160Mb of code, 250 authors. The Amber repo (to take just one OpenJDK repo at random) has 45k commits, 57k files, 560Mb of code, 450 authors. Bazel has 6 repos (including the one I quoted above). OpenJDK has hundreds (including Amber's 8). Whatever we do has to robustly serve a lot of code and history, for a long time. (I'm not going to try to evaluate git[hub] vs mercurial on the merits of popularity, tools, APIs, etc.) ? John From kellyohair at gmail.com Thu Sep 7 20:30:46 2017 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 7 Sep 2017 13:30:46 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> Message-ID: <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. -kto From neugens.limasoftware at gmail.com Thu Sep 7 20:58:08 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 7 Sep 2017 22:58:08 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: 2017-09-07 22:30 GMT+02:00 Kelly O'Hair : > Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. > > -kto Mercurial was a mistake all along, we should have stick to TeamWare! Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kellyohair at gmail.com Fri Sep 8 02:15:55 2017 From: kellyohair at gmail.com (O'Hair Kelly) Date: Thu, 7 Sep 2017 19:15:55 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: ?? Sent from my iPhone > On Sep 7, 2017, at 13:58, Mario Torre wrote: > > 2017-09-07 22:30 GMT+02:00 Kelly O'Hair : >> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. >> >> -kto > > Mercurial was a mistake all along, we should have stick to TeamWare! > > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From hufeng1987 at gmail.com Fri Sep 8 04:06:56 2017 From: hufeng1987 at gmail.com (Netroby) Date: Fri, 8 Sep 2017 12:06:56 +0800 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: Linus hosting it's kernel repo on github. Microsoft now hosting .net opensource on github either, python move from mercurial to github . PHP move from svn to github, Ruby on github, Swift move to github, Golang move to github. Rust lang on github, Scala on github, haskell GHC on github, Clojure on github, kotlin on github. So why you afraid move to github? Appreciate your time. ---------------------------- Netroby 2017-09-08 10:15 GMT+08:00 O'Hair Kelly : > ?? > > Sent from my iPhone > >> On Sep 7, 2017, at 13:58, Mario Torre wrote: >> >> 2017-09-07 22:30 GMT+02:00 Kelly O'Hair : >>> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. >>> >>> -kto >> >> Mercurial was a mistake all along, we should have stick to TeamWare! >> >> Cheers, >> Mario >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ From Alan.Bateman at oracle.com Fri Sep 8 06:33:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Sep 2017 07:33:04 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <1504811069478-0.post@n7.nabble.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: On 07/09/2017 20:04, cowwoc wrote: > While I like the idea of more frequent releases, I see two problems with the > proposal in its current form: > > 1. It takes longer than 6 months for users to expose design problems. > Consider tagging new features with @Beta annotations, allowing the breaking > of backward compatibility for another year or so, and eventually graduating > them to stability by removing the @Beta tags. > There is already support for incubating modules [1], also -XX:+UnlockExperimentalVMOptions to enable experimental options in the VM, and a few other mechanisms. In addition, if open build+test infrastructure can be established then it will should make it a lot easier for projects here to publish EA builds and should get more feedback around a feature while it is in development rather years after it has shipped. -Alan [1] http://openjdk.java.net/jeps/11 From martijnverburg at gmail.com Fri Sep 8 07:43:05 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 8 Sep 2017 08:43:05 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> Message-ID: Exactly this. Even if the uptake of developers applying modularity to their own applications is a little slow, Jigsaw is still proving it's worth many, many times over by enabling incubation modules and an enhanced @Deprecation system. It's truly going to allow Java to develop at a rapid pace in a *safe* manner, the best of both worlds. This probably hasn't been said enough, but Mark, Alan and the rest of the Jigsaw folks - I really appreciate the work that you've done to help accelerate Java and give it longevity. Cheers, Martijn On 8 September 2017 at 07:33, Alan Bateman wrote: > On 07/09/2017 20:04, cowwoc wrote: > >> While I like the idea of more frequent releases, I see two problems with >> the >> proposal in its current form: >> >> 1. It takes longer than 6 months for users to expose design problems. >> Consider tagging new features with @Beta annotations, allowing the >> breaking >> of backward compatibility for another year or so, and eventually >> graduating >> them to stability by removing the @Beta tags. >> >> There is already support for incubating modules [1], also > -XX:+UnlockExperimentalVMOptions to enable experimental options in the > VM, and a few other mechanisms. In addition, if open build+test > infrastructure can be established then it will should make it a lot easier > for projects here to publish EA builds and should get more feedback around > a feature while it is in development rather years after it has shipped. > > -Alan > > [1] http://openjdk.java.net/jeps/11 > From aph at redhat.com Fri Sep 8 08:15:14 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Sep 2017 09:15:14 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> On 06/09/17 15:49, mark.reinhold at oracle.com wrote: > Comments? Questions? I hardly need to say how delighted we at Red Hat, and I'm sure the wider developer community, are with this change. It'll make a substantial difference to the way we work, and I hope it'll encourage a new generation of developers to work with us. The proposed process you've described is similar to that used by other free software projects, so it sounds like it will work well. Hitherto, OpenJDK has been a rather unrewarding place for individual community developers and companies because of the very long cycle time between making a contribution and its use in a Java release. This new process will make it easier to encourage developers of free software to spend their time working with us on OpenJDK. The shrinking difference between the proprietary Oracle JDK and OpenJDK will reduce confusion and the feeling in some quarters that OpenJDK is in some way illegitimate, inferior, or in some way unreliable. It will also help encourage community development. This is another big step towards openness and co-operation since we began working together when OpenJDK Sun freed the Java source code ten years ago. Bravo! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 8 09:02:41 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 8 Sep 2017 10:02:41 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> Message-ID: On 08/09/17 09:15, Andrew Haley wrote: > On 06/09/17 15:49, mark.reinhold at oracle.com wrote: >> Comments? Questions? > > I hardly need to say how delighted we at Red Hat, and I'm sure the > wider developer community, are with this change. . . . Yeah, what he said! I am sure these proposed changes will bring great benefits to all parties involved in developing and using Java, both individual and corporate. I very much want to thank you, Mark (also other Oracle staff who took the decision), for making this happen. One thing I still have not seen addressed is maintenance and availability of TCKs. Are any changes planned there? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martijnverburg at gmail.com Fri Sep 8 09:16:04 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 8 Sep 2017 10:16:04 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> Message-ID: Hi Andrew, I'm not Mark (obviously) but it's something that the JCP EC has been working with Georges and Brian on. *Nothing* is set in concrete yet but the intention is to make a regular draft TCK's available under a friendly license so that the other Java implementors can implement against that spec as it moves along (as opposed to only getting access once the RI is officially released). That should allow the other Java implementers to closely follow the same release cycle (if they choose to do so). I won't have any further info on this until we have the next JCP EC meeting (just before JavaOne), but it's the number one item on the agenda for us to resolve. Cheers, Martijn On 8 September 2017 at 10:02, Andrew Dinn wrote: > On 08/09/17 09:15, Andrew Haley wrote: > > On 06/09/17 15:49, mark.reinhold at oracle.com wrote: > >> Comments? Questions? > > > > I hardly need to say how delighted we at Red Hat, and I'm sure the > > wider developer community, are with this change. . . . > Yeah, what he said! > > I am sure these proposed changes will bring great benefits to all > parties involved in developing and using Java, both individual and > corporate. I very much want to thank you, Mark (also other Oracle staff > who took the decision), for making this happen. > > One thing I still have not seen addressed is maintenance and > availability of TCKs. Are any changes planned there? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From adinn at redhat.com Fri Sep 8 09:22:42 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 8 Sep 2017 10:22:42 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> Message-ID: <0c99729b-30c5-b245-582f-b1b754081fda@redhat.com> Hi Martijn, On 08/09/17 10:16, Martijn Verburg wrote: > I'm not Mark (obviously) but it's something that the JCP EC has been > working with Georges and Brian on.? *Nothing* is set in concrete yet but > the intention is to make a regular draft TCK's available under a > friendly license so that the other Java implementors can implement > against that spec as it moves along (as opposed to only getting access > once the RI is officially released).? That should allow the other Java > implementers to closely follow the same release cycle (if they choose to > do so). > > I won't have any further info on this until we have the next JCP EC > meeting (just before JavaOne), but it's the number one item on the > agenda for us to resolve. Thanks, for the update. That's going to be a great help. This gets better and better! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martijnverburg at gmail.com Fri Sep 8 09:32:05 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 8 Sep 2017 10:32:05 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> Message-ID: On a separate note, Some folks outside of this list have asked about platforms outside of the main three (Linux x86, Windows, Mac OS X). The London Jamocha Community (to use it's legal name) has recently applied and been granted the J(TCK). This means that for the more esoteric platforms, we will be able to formally test the OpenJDK binaries on the Adopt OpenJDK build farm (https://ci.adoptopenjdk.net). Developers will be able to download those binaries for their use (https://www.adoptopenjdk.net and via an API), if they don't already have a convenient place to do so from. For OpenJDK 8 and 9 the Adopt OpenJDK programme currently builds and runs OpenJDK tests + some other donated tests for: * Linux x86, Windows, Mac OS X (Oracle will naturally be the default place to go for these anyhow) * AIX * Linux s390x, Linux ppc64le, Linux aarch64, Linux arm32 * SmartOS * And of course Docker (to be buzzword compliant) We'll need to apply for and get the TCK for Java 9+ but our intention is to provide binaries for these other platforms, following the release cycle that Mark has proposed. I know there's a lot of other folks producing various binaries etc (especially the distros and RH with IcedTea etc) and I'm hoping that many of us can we can all meet at JavaOne and figure out how we can share more common infrastructure and tests. I'll reach out separately to organise that. Cheers, Martijn On 8 September 2017 at 10:16, Martijn Verburg wrote: > Hi Andrew, > > I'm not Mark (obviously) but it's something that the JCP EC has been > working with Georges and Brian on. *Nothing* is set in concrete yet but > the intention is to make a regular draft TCK's available under a friendly > license so that the other Java implementors can implement against that spec > as it moves along (as opposed to only getting access once the RI is > officially released). That should allow the other Java implementers to > closely follow the same release cycle (if they choose to do so). > > I won't have any further info on this until we have the next JCP EC > meeting (just before JavaOne), but it's the number one item on the agenda > for us to resolve. > > > Cheers, > Martijn > > On 8 September 2017 at 10:02, Andrew Dinn wrote: > >> On 08/09/17 09:15, Andrew Haley wrote: >> > On 06/09/17 15:49, mark.reinhold at oracle.com wrote: >> >> Comments? Questions? >> > >> > I hardly need to say how delighted we at Red Hat, and I'm sure the >> > wider developer community, are with this change. . . . >> Yeah, what he said! >> >> I am sure these proposed changes will bring great benefits to all >> parties involved in developing and using Java, both individual and >> corporate. I very much want to thank you, Mark (also other Oracle staff >> who took the decision), for making this happen. >> >> One thing I still have not seen addressed is maintenance and >> availability of TCKs. Are any changes planned there? >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> > > From cowwoc at bbs.darktech.org Fri Sep 8 16:15:34 2017 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 8 Sep 2017 12:15:34 -0400 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: <44b68b26-8bed-07dc-d4cf-a0e087bccef6@bbs.darktech.org> No one is debating that git is popular. But popularity on its own does not imply goodness ("Eat shit, millions of flies can't be wrong") or a good fit for our use-case. Technology aside, how is the current approach impacting you negatively? How will moving the code to Github change your life? Gili On 2017-09-08 12:06 AM, Netroby wrote: > Linus hosting it's kernel repo on github. Microsoft now hosting .net > opensource on github either, python move from mercurial to github . > PHP move from svn to github, Ruby on github, Swift move to github, > Golang move to github. > Rust lang on github, Scala on github, haskell GHC on github, Clojure > on github, kotlin on github. > So why you afraid move to github? > > > Appreciate your time. > ---------------------------- > Netroby > > > 2017-09-08 10:15 GMT+08:00 O'Hair Kelly : >> ?? >> >> Sent from my iPhone >> >>> On Sep 7, 2017, at 13:58, Mario Torre wrote: >>> >>> 2017-09-07 22:30 GMT+02:00 Kelly O'Hair : >>>> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. >>>> >>>> -kto >>> Mercurial was a mistake all along, we should have stick to TeamWare! >>> >>> Cheers, >>> Mario >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ From kellyohair at gmail.com Fri Sep 8 17:07:47 2017 From: kellyohair at gmail.com (Kelly O'Hair) Date: Fri, 8 Sep 2017 10:07:47 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: Has nothing to do with "afraid". If you have gone through as many source repository changes as I have, you learn that it is never as easy as people think. I'm not anti-GIT, I use it all the time. But the longer an organization uses a particular technology, the more embedded it becomes in the overall processes, so just converting the repos is the easiest part. Just keep in mind that there is more to it than that. -kto > On Sep 7, 2017, at 9:06 PM, Netroby wrote: > > Linus hosting it's kernel repo on github. Microsoft now hosting .net > opensource on github either, python move from mercurial to github . > PHP move from svn to github, Ruby on github, Swift move to github, > Golang move to github. > Rust lang on github, Scala on github, haskell GHC on github, Clojure > on github, kotlin on github. > So why you afraid move to github? > > > Appreciate your time. > ---------------------------- > Netroby > > > 2017-09-08 10:15 GMT+08:00 O'Hair Kelly : >> ?? >> >> Sent from my iPhone >> >>> On Sep 7, 2017, at 13:58, Mario Torre wrote: >>> >>> 2017-09-07 22:30 GMT+02:00 Kelly O'Hair : >>>> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. >>>> >>>> -kto >>> >>> Mercurial was a mistake all along, we should have stick to TeamWare! >>> >>> Cheers, >>> Mario >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ From benjamin.john.evans at gmail.com Fri Sep 8 17:28:19 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Fri, 8 Sep 2017 22:58:19 +0530 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: +1. In my experience, the git and Mercurial tools are broadly equivalent in terms of functionality and usability. However, git != github. The latter is a single point of failure, that has (in my opinion) a rather high number of DDOS-related outages that have prevented people from working effectively when it's affected. This is not a good thing for OpenJDK. Some friends in the content caching business tell me that GH is one of a number of sites that are used by sophisticated attackers to wargame how effectively they can bring down a high-traffic website - an important "cyberwar" (I hate the ridiculous prevalence that prefix, but here we are) technique for adversaries operating in the increasingly centralized Internet we now live in. I'm not really seeing what benefit we'd get from moving to Github - we're basically painting a target on our back to offer ourselves up as collateral damage. Is that really what we'd want for the mainstream of OpenJDK development? However, a downstream (or 2-way) feed into GH, and a "Community Issues" GH board that can be triaged by the community & good ideas / actual bug reports sent upstream - I think that would have a lot of value. If I recall correctly, there are folks at AdoptOpenJDK already working on that - Martijn, do you have any specifics? Ben On Fri, Sep 8, 2017 at 10:37 PM, Kelly O'Hair wrote: > Has nothing to do with "afraid". > > If you have gone through as many source repository changes as I have, you learn that it is never as easy as people think. > I'm not anti-GIT, I use it all the time. But the longer an organization uses a particular technology, the more embedded it becomes in the overall processes, so just converting the repos is the easiest part. Just keep in mind that there is more to it than that. > > -kto > >> On Sep 7, 2017, at 9:06 PM, Netroby wrote: >> >> Linus hosting it's kernel repo on github. Microsoft now hosting .net >> opensource on github either, python move from mercurial to github . >> PHP move from svn to github, Ruby on github, Swift move to github, >> Golang move to github. >> Rust lang on github, Scala on github, haskell GHC on github, Clojure >> on github, kotlin on github. >> So why you afraid move to github? >> >> >> Appreciate your time. >> ---------------------------- >> Netroby >> >> >> 2017-09-08 10:15 GMT+08:00 O'Hair Kelly : >>> ?? >>> >>> Sent from my iPhone >>> >>>> On Sep 7, 2017, at 13:58, Mario Torre wrote: >>>> >>>> 2017-09-07 22:30 GMT+02:00 Kelly O'Hair : >>>>> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry. >>>>> >>>>> -kto >>>> >>>> Mercurial was a mistake all along, we should have stick to TeamWare! >>>> >>>> Cheers, >>>> Mario >>>> >>>> -- >>>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>>> >>>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>>> Proud GNU Classpath developer: http://www.classpath.org/ >>>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>>> >>>> Please, support open standards: >>>> http://endsoftpatents.org/ > From mark.reinhold at oracle.com Fri Sep 8 16:31:45 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 08 Sep 2017 09:31:45 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: <20170908093145.925360778@eggemoggin.niobe.net> 2017/9/7 21:06:56 -0700, Netroby : > Linus hosting it's kernel repo on github. False: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html - Mark From hufeng1987 at gmail.com Sat Sep 9 00:11:44 2017 From: hufeng1987 at gmail.com (Netroby) Date: Sat, 9 Sep 2017 08:11:44 +0800 Subject: Accelerating the JDK release cadence In-Reply-To: <20170908093145.925360778@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> <20170908093145.925360778@eggemoggin.niobe.net> Message-ID: And I want to share you my stories on github. As an user, if you got trouble, what you can not resolve by yourself, you may need help. Thanks microsoft, it have github repository. i post the issue try to find a solution. https://github.com/dotnet/coreclr/issues/13220 They heard from me. and do some changes. https://blog.nuget.org/20170907/Changes-to-NuGet-dot-org-service-management-and-performance-improvements-in-China.html It really help us a lot. Not complex steps need to find a help. every things open and transparent. Anyone can join, communicate . push the project move forward. Really thanks their great works. and the change will help more and more developers out. Appreciate your time. ---------------------------- Netroby 2017-09-09 0:31 GMT+08:00 : > 2017/9/7 21:06:56 -0700, Netroby : >> Linus hosting it's kernel repo on github. > > False: > > http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html > > - Mark From volker.simonis at gmail.com Sat Sep 9 10:24:24 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 09 Sep 2017 10:24:24 +0000 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> <20170908093145.925360778@eggemoggin.niobe.net> Message-ID: This is all really interesting, but shouldn't this thread be about discussing the newly proposed release model and its implications on OpenJDK? I suggest we start new threads for other topics. Thanks, Volker Netroby schrieb am Sa. 9. Sep. 2017 um 02:12: > And I want to share you my stories on github. > > As an user, if you got trouble, what you can not resolve by yourself, > you may need help. > > Thanks microsoft, it have github repository. i post the issue try to > find a solution. > > https://github.com/dotnet/coreclr/issues/13220 > > They heard from me. and do some changes. > > > https://blog.nuget.org/20170907/Changes-to-NuGet-dot-org-service-management-and-performance-improvements-in-China.html > > It really help us a lot. > > Not complex steps need to find a help. every things open and transparent. > > Anyone can join, communicate . push the project move forward. > > Really thanks their great works. and the change will help more and > more developers out. > > Appreciate your time. > ---------------------------- > Netroby > > > 2017-09-09 0:31 GMT+08:00 : > > 2017/9/7 21:06:56 -0700, Netroby : > >> Linus hosting it's kernel repo on github. > > > > False: > > > > http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html > > > > - Mark > From matecs at niif.hu Sun Sep 10 10:42:09 2017 From: matecs at niif.hu (matecs) Date: Sun, 10 Sep 2017 12:42:09 +0200 Subject: experiments with jdk9 Message-ID: <6dfadf1a-0317-c3e3-6380-99e771c9ebfb@niif.hu> hi, i'm the author of freerouter.nop.hu, it's an open source router a java. the source base is about 3mb nowadays. the project started back at jdk6 days. it have a lot of functional self-tests which bring up jvm routers and pings between them with various protocols. i'm writing to you to inform you that i've recently switched to jdk9. i had to fix some deprecation warnings, but mostly it was smooth. back in the jdk8 days, i had some issues with the default gc on my big (64+gb) route reflector jvms, but switched to g1gc, and it solved it. i've noticed that it's now the default so i'll remove the option from startup scripts soon. finally, i wish you all the best and keep up the great work guys! csaba mate niif/hungarnet/as1955 From dalibor.topic at oracle.com Mon Sep 11 05:43:21 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 11 Sep 2017 07:43:21 +0200 Subject: experiments with jdk9 In-Reply-To: <6dfadf1a-0317-c3e3-6380-99e771c9ebfb@niif.hu> References: <6dfadf1a-0317-c3e3-6380-99e771c9ebfb@niif.hu> Message-ID: Hi Csaba, it's great to hear that freerouter works well on JDK 9. I hope that improvements in JDK 9, like compact strings, present a performance benefit for the big JVMs. cheers, dalibor topic On 10.09.2017 12:42, matecs wrote: > hi, > i'm the author of freerouter.nop.hu, it's an open source router a java. > the source base is about 3mb nowadays. > the project started back at jdk6 days. it have a lot of functional > self-tests which bring up jvm routers and > pings between them with various protocols. i'm writing to you to inform > you that i've recently switched to jdk9. > i had to fix some deprecation warnings, but mostly it was smooth. back > in the jdk8 days, i had some issues with > the default gc on my big (64+gb) route reflector jvms, but switched to > g1gc, and it solved it. i've noticed that > it's now the default so i'll remove the option from startup scripts soon. > finally, i wish you all the best and keep up the great work guys! > csaba mate > niif/hungarnet/as1955 > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From matecs at niif.hu Mon Sep 11 06:14:44 2017 From: matecs at niif.hu (matecs) Date: Mon, 11 Sep 2017 08:14:44 +0200 Subject: experiments with jdk9 Message-ID: <31cbcaef-786c-e3a8-b9da-6010d2441fa6@niif.hu> hi, compact strings does not add too much in my case because i don't have too much strings, but a lot of lists of arbitrary own binary types, mainly this: http://sources.nop.hu/src/tab/tabRouteEntry.java there are a lot of similarities as a lot of route properties match, for example bgp as paths and bgp communities, etc... but in generally speaking, i'm very satisfied with the memory footprint, the full internet table contains 650k routes nowadays, i've 100 peer routers to flood this info to, and i keep track of each route per peer (which is just references to the calculated best path, so these differs just for a very limited time frame, when convergence happens in the wild and the old, sent route does not match newly calculated one), and the whole big jvms use 10-13gb of ram, and the g1gc does not pause for more than 300 msec which is within the bounds of the routing protocols' requirements (ospf). regarding the performance, my measures show about 10% gain on my routing table operations (add, del, replace, longest-match) which is very nice achievement! regards, cs > it's great to hear that freerouter works well on JDK 9. I hope that > improvements in JDK 9, like compact strings, present a performance > benefit for the big JVMs. From dalibor.topic at oracle.com Mon Sep 11 06:39:30 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 11 Sep 2017 08:39:30 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> Message-ID: On 08.09.2017 11:32, Martijn Verburg wrote: > The London Jamocha Community (to use it's legal name) has recently applied > and been granted the J(TCK). Yup, as noted at the signatories page: http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From scolebourne at joda.org Wed Sep 6 15:12:46 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Sep 2017 16:12:46 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: I'm glad to see this happen. In general it seems fine (although I'm still looking forward to OpenJDK on git ;-) My only comment is the proposed version numbers. IMO, year-based versions don't work well, who wants Java to be like Windows 95? I'd suggest a simple incrementing number - like Chrome - is quite sufficient for the problem - 10, 11, 12, 13 Stephen On 6 September 2017 at 15:49, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) > > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > [3] http://openjdk.java.net/projects/jdk9/rdp-2 > [4] http://openjdk.java.net/projects/jdk9/rc > [5] http://openjdk.java.net/jeps/0 > [6] http://openjdk.java.net/legal/gplv2+ce.html > [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html > [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html From mark.reinhold at oracle.com Mon Sep 11 19:37:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Sep 2017 12:37:21 -0700 (PDT) Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <20170911193721.A6359AB9B4@eggemoggin.niobe.net> 2017/9/6 8:31:47 -0700, Andrew Hughes : > On 6 September 2017 at 15:49, mark.reinhold at oracle.com wrote: >> ... >> >> The new JDK Project will run a bit differently than the past "JDK $N" >> Projects: >> >> - The main development line will always be open but fixes, enhancements, >> and features will be merged only when they're nearly finished. The >> main line will be Feature Complete [1] at all times. >> >> - We'll fork the main line into a release-stabilization branch three >> months before the GA date of the next feature release. That branch >> will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 >> [3] a month later, and then enter the Release Candidate phase [4] a >> month after that. (Whether the branch is another repository or an >> actual Mercurial branch is a detail we can figure out later.) > > Will these branches (whatever form they take) now be public? Yes, the main-line stabilization branches will be public. > With the current > 8u project, the stage between a release being forked for stabilization and then > released is currently non-public. There are obvious issues there with security > fixes, but currently we can only pick up a release at least a month > behind because > we don't have access to it in a finished form until release. > > For example, we'll not have access to 8u152 in its final form until > late October, > so I can't see us being able to release builds based on it until November at the > earliest. The quarterly update branches aren't public during stabilization precisely because they contain security fixes, which can't be revealed until the end. One of the goals of the Vulnerability Group is to make those fixes available earlier to maintainers (such as yourself) who need them. > Incidentally, my vote would be for separate repositories to avoid confusion. > My experience of Mercurial branches is they don't work in the same way as > in other distributed version control systems, such as git in particular. In what ways are Mercurial branches inadequate for this purpose? >> ... >> >> The JDK Updates Project will run in much the same way as the past "JDK $N" >> Updates Projects, though update releases will be strictly limited to fixes >> of security issues, regressions, and bugs in newer features. > > So I imagine the use case will be similar to now, where a fix is pushed to the > main line first, and then a backport requested in the updates project? Yes. > ... > >> Related to this proposal, we at Oracle intend to make a few changes in >> what we do: >> >> - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to >> make it easier for developers to deploy Java applications to cloud >> environments. We'll initially publish OpenJDK builds for Linux/x64, >> followed later by builds for macOS/x64 and Windows/x64. >> >> - We'll continue to ship proprietary "Oracle JDK" builds, which include >> "commercial features" [7] such as Java Flight Recorder and Mission >> Control [8], under a click-through binary-code license [9]. Oracle >> will continue to offer paid support for these builds. >> >> - After JDK 9 we'll open-source the commercial features in order to >> make the OpenJDK builds more attractive to developers and to reduce >> the differences between those builds and the Oracle JDK. This will >> take some time, but the ultimate goal is to make OpenJDK and Oracle >> JDK builds completely interchangeable. >> >> - Finally, for the long term we'll work with other OpenJDK contributors >> to establish an open build-and-test infrastructure. This will make >> it easier to publish early-access builds for features in development, >> and eventually make it possible for the OpenJDK Community itself to >> publish authoritative builds of the JDK. > > This is great news! > > What about open source features that are currently bundled with the Oracle > builds, such as JavaFX? Well, they're already open-source, so there's nothing to do in that sense. The new OpenJDK builds are intended mainly for server-side/cloud use so they won't include FX, at least to start. >> So ... that's a lot of proposed change, and there are (obviously!) many >> details to work out. Comments? Questions? > > From your blog: > > "the version strings of feature releases will be of the form $YEAR.$MONTH. > Thus next year???s March release will be 18.3, and the September long-term > support release will be 18.9." > > How does this interact with the idea of Java 9, 10, etc? Will those be a > thing of the past or will we see versions like 9.18.3? They are a thing of the past -- the feature releases would go straight from 9 to 18.3. > How does update > versioning fit in with that? Good question! The obvious approach is to label the 18.3 updates as 18.3.1, 18.3.2, and so forth. The problem with that is that if we need to create an emergency release to address an urgent security issue then we'd have to renumber the update line currently in development, which is painful. An alternative is to label them 18.3.$AGE, where $AGE is the number of months since the 18.3 GA release. That'd give us 18.3.1, 18.3.4, etc., with spare numbers in between for emergency releases, much like what we've done for years with the JDK 7/8 updates. (Version schemes are, in general, a huge bikeshed -- second only to language syntax -- so I'm sure there will be much more discussion of this topic.) - Mark From mark.reinhold at oracle.com Mon Sep 11 19:38:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Sep 2017 12:38:21 -0700 (PDT) Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <20170911193821.B140AAB9B8@eggemoggin.niobe.net> 2017/9/6 8:39:32 -0700, Mario Torre : > This is fantastic news Mark, together with the recent Security group, > I really like where this is all going, thanks to you and all the > involved people to really pushing to the openness! Thanks! > I'm curious about the model and how it will practically work out, i.e > "a new feature release every six months, update releases every > quarter, and a long-term support release every three years". Does it > means that the long-term support is the equivalent of today > jdk7jdk8/jdk9 etc.. while the other will be basically just development > version in between with various degree of stability? Or is it the goal > that every version will be production ready? The latter: Every feature release will be production-ready. > Another question is about open sourcing the commercial features. Wow, > this is really awesome, kudos! Is that "limited" to the bits that are > inside the JDK or are you planning to open source mission control as a > whole too? We intend to open-source both Flight Recorder and Mission Control. > ... > > It's exciting times waiting ahead of us. Indeed! - Mark From mark.reinhold at oracle.com Mon Sep 11 19:39:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Sep 2017 12:39:21 -0700 (PDT) Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <20170911193921.BD32FAB9BC@eggemoggin.niobe.net> 2017/9/6 9:00:36 -0700, martijnverburg at gmail.com: > Hi Mark, > > This is really welcome news, I suspect you're going to have a very happy X > Million developers (the twitter storm is already glowing with positive > reaction)! > > Like Mario I'm also curious about how the release numbering will work. The > change to semver in Java 9 was welcome, but did require some tooling > changes. Yes, it did, and it's an unfortunate accident of timing that we're so soon contemplating another change in the version-string scheme, but there it is. There's definitely some risk here, but to the extent that people took (or will soon take) the opportunity with JDK 9 to start using the new API (`java.lang.Runtime.Version` [1]) to compare version strings then they'll find it easier to adapt to this next change. > As for the open sourcing of items like JFR and Mission Control - that's > going to be a huge boost to the ecosystem in terms of debug and performance > tuning not to mention everything else, so thank you (and to the other > Oracle folks who helped make this decision)! You're welcome! - Mark [1] http://download.java.net/java/jdk9/docs/api/java/lang/Runtime.Version.html From mark.reinhold at oracle.com Mon Sep 11 19:40:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Sep 2017 12:40:21 -0700 (PDT) Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <20170911194021.C93E8AB9C1@eggemoggin.niobe.net> 2017/9/6 9:58:15 -0700, Andrew Hughes : > On 6 September 2017 at 16:39, Mario Torre wrote: >> ... >> >> I'm curious about the model and how it will practically work out, i.e >> "a new feature release every six months, update releases every >> quarter, and a long-term support release every three years". Does it >> means that the long-term support is the equivalent of today >> jdk7jdk8/jdk9 etc.. while the other will be basically just development >> version in between with various degree of stability? Or is it the goal >> that every version will be production ready? > > My interpretation of this was that it would be something like the Firefox > model. As Mark's blog states in more detail, the idea is for all releases > to be production ready and, indeed, for the development mainline to be > more stable in general, so big features would only go in when they > are ready to go out (implying they need to be tested heavily elsewhere) Exactly. > So I see it more as distros like Fedora would pick up every feature > release, while something like RHEL would use the long-term > support release. I presume update releases would be made available > for both; basically the equivalent of the current security releases > on the same cycle. So, October 2018 & January 2019 would see > just the security update for the long-term support release, 18.9, but > April 2019 would see security updates for both 18.9 and 19.3, the next > feature release after the long-term release (assuming updates stick > to Oracle's product-wide quarterly update cycle). That's the plan. - Mark From mark.reinhold at oracle.com Mon Sep 11 19:41:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Sep 2017 12:41:21 -0700 (PDT) Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <20170911194121.D67FFAB9C6@eggemoggin.niobe.net> 2017/9/6 10:07:31 -0700, volker.simonis at gmail.com: > ... > > What does "the main development line will always be open but fixes, > enhancements, and features will be merged only when they're nearly > finished" really means? > > 1. Merged from where? From which other code line or repository? That depends upon the change. A small fix or enhancement can originate as a simple patch or webrev, as today. Larger changes can be developed over time in a separate branch in the sandbox repo. Big features will most likely originate and evolve for a while -- possibly years -- in their own Project-specific repos (e.g., Jigsaw, Amber, Panama, etc.). > 2. Do we have other kind of changes than "fixes, enhancements, and features" ? No. Do you think an important case is missing from this high-level categorization of types of changes? > 3. Currently we have jdk10/jdk10, jdk10/hs and jdk10/client. At least > all fixes and enhancements (i.e. 'the daily development stuff') go > into one of these repos. In the future, lets say we'll have something > like jdk/master, jdk/hs and jdk/client. Will all fixes and > enhancements be considered "nearly finished" by default? No. All changes will be subject to the same, higher bar. Historically, however, I suspect that many of the small changes in the past few feature releases would have cleared that bar owing to our other long-standing practices, such as review-before-commit. > ... > > 4. Having more features being developed in their own repositories > (until they are "nearly ready") raises the question, how changes for > such features will be reviewed? Currently we only have own repos for > quite big features like a new port, Jigsaw or Value Types to name some > examples. These "big" features have always been sponsored by OpenJDK > groups with their own, special review rules and later, when they have > been integrated into the main development repos they had to be > reviewed once again under the jdk8/jdk9/hotspot review rules. If we > will have much more features being developed in parallel to the main > development line, this approach would impose a significant overhead. > What do you think? I don't see significant additional overhead here. To the extent that separate lines of development have had their own review rules then those rules have generally been much more lax than those for merging into the main line. I expect that to continue, though ultimately it's up to those working on such separate lines, whether in a sandbox branch or a separate Project repo, to figure out how to work together, with some rules or no rules at all. > 5. What do you mean by "The main line will be Feature Complete [1] at > all times". How can a development line be "feature complete"? > Features and JEPs will always be targeted to a specific release so > from my understanding only a release-branch can be "feature complete". The "Feature Complete" milestone is defined as "All features have been implemented and integrated into the master forest, together with unit tests" [1]. If a development line is "Feature Complete at all times" then it is, by definition, always ready to enter the first ramp-down phase in preparation for release, i.e., it's always ready to become a release-stabilization branch. To put it another way, the "complete" set of features at any given time is just the set of features in the main line at that point in time. >> - We'll continue to use the JEP Process [5] for new features and other >> significant changes. The bar to target a JEP to a specific release >> will, however, be higher since the work must be Feature Complete in >> order to go in. Owners of large or risky features will be strongly >> encouraged to split such features up into smaller and safer parts, to >> integrate earlier in the release cycle, and to publish separate lines >> of early-access builds prior to integration. > > a. Targeting for a release X now means a JEP will have to be > integrated into the main development line not later than three months > before the GA date of X (i.e. before the release-stabilization branch > will be forked). Correct. > That means there's always a 6-month window (between > two forks) for bringing new features into the main line right? Yes. > And > during this six month, we can only integrate features into the main > line which are targeted for next release, right? Right. > b. In other words: every feature which is integrated into the main > line in the six month period between the forks of two releases X and Y > will be targeted for Y. But again, we can't now all the features which > will go into Y after we've forked X (and it would contradict the > 'train-model' if we would know). So how could the main line be feature > complete at all times? See above. > c. For some features, such a model may be OK. But consider a "feature" > like G1. It was in hotspot for years, before it became officially > supported (i.e. "feature complete"). I don't think we can use such a > strong model of "Feature Completeness" for such kind of projects and > insist on the fact that the main development line always has to be > "feature complete". It would also be hard to split such features into > smaller parts which can still be considered features. Any thoughts on > this? Yes. I have yet to see a big feature that can't be divided into smaller pieces, and it's perfectly fine for a "feature" to be something that most users won't notice. The important thing is that every "feature" be a coherent and testable set of changes that's ready for release. As an example, we merged Jigsaw into JDK 9 in several large phases, each of which could've been a separate feature over a series of six-month time-boxed releases. Some of those features would have had little to no impact on users (e.g., modularizing the JDK source code), but the end result would've been the same. In addition to divide-and-conquer, implementation features can be merged in an experimental mode at first (e.g., G1, AoT) and then, over time, be made non-experimental and even become the default, if appropriate, as they mature. With the incubator-module concept introduced in JDK 9 [2] we can now take a similar approach with new APIs. (Language and VM changes remain tricky to do in any kind of experimental or incubator mode, though I've recently heard some ideas that are worth further exploration.) - Mark [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [2] http://openjdk.java.net/jeps/11 From mark.reinhold at oracle.com Mon Sep 11 19:42:21 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Sep 2017 12:42:21 -0700 (PDT) Subject: Accelerating the JDK release cadence In-Reply-To: <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> Message-ID: <20170911194221.E2368AB9CA@eggemoggin.niobe.net> 2017/9/8 1:15:14 -0700, Andrew Haley : > I hardly need to say how delighted we at Red Hat, and I'm sure the > wider developer community, are with this change. It'll make a > substantial difference to the way we work, and I hope it'll encourage > a new generation of developers to work with us. > > ... > > This is another big step towards openness and co-operation since we > began working together when OpenJDK Sun freed the Java source code ten > years ago. Bravo! Thank you for your kind words, and thank you -- and everyone else in Red Hat's Java team -- for all of your support and contributions over the past ten years. Here's to many more to come! - Mark From neugens.limasoftware at gmail.com Mon Sep 11 20:26:06 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 11 Sep 2017 22:26:06 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <20170911194221.E2368AB9CA@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <387df280-98f2-a1e2-c4c4-1e3d76dd961d@redhat.com> <20170911194221.E2368AB9CA@eggemoggin.niobe.net> Message-ID: 2017-09-11 21:42 GMT+02:00 : > 2017/9/8 1:15:14 -0700, Andrew Haley : >> I hardly need to say how delighted we at Red Hat, and I'm sure the >> wider developer community, are with this change. It'll make a >> substantial difference to the way we work, and I hope it'll encourage >> a new generation of developers to work with us. >> >> ... >> >> This is another big step towards openness and co-operation since we >> began working together when OpenJDK Sun freed the Java source code ten >> years ago. Bravo! > > Thank you for your kind words, and thank you -- and everyone else in > Red Hat's Java team -- for all of your support and contributions over > the past ten years. Here's to many more to come! Cheers to that! Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From david at davidherron.com Mon Sep 11 22:27:32 2017 From: david at davidherron.com (David Herron) Date: Mon, 11 Sep 2017 15:27:32 -0700 Subject: Accelerating the JDK release cadence Message-ID: First - this is excellent news. I've been away from OpenJDK anything for quite awhile, but news about this popped up on my radar and I'm happy to see this decision. A part of the announcement concerned working with OpenJDK partners on some kind of test infrastructure. Which touches into the ideas I'd been concocting while still at Sun, and never got to implement. Water under the bridge for me, but I wish the best results for whoever gets to do it. In any case, I have a couple items of feedback > 2. Every product that has used time-based version numbers has inevitably > dropped the approach (the only exception that comes to mind is MS Word). > When this happens, the version history is permanently polluted with large > version numbers. Instead of hijacking the major.minor version numbers, > consider placing this information in the build number (e.g. > 9.1.5+2017-11-15) Please take a look at Node.js version numbering. It is semver-compliant, they're also on a 6 month release schedule, the version numbers are not based on the year, and the version numbers do not become hideous. For example 6.11.3 is the most recent LTS release -- the 6.x train having begun in April 2016. In a few weeks the 8.x release train is scheduled to become the LTS release train. The odd-number release trains are used for speculative development, the even number releases are used as stable branches. I see some are yammering for git to supplant mercurial. I don't have any opinion on which are better, just that the world at large is far more familiar with git than mercurial, there's more tools for that ecosystem (GitKraken is supremely excellent), and so forth. It's not necessary to use Github to use Git, fortunately. There are other Git servers that provide similar capabilities to Github. At home I use Gogs for a few personal repositories. I've used Gitlab in the past -- that one has the advantage of a built-in continuous integration system. Both Gogs and Gitlab can be installed on your hardware. Linus hosting it's kernel repo on github. Microsoft now hosting .net > opensource on github either, python move from mercurial to github . > PHP move from svn to github, Ruby on github, Swift move to github, > Golang move to github. > Rust lang on github, Scala on github, haskell GHC on github, Clojure > on github, kotlin on github. > So why you afraid move to github? Github, github, github, github.... Can you say "Single Point of Failure"? What's wrong with this picture is if everyone adopts Github what happens when Github flames out in a big horrible way? It'd be like the problem we collectively face with monocultures in the food supply. If there's only one kind of corn being grown, and a nasty virus starts infesting that one variety of corn, won't that wipe out our food supply and we'll all starve? But ... discussing Git is outside the scope of this. I think when Kelly O'Hair says the conversion would be a major headache, that you should pay attention. Getting to more important things ... what about JCP and JSR's? Previously the major release cycles were designed to coincide with JSR's being finished. I take it the idea that a JSR will land in whatever release it coincides with rather than rigidly holding up a release until the JSR is finished. And that the reason for more granular releases is to decrease the time between a JSR finishing and it landing in an official release. Is that about right? + David Herron From benjamin.john.evans at gmail.com Tue Sep 12 05:47:39 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 12 Sep 2017 11:17:39 +0530 Subject: Accelerating the JDK release cadence In-Reply-To: <20170911194121.D67FFAB9C6@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <20170911194121.D67FFAB9C6@eggemoggin.niobe.net> Message-ID: On Tue, Sep 12, 2017 at 1:11 AM, wrote: > > In addition to divide-and-conquer, implementation features can be merged > in an experimental mode at first (e.g., G1, AoT) and then, over time, be > made non-experimental and even become the default, if appropriate, as > they mature. On the subject of G1, doesn't the new release cycle reopen the case for delaying the cutover of G1 to default GC? The G1 collector is coming on nicely, but in the field migrations to it still fails extremely often - in my experience up to 30% of applications are unable to move to G1 due to unacceptable performance regressions. I've also heard from the Oracle engineers that the version of G1 that is present in 9 is significantly different from what's been shipped in any release of 8. With the new 6-month release cycle, isn't this an ideal opportunity to delay default cutover to provide some production feedback on this new version of G1? With 18.3 and 18.9 as possible release targets for default G1, is it still so important to have default G1 arrive as part of Java 9? Thanks, Ben From dalibor.topic at oracle.com Tue Sep 12 07:37:58 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 12 Sep 2017 09:37:58 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <1504811069478-0.post@n7.nabble.com> <5227bec7-a167-8915-a8b6-8d65006ff5e6@bbs.darktech.org> <571A988B-4CA7-4CA0-89A1-BB5D467B04F2@gmail.com> Message-ID: On 08.09.2017 19:07, Kelly O'Hair wrote: > Has nothing to do with "afraid". > > If you have gone through as many source repository changes as I have, you learn that it is never as easy as people think. > I'm not anti-GIT, I use it all the time. But the longer an organization uses a particular technology, the more embedded it becomes in the overall processes, so just converting the repos is the easiest part. Just keep in mind that there is more to it than that. Yup. http://mail.openjdk.java.net/pipermail/adoption-discuss/2015-July/000999.html goes into some of that. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Sep 12 08:03:45 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 12 Sep 2017 10:03:45 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <20170911194121.D67FFAB9C6@eggemoggin.niobe.net> Message-ID: On 12.09.2017 07:47, Ben Evans wrote: > On Tue, Sep 12, 2017 at 1:11 AM, wrote: >> >> In addition to divide-and-conquer, implementation features can be merged >> in an experimental mode at first (e.g., G1, AoT) and then, over time, be >> made non-experimental and even become the default, if appropriate, as >> they mature. > > On the subject of G1, doesn't the new release cycle reopen the case > for delaying the cutover of G1 to default GC? The process in place for JDK 9 at this time is specified at http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-June/005884.html Quoting form the above mail: "The overall feature set has been frozen for some time now. No further enhancements, no matter how small and low-risk, will be approved after the Initial Release Candidate build." cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From benjamin.john.evans at gmail.com Tue Sep 12 17:54:46 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 12 Sep 2017 23:24:46 +0530 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <20170911194121.D67FFAB9C6@eggemoggin.niobe.net> Message-ID: On Tue, Sep 12, 2017 at 1:33 PM, dalibor topic wrote: > > On 12.09.2017 07:47, Ben Evans wrote: >> >> On Tue, Sep 12, 2017 at 1:11 AM, wrote: >>> >>> In addition to divide-and-conquer, implementation features can be merged >>> in an experimental mode at first (e.g., G1, AoT) and then, over time, be >>> made non-experimental and even become the default, if appropriate, as >>> they mature. >> >> On the subject of G1, doesn't the new release cycle reopen the case >> for delaying the cutover of G1 to default GC? > > The process in place for JDK 9 at this time is specified at > http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-June/005884.html > > Quoting form the above mail: > > "The overall feature set has been frozen for some time now. No further > enhancements, no matter how small and low-risk, will be approved after > the Initial Release Candidate build." This isn't an "enhancement". This is a suggestion to reconsider making default an implementation that seems to be unfit for purpose in a non-trivial %age of real world cases. I repeat: Given the new release schedule, why is it so important that this high-profile potentially breaking change be forced through now? Isn't the whole point to allow implementation features to be merged, made non-experimental and become the default over time? Why the urgency to do it now, rather than in March or September 2018? Ben From dalibor.topic at oracle.com Wed Sep 13 14:03:13 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 13 Sep 2017 16:03:13 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <20170911194121.D67FFAB9C6@eggemoggin.niobe.net> Message-ID: <3f974306-77dc-dd26-bb5e-88a95ce53824@oracle.com> On 12.09.2017 19:54, Ben Evans wrote: > On Tue, Sep 12, 2017 at 1:33 PM, dalibor topic wrote: >> The process in place for JDK 9 at this time is specified at >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-June/005884.html >> >> Quoting form the above mail: >> >> "The overall feature set has been frozen for some time now. No further >> enhancements, no matter how small and low-risk, will be approved after >> the Initial Release Candidate build." > > This isn't an "enhancement". Making G1 the Default Garbage Collector is JDK Enhancement Proposal (short: JEP) 248. Quoting from JEP 248: "G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. If a critical issue is found that can't be addressed in the JDK 9 time frame, we will revert back to use Parallel GC as the default for the JDK 9 GA." As you can see from https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20priority%20%3D%20P1%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%20%229%22%20AND%20labels%20%3D%20gc-g1%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC there are no open, P1 issues with G1 GC affecting JDK 9. Accordingly, implementing another JDK enhancement proposal to switch JDK 9 to a different default GC would not make a lot of sense for JDK 9 itself, aside from the JDK 9 feature set being frozen anyway at this stage of its development. As the JEP's authors explain, making G1 default in JDK 9 will increase its visibility. In turn, that may be the best way to get broad feedback on any remaining, previously unknown issues, potentially allowing such issues to be discovered, raised and addressed in time for the next major JDK or LTS release. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From brian.goetz at oracle.com Wed Sep 13 14:25:01 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 13 Sep 2017 10:25:01 -0400 Subject: Accelerating the JDK release cadence In-Reply-To: References: Message-ID: <55daa7d6-fb0b-f2b3-6b6f-38953c9f7494@oracle.com> On 9/11/2017 6:27 PM, David Herron wrote: > Getting to more important things ... what about JCP and JSR's? > > Previously the major release cycles were designed to coincide with JSR's > being finished. > > I take it the idea that a JSR will land in whatever release it coincides > with rather than rigidly holding up a release until the JSR is finished. > And that the reason for more granular releases is to decrease the time > between a JSR finishing and it landing in an official release. Is that > about right? Platform JSR for 18.3 posted yesterday: ??? https://jcp.org/en/jsr/detail?id=383 Now in review, to be followed by ballot, in accordance with JCP process, as usual. Component JSRs will come in as they always have; through the appropriate platform (umbrella) JSRs. From aph at redhat.com Wed Sep 13 16:55:34 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Sep 2017 17:55:34 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <55daa7d6-fb0b-f2b3-6b6f-38953c9f7494@oracle.com> References: <55daa7d6-fb0b-f2b3-6b6f-38953c9f7494@oracle.com> Message-ID: <4e33dee8-bc78-2be8-e5b2-b919bc1e97ad@redhat.com> On 13/09/17 15:25, Brian Goetz wrote: > > Platform JSR for 18.3 posted yesterday: > https://jcp.org/en/jsr/detail?id=383 > > Now in review, to be followed by ballot, in accordance with JCP process, > as usual. > > Component JSRs will come in as they always have; through the appropriate > platform (umbrella) JSRs. But why the blinking flip is it called 18.3? I've looked in a few emails but I get so many, I may have missed the explanation. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mark.reinhold at oracle.com Wed Sep 13 16:59:41 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Sep 2017 09:59:41 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: <4e33dee8-bc78-2be8-e5b2-b919bc1e97ad@redhat.com> References: <55daa7d6-fb0b-f2b3-6b6f-38953c9f7494@oracle.com> <4e33dee8-bc78-2be8-e5b2-b919bc1e97ad@redhat.com> Message-ID: <20170913095941.124682514@eggemoggin.niobe.net> 2017/9/13 9:55:34 -0700, aph at redhat.com: > On 13/09/17 15:25, Brian Goetz wrote: >> Platform JSR for 18.3 posted yesterday: >> >> https://jcp.org/en/jsr/detail?id=383 >> >> Now in review, to be followed by ballot, in accordance with JCP process, >> as usual. >> >> Component JSRs will come in as they always have; through the appropriate >> platform (umbrella) JSRs. > > But why the blinking flip is it called 18.3? I've looked in a few emails but I > get so many, I may have missed the explanation. >From my blog entry (https://mreinhold.org/blog/forward-faster): To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form `$YEAR.$MONTH`. Thus next year's March release will be 18.3, and the September long-term support release will be 18.9. That's the proposal. I'm sure there will be further discussion, but in the meantime we had to pick some number to use on the JSR submission, so it's "18.3". - Mark From aph at redhat.com Wed Sep 13 17:21:05 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Sep 2017 18:21:05 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <20170913095941.124682514@eggemoggin.niobe.net> References: <55daa7d6-fb0b-f2b3-6b6f-38953c9f7494@oracle.com> <4e33dee8-bc78-2be8-e5b2-b919bc1e97ad@redhat.com> <20170913095941.124682514@eggemoggin.niobe.net> Message-ID: On 13/09/17 17:59, mark.reinhold at oracle.com wrote: > 2017/9/13 9:55:34 -0700, aph at redhat.com: > From my blog entry (https://mreinhold.org/blog/forward-faster): > > To make it clear that these are time-based releases, and to make it > easy to figure out the release date of any particular release, the > version strings of feature releases will be of the form `$YEAR.$MONTH`. > Thus next year's March release will be 18.3, and the September > long-term support release will be 18.9. > > That's the proposal. I'm sure there will be further discussion, but in > the meantime we had to pick some number to use on the JSR submission, so > it's "18.3". Aha! OK. This numbering scheme is somewhat familiar to me from Cygnus days in the form 99r2, i.e. Release 2 in the year 1999. I think that release numbering makes more sense than month numbering, but that's a bikeshed down the road. Having said that, my wife points out that it's good to have the month number in there because it's easier to understand: you immediately know when a release happened. So I suppose I could be persuaded. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From peter.lawrey at gmail.com Wed Sep 13 18:20:37 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Wed, 13 Sep 2017 19:20:37 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <20170913095941.124682514@eggemoggin.niobe.net> References: <55daa7d6-fb0b-f2b3-6b6f-38953c9f7494@oracle.com> <4e33dee8-bc78-2be8-e5b2-b919bc1e97ad@redhat.com> <20170913095941.124682514@eggemoggin.niobe.net> Message-ID: This reminds me of the Ubuntu version numbers which I don't mind at all. https://wiki.ubuntu.com/Releases Note: the $MONTH is always 2 digits which has a nice symmetry as "yy'.'MM". If we avoid releasing after September each year, one digit should be fine. -- Peter. ? On 13 September 2017 at 17:59, wrote: > 2017/9/13 9:55:34 -0700, aph at redhat.com: > > On 13/09/17 15:25, Brian Goetz wrote: > >> Platform JSR for 18.3 posted yesterday: > >> > >> https://jcp.org/en/jsr/detail?id=383 > >> > >> Now in review, to be followed by ballot, in accordance with JCP process, > >> as usual. > >> > >> Component JSRs will come in as they always have; through the appropriate > >> platform (umbrella) JSRs. > > > > But why the blinking flip is it called 18.3? I've looked in a few > emails but I > > get so many, I may have missed the explanation. > > From my blog entry (https://mreinhold.org/blog/forward-faster): > > To make it clear that these are time-based releases, and to make it > easy to figure out the release date of any particular release, the > version strings of feature releases will be of the form `$YEAR.$MONTH`. > Thus next year's March release will be 18.3, and the September > long-term support release will be 18.9. > > That's the proposal. I'm sure there will be further discussion, but in > the meantime we had to pick some number to use on the JSR submission, so > it's "18.3". > > - Mark > From john.r.rose at oracle.com Thu Sep 14 05:08:25 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 13 Sep 2017 22:08:25 -0700 Subject: RFC, Project Metropolis` Message-ID: I would like to invite discussion on a proposal for a new OpenJDK Project[1], to be titled ?Project Metropolis?, an incubator for experimenting with advanced JVM implementation techniques. Specifically, we wish to re-implement significant parts of Hotspot?s C++ runtime in Java itself, a move we call Java-on-Java. The key experiments will center around investigating Graal[2] as a code generator for the JVM in two modes: as an online compiler replacing one or more of Hotspot?s existing JITs, and as an offline compiler for Java code intended to replace existing C++ code in Hotspot. In the latter role, we will experiment with static compilation techniques (such as the Substrate VM[3]) to compile Java into statically restricted formats that can easily integrate with C++ as used in Hotspot. The Project will be an experimental technology incubator, similar to the Lambda, Panama, Valhalla, and Amber projects. Such incubator projects absorb changes from the current Java release, but do not directly push to Java releases. Instead, they accumulate prototype changes which are sometimes discarded and sometimes merged by hand (after appropriate review) into a Java release. (In this model, prototype changes accumulate quickly, since they are not subject to the relatively stringent rules governing JDK change-sets. These rules involving review, bug tracking, regression tests, and pre-integration builds. The Metropolis project will have similar rules, of course, but they are likely to be more relaxed.) Implementing the Java runtime in the Java-on-Java style has numerous advantages, including: * Self-optimization: We obtain more complete control of optimization techniques used for compiling the JVM itself. * Self-determination: We can decouple the JVM from changes (possibly destabilizing ones) in other implementation languages (C++NN). * Simplification: More consistent usage of the ?native? language of the Java ecosystem, reducing costs to contributors and maintainers. * Speed: More agile delivery of new JVM backends (future hardware), new JVM frontends (value type bytecodes), new bytecode shapes (stream optimizations), and application formats (static application assembly). However, the Java-on-Java tactic has significant risks which must be investigated and reduced before we can think about deploying products. These risks are: * Startup: Startup overheads for Java code must not harm overall JVM startup. * Isolation: GC or JIT activity required by Java-on-Java execution must not interfere with application execution. * Density: Java-based data structures may require enhancement (such as value types) to support dense data structures competitive with C++. * Succession: Adoption of Java-on-Java implementations must not cause regressions for customers who rely on the quality and performance of existing modules. Therefore, the key experiments for the Project will include: * Running Graal to statically compile Java code in a ?native compilation mode? to prepare JVM components that can replace C++ components. (This will extend existing work with AOT and/or the Substrate VM.) * Statically compiling Graal itself (again in a native compilation mode) to run as a JIT, evaluating it as a successor to C2. * Isolating the resulting Java-on-Java component (i.e., Graal running as a JIT) from application code, especially with respect to GC dynamics, name resolution, and side effects. The ?native compilation mode? referred to above means that the compiler will produce a kind of object code that uses C-like calling conventions and a smaller runtime, rather than the specialized calling sequences and runtime required by JIT-generated Java code. Such object code is appropriate to separate compilation as a stand-alone program or component of a larger program like HotSpot, usually at the cost of high-end features like code instrumentation and dynamic reoptimization. We will develop and track metrics for startup, footprint, peak performance, and application latency, to be used to characterize the effects (in startup, isolation, density, and quality) of implementing Java on Java. An iterative cycle of such metrics, community evaluation, and regression testing will enable us to evaluate progress toward our eventual goals of replacing, in the HotSpot reference implementation of Java, C++ code by Java code, and particularly C2 by Graal. If these experiments are successful, numerous additional experiments are possible within the overall goal of implementing Java-on-Java: * Using Graal as a replacement for the client JIT (C1). * Using Graal to code-generate a bytecode interpreter. * Using Graal to spin adapters, such as native-to-Java bindings. * Using Graal to dynamically customize other JVM hot paths. * Prototyping new JVM features, such as value types, in Graal. * Coding native methods in statically-compiled Java. * Coding metadata access and processing in Java. * Coding smaller JVM modules in statically-compiled Java, such as class file parsing or verification. * Coding GC logic in statically-compiled Java. However, the Project will be a success even if it only lays the foundation for such additional use cases, to be investigated by future projects. It seems likely, today, that the key goal is creating a flexible code generation technology, in Java, for use by the JVM. Achieving this first goal is an important step toward many future upgrades to the Java technology stack. The Project will be sponsored by the HotSpot Group. Project members will include HotSpot team members (including the JIT, GC, runtime, and performance teams), Graal project members from Oracle Labs, and non-Oracle developers from organizations interested in the Java-on-Java problem. Relations to other projects: * The project will start with a full copy of the JDK source base. * The project will preserve relevance by tracking these sources. * The project will contain the Graal repository, or a copy thereof. * The project will not feed change sets directly into any JDK release. * The project will routinely push changes to the Graal repository. Changes to the Graal repository are likely to include: * Support for static compilation (including AOT changes). * Integration APIs with the JVM (beyond the current JVMCI). * Optimizations specific to code running Java-on-Java patterns. * General-purpose optimizations (to replace C2). * New platform optimizations (such as AVX). * Proposed new instructions (such as value types). Such changes will coordinated with the Graal development team, adhering to practices set up by the Graal Project, in such as way that changes from either project will not lead to regressions. This means that each project will perform some amount of integration testing for both projects. Since the Graal project is an active project in its own right, coordination between the projects, and overlap between the teams, is a necessary condition for the success of the Java-on-Java experiments. For documentation beyond Java APIs, and for design works in progress, the Project should be supplied with a wiki writable to all Project committers. Alternatively, the Graal or HotSpot wiki could be used. Finally, I would like to propose Vladimir Kozlov (the HotSpot JIT lead and a key AOT engineer) as the Lead for the Project. [1]: http://openjdk.java.net/projects/#new-project-vote [2]: http://openjdk.java.net/projects/graal/ [3]: https://www.youtube.com/watch?v=3JphI1Z0MTk&feature=youtu.be&t=2m38s From ebourg at apache.org Thu Sep 14 09:13:58 2017 From: ebourg at apache.org (Emmanuel Bourg) Date: Thu, 14 Sep 2017 11:13:58 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <89d80760-f03f-c2f3-f2cc-5dfa83a48277@apache.org> Hi, Le 6/09/2017 ? 16:49, mark.reinhold at oracle.com a ?crit?: > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. Will the new version scheme also affect the language level? How will that play with JEP 182? Will we see an accelerated deprecation/removal of old source/target levels in javac? > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. Do you plan to open-source Java Web Start too? Emmanuel Bourg From mark.reinhold at oracle.com Thu Sep 14 15:22:57 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 14 Sep 2017 08:22:57 -0700 Subject: Accelerating the JDK release cadence In-Reply-To: <89d80760-f03f-c2f3-f2cc-5dfa83a48277@apache.org> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <89d80760-f03f-c2f3-f2cc-5dfa83a48277@apache.org> Message-ID: <20170914082257.376583091@eggemoggin.niobe.net> 2017/9/14 2:13:58 -0700, Emmanuel Bourg : > Le 6/09/2017 ? 16:49, mark.reinhold at oracle.com a ?crit: > ... > > Will the new version scheme also affect the language level? How will > that play with JEP 182? Will we see an accelerated deprecation/removal > of old source/target levels in javac? I expect the language level to use the same versioning scheme as the platform itself, as it always has. The deprecation/removal policy, not just for the language level but also for APIs and other types of interfaces, will need to be reformulated given that feature releases will be much more frequent. >> - After JDK 9 we'll open-source the commercial features in order to >> make the OpenJDK builds more attractive to developers and to reduce >> the differences between those builds and the Oracle JDK. This will >> take some time, but the ultimate goal is to make OpenJDK and Oracle >> JDK builds completely interchangeable. > > Do you plan to open-source Java Web Start too? Not at this time. - Mark From dominik.helm at stud.tu-darmstadt.de Thu Sep 14 16:55:10 2017 From: dominik.helm at stud.tu-darmstadt.de (Dominik Helm) Date: Thu, 14 Sep 2017 18:55:10 +0200 Subject: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Message-ID: I did not find a better place to report this, so I'm going to post it here: There is an obvious ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar.actualMonthLength(): The third and fourth lines read if (eraIndex == -1) { long transitionFixedDate = sinceFixedDates[eraIndex]; thereby always trying to access an out ouf bounds element on sinceFixedDates. Best regards, Dominik From sean.coffey at oracle.com Thu Sep 14 17:45:11 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 14 Sep 2017 18:45:11 +0100 Subject: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar In-Reply-To: References: Message-ID: <36565075-fd59-84cf-7cc7-c31479784e84@oracle.com> You can report JDK bugs at : http://bugreport.java.com/ regards, Sean. On 14/09/2017 17:55, Dominik Helm wrote: > I did not find a better place to report this, so I'm going to post it here: > > There is an obvious ArrayIndexOutOfBoundsException in > java.util.JapaneseImperialCalendar.actualMonthLength(): > The third and fourth lines read > > if (eraIndex == -1) { > long transitionFixedDate = sinceFixedDates[eraIndex]; > > thereby always trying to access an out ouf bounds element on > sinceFixedDates. > > Best regards, > Dominik From adinn at redhat.com Mon Sep 18 14:05:34 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 18 Sep 2017 15:05:34 +0100 Subject: RFC, Project Metropolis` In-Reply-To: References: Message-ID: Hi John, On 14/09/17 06:08, John Rose wrote: > > > I would like to invite discussion on a proposal for a new OpenJDK > Project[1], to be titled ?Project Metropolis?, an incubator for > experimenting with advanced JVM implementation > techniques. Specifically, we wish to re-implement significant parts of > Hotspot?s C++ runtime in Java itself, a move we call Java-on-Java. Please don't take the the following as representing an answer from Red Hat. With that qualification out of the way, I can say that am personally very interested in contributing to a Java-on-Java OpenJDK runtime -- having experienced many of the benefits of such a model working on the JikesRVM and Xerox Interlisp-D runtimes. This idea has many benefits, as you mentioned. I think it is particularly valuable that a Java-on-Java implementation replaces the hard, black box that currently separates VM tech from JDK tech with a much more fluid, transparent boundary layer. The more that those who use the JVM can understand about what it does for them and at what cost the better. So, this gets a very excited thumbs up from me! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From stuart.monteith at linaro.org Mon Sep 18 15:10:35 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 18 Sep 2017 16:10:35 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: This is a welcome development. One of my wishes, working on Aarch64, would be for all architectures to be at parity on release. With open build-and-test infrastructure, and the more frequent releases, this looks far more achievable. In the worst case, a well maintained architecture would be 6 months behind. In that scenario I wonder whether different architectures would have different ideas of long-term-support releases. Will there ever be a JDK 9u? The update releases are normally created soon after a major release. Best regards, Stuart On 6 September 2017 at 15:49, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) > > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > [3] http://openjdk.java.net/projects/jdk9/rdp-2 > [4] http://openjdk.java.net/projects/jdk9/rc > [5] http://openjdk.java.net/jeps/0 > [6] http://openjdk.java.net/legal/gplv2+ce.html > [7] http://www.oracle.com/technetwork/java/javase/terms/ > products/index.html > [8] http://www.oracle.com/technetwork/java/javaseproducts/mission- > control/index.html > [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html > From john.r.rose at oracle.com Mon Sep 18 19:40:54 2017 From: john.r.rose at oracle.com (John Rose) Date: Mon, 18 Sep 2017 12:40:54 -0700 Subject: Call for Discussion: New Project: Metropolis In-Reply-To: References: Message-ID: <422B0773-111C-495E-AA27-1728C99D9039@oracle.com> On Sep 13, 2017, at 10:08 PM, John Rose wrote: > > Here's a small bit of administration, for the record. Mark has reminded me that OpenJDK has no "RFC" actions. The official subject line for this discussion thread should be "Call for Discussion: New Project: Metropolis", as documented here. http://openjdk.java.net/projects/#new-project-discuss At the risk of splitting the thread, I am correcting the subject line in this message, so that the archives will be in better shape. My thanks to the responders so far, including Andrew Dinn: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004341.html The next step is a call for votes; please stay tuned for that. ? John From dalibor.topic at oracle.com Mon Sep 18 19:54:04 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 18 Sep 2017 21:54:04 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <65bc20a2-2734-e54a-2516-851b3dc66e25@oracle.com> On 18.09.2017 17:10, Stuart Monteith wrote: > Will there ever be a JDK 9u? The update releases are normally created soon > after a major release. I would expect the updates to JDK 9 to be developed under the umbrella of the new JDK Updates Project suggested by Mark. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From cthalinger at twitter.com Thu Sep 21 23:26:52 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 21 Sep 2017 16:26:52 -0700 Subject: Call for Discussion: New Project: Metropolis In-Reply-To: <422B0773-111C-495E-AA27-1728C99D9039@oracle.com> References: <422B0773-111C-495E-AA27-1728C99D9039@oracle.com> Message-ID: > On Sep 18, 2017, at 12:40 PM, John Rose wrote: > > On Sep 13, 2017, at 10:08 PM, John Rose wrote: >> >> > > > Here's a small bit of administration, for the record. > > Mark has reminded me that OpenJDK has no "RFC" actions. > > The official subject line for this discussion thread should be > "Call for Discussion: New Project: Metropolis", as documented here. > http://openjdk.java.net/projects/#new-project-discuss > > At the risk of splitting the thread, I am correcting the subject > line in this message, so that the archives will be in better shape. Replying here then? You and I are talking about this for quite a while now and I welcome this becoming an official OpenJDK project now. How do you envision people working on this project? Should individual people just become contributors and then work on whichever module they want to replace? > > My thanks to the responders so far, including Andrew Dinn: > http://mail.openjdk.java.net/pipermail/discuss/2017-September/004341.html > > The next step is a call for votes; please stay tuned for that. > > ? John From john.r.rose at oracle.com Fri Sep 22 01:31:50 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 21 Sep 2017 18:31:50 -0700 Subject: Call for Discussion: New Project: Metropolis In-Reply-To: References: <422B0773-111C-495E-AA27-1728C99D9039@oracle.com> Message-ID: On Sep 21, 2017, at 4:26 PM, Christian Thalinger wrote: > > Replying here then? > > You and I are talking about this for quite a while now and I > welcome this becoming an official OpenJDK project now. Yes, we have. We have been watching Java-based JITs slowly mature since Jikes, Maxine, JavaC1, C1X, and now Graal. The stars have aligned, I think, for a major shift. (In more detail: I have enjoyed watching the experimentation in JVM implementation techniques by Hanspeter Mo?ssenbo?ck's students at JKU, with collaboration by Sun/Oracle Labs engineers. There is a wealth of literature just from that department, and Graal was grown there. A good place to connect into this history is Titzer et al in VEE'10. People get inspired in crazy ways; I just noticed a paper on doing JVMs in Haskell and FORTH: http://wien.tomnetworks.com/uni/thesis_matevm_oneside.pdf ) (Ever further back: Some of my happiest programming memories come from hacking around in the Symbolics Lisp Machine OS, which was extravagantly metacircular. Anything not written in Lisp was written in microcode and/or assembly code, in Lisp syntax, on a Lisp toolchain. There was a flexible, hackable system. Such flexibility never goes out of style, I think, although there are always balancing concerns like reliability and usability.) > How do you envision people working on this project? Should individual > people just become contributors and then work on whichever module the > want to replace? This is not mainly up to me, but rather the guys you know: Vladimir, Igor, Thomas, Doug, Tom. Whatever the group decides as a consensus is where it will go. Can we hope that you will be in the group??? That said, here are a few of my thoughts: I notice that we are growing some tools and experience with branches as a way to maintain multiple parallel experiments. See Project Amber. Maurizio's scripts keep the branches properly stacked into dependency order and refreshed from their dependencies, and all of them from the default branch. If someone wanted to replace a relatively small, isolated component like MethodLiveness, that would fit easily in a branch. Trying to code up a simpler verifier in Java would be a worthy goal. By simpler I don't mean a different algorithm, but rather a higher-level expression of the same algorithm, more amenable to review and validation, both human and robotic. Anything is fair game: The reflection runtime, the LinkResolver and SystemDictionary, eventually the metadata itself (when we have more control over object layout). An especially tantalizing area would be to find "hot spots" in the C++ code where JVM-specific optimizations would improve the system performance more than a C++ optimizer could do. If we have a clever code shape we need generated for the JVM, we can train Graal to do it for us, if we can figure out how to replace the affected range of C++ code with Java code. GC inner loops are probably amenable to GC-specific optimization techniques. The main driving function, I expect, will be making Graal compile itself into a static-linked "C++ mode" (using SVM I hope), into a linkable Graal JIT to supplant C2. But that's just a driving function, not the endpoint, of Java-on-Java. An ambitious person could try to replace C1 or the interpreter with Graal. Did I mention this is likely to be a very long-running project? :-) ? John From andreas.lundblad at gmail.com Fri Sep 22 12:09:59 2017 From: andreas.lundblad at gmail.com (Andreas Lundblad) Date: Fri, 22 Sep 2017 14:09:59 +0200 Subject: State of the Java Style Guidelines document Message-ID: Current status: The page has been rewritten as a patch for the web repo. Formatting is in line with the other pages on o.j.n. It's v6 with a few rewordings, among others those suggested by Lars Francke. (Grammar and typos IIRC.) This was done before I left Oracle but it never got the final sign-off due to some last minute opinions on the content. Since then I've reached out on four occasions trying to get the ball rolling without success. I imagine people have been busy with more important stuff (like finalizing Java 9) and I'm now hoping this will get some attention. Personally I have no problem spending time on this. @Mike, sorry for not getting back to you on all items. I think many of your remarks have been addressed. I'll respond to two of them below. If there's anything else you feel have been left behind, please let me know. *** UTF-8 vs ASCII *** I initially had UTF-8, but changed to ASCII. Currently the effort focuses on documenting existing practices, rather than updating to new practices, and ASCII is the current standard (at least it was when at the time of writing). >From Jon Gibbons: > [...] > But ASCII is still the rule for JDK code, partly for historical reasons and > partly (I suspect) because there is not enough motivation to investigate > whether the entire JDK code ecosystem can cope with anything more than > ASCII. > [...] >From Joe Darcy: > [...] > I double checked the relevant makefile (make/common/SetupJavaCompilers.gmk) > and the JDK build does indeed specify to javac > > -encoding ascii > [...] I hope this explains the current formulation. *** Opening brace on a separate line *** One could argue both ways regarding readability. I don't think one alternative is, objectively speaking, more readable than the other. I know java.nio uses this for instance, and v1 (index-v1.html) mentioned this as an alternative, but there were complains about this and it was dropped in v2. To make an objective assessment I analyzed the existing code and found that the style recommended in the current draft is used in 74% of all cases where class declarations or methods are wrapped. (Pasting the source code I used for the analysis at the bottom of this mail.) That's across all OpenJDK projects however. Formatting is presumably much more consistent within each separate project. This has in fact been a bit of a blocker. At this point I think that Lars' suggestion is the best (only?) way forward. One general document covering the guidelines that all projects agree on, and for projects that find it necessary, additional pages in the project spaces, refining what's needed. I'd suggest that the general document tries to stick to the intersection of what all projects find acceptable since it it might be confusing if project specific style guides need to opt out from stuff. Also, if a case is not covered, it's often clear from surrounding code what the preferred formatting is. The general document can include notes like "For further details, see project specific documentation" where needed. OpenJDK is huge with a lot of legacy code. I think this a natural approach. -- Andreas ------------------- Code to analyze placement of braces in wrapped method headers: import java.io.IOException; import java.nio.file.*; import java.nio.file.attribute.BasicFileAttributes; import java.util.regex.Matcher; import java.util.regex.Pattern; import static java.nio.charset.StandardCharsets.UTF_8; import static java.nio.file.FileVisitResult.CONTINUE; import static java.util.regex.Pattern.DOTALL; import static java.util.regex.Pattern.MULTILINE; public class Scratch { static String id = "\\p{Alpha}\\p{Alnum}*"; static String clsHdr = "^(public )?class (.*?)\\{"; static String mthHdr = "^ *" // beginning of line + indentation + "(public|private|protected|static|final| )*" // method modifiers + id + "\\s+" + id // return type - method identifier + "\\([^\\)]*\\)" // arguments + "[^;{]*" // throws declarations + "\\{$"; // opening brace static Pattern CLASS_HDR = Pattern.compile(clsHdr, MULTILINE | DOTALL); static Pattern METHOD_HDR = Pattern.compile(mthHdr, MULTILINE | DOTALL); static int fileCount = 0; static int knrCounter = 0; // Counter for '{' at the end of the same line static int mrCounter = 0; // Counter for '{' on a line by itself public static void main(String[] args) throws IOException { analyze(Paths.get("/home/aioobe/work/oracle/repo/dev-tip")); System.err.println("knrCounter: " + knrCounter); System.err.println("mrCounter: " + mrCounter); System.err.printf("k&r: %.2f%%", 100.0 * knrCounter / (knrCounter + mrCounter)); } static void analyze(Path root) throws IOException { Files.walkFileTree(root, new SimpleFileVisitor() { @Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException { if (file.toString().contains("test/java/util/Formatter/")) { return CONTINUE; } if (file.toString().endsWith(".java")) { fileCount++; if (fileCount % 1000 == 0) { System.err.printf("%.2f%%%n", 100.0 * fileCount / 38016); } String sourceCode = new String(Files.readAllBytes(file), UTF_8); checkHeaders(sourceCode); } return CONTINUE; } }); } // Traverse all method and class headers in given source code. static void checkHeaders(String sourceCode) { Matcher m = METHOD_HDR.matcher(sourceCode); while (m.find()) { analyzeHeader(m.group()); } m = CLASS_HDR.matcher(sourceCode); while (m.find()) { analyzeHeader(m.group()); } } // Check content between "class" and "{" or "methodName()" and "{" // and increment mrCounter or knrCounter as appropriate. static void analyzeHeader(String header) { String[] lines = header.split("\n"); if (lines.length == 1) { // No wrapping return; } if (lines.length == 2 && lines[1].trim().equals("{")) { // Allman style: // void method() // { // ... // } return; } if (lines[lines.length - 1].trim().equals("{")) { // Last line is a single "{" mrCounter++; } else { // Last line is more than just "{" knrCounter++; } } } From volker.simonis at gmail.com Fri Sep 22 14:34:46 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Sep 2017 16:34:46 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <20170906144928.13997AA82D@eggemoggin.niobe.net> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: Hi Mark, can you please detail what the statements from your blog regarding the LTS releases means for the OpenJDK: "Every three years, start?ing in Sep?tem?ber of 2018, the fea?ture re?lease will be a long-term sup?port re?lease. Up?dates for these re?leases will be avail?able for at least three years and quite pos?si?bly longer, de?pend?ing upon your ven?dor." Does this mean that Oracle will provide updates for the LTS versions in the OpenJDK for at least three years? According to the "Oracle Java SE Support Roadmap" [1] Oracle plans to offer much longer support time frames for LTS releases. How is this going to work. Will Oracle step back as lead of the corresponding LTS update projects after three years (much as this was done for jdk7u for example) and leave the project up to the community while doing its own LTS support from private repos? Thank you and best regards, Volker [1] http://www.oracle.com/technetwork/java/eol-135779.html On Wed, Sep 6, 2017 at 4:49 PM, wrote: > Over on my blog today I've argued that Java needs to move forward faster. > To achieve that I've proposed that the Java SE Platform and the JDK shift > from the historical feature-driven release model to a strict, time-based > model with a new feature release every six months, update releases every > quarter, and a long-term support release every three years: > > https://mreinhold.org/blog/forward-faster > > Here are some initial thoughts on how we might implement this proposal > here in the OpenJDK Community. Comments and questions about both the > proposal and its implementation are welcome on this list. > > Rather than create a brand new "JDK $N" Release Project every six months, > I suggest that we create a single long-running "JDK" Release Project to > host the main-line code base and produce the feature releases. Similarly, > let's create a single long-running "JDK Updates" Project to produce the > update releases, for the most recent feature release and the current > long-term support release. > > Two long-running Projects will save some administrative overhead, and also > eliminate the confusion that regularly arises when someone is a Committer > to JDK $N but not JDK $N + 1. (We could consider just one long-running > Project, but two makes more sense since since the two types of releases > will have different policies, content, schedules, and leadership.) > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The > main line will be Feature Complete [1] at all times. > > - We'll fork the main line into a release-stabilization branch three > months before the GA date of the next feature release. That branch > will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2 > [3] a month later, and then enter the Release Candidate phase [4] a > month after that. (Whether the branch is another repository or an > actual Mercurial branch is a detail we can figure out later.) > > - We'll continue to use the JEP Process [5] for new features and other > significant changes. The bar to target a JEP to a specific release > will, however, be higher since the work must be Feature Complete in > order to go in. Owners of large or risky features will be strongly > encouraged to split such features up into smaller and safer parts, to > integrate earlier in the release cycle, and to publish separate lines > of early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK $N" > Updates Projects, though update releases will be strictly limited to fixes > of security issues, regressions, and bugs in newer features. > > Related to this proposal, we at Oracle intend to make a few changes in > what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [7] such as Java Flight Recorder and Mission > Control [8], under a click-through binary-code license [9]. Oracle > will continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to > make the OpenJDK builds more attractive to developers and to reduce > the differences between those builds and the Oracle JDK. This will > take some time, but the ultimate goal is to make OpenJDK and Oracle > JDK builds completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make > it easier to publish early-access builds for features in development, > and eventually make it possible for the OpenJDK Community itself to > publish authoritative builds of the JDK. > > So ... that's a lot of proposed change, and there are (obviously!) many > details to work out. Comments? Questions? > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > [3] http://openjdk.java.net/projects/jdk9/rdp-2 > [4] http://openjdk.java.net/projects/jdk9/rc > [5] http://openjdk.java.net/jeps/0 > [6] http://openjdk.java.net/legal/gplv2+ce.html > [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html > [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html From aph at redhat.com Fri Sep 22 15:49:49 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Sep 2017 16:49:49 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> Message-ID: <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> On 22/09/17 15:34, Volker Simonis wrote: > Hi Mark, > > can you please detail what the statements from your blog regarding the > LTS releases means for the OpenJDK: > > "Every three years, start?ing in Sep?tem?ber of 2018, the fea?ture > re?lease will be a long-term sup?port re?lease. Up?dates for these > re?leases will be avail?able for at least three years and quite > pos?si?bly longer, de?pend?ing upon your ven?dor." > > Does this mean that Oracle will provide updates for the LTS versions > in the OpenJDK for at least three years? According to the "Oracle Java > SE Support Roadmap" [1] Oracle plans to offer much longer support time > frames for LTS releases. How is this going to work. Will Oracle step > back as lead of the corresponding LTS update projects after three > years (much as this was done for jdk7u for example) and leave the > project up to the community while doing its own LTS support from > private repos? That is pretty how it works now. While it'll be a PITA to handle divergent repos, we do know how to do it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Fri Sep 22 16:02:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Sep 2017 18:02:18 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> Message-ID: On Fri, Sep 22, 2017 at 5:49 PM, Andrew Haley wrote: > On 22/09/17 15:34, Volker Simonis wrote: >> Hi Mark, >> >> can you please detail what the statements from your blog regarding the >> LTS releases means for the OpenJDK: >> >> "Every three years, start?ing in Sep?tem?ber of 2018, the fea?ture >> re?lease will be a long-term sup?port re?lease. Up?dates for these >> re?leases will be avail?able for at least three years and quite >> pos?si?bly longer, de?pend?ing upon your ven?dor." >> >> Does this mean that Oracle will provide updates for the LTS versions >> in the OpenJDK for at least three years? According to the "Oracle Java >> SE Support Roadmap" [1] Oracle plans to offer much longer support time >> frames for LTS releases. How is this going to work. Will Oracle step >> back as lead of the corresponding LTS update projects after three >> years (much as this was done for jdk7u for example) and leave the >> project up to the community while doing its own LTS support from >> private repos? > > That is pretty how it works now. Yes, but I think jdk7 was supported nearly 5 years by Oracle while 18.9 maybe only three years? > While it'll be a PITA to handle > divergent repos, we do know how to do it. Especially because there will be new releases every six month so it will potentially become harder to identify and downport security and bug fixes from an increasing number of new release branches. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Fri Sep 22 16:21:49 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Sep 2017 18:21:49 +0200 Subject: JDK 9: General Availability In-Reply-To: <20170921192133.60047C9D19@eggemoggin.niobe.net> References: <20170921192133.60047C9D19@eggemoggin.niobe.net> Message-ID: On Thu, Sep 21, 2017 at 9:21 PM, wrote: > I'm pleased -- nay, thrilled! -- to announce that JDK 9 is now Generally > Available. We've identified no P1 bugs since we promoted build 181 seven > weeks ago so that is the official GA release, ready for production use. > > GPL'd binaries from Oracle are available here: > > http://jdk.java.net/9 > > (There are links on that page to Oracle's commercial binaries for those > who are interested.) I'm sure that binaries from other implementors will > be available in short order. > Hi Mark, on the one side I'm really happy to see that Java 9 has finally been released (with some of our contributions inside :) On the other hand however, I'm a little sad because I know for sure that the released version doesn't pass all of the current TCK 9 tests (but unfortunately I'm not allowed to say you which ones - at least not publicly :) So either Oracle cheated (which I don't believe), or they run the tests with a different "Exclude List", which isn't fair either. But I don't write this mail to blame anybody. Instead, the real intent is to urge you and Oracle to finally open source the TCK and make it available along side the OpenJDK reference implementation. Only if the TCK will be developed openly and in parallel with the reference implementation, we will have a transparent way of discussing and improving the conformance tests and only then it will be possible to transparently certify one's own implementation as well as verifying the implementation of others being standards conforming. Finally, having an open TCK is even more important with the new, six-monthly release cycle and the release of the new Eclipse OpenJ9 version of Java [1] which gives the users an even bigger choice between various Java SE implementations. I think an open Java SE TCK will be crucial here to ensure the stability of the Java platform and prevent fragmentation. Thank you and best regards, Volker [1] http://www.eclipse.org/openj9/ > The key feature of this release is, of course, Project Jigsaw, about > which I've written a bit more over on my blog: > > https://mreinhold.org/blog/jigsaw-complete > > Jigsaw is not, however, the only feature! There are many other excellent > additions and improvements including, but not limited to: > > Improved Process API http://openjdk.java.net/jeps/102 > HTTP/2 Client (incubating) http://openjdk.java.net/jeps/110 > Variable Handles http://openjdk.java.net/jeps/193 > JShell Read-Eval-Print Loop http://openjdk.java.net/jeps/222 > Javadoc Search http://openjdk.java.net/jeps/225 > Linux/AArch64 Port http://openjdk.java.net/jeps/237 > Marlin Graphics Renderer http://openjdk.java.net/jeps/265 > Collection Factories http://openjdk.java.net/jeps/269 > Enhanced Deprecation http://openjdk.java.net/jeps/277 > Linux/s390x Port http://openjdk.java.net/jeps/294 > Ahead-of-Time Compilation http://openjdk.java.net/jeps/295 > > The complete list of features is on the JDK 9 Project page: > > http://openjdk.java.net/projects/jdk9/ > > Thank you to everyone who contributed to JDK 9, whether directly or > indirectly. It's been a long road, but it will have been worth it. > This release lays a strong foundation for the future of Java. > > - Mark From scolebourne at joda.org Fri Sep 22 18:04:05 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 22 Sep 2017 19:04:05 +0100 Subject: An impassioned plea on version numbers Message-ID: While I am super happy to see Java 9 released I remain strongly opposed to the proposed version number scheme from now on. Here is why: 1) The vast majority of existing code that needs to know the version of Java only cares about the major digit. For example online CI like Travis/Shippable, build tools like Maven, community projects that target different behaviour to different releases, all only consider the version to be a single number. This is far more disruptive than changing 1.9 to 9 because these pieces of code would need to handle two important numbers (18 and 3), not one.. Forcing all this code to change is simply not a good choice. 2) No version is more important than any other going forward in terms of features. A new language change (the most disruptive) could occur in March or September. It will require a developer to specify two numbers (18.3) to say what release LVTI is in for example. Given the strong link to semantic version numbering in developers minds, the numbering scheme simply does not make sense. A major new language change in a minor point release??!! Being able to say quickly and easily what version a new language feature is in is vital, and 18.3 / 18.9 obscures that horribly. 3) While the LTS release is important to Oracle and big business, it will be pretty unimportant to the community. It should not be the basis of the version. 4) The proposed scheme appears to be a lot about forcing through the change within Oracle processes, based on the idea that if it is named after a month then no one can ask it to slip. However true that fear might be, it does not justify developers having to face a sub-standard version scheme. 5) Java is not an OS like Ubuntu. The version of Java is referred to all the time - it is front and centre in discussions about Java. Even recruiters talk about it! It needs to be simple and straightforward for all the tasks it is used for - a year/month scheme is unusual and unexpected. I propose that versions should simply increase incrementally. March 2018 - v10 September 2018 - v11 March 2019 - v12 September 2019 - v13 and so on. Stephen From dalibor.topic at oracle.com Fri Sep 22 20:30:40 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 22 Sep 2017 22:30:40 +0200 Subject: JDK 9: General Availability In-Reply-To: References: <20170921192133.60047C9D19@eggemoggin.niobe.net> Message-ID: <6558a203-9fa0-a7bb-4e6e-024f26c3e072@oracle.com> On 22.09.2017 18:21, Volker Simonis wrote: > improving the conformance tests and only then it will be possible to > transparently certify one's own implementation as well as verifying > the implementation of others being standards conforming. 'Verifying' wouldn't work, if you think a bit further about how that would play out in practice. Failure to reproduce results of others could have any number of benign reasons without cause for alarm. For a related, timely discussion in the field of science, please see https://news.northeastern.edu/2015/09/failure-to-reproduce-results-is-a-normal-part-of-how-science-works/ . cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From volker.simonis at gmail.com Sat Sep 23 23:25:11 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 23 Sep 2017 23:25:11 +0000 Subject: JDK 9: General Availability In-Reply-To: <6558a203-9fa0-a7bb-4e6e-024f26c3e072@oracle.com> References: <20170921192133.60047C9D19@eggemoggin.niobe.net> <6558a203-9fa0-a7bb-4e6e-024f26c3e072@oracle.com> Message-ID: dalibor topic schrieb am Fr. 22. Sep. 2017 um 22:30: > > > On 22.09.2017 18:21, Volker Simonis wrote: > > > improving the conformance tests and only then it will be possible to > > transparently certify one's own implementation as well as verifying > > the implementation of others being standards conforming. > > 'Verifying' wouldn't work, if you think a bit further about how that > would play out in practice. Failure to reproduce results of others could > have any number of benign reasons without cause for alarm. > For a related, timely discussion in the field of science, please see > > https://news.northeastern.edu/2015/09/failure-to-reproduce-results-is-a-normal-part-of-how-science-works/ > . > I hope you don't want to propose that nobody should publish any scientific findings in the future just because their reproduction by others may fail. That sounds a little "Trumpish" to make obscurity great again :) For our concrete problem (i.e. a JCK certification run) publishing the complete certification data (especially all the .jtr files) would give a pretty good overview of what people really did. And if this data still leaves open questions which are debatable - that would actually be great! That would be fruitful for everybody: the Java community, the Java implementations, the Java specification and last but not least, for the TCK itself! I know that big companies love "security by obscurity" (I'm working for one myself ;) But that's not my personal opinion. Instead, I think an open TCK would help the Java ecosystem just as much as the OpenJDK did. Open sourcing the TCK for Java EE is a good step into the right direction. However if Oracle wants to be taken seriously with this step, open sourcing the Jave SE TCK must be the direct consequence. Otherwise there's a danger that the whole Java EE open sourcing story may look a little like riding a dead horse :) Regards, Volker > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 H > > amburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riess > tr. 25, > D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From david at davidherron.com Sat Sep 23 23:51:08 2017 From: david at davidherron.com (David Herron) Date: Sat, 23 Sep 2017 16:51:08 -0700 Subject: Open source TCK was: JDK 9: General Availability Message-ID: On Sat, Sep 23, 2017 at 4:25 PM, Volker Simonis wrote: > dalibor topic schrieb am Fr. 22. Sep. 2017 um > 22:30: > > > On 22.09.2017 18:21, Volker Simonis wrote: > > > > > improving the conformance tests and only then it will be possible to > > > transparently certify one's own implementation as well as verifying > > > the implementation of others being standards conforming. > > > > 'Verifying' wouldn't work, if you think a bit further about how that > > would play out in practice. Failure to reproduce results of others could > > have any number of benign reasons without cause for alarm. > > > > For a related, timely discussion in the field of science, please see > > > > https://news.northeastern.edu/2015/09/failure-to-reproduce- > results-is-a-normal-part-of-how-science-works/ > > . > > > > I hope you don't want to propose that nobody should publish any scientific > findings in the future just because their reproduction by others may fail. > That sounds a little "Trumpish" to make obscurity great again :) > > For our concrete problem (i.e. a JCK certification run) publishing the > complete certification data (especially all the .jtr files) would give a > pretty good overview of what people really did. And if this data still > leaves open questions which are debatable - that would actually be great! > That would be fruitful for everybody: the Java community, the Java > implementations, the Java specification and last but not least, for the TCK > itself! > > I know that big companies love "security by obscurity" (I'm working for one > myself ;) But that's not my personal opinion. Instead, I think an open TCK > would help the Java ecosystem just as much as the OpenJDK did. > > Open sourcing the TCK for Java EE is a good step into the right direction. > However if Oracle wants to be taken seriously with this step, open sourcing > the Jave SE TCK must be the direct consequence. Otherwise there's a danger > that the whole Java EE open sourcing story may look a little like riding a > dead horse :) > > Regards, > Volker > > You make a compelling case and I largely agree with the goal of "open sourcing" the TCK's. Doing so would go a long way towards truly opening the OpenJDK project. There is a practical question regarding the primary use for the TCK's - which is to certify compliance with the specifications. An open source software project is free to be downloaded, modified, and the modified version distributed at will. Hence, if someone tested with a modified TCK how can there be certainty about the result? Can the results of testing with a modified TCK be trusted for certification of compliance? For the purpose of sharing of test results, open sourcing the TCK's would be great. The TCK's have a different purpose than just verifying functionality. David Herron From aph at redhat.com Sun Sep 24 06:46:43 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 24 Sep 2017 07:46:43 +0100 Subject: Open source TCK was: JDK 9: General Availability In-Reply-To: References: Message-ID: <6133525e-b684-2587-2a9b-8a235e1cc364@redhat.com> On 24/09/17 00:51, David Herron wrote: > You make a compelling case and I largely agree with the goal of "open > sourcing" the TCK's. Doing so would go a long way towards truly opening > the OpenJDK project. > > There is a practical question regarding the primary use for the > TCK's - which is to certify compliance with the specifications. > > An open source software project is free to be downloaded, modified, > and the modified version distributed at will. Not necessarily: there are variants of free licences which don't permit some sections to be changed. But it doesn't really matter what licence is used for the TCK itself: the Java Compatible badge would be reserved for implementations which had passed TCK Version n.n, as posted at java.net. That would be the canonical one true TCK. Sure, people would be able to hack their own copies of the TCK, but what would be the point? The purpose of passing the TCK is to ensure compatibility with other implementations. There isn't any motive to claim compliance with a private version of the TCK. > For the purpose of sharing of test results, open sourcing the TCK's would > be great. The TCK's have a different purpose than just verifying > functionality. > > Hence, if someone tested with a modified TCK how can there be certainty > about the result? Can the results of testing with a modified TCK be > trusted for certification of compliance? No, and no. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sun Sep 24 07:05:21 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 24 Sep 2017 08:05:21 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> Message-ID: <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> On 22/09/17 17:02, Volker Simonis wrote: > On Fri, Sep 22, 2017 at 5:49 PM, Andrew Haley wrote: >> On 22/09/17 15:34, Volker Simonis wrote: >>> Hi Mark, >>> >>> can you please detail what the statements from your blog regarding the >>> LTS releases means for the OpenJDK: >>> >>> "Every three years, start?ing in Sep?tem?ber of 2018, the fea?ture >>> re?lease will be a long-term sup?port re?lease. Up?dates for these >>> re?leases will be avail?able for at least three years and quite >>> pos?si?bly longer, de?pend?ing upon your ven?dor." >>> >>> Does this mean that Oracle will provide updates for the LTS versions >>> in the OpenJDK for at least three years? According to the "Oracle Java >>> SE Support Roadmap" [1] Oracle plans to offer much longer support time >>> frames for LTS releases. How is this going to work. Will Oracle step >>> back as lead of the corresponding LTS update projects after three >>> years (much as this was done for jdk7u for example) and leave the >>> project up to the community while doing its own LTS support from >>> private repos? >> >> That is pretty how it works now. > > Yes, but I think jdk7 was supported nearly 5 years by Oracle while > 18.9 maybe only three years? August 2011 was the jdk7 GA, and Oracle EOL'd it April 2015. Three years, eight months. >> While it'll be a PITA to handle >> divergent repos, we do know how to do it. > > Especially because there will be new releases every six month so it > will potentially become harder to identify and downport security and > bug fixes from an increasing number of new release branches. I don't think that the porting will be especially onerous. The six- monthly releases won't live for very long and won't differ from each other very much, so backports will hopefully be a NOP. I can't immediately see any motivation for anyone to want to do long-term support on a six-monthly release, but if they really want to that's up to them. Fedora EOL happens one month after the GA of the next-but-one release, and I'd expect Java to be the same. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From geir at pobox.com Sun Sep 24 20:02:08 2017 From: geir at pobox.com (Geir Magnusson Jr.) Date: Sun, 24 Sep 2017 16:02:08 -0400 Subject: Open source TCK was: JDK 9: General Availability In-Reply-To: <6133525e-b684-2587-2a9b-8a235e1cc364@redhat.com> References: <6133525e-b684-2587-2a9b-8a235e1cc364@redhat.com> Message-ID: <53B49B26-767F-4091-96B6-9E8EE5D36E65@pobox.com> > On Sep 24, 2017, at 2:46 AM, Andrew Haley wrote: > > On 24/09/17 00:51, David Herron wrote: >> You make a compelling case and I largely agree with the goal of "open >> sourcing" the TCK's. Doing so would go a long way towards truly opening >> the OpenJDK project. >> >> There is a practical question regarding the primary use for the >> TCK's - which is to certify compliance with the specifications. >> >> An open source software project is free to be downloaded, modified, >> and the modified version distributed at will. > > Not necessarily: there are variants of free licences which don't > permit some sections to be changed. But it doesn't really matter what > licence is used for the TCK itself: the Java Compatible badge would be > reserved for implementations which had passed TCK Version n.n, as > posted at java.net. That would be the canonical one true TCK. Sure, > people would be able to hack their own copies of the TCK, but what > would be the point? The purpose of passing the TCK is to ensure > compatibility with other implementations. There isn't any motive to > claim compliance with a private version of the TCK. Generally agree. Only quibble is that there may be plenty of motive (for example, AIUI, the Java SE TCK still has limiting constraints when licensed to third parties?), but still, no benefit. A private version of the TCK wouldn?t be the TCK as a derivative work of the TCK isn?t the TCK. Only the software suite defined by and distributed by the spec lead is the TCK. (Similar parallel with OpenJDK. Derivatives aren?t the OpenJDK.) > >> For the purpose of sharing of test results, open sourcing the TCK's would >> be great. The TCK's have a different purpose than just verifying >> functionality. >> >> Hence, if someone tested with a modified TCK how can there be certainty >> about the result? Can the results of testing with a modified TCK be >> trusted for certification of compliance? > > No, and no. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mark.reinhold at oracle.com Mon Sep 25 13:56:51 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 25 Sep 2017 06:56:51 -0700 Subject: An impassioned plea on version numbers In-Reply-To: References: Message-ID: <20170925065651.77408868@eggemoggin.niobe.net> 2017/9/22 11:04:05 -0700, Stephen Colebourne : > While I am super happy to see Java 9 released I remain strongly opposed to > the proposed version number scheme from now on. Here is why: > > ... Thanks for your impassioned plea. You make some reasonable arguments. I'll reply at length after JavaOne. - Mark From aph at redhat.com Mon Sep 25 14:50:01 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Sep 2017 15:50:01 +0100 Subject: Do we need an unsigned multiplyHigh? Message-ID: We now have a multiplyHigh intrinsic, but it is signed. Unsigned multiplyHigh is in general a more useful primitive for crypto than signed, and I wonder if we need an intrinsic for that as well. I've looked at cooking up an unsigned multiplyHigh in Java, and I think the fastest way is this: private static final long unsignedMultiplyHigh(long a, long b) { long result = Math.multiplyHigh(a, b); if (a < 0) result += b; if (b < 0) result += a; // Can also be written as: // result += (a >> 63) & b; // result += (b >> 63) & a; return result; } It's still about 50% slower than the signed multiplyHigh, though. Thoughts? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adam.petcher at oracle.com Mon Sep 25 17:21:55 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 25 Sep 2017 13:21:55 -0400 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: I agree that an unsigned multiplyHigh would be useful for crypto purposes, and we should consider adding it. Of course, I would much rather have multiply operations that return both 64-bit parts of the result, but that is going to be hard to do well without value types. So it would be nice to have something like this in the meantime. If we are going to add this operation, it should probably be added along with an intrinsic. I think the Java code can simply factor out the else branch from the existing multiplyHigh code. This way, unsignedMultiplyHigh will be at least as fast as multiplyHigh, whether the intrinsic implementation is available or not. If possible, the implementation of this operation should not branch on either operand. This would make it more widely useful for constant-time crypto implementations. Though this property would need to go into the spec in order for constant-time crypto code to use this method, and I don't know how reasonable it is to put something like this in the spec. Side note: at the moment, I am using signed arithmetic in prototypes for Poly1305, X25519, and EdDSA, partially due to lack of support for unsigned operations like this one. I don't think having unsignedMultiplyHigh would, on its own, convince me to use an unsigned representation, but the forces are different for each algorithm/implementation. On 9/25/2017 10:50 AM, Andrew Haley wrote: > We now have a multiplyHigh intrinsic, but it is signed. Unsigned > multiplyHigh is in general a more useful primitive for crypto than > signed, and I wonder if we need an intrinsic for that as well. I've > looked at cooking up an unsigned multiplyHigh in Java, and I think the > fastest way is this: > > private static final long unsignedMultiplyHigh(long a, long b) { > long result = Math.multiplyHigh(a, b); > if (a < 0) result += b; > if (b < 0) result += a; > // Can also be written as: > // result += (a >> 63) & b; > // result += (b >> 63) & a; > return result; > } > > It's still about 50% slower than the signed multiplyHigh, though. > Thoughts? > From aph at redhat.com Mon Sep 25 17:48:37 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Sep 2017 18:48:37 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: On 25/09/17 18:21, Adam Petcher wrote: > I agree that an unsigned multiplyHigh would be useful for crypto > purposes, and we should consider adding it. Of course, I would much > rather have multiply operations that return both 64-bit parts of the > result, but that is going to be hard to do well without value types. So > it would be nice to have something like this in the meantime. I take your point, but it won't be excruciatingly difficult for the C2 compiler to turn the multiply operations into a single one, if the CPU can do that. From what I've seen recently, though, on non-x86 it's common for the two halves of the result to be calculated by separate instructions. > If we are going to add this operation, it should probably be added > along with an intrinsic. I think the Java code can simply factor out > the else branch from the existing multiplyHigh code. This way, > unsignedMultiplyHigh will be at least as fast as multiplyHigh, > whether the intrinsic implementation is available or not. Sure. I can do that. > If possible, the implementation of this operation should not branch on > either operand. This would make it more widely useful for constant-time > crypto implementations. Though this property would need to go into the > spec in order for constant-time crypto code to use this method, and I > don't know how reasonable it is to put something like this in the spec. OK. I can do it so that there are no branches in the Java. The Java code for signed multiplyHigh has some data-dependent branches in an attempt to speed it up, though. I don't know how effective they are, and I could have a look at taking them out. > Side note: at the moment, I am using signed arithmetic in prototypes for > Poly1305, X25519, and EdDSA, partially due to lack of support for > unsigned operations like this one. I don't think having > unsignedMultiplyHigh would, on its own, convince me to use an unsigned > representation, but the forces are different for each > algorithm/implementation. Sure. I don't think it really matters from a performance point of view which you use, given intrinsics for both. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From cthalinger at twitter.com Mon Sep 25 19:57:15 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 25 Sep 2017 09:57:15 -1000 Subject: Call for Discussion: New Project: Metropolis In-Reply-To: References: <422B0773-111C-495E-AA27-1728C99D9039@oracle.com> Message-ID: > On Sep 21, 2017, at 3:31 PM, John Rose wrote: > > On Sep 21, 2017, at 4:26 PM, Christian Thalinger > wrote: >> >> Replying here then? >> >> You and I are talking about this for quite a while now and I >> welcome this becoming an official OpenJDK project now. > > Yes, we have. We have been watching Java-based JITs slowly mature > since Jikes, Maxine, JavaC1, C1X, and now Graal. The stars have > aligned, I think, for a major shift. > > (In more detail: I have enjoyed watching the experimentation in JVM > implementation techniques by Hanspeter Mo?ssenbo?ck's students at JKU, > with collaboration by Sun/Oracle Labs engineers. There is a wealth > of literature just from that department, and Graal was grown there. > A good place to connect into this history is Titzer et al in VEE'10. > People get inspired in crazy ways; I just noticed a paper on doing > JVMs in Haskell and FORTH: > http://wien.tomnetworks.com/uni/thesis_matevm_oneside.pdf ) > > (Ever further back: Some of my happiest programming memories come > from hacking around in the Symbolics Lisp Machine OS, which was > extravagantly metacircular. Anything not written in Lisp was written > in microcode and/or assembly code, in Lisp syntax, on a Lisp toolchain. > There was a flexible, hackable system. Such flexibility never goes out > of style, I think, although there are always balancing concerns like > reliability and usability.) > >> How do you envision people working on this project? Should individual >> people just become contributors and then work on whichever module the >> want to replace? > > This is not mainly up to me, but rather the guys you know: Vladimir, > Igor, Thomas, Doug, Tom. Whatever the group decides as a consensus > is where it will go. Can we hope that you will be in the group??? I certainly would like to but it all depends if this is in any way helpful to my current employer. > > That said, here are a few of my thoughts: > > I notice that we are growing some tools and experience with branches > as a way to maintain multiple parallel experiments. See Project Amber. > Maurizio's scripts keep the branches properly stacked into dependency > order and refreshed from their dependencies, and all of them from the > default branch. > > If someone wanted to replace a relatively small, isolated component > like MethodLiveness, that would fit easily in a branch. > > Trying to code up a simpler verifier in Java would be a worthy goal. > By simpler I don't mean a different algorithm, but rather a higher-level > expression of the same algorithm, more amenable to review and > validation, both human and robotic. I know that this would be your preferred first task. > > Anything is fair game: The reflection runtime, the LinkResolver and > SystemDictionary, eventually the metadata itself (when we have more > control over object layout). An especially tantalizing area would be > to find "hot spots" in the C++ code where JVM-specific optimizations > would improve the system performance more than a C++ optimizer > could do. If we have a clever code shape we need generated for > the JVM, we can train Graal to do it for us, if we can figure out how > to replace the affected range of C++ code with Java code. GC inner > loops are probably amenable to GC-specific optimization techniques. > > The main driving function, I expect, will be making Graal compile itself > into a static-linked "C++ mode" (using SVM I hope), into a linkable Graal > JIT to supplant C2. But that's just a driving function, not the endpoint, > of Java-on-Java. An ambitious person could try to replace C1 or the > interpreter with Graal. Totally. One thing I would like to see coming out of this project is a slimmed-down, less complicated version of HotSpot. Remove C1, C2, CI and replace with Graal. Same for the interpreter, as you say. Since we have control over how Graal compiles code generating the interpreter from a DSL-type description as we did in "Superinstructions and replication in the Cacao JVM interpreter? should be easily doable (sorry, the old link to the paper is dead). That would get rid of most (all?) handwritten interpreter assembly code while keeping or even improving current performance. > > Did I mention this is likely to be a very long-running project? :-) You didn?t have to :-) From peter.lawrey at gmail.com Tue Sep 26 07:25:35 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Tue, 26 Sep 2017 08:25:35 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: I am looking forward to intrinsic support for 128 bit math using ?Long2? and XMM (or even YMM, ZMM) instructions. This is the best way forward, I hope. Personally I would like to see a long long type, or even uint128, uint256, uint512 style notation. Another option might be something like long<128> or an annotation like @uint128 long or even @decimal128 double but who knows. Regards, Peter. ? On 25 September 2017 at 18:48, Andrew Haley wrote: > On 25/09/17 18:21, Adam Petcher wrote: > > I agree that an unsigned multiplyHigh would be useful for crypto > > purposes, and we should consider adding it. Of course, I would much > > rather have multiply operations that return both 64-bit parts of the > > result, but that is going to be hard to do well without value types. So > > it would be nice to have something like this in the meantime. > > I take your point, but it won't be excruciatingly difficult for the C2 > compiler to turn the multiply operations into a single one, if the CPU > can do that. From what I've seen recently, though, on non-x86 it's > common for the two halves of the result to be calculated by separate > instructions. > > > If we are going to add this operation, it should probably be added > > along with an intrinsic. I think the Java code can simply factor out > > the else branch from the existing multiplyHigh code. This way, > > unsignedMultiplyHigh will be at least as fast as multiplyHigh, > > whether the intrinsic implementation is available or not. > > Sure. I can do that. > > > If possible, the implementation of this operation should not branch on > > either operand. This would make it more widely useful for constant-time > > crypto implementations. Though this property would need to go into the > > spec in order for constant-time crypto code to use this method, and I > > don't know how reasonable it is to put something like this in the spec. > > OK. I can do it so that there are no branches in the Java. The Java > code for signed multiplyHigh has some data-dependent branches in an > attempt to speed it up, though. I don't know how effective they are, > and I could have a look at taking them out. > > > Side note: at the moment, I am using signed arithmetic in prototypes for > > Poly1305, X25519, and EdDSA, partially due to lack of support for > > unsigned operations like this one. I don't think having > > unsignedMultiplyHigh would, on its own, convince me to use an unsigned > > representation, but the forces are different for each > > algorithm/implementation. > > Sure. I don't think it really matters from a performance point of > view which you use, given intrinsics for both. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Tue Sep 26 08:31:42 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Sep 2017 09:31:42 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: On 26/09/17 08:25, Peter Lawrey wrote: > I am looking forward to intrinsic support for 128 bit math using ?Long2? > and XMM (or even YMM, ZMM) instructions. > This is the best way forward, I hope. > > Personally I would like to see a long long type, or even uint128, uint256, > uint512 style notation. > > Another option might be something like long<128> or an annotation like > @uint128 long or even @decimal128 double but who knows. Do you actually need any of that? I think vector types make more sense. Java already has a great many scalar types. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From peter.lawrey at gmail.com Tue Sep 26 10:20:59 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Tue, 26 Sep 2017 11:20:59 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: We have arrays already but we don't have primitive types of more than 64-bit. If we had uint128 for example we wouldn't need this method. On 26 Sep. 2017 11:31, "Andrew Haley" wrote: > On 26/09/17 08:25, Peter Lawrey wrote: > > I am looking forward to intrinsic support for 128 bit math using ?Long2? > > and XMM (or even YMM, ZMM) instructions. > > This is the best way forward, I hope. > > > > Personally I would like to see a long long type, or even uint128, > uint256, > > uint512 style notation. > > > > Another option might be something like long<128> or an annotation like > > @uint128 long or even @decimal128 double but who knows. > > Do you actually need any of that? I think vector types make more sense. > Java already has a great many scalar types. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From peter.lawrey at gmail.com Tue Sep 26 12:33:50 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Tue, 26 Sep 2017 13:33:50 +0100 Subject: An impassioned plea on version numbers In-Reply-To: References: Message-ID: A single number approach might be 183 189 193 199 203 209 Given we have 3 digit updates now it might not matter as much. However 10, 11, 12 seems like a fine suggestion. Regards Peter On 22 Sep. 2017 21:04, "Stephen Colebourne" wrote: While I am super happy to see Java 9 released I remain strongly opposed to the proposed version number scheme from now on. Here is why: 1) The vast majority of existing code that needs to know the version of Java only cares about the major digit. For example online CI like Travis/Shippable, build tools like Maven, community projects that target different behaviour to different releases, all only consider the version to be a single number. This is far more disruptive than changing 1.9 to 9 because these pieces of code would need to handle two important numbers (18 and 3), not one.. Forcing all this code to change is simply not a good choice. 2) No version is more important than any other going forward in terms of features. A new language change (the most disruptive) could occur in March or September. It will require a developer to specify two numbers (18.3) to say what release LVTI is in for example. Given the strong link to semantic version numbering in developers minds, the numbering scheme simply does not make sense. A major new language change in a minor point release??!! Being able to say quickly and easily what version a new language feature is in is vital, and 18.3 / 18.9 obscures that horribly. 3) While the LTS release is important to Oracle and big business, it will be pretty unimportant to the community. It should not be the basis of the version. 4) The proposed scheme appears to be a lot about forcing through the change within Oracle processes, based on the idea that if it is named after a month then no one can ask it to slip. However true that fear might be, it does not justify developers having to face a sub-standard version scheme. 5) Java is not an OS like Ubuntu. The version of Java is referred to all the time - it is front and centre in discussions about Java. Even recruiters talk about it! It needs to be simple and straightforward for all the tasks it is used for - a year/month scheme is unusual and unexpected. I propose that versions should simply increase incrementally. March 2018 - v10 September 2018 - v11 March 2019 - v12 September 2019 - v13 and so on. Stephen From volker.simonis at gmail.com Tue Sep 26 13:59:06 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Sep 2017 15:59:06 +0200 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes On Tue, Sep 26, 2017 at 3:45 PM, wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From sean.coffey at oracle.com Tue Sep 26 14:05:46 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 26 Sep 2017 15:05:46 +0100 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes regards, Sean. On 26/09/2017 14:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From maurizio.cimadamore at oracle.com Tue Sep 26 14:10:52 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Sep 2017 15:10:52 +0100 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes Maurizio On 26/09/17 14:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From brian.goetz at oracle.com Tue Sep 26 14:13:33 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 26 Sep 2017 07:13:33 -0700 Subject: CFV: New Project: JDK In-Reply-To: References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <7A26CB03-17F8-46DE-90B8-FFDC7196C1E3@oracle.com> Vote: yes Sent from my iPad > On Sep 26, 2017, at 7:10 AM, Maurizio Cimadamore wrote: > > Vote: yes > > Maurizio > > >> On 26/09/17 14:45, mark.reinhold at oracle.com wrote: >> I hereby propose the creation of the JDK Project, with me as the Lead and >> the Governing Board as the sponsoring Group. >> >> The goal of this Project will be to produce open-source reference >> implementations of the Java SE Platform, to be specified by JSRs in the >> Java Community Process. Unlike past JDK Release Projects, which produced >> just one feature release and then terminated, this long-running Project >> will produce all future JDK feature releases. Per my recent proposal >> [1][2] to accelerate the release cadence of the Java SE Platform and the >> JDK, this Project will ship a feature release every six months according >> to a strict, time-based model. >> >> The Project's repositories will be initialized from those of the JDK 10 >> Project, and that Project will terminate. Features for the release will >> be proposed and tracked via the JEP Process [3], as usual. >> >> The Authors, Committers, and Reviewers of this Project will initially be >> those of the JDK 10 Project [4]. I expect the first items of discussion >> amongst these contributors to include the schedule for the March 2018 >> release and the version-string scheme. >> >> Votes are due by 17:00 UTC on Tuesday, 10 October [5]. >> >> Only current OpenJDK Members [6] are eligible to vote on this motion. >> Votes must be cast in the open on the discuss list. Replying to this >> message is sufficient if your mail program honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [7]. >> >> - Mark >> >> >> [1] https://mreinhold.org/blog/forward-faster >> [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html >> [3] http://openjdk.java.net/jeps >> [4] http://openjdk.java.net/census#jdk10 >> [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 >> [6] http://openjdk.java.net/census#members >> [7] http://openjdk.java.net/projects/#new-project-vote > From Alan.Bateman at oracle.com Tue Sep 26 14:17:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Sep 2017 15:17:44 +0100 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes From aph at redhat.com Tue Sep 26 14:25:02 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Sep 2017 15:25:02 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: On 26/09/17 11:20, Peter Lawrey wrote: > We have arrays already but we don't have primitive types of more than > 64-bit. If we had uint128 for example we wouldn't need this method. Perhaps not, but why is needing this method a problem? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From weijun.wang at oracle.com Tue Sep 26 14:42:10 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 Sep 2017 22:42:10 +0800 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <86B048DA-9DE8-4756-AD11-5E52D95F0597@oracle.com> Vote: yes. --Weijun > On Sep 26, 2017, at 9:45 PM, mark.reinhold at oracle.com wrote: > > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. From james.laskey at oracle.com Tue Sep 26 14:44:46 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 26 Sep 2017 11:44:46 -0300 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes > On Sep 26, 2017, at 10:45 AM, mark.reinhold at oracle.com wrote: > > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From peter.lawrey at gmail.com Tue Sep 26 14:53:29 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Tue, 26 Sep 2017 15:53:29 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: None, except you end up jumping through hoops to implement 128 bit arithmetic efficiently or cleanly. At some point language support for such a basic operation is the simplest and clearest solution. On 26 Sep. 2017 17:25, "Andrew Haley" wrote: > On 26/09/17 11:20, Peter Lawrey wrote: > > We have arrays already but we don't have primitive types of more than > > 64-bit. If we had uint128 for example we wouldn't need this method. > > Perhaps not, but why is needing this method a problem? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Tue Sep 26 14:57:25 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Sep 2017 15:57:25 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: On 26/09/17 15:53, Peter Lawrey wrote: > None, except you end up jumping through hoops to implement 128 bit > arithmetic efficiently or cleanly. At some point language support for such > a basic operation is the simplest and clearest solution. There's nothing inefficient about this approach. I don't quite see how 128-bit types help with cleanliness, because then you'd need a multiplyHigh for 128-bit types, surely? You need that for the type system to be complete. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Tue Sep 26 15:01:04 2017 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 26 Sep 2017 17:01:04 +0200 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment > On 26. Sep 2017, at 15:45, mark.reinhold at oracle.com wrote: > > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From david.grieve at oracle.com Tue Sep 26 15:14:06 2017 From: david.grieve at oracle.com (David Grieve) Date: Tue, 26 Sep 2017 11:14:06 -0400 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <3a96bdda-8f56-a150-21d2-a5eac5fae1d4@oracle.com> Vote: Yes On 9/26/17 9:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From neugens.limasoftware at gmail.com Tue Sep 26 15:21:44 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 26 Sep 2017 17:21:44 +0200 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: Yes, Cheers, Mario 2017-09-26 15:45 GMT+02:00 : > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From mandy.chung at oracle.com Tue Sep 26 15:24:15 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 26 Sep 2017 08:24:15 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <24acc0f4-f461-e6d0-1a90-a09a53a9a2e0@oracle.com> Vote: Yes Mandy On 9/26/17 6:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From adinn at redhat.com Tue Sep 26 15:30:45 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 26 Sep 2017 16:30:45 +0100 Subject: CFV: New Project: JDK In-Reply-To: References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <7af84c40-303f-0a22-7d8b-3ab1b8e672e2@redhat.com> Vote: yes > On Tue, Sep 26, 2017 at 3:45 PM, wrote: >> I hereby propose the creation of the JDK Project, with me as the Lead and >> the Governing Board as the sponsoring Group. >> >> The goal of this Project will be to produce open-source reference >> implementations of the Java SE Platform, to be specified by JSRs in the >> Java Community Process. Unlike past JDK Release Projects, which produced >> just one feature release and then terminated, this long-running Project >> will produce all future JDK feature releases. Per my recent proposal >> [1][2] to accelerate the release cadence of the Java SE Platform and the >> JDK, this Project will ship a feature release every six months according >> to a strict, time-based model. >> >> The Project's repositories will be initialized from those of the JDK 10 >> Project, and that Project will terminate. Features for the release will >> be proposed and tracked via the JEP Process [3], as usual. >> >> The Authors, Committers, and Reviewers of this Project will initially be >> those of the JDK 10 Project [4]. I expect the first items of discussion >> amongst these contributors to include the schedule for the March 2018 >> release and the version-string scheme. >> >> Votes are due by 17:00 UTC on Tuesday, 10 October [5]. >> >> Only current OpenJDK Members [6] are eligible to vote on this motion. >> Votes must be cast in the open on the discuss list. Replying to this >> message is sufficient if your mail program honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [7]. >> >> - Mark >> >> >> [1] https://mreinhold.org/blog/forward-faster >> [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html >> [3] http://openjdk.java.net/jeps >> [4] http://openjdk.java.net/census#jdk10 >> [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 >> [6] http://openjdk.java.net/census#members >> [7] http://openjdk.java.net/projects/#new-project-vote regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dbhole at redhat.com Tue Sep 26 15:34:22 2017 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 26 Sep 2017 11:34:22 -0400 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <20170926153421.GB8743@redhat.com> Vote: yes * mark.reinhold at oracle.com [2017-09-26 09:46]: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From neugens.limasoftware at gmail.com Tue Sep 26 15:43:13 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 26 Sep 2017 17:43:13 +0200 Subject: Authors, Committers, and Reviewers for JDK10 and forward Message-ID: Hi Mark, With the JDK project moving forward to a strictly time based release schedule, there is a question regarding the external contributions in OpenJDK. So far, the rule was to basically keep whatever the role was for each person in the previous release. I don't think this is specified by the GB but it has been a sane default, after all, most people that have contributed over the years to the previous projects would likely contribute again to the new one, but at the same time it would keep the number of "sleeping" committers down, since you should at least have one contribution in any of the repositories before getting granted the same powers in the new repos. This worked well because the timeframe for the release was large, giving enough time for people involved in the project to find some bug, file a bug report, do some work, etc... With the strict six month cadence I'm afraid this may not be the case anymore for the ones of us contributing a smaller amount of patches over the years (like I do, which is basically about fixing the occasion bugs in the graphics or font stack, which I think are still significant but happen at a much lower frequency than other contributions). Is there any plan to change the rules for keeping the contribution status? I would not personally like a situation where people who are not contributing for years stay committer forever, but at the same time I would prefer a higher threshold for dropping privileges. As a suggestion, I think that we could count the review/committer/etc.. status at every LTS release, so those that accumulated at least a contribution up to the LTS retain the status they achieved during that timeline. Would something like that work or I need to look harder for bugs in the jdk? :) Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From joe.darcy at oracle.com Tue Sep 26 15:44:49 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 26 Sep 2017 08:44:49 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes -Joe From roman at kennke.org Tue Sep 26 15:46:19 2017 From: roman at kennke.org (Roman Kennke) Date: Tue, 26 Sep 2017 17:46:19 +0200 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <6308c33a-8d71-4e78-2d76-fc7abd3bd7fd@kennke.org> Vote: yes > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From vladimir.kozlov at oracle.com Tue Sep 26 15:47:13 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Sep 2017 08:47:13 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <2fad9a7a-4bdb-60c3-64ea-9b9870a1adc1@oracle.com> Vote: yes On 9/26/17 6:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From john.r.rose at oracle.com Tue Sep 26 15:50:31 2017 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Sep 2017 08:50:31 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes From iris.clark at oracle.com Tue Sep 26 16:02:27 2017 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 26 Sep 2017 09:02:27 -0700 (PDT) Subject: New Project: JDK In-Reply-To: <<20170926134505.929E8CA2E5@eggemoggin.niobe.net>> References: <<20170926134505.929E8CA2E5@eggemoggin.niobe.net>> Message-ID: <47131c26-c725-48ff-b701-488fea548e10@default> Vote: yes iris From ron.pressler at oracle.com Tue Sep 26 16:05:12 2017 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 26 Sep 2017 19:05:12 +0300 Subject: Call for Discussion: New Project: Loom Message-ID: I would like to invite discussion on a proposal for a new OpenJDK Project[1], to be titled ?Project Loom?, which is intended to add alternative, user-mode thread implementations, delimited continuations (coroutines) and other constructs involving call-stack manipulation, such as tail calls, to the Java platform. The main mission of the project is to provide an alternative implementation of threads (either represented by the Thread class, which will be modified, or by a new API), managed by schedulers written in Java, that preserve the same programming model of ordinary Java threads (currently implemented by the operating system?s thread construct), but offer drastically improved performance and a smaller footprint. The alternative implementation(s) will be available in addition to the current one. This will significantly lower the complexity of writing efficient concurrent applications, as a large number of such lightweight threads (hundreds of thousands or even millions) could be spawned, and blocking them would incur negligible overhead. Those lightweight threads would be implemented on top of a lower-level construct -- delimited continuations. Delimited continuations may also become a public API, and be used to implement other interesting constructs. The Project will be a technology incubator, similar to the Lambda, Panama, Valhalla, and Amber projects. Such incubator projects absorb changes from the current Java release, but do not directly push to Java releases. Instead, they accumulate prototype changes which are sometimes discarded and sometimes merged by hand (after appropriate review) into a Java release. (In this model, prototype changes accumulate quickly, since they are not subject (to the relatively stringent rules governing JDK change-sets. These rules (involving review, bug tracking, regression tests, and pre-integration builds. (The Loom project will have similar rules, of course, but they are likely to be (more relaxed.) The Project will be sponsored by the HotSpot Group, but will affect other aspects of the JDK as well, including core libraries and serviceability. Project members will include HotSpot team members (including the JIT, GC, runtime, and performance teams), core-libs members, serviceability team members, and non- Oracle developers from organizations interested in lightweight concurrency and continuations. Relations to other projects: * The project will start with a full copy of the JDK source base. * The project will preserve relevance by tracking these sources. * The project will not feed change sets directly into any JDK release. I would like to propose myself as the Lead for the Project, and, in addition, the following people as initial committers: Alan Bateman Paul Sandoz Mandy Chung Karen Kinnear Vladimir Ivanov John Rose Others who are interested in becoming contributors should reply this email. For a detailed proposal, with a discussion of motivations, tradeoffs and technical challenges, see [2]. [1]: http://openjdk.java.net/projects/#new-project-vote [2]: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html From Roger.Riggs at Oracle.com Tue Sep 26 16:44:31 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 26 Sep 2017 12:44:31 -0400 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <15f985ce-52a5-68ba-cda6-a64d6d11a1a5@Oracle.com> Vote: Yes On 9/26/2017 9:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. From stefan.karlsson at oracle.com Tue Sep 26 16:51:17 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 26 Sep 2017 18:51:17 +0200 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <36260059-0a3e-1b60-a83e-7d6295c8a0dc@oracle.com> Vote: yes StefanK On 2017-09-26 15:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From lance.andersen at oracle.com Tue Sep 26 16:59:35 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 26 Sep 2017 12:59:35 -0400 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <1A50A21F-457A-4314-908F-C4DD0DB9DE79@oracle.com> vote: yes > On Sep 26, 2017, at 9:45 AM, mark.reinhold at oracle.com wrote: > > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From cthalinger at twitter.com Tue Sep 26 17:15:29 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 26 Sep 2017 07:15:29 -1000 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes > On Sep 26, 2017, at 3:45 AM, mark.reinhold at oracle.com wrote: > > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From naoto.sato at oracle.com Tue Sep 26 17:30:24 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 26 Sep 2017 10:30:24 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <9142ffe4-74c3-5d10-6373-9d0de8856b2f@oracle.com> Vote: yes Naoto On 9/26/17 6:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From jonathan.gibbons at oracle.com Tue Sep 26 17:48:02 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 26 Sep 2017 10:48:02 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes On 9/26/17 6:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From Peter.B.Kessler at Oracle.COM Tue Sep 26 18:02:30 2017 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Tue, 26 Sep 2017 11:02:30 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <1a6d5053-9c59-8800-9a9e-1dd119510bce@Oracle.COM> Vote: yes ... peter On 09/26/17 06:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From david.holmes at oracle.com Tue Sep 26 22:03:13 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 08:03:13 +1000 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <6ca5058c-a034-ab5d-32a7-6d34207dba36@oracle.com> Vote: yes David On 26/09/2017 11:45 PM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From ysr1729 at gmail.com Tue Sep 26 22:48:26 2017 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 26 Sep 2017 15:48:26 -0700 Subject: CFV: New Project: JDK Message-ID: Vote: yes -- ysr From daniel.fuchs at oracle.com Wed Sep 27 07:22:20 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 27 Sep 2017 08:22:20 +0100 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes -- daniel On 26/09/17 14:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From magnus.ihse.bursie at oracle.com Wed Sep 27 08:02:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 10:02:38 +0200 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes /Magnus On 2017-09-26 15:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From dalibor.topic at oracle.com Wed Sep 27 09:22:37 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 27 Sep 2017 11:22:37 +0200 Subject: Authors, Committers, and Reviewers for JDK10 and forward In-Reply-To: References: Message-ID: On 26.09.2017 17:43, Mario Torre wrote: > With the strict six month cadence I'm afraid this may not be the case > anymore for the ones of us contributing a smaller amount of patches > over the years (like I do, which is basically about fixing the > occasion bugs in the graphics or font stack, which I think are still > significant but happen at a much lower frequency than other > contributions). Since the JDK Project would be a single Project for all future releases, contributions to that Project would be cumulative. So we would avoid the administrative role/user union set operations that we need to perform today, whenever a new JDK Release Project is created. So, if things work as before (as they should, in my opinion), then even occasional bug fixing could lead to more responsible roles over time. I think that's fine - after all, if you happen to write perfect code every now and then, you shouldn't have to worry about losing your gradually gained reviewer/committer privileges over time due to the consequent lack of bug fixing opportunities. ;) cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From nipa at codefx.org Wed Sep 27 10:00:31 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Wed, 27 Sep 2017 12:00:31 +0200 Subject: An impassioned plea on version numbers In-Reply-To: <20170925065651.77408868@eggemoggin.niobe.net> References: <20170925065651.77408868@eggemoggin.niobe.net> Message-ID: Hi, I appreciate the push towards releasing Java more often and the same goes for reducing the differences between Oracle JDK and Open JDK as well as the new licensing details. These are all great decisions moving Java into the right direction! Alas, discussions usually focus on disagreements and I want to chime in on the one thing that I don't agree with: the versioning scheme. Here's what I wrote elsewhere[1]... ## Disagreement One problem with year.month is that it looks like semantic versioning but isn't - 18.9 might have more severe changes than 19.3, yet the latter incremented the "major version", while the former did not. And it not only looks like semver, the new Java 9 API even claims it is[2]. Also, every newcomer has to be taught about this, so they don?t go looking for 18.4. And heavens forbid one release is not on time, so there?s a 18.4 after all. Or the release months change because nobody works over the summer, so x.9 never had any interesting new features. (At least that would reestablish semantic versioning.) Then there?s the risk of polluting the ?version space? with artificially high numbers. Java already changed the version schema a few times, most recently on September 21st which was still in the future when this proposal was made, so it sounds unrealistic to assume that this change is the last one. But there?s no way but forward from 20.3???you can hardly go back to 13, explain to your users why that?s better than 20.3 and then at some point awkwardly jump from 17 over 18.3?20.3 and continue with 21. No, I don?t think that?s a good idea. ## Alternative proposals Why not stick to the current scheme and increment the minor version with every feature release unless it contains considerable language/JVM changes, in which case the major version gets bumped. To pick a few examples from history, Java 6 and 7 might have been 5.1 and 5.2 and, leaving the module system aside, Java 9 could have been Java 8.1 because the few language changes don?t require the bump to 9. Examples for major upcoming language changes would be generic specialization and value types from Project Valhalla. Amber?s proposals, on the other hand, could be seen on either side???I?d file enhanced enums and lambda leftovers under minor changes whereas local variable type inference, pattern matching, and data classes constitute major ones. This would of course lead to discussions about how much impact a language change might have and whether it deserves a major version bump or not, but I don?t see any problems with that???the expected impact of a feature and how much it would change the code we write are already being discussed extensively anyways. If all that?s no good and the year needs to be in there, I have a final suggestion: Go with year.increment (18.1, 18.2, ...) like JetBrains does for IntelliJ et al. This would give more leeway for adding, omitting, or rescheduling releases or the entire release schedule without baking that into the version. so long ... Nicolai [1] https://medium.com/codefx-weekly/radical-new-plans-for-java-5f237ab05b0#b2dc [2] http://download.java.net/java/jdk9/docs/api/java/lang/Runtime.Version.html#major On 25.09.2017 15:56, mark.reinhold at oracle.com wrote: > 2017/9/22 11:04:05 -0700, Stephen Colebourne : >> While I am super happy to see Java 9 released I remain strongly opposed to >> the proposed version number scheme from now on. Here is why: >> >> ... > > Thanks for your impassioned plea. You make some reasonable arguments. > I'll reply at length after JavaOne. > > - Mark > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From peter.lawrey at gmail.com Wed Sep 27 10:28:19 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Wed, 27 Sep 2017 11:28:19 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: If you need multiplyHigh for 128-bit then you need uint256. At some point you have to decide whether you need that many bits as a supported operation. When Java was created a 64-bit long as the widest type made sense, however CPUs such as x64 now support 128, 256 and 512 bit natively and having the JVM dong its best to work this out is not as clean as defining it explicitly. ? On 26 September 2017 at 15:57, Andrew Haley wrote: > On 26/09/17 15:53, Peter Lawrey wrote: > > None, except you end up jumping through hoops to implement 128 bit > > arithmetic efficiently or cleanly. At some point language support for > such > > a basic operation is the simplest and clearest solution. > > There's nothing inefficient about this approach. I don't quite see > how 128-bit types help with cleanliness, because then you'd need a > multiplyHigh for 128-bit types, surely? You need that for the type > system to be complete. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Wed Sep 27 13:40:03 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 14:40:03 +0100 Subject: An impassioned plea on version numbers In-Reply-To: References: Message-ID: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> On 22/09/17 19:04, Stephen Colebourne wrote: > I propose that versions should simply increase incrementally. > March 2018 - v10 > September 2018 - v11 > March 2019 - v12 > September 2019 - v13 I'd prefer 18r1, 18r2, 19r1, etc. 18.1 is OK, but too much like a "conventional" version number. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Sep 27 13:44:50 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 14:44:50 +0100 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: Message-ID: <16902fb8-bf7d-d9fd-ee6f-d2f7eaa24abd@redhat.com> On 27/09/17 11:28, Peter Lawrey wrote: > If you need multiplyHigh for 128-bit then you need uint256. At some point > you have to decide whether you need that many bits as a supported > operation. When Java was created a 64-bit long as the widest type made > sense, however CPUs such as x64 now support 128, 256 and 512 bit natively > and having the JVM dong its best to work this out is not as clean as > defining it explicitly. I guess cleanliness is in the eye of the beholder. IMO multiplyHigh is as clean as we need, and I'd rather see more complexity there than in the type system. It'd be nice to be able to return more than one scalar value from a method, for sure. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sean.coffey at oracle.com Wed Sep 27 13:49:35 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 27 Sep 2017 14:49:35 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <8b24135a-3f52-7ac4-fa53-653310b4017c@oracle.com> Vote: Yes regards, Sean. On 27/09/2017 14:39, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From roman at kennke.org Wed Sep 27 14:09:37 2017 From: roman at kennke.org (Roman Kennke) Date: Wed, 27 Sep 2017 16:09:37 +0200 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > > From sean.mullan at oracle.com Wed Sep 27 15:01:09 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 Sep 2017 11:01:09 -0400 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <246a5f91-5d72-fd1a-ce6e-71958dc69a86@oracle.com> Vote: yes --Sean From john.r.rose at oracle.com Wed Sep 27 15:04:40 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Sep 2017 08:04:40 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <127443F3-763D-458D-BA9B-38CDC5B6B148@oracle.com> Vote: yes From Sergey.Bylokhov at oracle.com Wed Sep 27 15:07:56 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Sep 2017 08:07:56 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <64de3ad2-b556-c22b-1197-69273b4b2c52@oracle.com> Vote: yes On 9/26/17 06:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > -- Best regards, Sergey. From Alan.Bateman at oracle.com Wed Sep 27 15:09:46 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Sep 2017 16:09:46 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <64683dcb-f582-5fe5-1edb-c405bc727284@oracle.com> Vote: yes From peter.lawrey at gmail.com Wed Sep 27 15:25:32 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Wed, 27 Sep 2017 18:25:32 +0300 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: <16902fb8-bf7d-d9fd-ee6f-d2f7eaa24abd@redhat.com> References: <16902fb8-bf7d-d9fd-ee6f-d2f7eaa24abd@redhat.com> Message-ID: Indeed cleanliness is in the eye of the beholder. ;) I feel for mathematical code like this it should be possible to write something as fast and clear as C++, whether that is desirable or not is another matter. Perhaps project Valhalla will be a way to return multiple values by having a composite value type, or panama with it's support for XMM instructions (or both) ? On 27 September 2017 at 16:44, Andrew Haley wrote: > On 27/09/17 11:28, Peter Lawrey wrote: > > If you need multiplyHigh for 128-bit then you need uint256. At some point > > you have to decide whether you need that many bits as a supported > > operation. When Java was created a 64-bit long as the widest type made > > sense, however CPUs such as x64 now support 128, 256 and 512 bit natively > > and having the JVM dong its best to work this out is not as clean as > > defining it explicitly. > > I guess cleanliness is in the eye of the beholder. IMO multiplyHigh is > as clean as we need, and I'd rather see more complexity there than in > the type system. It'd be nice to be able to return more than one scalar > value from a method, for sure. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From james.laskey at oracle.com Wed Sep 27 15:30:34 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 27 Sep 2017 12:30:34 -0300 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <6F4DC60D-A850-48C8-926D-CEA79129A919@oracle.com> Vote: yes > On Sep 27, 2017, at 10:39 AM, Rob McKenna wrote: > > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From peter.lawrey at gmail.com Wed Sep 27 15:31:01 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Wed, 27 Sep 2017 18:31:01 +0300 Subject: An impassioned plea on version numbers In-Reply-To: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> References: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> Message-ID: It's worth noting the version is likely to be 1.10.0_1 1.11.0_1 or 1.18.3_1 1.18.9_1 1.19.3_1 I am not sure adding r1, r2 really helps. Perhaps a combination would work 1.10.18_300 1.10.18_900 1.10.19_300 1.11.19_900 1.11.20_300 or 1.10.183_1 1.10.189_1 1.10.193_1 1.11.199_1 1.11.203_1 This way the middle/major-ish version shows changes in the language and the minor version show updates in the libraries/JSRs included. ? On 27 September 2017 at 16:40, Andrew Haley wrote: > On 22/09/17 19:04, Stephen Colebourne wrote: > > I propose that versions should simply increase incrementally. > > March 2018 - v10 > > September 2018 - v11 > > March 2019 - v12 > > September 2019 - v13 > > I'd prefer 18r1, 18r2, 19r1, etc. 18.1 is OK, but too much like a > "conventional" version number. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From mandy.chung at oracle.com Wed Sep 27 15:31:59 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 27 Sep 2017 08:31:59 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <0dee6014-54e8-3d50-be51-79e95913b0f8@oracle.com> Vote: Yes Mandy From daniel.fuchs at oracle.com Wed Sep 27 15:41:59 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 27 Sep 2017 16:41:59 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes -- daniel On 27/09/2017 14:39, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] From Sergey.Bylokhov at oracle.com Wed Sep 27 15:49:37 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Sep 2017 08:49:37 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes On 9/27/17 06:39, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > -- Best regards, Sergey. From vladimir.kozlov at oracle.com Wed Sep 27 15:50:44 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Sep 2017 08:50:44 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <974e35f4-6fdb-cd68-d07f-96075ea09c80@oracle.com> Vote: yes On 9/27/17 6:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From joe.darcy at oracle.com Wed Sep 27 16:05:14 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 27 Sep 2017 09:05:14 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <1f01bf9d-a77d-eb10-c493-1e18772c9a17@oracle.com> Vote: yes -Joe From neugens.limasoftware at gmail.com Wed Sep 27 16:05:12 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 27 Sep 2017 18:05:12 +0200 Subject: Authors, Committers, and Reviewers for JDK10 and forward In-Reply-To: References: Message-ID: 2017-09-27 11:22 GMT+02:00 dalibor topic : > On 26.09.2017 17:43, Mario Torre wrote: >> >> With the strict six month cadence I'm afraid this may not be the case >> anymore for the ones of us contributing a smaller amount of patches >> over the years (like I do, which is basically about fixing the >> occasion bugs in the graphics or font stack, which I think are still >> significant but happen at a much lower frequency than other >> contributions). > > > Since the JDK Project would be a single Project for all future releases, > contributions to that Project would be cumulative. So we would avoid the > administrative role/user union set operations that we need to perform today, > whenever a new JDK Release Project is created. > > So, if things work as before (as they should, in my opinion), then even > occasional bug fixing could lead to more responsible roles over time. I > think that's fine - after all, if you happen to write perfect code every now > and then, you shouldn't have to worry about losing your gradually gained > reviewer/committer privileges over time due to the consequent lack of bug > fixing opportunities. ;) That makes sense. I still need to wrap my head around how the process will work in practice, but at least I'm happy I won't have to look harder for bugs in the jdk, they are getting rarer by the day! ;) Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From aph at redhat.com Wed Sep 27 16:12:47 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 17:12:47 +0100 Subject: An impassioned plea on version numbers In-Reply-To: References: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> Message-ID: <9f6394cb-585d-0409-00a5-baf799200026@redhat.com> On 27/09/17 16:31, Peter Lawrey wrote: > It's worth noting the version is likely to be > > 1.10.0_1 > 1.11.0_1 > > or > > 1.18.3_1 > 1.18.9_1 > 1.19.3_1 Why do you say that? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From iris.clark at oracle.com Wed Sep 27 16:18:07 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 27 Sep 2017 09:18:07 -0700 (PDT) Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes iris From naoto.sato at oracle.com Wed Sep 27 16:19:12 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 27 Sep 2017 09:19:12 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <53dcf748-250e-042f-c37f-935054bd491e@oracle.com> Vote: yes Naoto On 9/27/17 6:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From maurizio.cimadamore at oracle.com Wed Sep 27 16:37:44 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Sep 2017 17:37:44 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes Maurizio On 27/09/17 14:39, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From aph at redhat.com Wed Sep 27 16:47:25 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 17:47:25 +0100 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes. On 26/09/17 14:45, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.grieve at oracle.com Wed Sep 27 16:48:00 2017 From: david.grieve at oracle.com (David Grieve) Date: Wed, 27 Sep 2017 12:48:00 -0400 Subject: CFV: New Project: JDK Updates In-Reply-To: <1f01bf9d-a77d-eb10-c493-1e18772c9a17@oracle.com> References: <20170927133908.GA6441@vimes> <1f01bf9d-a77d-eb10-c493-1e18772c9a17@oracle.com> Message-ID: <87bb9b43-97f3-435d-9748-57ac6e6776bd@oracle.com> Vote: Yes From jonathan.gibbons at oracle.com Wed Sep 27 17:29:45 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 27 Sep 2017 10:29:45 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <59CBE009.3090101@oracle.com> Vote: yes On 09/27/2017 06:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From omajid at redhat.com Wed Sep 27 17:49:41 2017 From: omajid at redhat.com (Omair Majid) Date: Wed, 27 Sep 2017 13:49:41 -0400 Subject: An impassioned plea on version numbers In-Reply-To: References: Message-ID: <20170927174941.GA22553@redhat.com> * Stephen Colebourne [2017-09-22 14:06]: > 5) Java is not an OS like Ubuntu. The version of Java is referred to all > the time - it is front and centre in discussions about Java. Even > recruiters talk about it! It needs to be simple and straightforward for all > the tasks it is used for - a year/month scheme is unusual and unexpected. And if anyone thinks the Ubuntu versioning system is simple, a quick google shows many documents where users are confused. For example, these docs refer to Ubuntu 16. Not 16.04 or 16.10, just 16. https://github.com/openstreetmap/Nominatim/blob/master/docs/Install-on-Ubuntu-16.md http://www.geoffstratton.com/spamassassin-3-ubuntu-16 https://www.upcloud.com/support/installing-snort-on-ubuntu/ https://community.qualys.com/thread/17402-qualys-cloud-agent-and-ubuntu-16 https://www.vpsserver.com/community/tutorials/49/installing-drupal-on-ubuntu-16-vps-server/ http://www.aerospike.com/docs/client/c/install/ubuntu16.html We should not be surprised if the same happens with Java: instead of 18.3 or 18.9, people will be taking about Java 18. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From poonam.bajaj at oracle.com Wed Sep 27 17:57:20 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Wed, 27 Sep 2017 17:57:20 +0000 (UTC) Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: Yes regards, Poonam > -----Original Message----- > From: Rob McKenna > Sent: Wednesday, September 27, 2017 6:39 AM > To: announce at openjdk.java.net > Subject: CFV: New Project: JDK Updates > > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of a > JDK Updates Project. I work as an engineer in the Oracle Java Platform > Group where JDK updates are key for delivering bug fixes to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017- > September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017- > September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From lance.andersen at oracle.com Wed Sep 27 17:59:53 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 Sep 2017 13:59:53 -0400 Subject: CFV: New Project: JDK Updates In-Reply-To: References: <20170927133908.GA6441@vimes> Message-ID: vote: yes > >> -----Original Message----- >> From: Rob McKenna >> Sent: Wednesday, September 27, 2017 6:39 AM >> To: announce at openjdk.java.net >> Subject: CFV: New Project: JDK Updates >> >> I hereby propose the creation of the "JDK Updates" Project with myself >> as the Lead and the Build Group as the sponsoring Group. The goal of >> this Project will be to produce JDK Updates on top of the JDK Project >> currently under discussion. [1] >> >> I've been involved as a maintainer of the JDK 8 Updates Project [2] >> since Dec 2013 and have been involved with managing all aspects of a >> JDK Updates Project. I work as an engineer in the Oracle Java Platform >> Group where JDK updates are key for delivering bug fixes to end users >> >> This will be a long running project responsible for producing all >> future updates to the feature releases. [3] The Project's repositories >> will initially be open for select critical bug fixes only. The first >> release of this project will focus on the updates for the JDK 9 >> Project. [4] >> >> The initial Authors/Committers/Reviewers will be anyone who holds a >> role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed >> at least one changeset. The most senior role across those Projects >> will be granted in this Project >> >> Votes are due by 23:59 UTC on October 11th. >> >> Only current OpenJDK Members [5] are eligible to vote on this motion >> Votes must be cast in the open on the discuss list. Replying to this >> message is sufficient if your mail program honors the Reply-To header >> For Lazy Consensus voting instructions, see [6] >> >> Regards >> >> Rob >> >> [1] http://mail.openjdk.java.net/pipermail/discuss/2017- >> September/004281.html >> [2] http://openjdk.java.net/projects/jdk8u >> [3] http://mail.openjdk.java.net/pipermail/announce/2017- >> September/000231.html >> [4] http://openjdk.java.net/projects/jdk9 >> [5] http://openjdk.java.net/census#members >> [6] http://openjdk.java.net/projects/#new-project-vote >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From ChrisPhi at LGonQn.Org Wed Sep 27 18:18:34 2017 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Wed, 27 Sep 2017 14:18:34 -0400 Subject: CFV: New Project: JDK Message-ID: <6e45ad71-a158-044e-c37a-f9b9c98e19a5@LGonQn.Org> Vote: yes From ChrisPhi at LGonQn.Org Wed Sep 27 18:19:49 2017 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Wed, 27 Sep 2017 14:19:49 -0400 Subject: CFV: New Project: JDK Updates Message-ID: <5ee2b045-748e-22df-d5ba-a062505a3a17@LGonQn.Org> Vote: yes From john.r.rose at oracle.com Wed Sep 27 18:45:24 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Sep 2017 11:45:24 -0700 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: References: <16902fb8-bf7d-d9fd-ee6f-d2f7eaa24abd@redhat.com> Message-ID: <97F9D736-E850-4C83-A185-22191658F279@oracle.com> On Sep 27, 2017, at 8:25 AM, Peter Lawrey wrote: > > Perhaps project Valhalla will be a way to return multiple values by having > a composite value type, or panama with it's support for XMM instructions > (or both) That seems likely; we are aiming in both of those directions, to support direct programming with AVX-type registers (not just x86 specific, by the way) and general support for by-value return of structured objects (starting with "minimal value types"). For now, though, every method is limited to at most 64 bits of return value "payload", which means that 128-bit operations need to be split into two method calls, or else buffer their result into a temp object (e.g., array). The JIT knows how to combine two intrinsic calls into a single machine operation, in some very limited circumstances, notably the classic "div/rem" instructions. This technique would probably work for 64-to-128 multiplies. (Also AES-128, by the way.) ? John From magnus.ihse.bursie at oracle.com Wed Sep 27 20:32:45 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 22:32:45 +0200 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <766effee-05f1-2108-c5ad-da5b00b9f945@oracle.com> Vote: yes /Magnus On 2017-09-27 15:39, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From philip.race at oracle.com Wed Sep 27 20:42:44 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Sep 2017 13:42:44 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <33475458-a0e7-7cd9-d3e7-218205b46d55@oracle.com> Vote: yes. -phil. From dalibor.topic at oracle.com Wed Sep 27 21:07:15 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 27 Sep 2017 23:07:15 +0200 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: Yes. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From philip.race at oracle.com Wed Sep 27 21:08:56 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Sep 2017 14:08:56 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <34a49c26-1db8-2034-71bf-5ad0f206ad5f@oracle.com> Vote: yes. -phil. From david.holmes at oracle.com Wed Sep 27 21:53:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Sep 2017 07:53:51 +1000 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <4c5cfefc-96a8-9802-7d10-2f4b173114a5@oracle.com> Vote: yes David On 27/09/2017 11:39 PM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From weijun.wang at oracle.com Wed Sep 27 23:15:34 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 Sep 2017 07:15:34 +0800 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes --weijun > On Sep 27, 2017, at 9:39 PM, Rob McKenna wrote: > > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] From volker.simonis at gmail.com Wed Sep 27 23:43:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Sep 2017 01:43:18 +0200 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes On Wed, Sep 27, 2017 at 3:39 PM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From bradford.wetmore at oracle.com Thu Sep 28 06:21:44 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 27 Sep 2017 23:21:44 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <27d8ec8a-7b85-9605-2581-f5b4811e5fb7@oracle.com> Vote: Yes On 9/26/2017 6:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From bradford.wetmore at oracle.com Thu Sep 28 06:21:46 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 27 Sep 2017 23:21:46 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <573054f9-11b1-8b9e-dfa0-af3d1afe726d@oracle.com> Vote: Yes On 9/27/2017 6:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From peter.lawrey at gmail.com Thu Sep 28 06:39:23 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Thu, 28 Sep 2017 09:39:23 +0300 Subject: Do we need an unsigned multiplyHigh? In-Reply-To: <97F9D736-E850-4C83-A185-22191658F279@oracle.com> References: <16902fb8-bf7d-d9fd-ee6f-d2f7eaa24abd@redhat.com> <97F9D736-E850-4C83-A185-22191658F279@oracle.com> Message-ID: For context, While I am more than happy to the builtin encryption libraries which don't need to be written in Java, we do use wider integers to speed up our parser and text renders. e.g. it is faster to parse/cache a date/time as if it was a 128-bit value, than 16 bytes, one byte at a time. This is a use case which I wouldn't expect a library have an intrinsic for. Peter. ? On 27 September 2017 at 21:45, John Rose wrote: > On Sep 27, 2017, at 8:25 AM, Peter Lawrey wrote: > > > Perhaps project Valhalla will be a way to return multiple values by having > a composite value type, or panama with it's support for XMM instructions > (or both) > > > That seems likely; we are aiming in both of those directions, > to support direct programming with AVX-type registers (not > just x86 specific, by the way) and general support for by-value > return of structured objects (starting with "minimal value types"). > > For now, though, every method is limited to at most 64 bits > of return value "payload", which means that 128-bit operations > need to be split into two method calls, or else buffer their > result into a temp object (e.g., array). The JIT knows how > to combine two intrinsic calls into a single machine operation, > in some very limited circumstances, notably the classic > "div/rem" instructions. This technique would probably work > for 64-to-128 multiplies. (Also AES-128, by the way.) > > ? John > From peter.lawrey at gmail.com Thu Sep 28 06:43:20 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Thu, 28 Sep 2017 09:43:20 +0300 Subject: An impassioned plea on version numbers In-Reply-To: <9f6394cb-585d-0409-00a5-baf799200026@redhat.com> References: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> <9f6394cb-585d-0409-00a5-baf799200026@redhat.com> Message-ID: I am assuming a minimum of changes to the format of the current internal Java version $ java -version java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) With a recent version of Java 8 update 144, being 1.8.0_144 internally. ? On 27 September 2017 at 19:12, Andrew Haley wrote: > On 27/09/17 16:31, Peter Lawrey wrote: > > It's worth noting the version is likely to be > > > > 1.10.0_1 > > 1.11.0_1 > > > > or > > > > 1.18.3_1 > > 1.18.9_1 > > 1.19.3_1 > > Why do you say that? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From sven.reimers at gmail.com Thu Sep 28 08:17:37 2017 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 28 Sep 2017 10:17:37 +0200 Subject: An impassioned plea on version numbers In-Reply-To: References: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> <9f6394cb-585d-0409-00a5-baf799200026@redhat.com> Message-ID: This format already changed for 9. Sven Am 28.09.2017 08:43 schrieb "Peter Lawrey" : > I am assuming a minimum of changes to the format of the current internal > Java version > > $ java -version > java version "1.8.0_144" > Java(TM) SE Runtime Environment (build 1.8.0_144-b01) > Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) > > With a recent version of Java 8 update 144, being 1.8.0_144 internally. > ? > > On 27 September 2017 at 19:12, Andrew Haley wrote: > > > On 27/09/17 16:31, Peter Lawrey wrote: > > > It's worth noting the version is likely to be > > > > > > 1.10.0_1 > > > 1.11.0_1 > > > > > > or > > > > > > 1.18.3_1 > > > 1.18.9_1 > > > 1.19.3_1 > > > > Why do you say that? > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From mlists at juma.me.uk Thu Sep 28 08:55:17 2017 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 28 Sep 2017 09:55:17 +0100 Subject: An impassioned plea on version numbers In-Reply-To: References: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> <9f6394cb-585d-0409-00a5-baf799200026@redhat.com> Message-ID: That's right: $ java -version java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) Ismael On Thu, Sep 28, 2017 at 9:17 AM, Sven Reimers wrote: > This format already changed for 9. > > Sven > > Am 28.09.2017 08:43 schrieb "Peter Lawrey" : > > > I am assuming a minimum of changes to the format of the current internal > > Java version > > > > $ java -version > > java version "1.8.0_144" > > Java(TM) SE Runtime Environment (build 1.8.0_144-b01) > > Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) > > > > With a recent version of Java 8 update 144, being 1.8.0_144 internally. > > ? > > > > On 27 September 2017 at 19:12, Andrew Haley wrote: > > > > > On 27/09/17 16:31, Peter Lawrey wrote: > > > > It's worth noting the version is likely to be > > > > > > > > 1.10.0_1 > > > > 1.11.0_1 > > > > > > > > or > > > > > > > > 1.18.3_1 > > > > 1.18.9_1 > > > > 1.19.3_1 > > > > > > Why do you say that? > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > > > From adinn at redhat.com Thu Sep 28 09:03:29 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Sep 2017 10:03:29 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <8b24135a-3f52-7ac4-fa53-653310b4017c@oracle.com> References: <20170927133908.GA6441@vimes> <8b24135a-3f52-7ac4-fa53-653310b4017c@oracle.com> Message-ID: <5c7a9ec6-02de-6d00-40f2-c48fffe4d629@redhat.com> Vote: Yes regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander On 27/09/2017 14:39, Rob McKenna wrote: >> I hereby propose the creation of the "JDK Updates" Project with myself >> as the Lead and the Build Group as the sponsoring Group. The goal of >> this Project will be to produce JDK Updates on top of the JDK Project >> currently under discussion. [1] >> >> I've been involved as a maintainer of the JDK 8 Updates Project [2] >> since Dec 2013 and have been involved with managing all aspects of >> a JDK Updates Project. I work as an engineer in the Oracle Java >> Platform Group where JDK updates are key for delivering bug fixes >> to end users >> >> This will be a long running project responsible for producing all >> future updates to the feature releases. [3]? The Project's repositories >> will initially be open for select critical bug fixes only. The first >> release of this project will focus on the updates for the JDK 9 >> Project. [4] >> >> The initial Authors/Committers/Reviewers will be anyone who holds a >> role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed >> at least one changeset.? The most senior role across those Projects >> will be granted in this Project >> >> Votes are due by 23:59 UTC on October 11th. >> >> Only current OpenJDK Members [5] are eligible to vote on this motion >> Votes must be cast in the open on the discuss list.? Replying to this >> message is sufficient if your mail program honors the Reply-To header >> For Lazy Consensus voting instructions, see [6] >> >> Regards >> >> Rob >> >> [1] >> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html >> [2] http://openjdk.java.net/projects/jdk8u >> [3] >> http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html >> [4] http://openjdk.java.net/projects/jdk9 >> [5] http://openjdk.java.net/census#members >> [6] http://openjdk.java.net/projects/#new-project-vote >> From Roger.Riggs at Oracle.com Thu Sep 28 13:30:44 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 28 Sep 2017 09:30:44 -0400 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: Yes On 9/27/2017 9:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > From sean.mullan at oracle.com Thu Sep 28 20:42:35 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 28 Sep 2017 16:42:35 -0400 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <07f31517-6300-3cef-1602-fbb2a6cdc2bf@oracle.com> Vote: yes --Sean From nipa at codefx.org Fri Sep 29 10:08:45 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Fri, 29 Sep 2017 12:08:45 +0200 Subject: An impassioned plea on version numbers In-Reply-To: References: <7cbc3afd-6b75-149f-6942-212778470d06@redhat.com> <9f6394cb-585d-0409-00a5-baf799200026@redhat.com> Message-ID: <44aa3e6d-93fa-3a89-912e-7311533d15a8@codefx.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Which I find truly funny, because when the year.month scheme was proposed, 9.0 was still in the future. On 28.09.2017 10:17, Sven Reimers wrote: > This format already changed for 9. > > Sven > > Am 28.09.2017 08:43 schrieb "Peter Lawrey" > : > >> I am assuming a minimum of changes to the format of the current >> internal Java version >> >> $ java -version java version "1.8.0_144" Java(TM) SE Runtime >> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server >> VM (build 25.144-b01, mixed mode) >> >> With a recent version of Java 8 update 144, being 1.8.0_144 >> internally. ? >> >> On 27 September 2017 at 19:12, Andrew Haley >> wrote: >> >>> On 27/09/17 16:31, Peter Lawrey wrote: >>>> It's worth noting the version is likely to be >>>> >>>> 1.10.0_1 1.11.0_1 >>>> >>>> or >>>> >>>> 1.18.3_1 1.18.9_1 1.19.3_1 >>> >>> Why do you say that? >>> >>> -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD >>> 6035 332F A671 >>> >> > - -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEB4Ehg6tSyQFzO00OyjutLpzM1QkFAlnOG6wACgkQyjutLpzM 1QkDOQ/+O64by3nrJpVrkF2aI+gJd6jdG0S9ptMb0uKr1MbE1jZLjhc1qeDnKlWs UYrj6EbuhVciA8HQuJuEOBdpvNO++x5BocJKYQUjztKtE0bbSP3DBlkdEljeAncJ ooWWzilJi33Aj55BtjfMBkBmdFJYBXS9IDLaS0e9jVA73qO/bVbpooz73b5ch/eL FQLgB1cdKtSQy1199UwWa9O/HTNCSGPzLIeJw+MJc+/05mKs73XdtiuD/qx4A28u eutNUwFmDVP4ytQAqhgo6ia2ZnFYrkSkqg79BHfWOq6t0hQk/+EkaEkobzBxBJFx i1yEKkzc/9WCbiuXvx92rAueCuKBhro9eOMEgINELJ53MAx7fJkdZMfBLT5IANgN 82K7JRHNLCMJCdnBTseYJ8UM6svdfiGLwekkhyQm7t5qGjMzUIcALz/5cqq+QOGk cebzyr1ellHcRk0mxVU0sQ6v3CTJ+nnoCBLui4RfONjiAX3ggq9gST55ibahcfii VW6sGbrwAAAEo7LJ1FPMPDqMUokV0KT96G5WW/r0T9IyTJlgGyPBONKPANRqAd/4 60AiwGEAhUGvyiPE5GY6P6sgDi/77Nuuln5zuRmL21II5tXChfEOvx6PA74fzFso 0IX6lVFPOyK2GJx2qFPk6y0Vs2Gui5ObdD5WGvz4fZLLIYzn23o= =t4cD -----END PGP SIGNATURE----- From stuart.marks at oracle.com Sat Sep 30 05:57:56 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Sep 2017 22:57:56 -0700 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <23147d88-4207-abb5-8b21-50220b3bd18a@oracle.com> Vote: yes On 9/26/17 6:45 AM, mark.reinhold at oracle.com wrote: > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote > From stuart.marks at oracle.com Sat Sep 30 05:58:26 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Sep 2017 22:58:26 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: <0247b19c-d0b4-eb6d-bfe6-8d8a53baddf0@oracle.com> Vote: yes On 9/27/17 6:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > From brian.goetz at oracle.com Sat Sep 30 17:47:49 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 30 Sep 2017 10:47:49 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> vote: yes! > On Sep 29, 2017, at 10:43 PM, John Rose wrote: > > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov as the Lead and the HotSpot Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will > provide a venue to explore and incubate advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 2017 (UTC). > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From mark.reinhold at oracle.com Sat Sep 30 17:49:39 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 30 Sep 2017 10:49:39 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> Message-ID: <20170930104939.359077166@eggemoggin.niobe.net> Vote: yes - Mark From chris.hegarty at oracle.com Sat Sep 30 17:54:22 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 30 Sep 2017 18:54:22 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <0247b19c-d0b4-eb6d-bfe6-8d8a53baddf0@oracle.com> References: <20170927133908.GA6441@vimes> <0247b19c-d0b4-eb6d-bfe6-8d8a53baddf0@oracle.com> Message-ID: <8F680133-65B8-4348-9263-1C32B11F5BE6@oracle.com> Vote: YES. -Chris. On 9/27/17 6:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] are eligible to vote on this motion > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header > For Lazy Consensus voting instructions, see [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote From chris.hegarty at oracle.com Sat Sep 30 17:55:12 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 30 Sep 2017 18:55:12 +0100 Subject: CFV: New Project: JDK In-Reply-To: <23147d88-4207-abb5-8b21-50220b3bd18a@oracle.com> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> <23147d88-4207-abb5-8b21-50220b3bd18a@oracle.com> Message-ID: <3E46D1DB-15B1-4183-94DE-C0B82A800496@oracle.com> Vote: YES. -Chris. > On 9/26/17 6:45 AM, mark.reinhold at oracle.com wrote: >> I hereby propose the creation of the JDK Project, with me as the Lead and >> the Governing Board as the sponsoring Group. >> >> The goal of this Project will be to produce open-source reference >> implementations of the Java SE Platform, to be specified by JSRs in the >> Java Community Process. Unlike past JDK Release Projects, which produced >> just one feature release and then terminated, this long-running Project >> will produce all future JDK feature releases. Per my recent proposal >> [1][2] to accelerate the release cadence of the Java SE Platform and the >> JDK, this Project will ship a feature release every six months according >> to a strict, time-based model. >> >> The Project's repositories will be initialized from those of the JDK 10 >> Project, and that Project will terminate. Features for the release will >> be proposed and tracked via the JEP Process [3], as usual. >> >> The Authors, Committers, and Reviewers of this Project will initially be >> those of the JDK 10 Project [4]. I expect the first items of discussion >> amongst these contributors to include the schedule for the March 2018 >> release and the version-string scheme. >> >> Votes are due by 17:00 UTC on Tuesday, 10 October [5]. >> >> Only current OpenJDK Members [6] are eligible to vote on this motion. >> Votes must be cast in the open on the discuss list. Replying to this >> message is sufficient if your mail program honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [7]. >> >> - Mark >> >> >> [1] https://mreinhold.org/blog/forward-faster >> [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html >> [3] http://openjdk.java.net/jeps >> [4] http://openjdk.java.net/census#jdk10 >> [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 >> [6] http://openjdk.java.net/census#members >> [7] http://openjdk.java.net/projects/#new-project-vote From vicente.romero at oracle.com Sat Sep 30 19:23:57 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 30 Sep 2017 15:23:57 -0400 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <49d1bfbe-6d2b-49fe-2d91-e3f9305242b1@oracle.com> vote: yes Vicente On 09/30/2017 01:43 AM, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov as the Lead and the HotSpot Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will > provide a venue to explore and incubate advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 2017 (UTC). > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From iris.clark at oracle.com Sat Sep 30 20:17:52 2017 From: iris.clark at oracle.com (Iris Clark) Date: Sat, 30 Sep 2017 13:17:52 -0700 (PDT) Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <95d8366b-1a94-48e9-9b47-d484b32fa664@default> Vote: yes iris From volker.simonis at gmail.com Sat Sep 30 20:52:02 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 30 Sep 2017 22:52:02 +0200 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes On Sat, Sep 30, 2017 at 7:43 AM, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov as the Lead and the HotSpot Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], this project will > provide a venue to explore and incubate advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 2017 (UTC). > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 >