From mark.reinhold at oracle.com Thu Feb 1 19:40:38 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 1 Feb 2018 11:40:38 -0800 (PST) Subject: JDK 10 Release Candidate Phase: Process proposal Message-ID: <20180201194038.25FB915E32F@eggemoggin.niobe.net> Per the JDK 10 schedule [1], we'll enter the Release Candidate Phase next week, on Thursday, 8 February. The goal of this phase is the same as it was for JDK 9: Ensure that we fix the bugs that are absolutely critical to the success of the release. I propose that we use the same process as for JDK 9. I've drafted a page for this phase and posted it here: http://openjdk.java.net/projects/jdk/10/rc This phase will run from the Initial Release Candidate milestone, on 8 February, until the end of the release. JDK Committers are invited to comment on this process proposal. If no objections are raised in one week's time, by 23:00 UTC next Thursday, 8 February, then this is the process that we'll use. - Mark [1] http://openjdk.java.net/projects/jdk/10/#Schedule From mark.reinhold at oracle.com Fri Feb 2 04:00:04 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Feb 2018 20:00:04 -0800 Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters In-Reply-To: <20180125114048.564564978@eggemoggin.niobe.net> References: <20180125114048.564564978@eggemoggin.niobe.net> Message-ID: <20180201200004.917283733@eggemoggin.niobe.net> 2018/1/25 11:40:48 -0800, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 323: Local-Variable Syntax for Lambda Parameters > http://openjdk.java.net/jeps/323 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 1 February, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. Reviewing the vigorous discussion of this proposal, it appears to me that the objections raised have been satisfactorily answered. I've therefore targeted this JEP to JDK 11. - Mark From asmehra1 at in.ibm.com Mon Feb 5 05:48:17 2018 From: asmehra1 at in.ibm.com (Ashutosh Mehra1) Date: Mon, 5 Feb 2018 11:18:17 +0530 Subject: Effect of setting CPU quota on Java performance Message-ID: I have been trying to understand if setting CPU quota limit on a docker container, provided the "effective" CPUs are the same, has any impact on the application performance. As an example, if my app is running on 4 CPUs @ 100% quota, would I get same performance if my app is running on 8 CPUs at 50% quota? Note that "effective" CPUs is 4 in both cases. Since OpenJDK early access builds for Java 10 have improved support for docker container (https://bugs.openjdk.java.net/browse/JDK-8146115), I decided to do some measurements using that build. I got the build OpenJDK build jdk-10-ea+40 from http://jdk.java.net/10/. This build by default has container support enabled. The system I used has 32 CPUs including 2 hyperthreads per core. I turned off hyperthreading for this experiment. That leaves me with 16 cores on 2 sockets: 0-7 on 1 socket and 8-15 on 2nd socket. System details are: # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial # uname -r 4.4.0-103-generic For measurements I used AcmeAir benchmark at https://github.com/sabkrish/acmeair/tree/microservice_changes. I ran the AcmeAir benchmark with the said build for following cases: 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. Lets call this 4CPU at 100. This used following JVM settings: CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota. Lets call this 8CPU at 50. In this case container support was enabled by default and it used following JVM settings: CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with -XX:-UseContainerSupport option to disable container support. Lets call this 8CPU at 50NoCS. This used following JVM settings: CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 Load on the server was applied using JMeter which was running on same box but bound to 0-8 CPUs. I applied the load for few minutes to warm up the JVM before starting the final "measure" run. Throughput reported below is for the final "measure" run. All numbers reported below are an average of 10 iterations. Throughput result: 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS 9621.5 | 6970.6 | 7252.1 I also measured Total compilation time (in seconds) and Total pause time (in seconds) for the duration of the server (which includes warm up phase): Compilation time: 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS 79.8545 | 76.7041 | 100.085 GC Pasue time: 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS 1.829 | 1.886 | 1.927 I am quite surprised to see the drop in throughput between 4Cpu100Quota and 8Cpu50Quota case. Looking deeper into the results, I do notice that numbers for 8Cpu50Quota case were not very consistent, but in general I can say they are not matching 4Cpu100Quota case. I will be doing additional runs for this setup (and on different OS/kernel version) and increase warm up time for the JVM to see if that improves the consistency. Meanwhile, couple of questions I wanted to put forward: 1) Has anyone else noticed this kind of difference in Java application/JVM performance when CPU quota is used? 2) What other open-source benchmarks are available that I can use to verify the behavior I am observing? Any comments/feedback are welcome. Thanks, Ashutosh Mehra From david.holmes at oracle.com Mon Feb 5 06:18:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 5 Feb 2018 16:18:21 +1000 Subject: Effect of setting CPU quota on Java performance In-Reply-To: References: Message-ID: <795c513d-681b-2400-3dbc-ee371233665d@oracle.com> All "processors" are not created equal. Whether you bind to 4 or 8 "cpus" it will matter a great deal which 4 or 8 you choose. It would probably be more instructive to keep the same set of CPUs and change the quota and then see if your performance follows expectations. That said it will also depend a great deal on exactly how CPU quotas are implemented by the system and on how you are loading the system. If the quotas only kick in if the CPU's you have allocated to you are overloaded then you need to ensure your loading process runs on the same set of CPUs. David On 5/02/2018 3:48 PM, Ashutosh Mehra1 wrote: > I have been trying to understand if setting CPU quota limit on a docker > container, provided the "effective" CPUs are the same, has any impact on > the application performance. > As an example, if my app is running on 4 CPUs @ 100% quota, would I get > same performance if my app is running on 8 CPUs at 50% quota? Note that > "effective" CPUs is 4 in both cases. > > Since OpenJDK early access builds for Java 10 have improved support for > docker container (https://bugs.openjdk.java.net/browse/JDK-8146115), I > decided to do some measurements using that build. > I got the build OpenJDK build jdk-10-ea+40 from http://jdk.java.net/10/. > This build by default has container support enabled. > The system I used has 32 CPUs including 2 hyperthreads per core. I turned > off hyperthreading for this experiment. That leaves me with 16 cores on 2 > sockets: 0-7 on 1 socket and 8-15 on 2nd socket. > System details are: > > # lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 16.04.2 LTS > Release: 16.04 > Codename: xenial > > # uname -r > 4.4.0-103-generic > > For measurements I used AcmeAir benchmark at > https://github.com/sabkrish/acmeair/tree/microservice_changes. > I ran the AcmeAir benchmark with the said build for following cases: > > 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. Lets > call this 4CPU at 100. > This used following JVM settings: > CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 > > 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% > quota. Lets call this 8CPU at 50. > In this case container support was enabled by default and it used > following JVM settings: > CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 > > 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with > -XX:-UseContainerSupport option to disable container support. Lets call > this 8CPU at 50NoCS. > This used following JVM settings: > CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 > > Load on the server was applied using JMeter which was running on same box > but bound to 0-8 CPUs. I applied the load for few minutes to warm up the > JVM before starting the final "measure" run. > Throughput reported below is for the final "measure" run. All numbers > reported below are an average of 10 iterations. > > Throughput result: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 9621.5 | 6970.6 | 7252.1 > > I also measured Total compilation time (in seconds) and Total pause time > (in seconds) for the duration of the server (which includes warm up > phase): > > Compilation time: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 79.8545 | 76.7041 | 100.085 > > GC Pasue time: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 1.829 | 1.886 | 1.927 > > I am quite surprised to see the drop in throughput between 4Cpu100Quota > and 8Cpu50Quota case. > Looking deeper into the results, I do notice that numbers for 8Cpu50Quota > case were not very consistent, but in general I can say they are not > matching 4Cpu100Quota case. > I will be doing additional runs for this setup (and on different OS/kernel > version) and increase warm up time for the JVM to see if that improves the > consistency. > > Meanwhile, couple of questions I wanted to put forward: > 1) Has anyone else noticed this kind of difference in Java > application/JVM performance when CPU quota is used? > 2) What other open-source benchmarks are available that I can use to > verify the behavior I am observing? > > Any comments/feedback are welcome. > > Thanks, > Ashutosh Mehra > From manoj.palat at in.ibm.com Mon Feb 5 07:55:35 2018 From: manoj.palat at in.ibm.com (Manoj Palat) Date: Mon, 5 Feb 2018 13:25:35 +0530 Subject: Incubation Feature Clarifications Message-ID: Hi, I am Manoj from the Eclipse Java Development Tools (JDT) and from Eclipse JDT Dev, we have a couple of clarifications regarding the incubation features: ?Mandatory or Optional:?We understand that when an incubation feature is included in a release, it should be of production quality. However, do we, as spec/compiler implementers have the freedom to omit an incubation feature? In Other words, would we be termed non-compliant if we do not implement a particular incubation feature? ?Timeline:??How much minimum time (in weeks/months) before the release can we expect a feature to be?categorized as incubation? If it depends on the feature, what could be a ballpark estimate? Thanks, Manoj From magnus.ihse.bursie at oracle.com Mon Feb 5 08:21:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Feb 2018 09:21:18 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! Message-ID: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in runnable generated-configure.sh script has been removed. Instead, there's a new build-time dependency on autoconf. For most users, this should not make any difference. You will still initiate your configuration by running "bash configure". If you do not already have autoconf installed, when running configure the first time after checking out JDK-8195689, this will be detected, and you will be asked to install autoconf. For most systems, a suggestions on how to do this is also printed. If you have made changes to the build system before, you have probably had a work flow including a custom-built autoconf, running autogen.sh, and asking someone in Oracle to sponsor your patch for generation of the closed version of generated-configure.sh. Neither of this will now be needed. While you can of course keep a custom-built version of autoconf, you might also delete it. With the new solution, the exact version of autoconf does not matter. (Note that it will still be needed for backports, though.) The build documentation has been updated to reflect this change. /Magnus From Alan.Bateman at oracle.com Mon Feb 5 08:30:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Feb 2018 08:30:58 +0000 Subject: Incubation Feature Clarifications In-Reply-To: References: Message-ID: <9bd08e45-6762-7a32-d8bf-df03db8122e4@oracle.com> On 05/02/2018 07:55, Manoj Palat wrote: > > Hi, > I am Manoj from the Eclipse Java Development Tools (JDT) and from Eclipse > JDT Dev, we have a couple of clarifications regarding the incubation > features: > > ?Mandatory or Optional:?We understand that when an incubation feature is > included in a release, it should be of production quality. However, do > we, as spec/compiler implementers have the freedom to omit an incubation > feature? In Other words, would we be termed non-compliant if we do not > implement a particular incubation feature? I assume you are asking about informational JEP 12 "Incubating Language and VM Features" [1], currently in proposed state. The JEP seems very clear that if Java SE N specifies an incubating language or VM feature then it must be supported by every implementation of Java SE N, it's not optional, and is tested by the conformance suite for Java SE N. -Alan [1] http://openjdk.java.net/jeps/12 From thomas.stuefe at gmail.com Mon Feb 5 09:07:03 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 5 Feb 2018 10:07:03 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in > runnable generated-configure.sh script has been removed. Instead, there's a > new build-time dependency on autoconf. > > For most users, this should not make any difference. You will still > initiate your configuration by running "bash configure". > > If you do not already have autoconf installed, when running configure the > first time after checking out JDK-8195689, this will be detected, and you > will be asked to install autoconf. For most systems, a suggestions on how > to do this is also printed. > > If you have made changes to the build system before, you have probably had > a work flow including a custom-built autoconf, running autogen.sh, and > asking someone in Oracle to sponsor your patch for generation of the closed > version of generated-configure.sh. Neither of this will now be needed. > While you can of course keep a custom-built version of autoconf, you might > also delete it. With the new solution, the exact version of autoconf does > not matter. (Note that it will still be needed for backports, though.) > > The build documentation has been updated to reflect this change. > > /Magnus > > This is a nice change. Thank you! From thomas.schatzl at oracle.com Mon Feb 5 12:44:15 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 05 Feb 2018 13:44:15 +0100 Subject: Effect of setting CPU quota on Java performance In-Reply-To: References: Message-ID: <1517834655.2856.10.camel@oracle.com> Hi, On Mon, 2018-02-05 at 11:18 +0530, Ashutosh Mehra1 wrote: > I have been trying to understand if setting CPU quota limit on a > docker container, provided the "effective" CPUs are the same, has any > impact on the application performance. > As an example, if my app is running on 4 CPUs @ 100% quota, would I > get same performance if my app is running on 8 CPUs at 50% quota? Note > that "effective" CPUs is 4 in both cases. I can imagine that using "half-cpus" has significant detrimental impact on latency: i.e. it would as far as I understand provising partial cpus increase the chance that during a safepoint threads will be scheduled out, or threads moved between cpus. The container heuristics for choosing the number of threads do try to adapt for this (as your examples and results imply), but there likely still is the overhead of the (additional) reschedules. Of course this might be dependent a lot on OS/kernel etc. Thanks, Thomas From brian.goetz at oracle.com Mon Feb 5 14:52:25 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 5 Feb 2018 09:52:25 -0500 Subject: Incubation Feature Clarifications In-Reply-To: References: Message-ID: <11bb673b-395c-d45c-edd5-a8c38715b513@oracle.com> Part of the goal of the Incubating JEP is to make the incubation-vs-permanent difference as small as possible.? For almost anything not explicitly spelled out in the JEP, the answer is usually "no different than any other feature."? In that light: > Hi, > I am Manoj from the Eclipse Java Development Tools (JDT) and from Eclipse > JDT Dev, we have a couple of clarifications regarding the incubation > features: > > ?Mandatory or Optional:?We understand that when an incubation feature is > included in a release, it should be of production quality. However, do > we, as spec/compiler implementers have the freedom to omit an incubation > feature? In Other words, would we be termed non-compliant if we do not > implement a particular incubation feature? This one is spelled out in the JEP, but the answer is: no different than any other feature.? It's part of the spec, so its part of what the ecosystem should support.? (This further underscores the fact that incubating features are not for experimental or risky features.) > ?Timeline:??How much minimum time (in weeks/months) before the release > can we expect a feature to be?categorized as incubation? If it depends > on the feature, what could be a ballpark estimate? > No different than any other feature.? For any feature, incubating or not, the key milestone is Propose To Target; at this point, a JEP owner should consider whether including such a feature at this point in the cycle is the best choice.? (Incubating or not, integrating a risky feature near the close of the development cycle is not a good idea; there's another train coming soon.) JEPs that affect the platform specification are tagged as Scope: SE.? Language features are tracked in component specification:language; VM features in specification:vm.? It is easy to create queries that track JEPs by filtering on these fields; this dashboard, used by the SE 10 EG (https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17511), is one such example -- you can customize as you like.? So it is easy to track the lifecycle of JEPs that will affect the language and which will ultimately need IDE support. From thomas.stuefe at gmail.com Mon Feb 5 16:30:16 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 5 Feb 2018 17:30:16 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: Hi Magnus, On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > With the new solution, the exact version of autoconf does not > matter. > It seems to matter. I now get: Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] stdin:33: error: Autoconf version 2.69 or higher is required stdin:33: the top level autom4te: /usr/bin/m4 failed with exit status: 63 Do we actually need this strict check for the autoconf version? Is there a way to disable the check and retry with my old version? I would dislike for this to be a frequent error now - unfortunately, we have some build environments where getting the latest GNU tools is more work than just running an installer. Thanks, Thomas > > The build documentation has been updated to reflect this change. > > /Magnus > > From sean.mullan at oracle.com Mon Feb 5 16:31:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 5 Feb 2018 11:31:37 -0500 Subject: SecurityManager Survey Message-ID: Hello, The SecurityManager has been in Java SE for a long time, but we don't have a lot of data about how it is used in practice, especially outside of applets and Web Start apps. Thus, we have created an initial survey to gather more information and help us evaluate and understand how others are using it. If you have written or maintain code that uses the SecurityManager or related APIs such as the AccessController, then we would appreciate if you would complete this survey: https://www.surveymonkey.com/r/RSGMF3K We are specifically interested in use-cases other than applets or Web Start applications; for example, server applications, tools and libraries that have been designed to run properly when a SecurityManager is enabled. The survey will remain open through February 16th. The results of the survey will be made public after the survey closes. Thank you, Sean Mullan OpenJDK Security Group Lead http://openjdk.java.net/groups/security/ From martinrb at google.com Mon Feb 5 16:46:29 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Feb 2018 08:46:29 -0800 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: In defense of build-team's decision, autoconf 2.69 was released in 2012, and it's possible to run autoconf on another machine than the build machine, and autoconf itself is easy to build. If you can verify that your old version of autoconf works, then the version check in the sources can/should be relaxed. On Mon, Feb 5, 2018 at 8:30 AM, Thomas St?fe wrote: > Hi Magnus, > > On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > > > > With the new solution, the exact version of autoconf does not > > matter. > > > > It seems to matter. I now get: > > Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] > stdin:33: error: Autoconf version 2.69 or higher is required > stdin:33: the top level > autom4te: /usr/bin/m4 failed with exit status: 63 > > Do we actually need this strict check for the autoconf version? Is there a > way to disable the check and retry with my old version? > > I would dislike for this to be a frequent error now - unfortunately, we > have some build environments where getting the latest GNU tools is more > work than just running an installer. > > Thanks, Thomas > > > > > > The build documentation has been updated to reflect this change. > > > > /Magnus > > > > > From thomas.stuefe at gmail.com Mon Feb 5 16:53:50 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 5 Feb 2018 17:53:50 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: On Mon, Feb 5, 2018 at 5:46 PM, Martin Buchholz wrote: > In defense of build-team's decision, autoconf 2.69 was released in 2012, > and it's possible to run autoconf on another machine than the build > machine, and autoconf itself is easy to build. > > If you can verify that your old version of autoconf works, then the > version check in the sources can/should be relaxed. > > Yes, until now I just ran autoconf on my local linux box. I will check if the older autoconf works. ..Thomas > On Mon, Feb 5, 2018 at 8:30 AM, Thomas St?fe > wrote: > >> Hi Magnus, >> >> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >> >> > With the new solution, the exact version of autoconf does not >> > matter. >> > >> >> It seems to matter. I now get: >> >> Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] >> stdin:33: error: Autoconf version 2.69 or higher is required >> stdin:33: the top level >> autom4te: /usr/bin/m4 failed with exit status: 63 >> >> Do we actually need this strict check for the autoconf version? Is there a >> way to disable the check and retry with my old version? >> >> I would dislike for this to be a frequent error now - unfortunately, we >> have some build environments where getting the latest GNU tools is more >> work than just running an installer. >> >> Thanks, Thomas >> >> >> > >> > The build documentation has been updated to reflect this change. >> > >> > /Magnus >> > >> > >> > > From volker.simonis at gmail.com Mon Feb 5 17:55:14 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Feb 2018 18:55:14 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: Hi Magnus, great change! Thanks for finally pushing it. I'm sure it will initially cause us some headaches on our old and/or exotic platforms (as mentioned by Thomas) but I think in the end it is the right solution. Regards, Volker On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie wrote: > With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in > runnable generated-configure.sh script has been removed. Instead, there's a > new build-time dependency on autoconf. > > For most users, this should not make any difference. You will still initiate > your configuration by running "bash configure". > > If you do not already have autoconf installed, when running configure the > first time after checking out JDK-8195689, this will be detected, and you > will be asked to install autoconf. For most systems, a suggestions on how to > do this is also printed. > > If you have made changes to the build system before, you have probably had a > work flow including a custom-built autoconf, running autogen.sh, and asking > someone in Oracle to sponsor your patch for generation of the closed version > of generated-configure.sh. Neither of this will now be needed. While you can > of course keep a custom-built version of autoconf, you might also delete it. > With the new solution, the exact version of autoconf does not matter. (Note > that it will still be needed for backports, though.) > > The build documentation has been updated to reflect this change. > > /Magnus > From ioi.lam at oracle.com Mon Feb 5 18:12:16 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 6 Feb 2018 02:12:16 +0800 Subject: Effect of setting CPU quota on Java performance In-Reply-To: References: Message-ID: <04674F3C-0720-46EB-8F6F-F79BAC1FEF6A@oracle.com> As a control test, maybe you can run a simple multi-threaded C benchmark with the same settings? > On Feb 5, 2018, at 1:48 PM, Ashutosh Mehra1 wrote: > > I have been trying to understand if setting CPU quota limit on a docker > container, provided the "effective" CPUs are the same, has any impact on > the application performance. > As an example, if my app is running on 4 CPUs @ 100% quota, would I get > same performance if my app is running on 8 CPUs at 50% quota? Note that > "effective" CPUs is 4 in both cases. > > Since OpenJDK early access builds for Java 10 have improved support for > docker container (https://bugs.openjdk.java.net/browse/JDK-8146115), I > decided to do some measurements using that build. > I got the build OpenJDK build jdk-10-ea+40 from http://jdk.java.net/10/. > This build by default has container support enabled. > The system I used has 32 CPUs including 2 hyperthreads per core. I turned > off hyperthreading for this experiment. That leaves me with 16 cores on 2 > sockets: 0-7 on 1 socket and 8-15 on 2nd socket. > System details are: > > # lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 16.04.2 LTS > Release: 16.04 > Codename: xenial > > # uname -r > 4.4.0-103-generic > > For measurements I used AcmeAir benchmark at > https://github.com/sabkrish/acmeair/tree/microservice_changes. > I ran the AcmeAir benchmark with the said build for following cases: > > 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. Lets > call this 4CPU at 100. > This used following JVM settings: > CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 > > 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% > quota. Lets call this 8CPU at 50. > In this case container support was enabled by default and it used > following JVM settings: > CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 > > 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with > -XX:-UseContainerSupport option to disable container support. Lets call > this 8CPU at 50NoCS. > This used following JVM settings: > CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 > > Load on the server was applied using JMeter which was running on same box > but bound to 0-8 CPUs. I applied the load for few minutes to warm up the > JVM before starting the final "measure" run. > Throughput reported below is for the final "measure" run. All numbers > reported below are an average of 10 iterations. > > Throughput result: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 9621.5 | 6970.6 | 7252.1 > > I also measured Total compilation time (in seconds) and Total pause time > (in seconds) for the duration of the server (which includes warm up > phase): > > Compilation time: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 79.8545 | 76.7041 | 100.085 > > GC Pasue time: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 1.829 | 1.886 | 1.927 > > I am quite surprised to see the drop in throughput between 4Cpu100Quota > and 8Cpu50Quota case. > Looking deeper into the results, I do notice that numbers for 8Cpu50Quota > case were not very consistent, but in general I can say they are not > matching 4Cpu100Quota case. > I will be doing additional runs for this setup (and on different OS/kernel > version) and increase warm up time for the JVM to see if that improves the > consistency. > > Meanwhile, couple of questions I wanted to put forward: > 1) Has anyone else noticed this kind of difference in Java > application/JVM performance when CPU quota is used? > 2) What other open-source benchmarks are available that I can use to > verify the behavior I am observing? > > Any comments/feedback are welcome. > > Thanks, > Ashutosh Mehra > From lhochet at gmail.com Mon Feb 5 22:30:07 2018 From: lhochet at gmail.com (Ludovic HOCHET) Date: Mon, 5 Feb 2018 23:30:07 +0100 Subject: RFR: 8196383 : JDK 10 L10n resource file update - msg drop 20 In-Reply-To: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com> References: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com> Message-ID: Hello Johnny, launcher_fr.properties still has non doubled single quotes ', which breaks MessageFormat parameters replacement, as well as the display of single quotes (they are not displayed) making the text odd to read. Ludovic On 31 January 2018 at 07:30, Yue Liu wrote: > Hi all, > > Please help to review the changes for L10n resource file update message drop > 20. > > Some localized resource files are updated as English resource changed, some > just because of issue fixing > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8196383 > > Webrev: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8196383/webrev.00/ > > Have got build and passed the tier1/2/3 test on all platforms on Mach 5. > > Thanks, > Johnny > -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From david.holmes at oracle.com Tue Feb 6 01:25:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 11:25:28 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 Message-ID: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> It's time to increment the actual version to 11 for JDK 11. Joe Darcy and I have worked through numerous test issues that delayed the update and I've been addressing a number of issues in hotspot related to obsolete/expired flag warnings. I have tested the update with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI failures for either JDK or HS pipelines. Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 Change: --- a/make/autoconf/version-numbers +++ b/make/autoconf/version-numbers @@ -25,7 +25,7 @@ # Default version numbers to use unless overridden by configure -DEFAULT_VERSION_FEATURE=10 +DEFAULT_VERSION_FEATURE=11 DEFAULT_VERSION_INTERIM=0 DEFAULT_VERSION_UPDATE=0 DEFAULT_VERSION_PATCH=0 Thanks, David From joe.darcy at oracle.com Tue Feb 6 01:32:40 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 05 Feb 2018 17:32:40 -0800 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> Message-ID: <5A7905B8.7080203@oracle.com> Ship it :-) -Joe On 2/5/2018 5:25 PM, David Holmes wrote: > It's time to increment the actual version to 11 for JDK 11. > > Joe Darcy and I have worked through numerous test issues that delayed > the update and I've been addressing a number of issues in hotspot > related to obsolete/expired flag warnings. I have tested the update > with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI > failures for either JDK or HS pipelines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 > > Change: > > --- a/make/autoconf/version-numbers > +++ b/make/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > # Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_FEATURE=10 > +DEFAULT_VERSION_FEATURE=11 > DEFAULT_VERSION_INTERIM=0 > DEFAULT_VERSION_UPDATE=0 > DEFAULT_VERSION_PATCH=0 > > Thanks, > David From mandy.chung at oracle.com Tue Feb 6 01:46:50 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 5 Feb 2018 17:46:50 -0800 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> Message-ID: <03f6ae5a-b56f-2efb-575b-7a7c11df357a@oracle.com> +1 Mandy On 2/5/18 5:25 PM, David Holmes wrote: > It's time to increment the actual version to 11 for JDK 11. > > Joe Darcy and I have worked through numerous test issues that delayed > the update and I've been addressing a number of issues in hotspot > related to obsolete/expired flag warnings. I have tested the update > with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI > failures for either JDK or HS pipelines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 > > Change: > > --- a/make/autoconf/version-numbers > +++ b/make/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > ?# Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_FEATURE=10 > +DEFAULT_VERSION_FEATURE=11 > ?DEFAULT_VERSION_INTERIM=0 > ?DEFAULT_VERSION_UPDATE=0 > ?DEFAULT_VERSION_PATCH=0 > > Thanks, > David From david.holmes at oracle.com Tue Feb 6 02:25:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 12:25:45 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <5A7905B8.7080203@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> <5A7905B8.7080203@oracle.com> Message-ID: Thanks Joe! David On 6/02/2018 11:32 AM, Joseph D. Darcy wrote: > Ship it :-) > > -Joe > > On 2/5/2018 5:25 PM, David Holmes wrote: >> It's time to increment the actual version to 11 for JDK 11. >> >> Joe Darcy and I have worked through numerous test issues that delayed >> the update and I've been addressing a number of issues in hotspot >> related to obsolete/expired flag warnings. I have tested the update >> with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI >> failures for either JDK or HS pipelines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 >> >> Change: >> >> --- a/make/autoconf/version-numbers >> +++ b/make/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> ?# Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_FEATURE=10 >> +DEFAULT_VERSION_FEATURE=11 >> ?DEFAULT_VERSION_INTERIM=0 >> ?DEFAULT_VERSION_UPDATE=0 >> ?DEFAULT_VERSION_PATCH=0 >> >> Thanks, >> David > From david.holmes at oracle.com Tue Feb 6 02:26:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 12:26:01 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <03f6ae5a-b56f-2efb-575b-7a7c11df357a@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> <03f6ae5a-b56f-2efb-575b-7a7c11df357a@oracle.com> Message-ID: <31f51327-ff4e-a46b-f6e0-0cb7271baa98@oracle.com> Thanks Mandy! David On 6/02/2018 11:46 AM, mandy chung wrote: > +1 Mandy > > > On 2/5/18 5:25 PM, David Holmes wrote: >> It's time to increment the actual version to 11 for JDK 11. >> >> Joe Darcy and I have worked through numerous test issues that delayed >> the update and I've been addressing a number of issues in hotspot >> related to obsolete/expired flag warnings. I have tested the update >> with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI >> failures for either JDK or HS pipelines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 >> >> Change: >> >> --- a/make/autoconf/version-numbers >> +++ b/make/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> ?# Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_FEATURE=10 >> +DEFAULT_VERSION_FEATURE=11 >> ?DEFAULT_VERSION_INTERIM=0 >> ?DEFAULT_VERSION_UPDATE=0 >> ?DEFAULT_VERSION_PATCH=0 >> >> Thanks, >> David > From yumin.qi at gmail.com Tue Feb 6 06:32:22 2018 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 5 Feb 2018 22:32:22 -0800 Subject: JDK submit repo In-Reply-To: <20180130073502.342307114@eggemoggin.niobe.net> References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <20180130073502.342307114@eggemoggin.niobe.net> Message-ID: Hi, Mark I pushed with an error returned: $ hg tip changeset: 48771:b458b2ad109d branch: JDK-8194154 tag: tip parent: 48767:4d716bc7ed54 user: Yumin.Qi date: Mon Feb 05 22:23:38 2018 -0800 summary: 8194154: JDK crashes on canonicalization of parsing path string contains '//' on linux. $hg push --new-branch pushing to http://hg.openjdk.java.net/jdk/submit searching for changes abort: HTTP Error 403: Forbidden I am not sure if I have done correctly. Can you help what is wrong here? I am a commiter, but could not do the push to 'submit'. Thanks Yumin On Tue, Jan 30, 2018 at 7:35 AM, wrote: > 2018/1/30 2:50:45 -0800, Aleksey Shipilev : > > So I have submitted JDK-8174901 five days ago, and there was silence > > since then. Is *this* the kinds of thing to ask at ops@? > > Yes. > > - Mark > From asmehra1 at in.ibm.com Tue Feb 6 06:43:10 2018 From: asmehra1 at in.ibm.com (Ashutosh Mehra1) Date: Tue, 6 Feb 2018 12:13:10 +0530 Subject: Effect of setting CPU quota on Java performance In-Reply-To: <04674F3C-0720-46EB-8F6F-F79BAC1FEF6A@oracle.com> References: <04674F3C-0720-46EB-8F6F-F79BAC1FEF6A@oracle.com> Message-ID: > As a control test, maybe you can run a simple multi-threaded C benchmark with the same settings? Thats a good point. I have also been testing with a simple multi-threaded C program for past few days, and I observed similar difference in performance between 4CPU at 100 and 8CPU at 50. In fact I asked this question based on that multi-threaded C program here https://unix.stackexchange.com/questions/417506/what-is-the-effect-of-setting-cpu-cpu-quota-us-in-cpu-cgroup but didn't get any response. Yesterday, while testing with that C program we noticed CPU frequency for 4CPU at 100 case was close to maximum, but in case of 8CPU at 50, it was way below that. On further examination we found the system was using "powersave" as the kernel governor for CPU frequency. For a quick overview of different kernel governors for CPU frequency see this: https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt When we changed the kernel governor to "performance", we were able to see much better performance with 8CPU at 50 which was very close to 4CPU at 100. I am going to repeat my experiment with AcmeAir benchmark using "performance" kernel governor. I expect this should help in bridging the throughput gap I noticed in my earlier experiment. - Ashutosh From: Ioi Lam To: Ashutosh Mehra1 Cc: jdk-dev at openjdk.java.net, Dinakar Guniguntala Date: 02/05/2018 11:47 PM Subject: Re: Effect of setting CPU quota on Java performance As a control test, maybe you can run a simple multi-threaded C benchmark with the same settings? > On Feb 5, 2018, at 1:48 PM, Ashutosh Mehra1 wrote: > > I have been trying to understand if setting CPU quota limit on a docker > container, provided the "effective" CPUs are the same, has any impact on > the application performance. > As an example, if my app is running on 4 CPUs @ 100% quota, would I get > same performance if my app is running on 8 CPUs at 50% quota? Note that > "effective" CPUs is 4 in both cases. > > Since OpenJDK early access builds for Java 10 have improved support for > docker container ( https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8146115&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=pYU9iHBTE76q-M9IZrQkWIq_LZnocNRTSH1_bJFCGLQ&e= ), I > decided to do some measurements using that build. > I got the build OpenJDK build jdk-10-ea+40 from https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_10_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=_bL50Git2eGTEuWiDNdtvjIXdgc7499XiPL7JFilAxA&e= . > This build by default has container support enabled. > The system I used has 32 CPUs including 2 hyperthreads per core. I turned > off hyperthreading for this experiment. That leaves me with 16 cores on 2 > sockets: 0-7 on 1 socket and 8-15 on 2nd socket. > System details are: > > # lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 16.04.2 LTS > Release: 16.04 > Codename: xenial > > # uname -r > 4.4.0-103-generic > > For measurements I used AcmeAir benchmark at > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sabkrish_acmeair_tree_microservice-5Fchanges&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=bkcFfs-e2YzGHlWabfwKyipPqlqDOWXrW6W5-ns1EP8&e= . > I ran the AcmeAir benchmark with the said build for following cases: > > 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. Lets > call this 4CPU at 100. > This used following JVM settings: > CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 > > 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% > quota. Lets call this 8CPU at 50. > In this case container support was enabled by default and it used > following JVM settings: > CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 > > 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with > -XX:-UseContainerSupport option to disable container support. Lets call > this 8CPU at 50NoCS. > This used following JVM settings: > CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 > > Load on the server was applied using JMeter which was running on same box > but bound to 0-8 CPUs. I applied the load for few minutes to warm up the > JVM before starting the final "measure" run. > Throughput reported below is for the final "measure" run. All numbers > reported below are an average of 10 iterations. > > Throughput result: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 9621.5 | 6970.6 | 7252.1 > > I also measured Total compilation time (in seconds) and Total pause time > (in seconds) for the duration of the server (which includes warm up > phase): > > Compilation time: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 79.8545 | 76.7041 | 100.085 > > GC Pasue time: > 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS > 1.829 | 1.886 | 1.927 > > I am quite surprised to see the drop in throughput between 4Cpu100Quota > and 8Cpu50Quota case. > Looking deeper into the results, I do notice that numbers for 8Cpu50Quota > case were not very consistent, but in general I can say they are not > matching 4Cpu100Quota case. > I will be doing additional runs for this setup (and on different OS/kernel > version) and increase warm up time for the JVM to see if that improves the > consistency. > > Meanwhile, couple of questions I wanted to put forward: > 1) Has anyone else noticed this kind of difference in Java > application/JVM performance when CPU quota is used? > 2) What other open-source benchmarks are available that I can use to > verify the behavior I am observing? > > Any comments/feedback are welcome. > > Thanks, > Ashutosh Mehra > From yue.l.liu at oracle.com Tue Feb 6 06:50:01 2018 From: yue.l.liu at oracle.com (Yue Liu) Date: Tue, 6 Feb 2018 14:50:01 +0800 Subject: RFR: 8196383 : JDK 10 L10n resource file update - msg drop 20 In-Reply-To: References: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com> Message-ID: <2638d679-ed4a-e3c2-439f-f1873f631101@oracle.com> Hi Ludovic, As I understand, non doubled single quotes ' making the text odd to read means that all single quotes should be replaced by double quotes ''. e.g. "afficher l'?cran d'accueil avec l'image indiqu?e" should be updated to: "afficher l''?cran d''accueil avec l''image indiqu?e" If that's not the case, please providing more specific info and samples. I create a bug for tracking this: https://bugs.openjdk.java.net/browse/JDK-8196836 If properties file needs update, I'm afraid we couldn't integrate the change in this drop. Thanks, Johnny On 2018/2/6 6:30, Ludovic HOCHET wrote: > Hello Johnny, > > launcher_fr.properties still has non doubled single quotes ', which > breaks MessageFormat parameters replacement, as well as the display of > single quotes (they are not displayed) making the text odd to read. > > Ludovic > > On 31 January 2018 at 07:30, Yue Liu wrote: >> Hi all, >> >> Please help to review the changes for L10n resource file update message drop >> 20. >> >> Some localized resource files are updated as English resource changed, some >> just because of issue fixing >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8196383 >> >> Webrev: >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8196383/webrev.00/ >> >> Have got build and passed the tier1/2/3 test on all platforms on Mach 5. >> >> Thanks, >> Johnny >> > > From ioi.lam at oracle.com Tue Feb 6 09:14:24 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 6 Feb 2018 17:14:24 +0800 Subject: Effect of setting CPU quota on Java performance In-Reply-To: References: <04674F3C-0720-46EB-8F6F-F79BAC1FEF6A@oracle.com> Message-ID: <049D6283-A4B5-40A6-981D-D311B937A187@oracle.com> Just curious, what would be the use case for running on more cores with less CPU quota per core? Are you trying to find out ?can I maintain the same level of performance with lower power usage by plugging in more cores?? Or put it another way ?can I buy power with cores?? I think that would be great, as that would mean your investment in the extra core can eventually be paid back by power savings. Ioi On Feb 6, 2018, at 2:43 PM, Ashutosh Mehra1 wrote: >> As a control test, maybe you can run a simple multi-threaded C benchmark > with the same settings? > > Thats a good point. I have also been testing with a simple multi-threaded > C program for past few days, and I observed similar difference in > performance between 4CPU at 100 and 8CPU at 50. > In fact I asked this question based on that multi-threaded C program here > https://unix.stackexchange.com/questions/417506/what-is-the-effect-of-setting-cpu-cpu-quota-us-in-cpu-cgroup > but didn't get any response. > > Yesterday, while testing with that C program we noticed CPU frequency for > 4CPU at 100 case was close to maximum, but in case of 8CPU at 50, it was way > below that. > On further examination we found the system was using "powersave" as the > kernel governor for CPU frequency. > For a quick overview of different kernel governors for CPU frequency see > this: https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt > When we changed the kernel governor to "performance", we were able to see > much better performance with 8CPU at 50 which was very close to 4CPU at 100. > > I am going to repeat my experiment with AcmeAir benchmark using > "performance" kernel governor. > I expect this should help in bridging the throughput gap I noticed in my > earlier experiment. > > - Ashutosh > > > > From: Ioi Lam > To: Ashutosh Mehra1 > Cc: jdk-dev at openjdk.java.net, Dinakar Guniguntala > > Date: 02/05/2018 11:47 PM > Subject: Re: Effect of setting CPU quota on Java performance > > > > As a control test, maybe you can run a simple multi-threaded C benchmark > with the same settings? > >> On Feb 5, 2018, at 1:48 PM, Ashutosh Mehra1 wrote: >> >> I have been trying to understand if setting CPU quota limit on a docker >> container, provided the "effective" CPUs are the same, has any impact on > >> the application performance. >> As an example, if my app is running on 4 CPUs @ 100% quota, would I get >> same performance if my app is running on 8 CPUs at 50% quota? Note that >> "effective" CPUs is 4 in both cases. >> >> Since OpenJDK early access builds for Java 10 have improved support for >> docker container ( > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8146115&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=pYU9iHBTE76q-M9IZrQkWIq_LZnocNRTSH1_bJFCGLQ&e= > ), I >> decided to do some measurements using that build. >> I got the build OpenJDK build jdk-10-ea+40 from > https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_10_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=_bL50Git2eGTEuWiDNdtvjIXdgc7499XiPL7JFilAxA&e= > . >> This build by default has container support enabled. >> The system I used has 32 CPUs including 2 hyperthreads per core. I > turned >> off hyperthreading for this experiment. That leaves me with 16 cores on > 2 >> sockets: 0-7 on 1 socket and 8-15 on 2nd socket. >> System details are: >> >> # lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 16.04.2 LTS >> Release: 16.04 >> Codename: xenial >> >> # uname -r >> 4.4.0-103-generic >> >> For measurements I used AcmeAir benchmark at >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sabkrish_acmeair_tree_microservice-5Fchanges&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=bkcFfs-e2YzGHlWabfwKyipPqlqDOWXrW6W5-ns1EP8&e= > . >> I ran the AcmeAir benchmark with the said build for following cases: >> >> 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. > Lets >> call this 4CPU at 100. >> This used following JVM settings: >> CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 >> >> 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% > >> quota. Lets call this 8CPU at 50. >> In this case container support was enabled by default and it used >> following JVM settings: >> CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 >> >> 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with >> -XX:-UseContainerSupport option to disable container support. Lets call >> this 8CPU at 50NoCS. >> This used following JVM settings: >> CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 >> >> Load on the server was applied using JMeter which was running on same > box >> but bound to 0-8 CPUs. I applied the load for few minutes to warm up the > >> JVM before starting the final "measure" run. >> Throughput reported below is for the final "measure" run. All numbers >> reported below are an average of 10 iterations. >> >> Throughput result: >> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >> 9621.5 | 6970.6 | 7252.1 >> >> I also measured Total compilation time (in seconds) and Total pause time > >> (in seconds) for the duration of the server (which includes warm up >> phase): >> >> Compilation time: >> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >> 79.8545 | 76.7041 | 100.085 >> >> GC Pasue time: >> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >> 1.829 | 1.886 | 1.927 >> >> I am quite surprised to see the drop in throughput between 4Cpu100Quota >> and 8Cpu50Quota case. >> Looking deeper into the results, I do notice that numbers for > 8Cpu50Quota >> case were not very consistent, but in general I can say they are not >> matching 4Cpu100Quota case. >> I will be doing additional runs for this setup (and on different > OS/kernel >> version) and increase warm up time for the JVM to see if that improves > the >> consistency. >> >> Meanwhile, couple of questions I wanted to put forward: >> 1) Has anyone else noticed this kind of difference in Java >> application/JVM performance when CPU quota is used? >> 2) What other open-source benchmarks are available that I can use to >> verify the behavior I am observing? >> >> Any comments/feedback are welcome. >> >> Thanks, >> Ashutosh Mehra >> > > > > > From david.holmes at oracle.com Tue Feb 6 09:44:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 19:44:59 +1000 Subject: JDK submit repo In-Reply-To: References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <20180130073502.342307114@eggemoggin.niobe.net> Message-ID: Hi Yumin, On 6/02/2018 4:32 PM, yumin qi wrote: > Hi, Mark > > I pushed with an error returned: > > $ hg tip > changeset: 48771:b458b2ad109d > branch: JDK-8194154 > tag: tip > parent: 48767:4d716bc7ed54 > user: Yumin.Qi > date: Mon Feb 05 22:23:38 2018 -0800 > summary: 8194154: JDK crashes on canonicalization of parsing path > string contains '//' on linux. > > $hg push --new-branch > pushing to http://hg.openjdk.java.net/jdk/submit > searching for changes > abort: HTTP Error 403: Forbidden > > I am not sure if I have done correctly. Can you help what is wrong here? I > am a commiter, but could not do the push to 'submit'. You need to push using ssh not http. If you have the defpath extension: hg defpath -du David > Thanks > Yumin > > On Tue, Jan 30, 2018 at 7:35 AM, wrote: > >> 2018/1/30 2:50:45 -0800, Aleksey Shipilev : >>> So I have submitted JDK-8174901 five days ago, and there was silence >>> since then. Is *this* the kinds of thing to ask at ops@? >> >> Yes. >> >> - Mark >> From asmehra1 at in.ibm.com Tue Feb 6 10:13:00 2018 From: asmehra1 at in.ibm.com (Ashutosh Mehra1) Date: Tue, 6 Feb 2018 15:43:00 +0530 Subject: Effect of setting CPU quota on Java performance In-Reply-To: <049D6283-A4B5-40A6-981D-D311B937A187@oracle.com> References: <04674F3C-0720-46EB-8F6F-F79BAC1FEF6A@oracle.com> <049D6283-A4B5-40A6-981D-D311B937A187@oracle.com> Message-ID: > Just curious, what would be the use case for running on more cores with less CPU quota per core? > Are you trying to find out ?can I maintain the same level of performance with lower power usage by plugging in more cores?? > Or put it another way ?can I buy power with cores?? > I think that would be great, as that would mean your investment in the extra core can eventually be paid back by power savings. Well, my experiment is only to see if CPU quota, which is used quite extensively in kubernetes and docker environments, has any impact on performance of applications (especially JVM based). So, earlier if some one is running their app on 4 CPU system decides to deploy their app in kubernetes-docker environment which uses cpu quota to provide the requested "effective" CPUs, then what kind of performance issues can arise. The fact that the performance issue I encountered has its roots in kernel CPU frequency governor for power saving is just plain luck! (or should I say bad luck!) Another (long term) aim of this exercise is to understand how the JVM is performing in docker container, and if there is any scope of improvement there. As part of that, I am checking the impact of CPU quota on various aspects of JVM. GC pause time and JIT compilation time are two such quantities that I am currently measuring when running AcmeAir benchmark. Ashutosh From: Ioi Lam To: Ashutosh Mehra1 Cc: jdk-dev at openjdk.java.net, Dinakar Guniguntala Date: 02/06/2018 02:44 PM Subject: Re: Effect of setting CPU quota on Java performance Just curious, what would be the use case for running on more cores with less CPU quota per core? Are you trying to find out ?can I maintain the same level of performance with lower power usage by plugging in more cores?? Or put it another way ?can I buy power with cores?? I think that would be great, as that would mean your investment in the extra core can eventually be paid back by power savings. Ioi On Feb 6, 2018, at 2:43 PM, Ashutosh Mehra1 wrote: >> As a control test, maybe you can run a simple multi-threaded C benchmark > with the same settings? > > Thats a good point. I have also been testing with a simple multi-threaded > C program for past few days, and I observed similar difference in > performance between 4CPU at 100 and 8CPU at 50. > In fact I asked this question based on that multi-threaded C program here > https://urldefense.proofpoint.com/v2/url?u=https-3A__unix.stackexchange.com_questions_417506_what-2Dis-2Dthe-2Deffect-2Dof-2Dsetting-2Dcpu-2Dcpu-2Dquota-2Dus-2Din-2Dcpu-2Dcgroup&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=EoWnPxdBJetX_MYOuYzlqw_1dBePJ6X_jq9FyiwhTYg&s=pGc13T8qxYnbuyDanEF0tT7DuuzVgGtiwvZ55oB-o2A&e= > but didn't get any response. > > Yesterday, while testing with that C program we noticed CPU frequency for > 4CPU at 100 case was close to maximum, but in case of 8CPU at 50, it was way > below that. > On further examination we found the system was using "powersave" as the > kernel governor for CPU frequency. > For a quick overview of different kernel governors for CPU frequency see > this: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_doc_Documentation_cpu-2Dfreq_governors.txt&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=EoWnPxdBJetX_MYOuYzlqw_1dBePJ6X_jq9FyiwhTYg&s=7j2vI3sWYhJtMXE3T_Twbsggvc84INFKKuPm2Axgq3w&e= > When we changed the kernel governor to "performance", we were able to see > much better performance with 8CPU at 50 which was very close to 4CPU at 100. > > I am going to repeat my experiment with AcmeAir benchmark using > "performance" kernel governor. > I expect this should help in bridging the throughput gap I noticed in my > earlier experiment. > > - Ashutosh > > > > From: Ioi Lam > To: Ashutosh Mehra1 > Cc: jdk-dev at openjdk.java.net, Dinakar Guniguntala > > Date: 02/05/2018 11:47 PM > Subject: Re: Effect of setting CPU quota on Java performance > > > > As a control test, maybe you can run a simple multi-threaded C benchmark > with the same settings? > >> On Feb 5, 2018, at 1:48 PM, Ashutosh Mehra1 wrote: >> >> I have been trying to understand if setting CPU quota limit on a docker >> container, provided the "effective" CPUs are the same, has any impact on > >> the application performance. >> As an example, if my app is running on 4 CPUs @ 100% quota, would I get >> same performance if my app is running on 8 CPUs at 50% quota? Note that >> "effective" CPUs is 4 in both cases. >> >> Since OpenJDK early access builds for Java 10 have improved support for >> docker container ( > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8146115&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=pYU9iHBTE76q-M9IZrQkWIq_LZnocNRTSH1_bJFCGLQ&e= > ), I >> decided to do some measurements using that build. >> I got the build OpenJDK build jdk-10-ea+40 from > https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_10_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=_bL50Git2eGTEuWiDNdtvjIXdgc7499XiPL7JFilAxA&e= > . >> This build by default has container support enabled. >> The system I used has 32 CPUs including 2 hyperthreads per core. I > turned >> off hyperthreading for this experiment. That leaves me with 16 cores on > 2 >> sockets: 0-7 on 1 socket and 8-15 on 2nd socket. >> System details are: >> >> # lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 16.04.2 LTS >> Release: 16.04 >> Codename: xenial >> >> # uname -r >> 4.4.0-103-generic >> >> For measurements I used AcmeAir benchmark at >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sabkrish_acmeair_tree_microservice-5Fchanges&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=bkcFfs-e2YzGHlWabfwKyipPqlqDOWXrW6W5-ns1EP8&e= > . >> I ran the AcmeAir benchmark with the said build for following cases: >> >> 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. > Lets >> call this 4CPU at 100. >> This used following JVM settings: >> CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 >> >> 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% > >> quota. Lets call this 8CPU at 50. >> In this case container support was enabled by default and it used >> following JVM settings: >> CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 >> >> 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with >> -XX:-UseContainerSupport option to disable container support. Lets call >> this 8CPU at 50NoCS. >> This used following JVM settings: >> CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 >> >> Load on the server was applied using JMeter which was running on same > box >> but bound to 0-8 CPUs. I applied the load for few minutes to warm up the > >> JVM before starting the final "measure" run. >> Throughput reported below is for the final "measure" run. All numbers >> reported below are an average of 10 iterations. >> >> Throughput result: >> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >> 9621.5 | 6970.6 | 7252.1 >> >> I also measured Total compilation time (in seconds) and Total pause time > >> (in seconds) for the duration of the server (which includes warm up >> phase): >> >> Compilation time: >> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >> 79.8545 | 76.7041 | 100.085 >> >> GC Pasue time: >> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >> 1.829 | 1.886 | 1.927 >> >> I am quite surprised to see the drop in throughput between 4Cpu100Quota >> and 8Cpu50Quota case. >> Looking deeper into the results, I do notice that numbers for > 8Cpu50Quota >> case were not very consistent, but in general I can say they are not >> matching 4Cpu100Quota case. >> I will be doing additional runs for this setup (and on different > OS/kernel >> version) and increase warm up time for the JVM to see if that improves > the >> consistency. >> >> Meanwhile, couple of questions I wanted to put forward: >> 1) Has anyone else noticed this kind of difference in Java >> application/JVM performance when CPU quota is used? >> 2) What other open-source benchmarks are available that I can use to >> verify the behavior I am observing? >> >> Any comments/feedback are welcome. >> >> Thanks, >> Ashutosh Mehra >> > > > > > From aph at redhat.com Tue Feb 6 10:50:07 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Feb 2018 10:50:07 +0000 Subject: hg clone is unbelievably slow Message-ID: Half an hour or more here. AFAIK the problem is due to the inefficiency of Mercurial itself and the hg protocol. Aleksey Shipilev has done an experiment whereby trees are regularly cloned and compressed tarballs created; these can be downloaded in a couple of minutes. But really we don't want to depend on the largesse of one developer: if we could download the OpenJDK trees directly by means of wget (or something similar) we would reduce the load on the servers and reduce the time taken to download as well. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ashipile at redhat.com Tue Feb 6 11:05:05 2018 From: ashipile at redhat.com (Aleksey Shipilev) Date: Tue, 6 Feb 2018 12:05:05 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: Message-ID: <18a0a85d-e70a-9bb7-a6e2-f67720f3be48@redhat.com> On 02/06/2018 11:50 AM, Andrew Haley wrote: > Half an hour or more here. AFAIK the problem is due to the > inefficiency of Mercurial itself and the hg protocol. The compounding factors are: - hg.openjdk.java.net is too far from Europe, and bandwidth-delay-product kills TCP performance with regular-sized buffers (which have to be tuned on both client and server side). It was partially alleviated by forests where you had several concurrent hg clones (hotspot, jdk, ...) at the same time; - the Jigsaw and monorepo file moves inflated the repository size dramatically. See https://builds.shipilev.net/workspaces/: 8u is 240 MB compressed, 9 is 420 MB compressed, 10 is 760 MB compressed! > Aleksey Shipilev has done an experiment whereby trees are regularly > cloned and compressed tarballs created; these can be downloaded in a > couple of minutes. But really we don't want to depend on the largesse > of one developer: if we could download the OpenJDK trees directly by > means of wget (or something similar) we would reduce the load on the > servers and reduce the time taken to download as well. I second that. Also, we can do Mercurial and compressing tricks to make the compressed archive easier to download. Happy to share the script that makes the densest .tar.xz without going full-crazy (maybe other simple tricks missing?): function repack-jdk8 { URL=$1 NAME=$2 if [ ! -d $NAME ]; then hg clone $URL $NAME fi cd $NAME hg pull hg update HGFOREST_GLOBALOPTS=" --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1" sh common/bin/hgforest.sh clone sh common/bin/hgforest.sh pull sh common/bin/hgforest.sh update null hg update null cd .. # Cluster similar files together find $NAME/ -type f | awk -F '/' '{ print $(NF-2) " " $(NF-1) " " $(NF) " " $L; }' | sort | awk '{ print $4; }' > list.txt tar -T list.txt -c -f - | xz -6 > $NAME.tar.xz rsync $NAME.tar.xz builds at builds.shipilev.net:~/wwwroot/workspaces/ } function repack-jdk10 { URL=$1 NAME=$2 if [ ! -d $NAME ]; then hg --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1 clone $URL $NAME fi cd $NAME hg pull hg update null cd .. # Cluster similar files together find $NAME/ -type f | awk -F '/' '{ print $(NF-2) " " $(NF-1) " " $(NF) " " $L; }' | sort | awk '{ print $4; }' > list.txt tar -T list.txt -c -f - | xz -6 > $NAME.tar.xz rsync $NAME.tar.xz builds at builds.shipilev.net:~/wwwroot/workspaces/ } repack-jdk8 http://hg.openjdk.java.net/jdk8u/jdk8u/ jdk8u-jdk8u repack-jdk10 http://hg.openjdk.java.net/jdk/jdk jdk-jdk -Aleksey From dalibor.topic at oracle.com Tue Feb 6 11:21:11 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 12:21:11 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: Message-ID: <9ae8835c-c291-1d26-77c2-f0bfe7aa3d14@oracle.com> On 06.02.2018 11:50, Andrew Haley wrote: > couple of minutes. But really we don't want to depend on the largesse > of one developer: if we could download the OpenJDK trees directly by > means of wget (or something similar) we would reduce the load on the > servers and reduce the time taken to download as well. Fwiw, wget http://hg.openjdk.java.net/jdk/jdk/archive/tip.tar.bz2 takes just a few minutes. If all you need is the latest tip, then that's preferable to and much faster than cloning the full tree. But since it lacks the history, you can't pull 'further' from that archive. 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 aph at redhat.com Tue Feb 6 13:24:50 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Feb 2018 13:24:50 +0000 Subject: hg clone is unbelievably slow In-Reply-To: <9ae8835c-c291-1d26-77c2-f0bfe7aa3d14@oracle.com> References: <9ae8835c-c291-1d26-77c2-f0bfe7aa3d14@oracle.com> Message-ID: On 06/02/18 11:21, dalibor topic wrote: > Fwiw, wget http://hg.openjdk.java.net/jdk/jdk/archive/tip.tar.bz2 takes > just a few minutes. > > If all you need is the latest tip, then that's preferable to and much > faster than cloning the full tree. But since it lacks the history, you > can't pull 'further' from that archive. Well, quite, so it's no use to devs. If, on the other hand, it did have the full history, that would be a major win. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.lloyd at redhat.com Tue Feb 6 13:43:22 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 6 Feb 2018 07:43:22 -0600 Subject: hg clone is unbelievably slow In-Reply-To: References: <9ae8835c-c291-1d26-77c2-f0bfe7aa3d14@oracle.com> Message-ID: In some cases it might suffice to use my git mirror at https://github.com/dmlloyd/openjdk which seems somewhat faster. The "divided" trees (Java 9 and earlier) are not very up to date and a bit "hacky" but the consolidated trees (Java 10 and later) are up to date (with an automated job) and quite accurate. On Tue, Feb 6, 2018 at 7:24 AM, Andrew Haley wrote: > On 06/02/18 11:21, dalibor topic wrote: > > Fwiw, wget http://hg.openjdk.java.net/jdk/jdk/archive/tip.tar.bz2 takes > > just a few minutes. > > > > If all you need is the latest tip, then that's preferable to and much > > faster than cloning the full tree. But since it lacks the history, you > > can't pull 'further' from that archive. > > Well, quite, so it's no use to devs. If, on the other hand, it > did have the full history, that would be a major win. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -- - DML From forax at univ-mlv.fr Tue Feb 6 14:04:44 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 6 Feb 2018 15:04:44 +0100 (CET) Subject: hg clone is unbelievably slow In-Reply-To: References: Message-ID: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> +1 creating a tgz at each commit doesn't seems that difficult ... R?mi ----- Mail original ----- > De: "Andrew Haley" > ?: "jdk-dev" > Envoy?: Mardi 6 F?vrier 2018 11:50:07 > Objet: hg clone is unbelievably slow > Half an hour or more here. AFAIK the problem is due to the > inefficiency of Mercurial itself and the hg protocol. > > Aleksey Shipilev has done an experiment whereby trees are regularly > cloned and compressed tarballs created; these can be downloaded in a > couple of minutes. But really we don't want to depend on the largesse > of one developer: if we could download the OpenJDK trees directly by > means of wget (or something similar) we would reduce the load on the > servers and reduce the time taken to download as well. > > -- > 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 Feb 6 14:09:59 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Feb 2018 14:09:59 +0000 Subject: hg clone is unbelievably slow In-Reply-To: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: <31c89137-d327-d36a-639f-5f6c6da7188d@redhat.com> On 06/02/18 14:04, Remi Forax wrote: > creating a tgz at each commit doesn't seems that difficult ... Once a week would be fine: it only takes a moment to do "hg pull". -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens.limasoftware at gmail.com Tue Feb 6 14:10:59 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 6 Feb 2018 15:10:59 +0100 Subject: hg clone is unbelievably slow In-Reply-To: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: I think it should probably be done on demand, it may be more expensive to keep a commit based tgz otherwise. In fact the most awesome thing would be to have a special repository that we clone but gives us back only the tgz to unpack locally, with all the history and correct hg paths. Cheers, Mario 2018-02-06 15:04 GMT+01:00 Remi Forax : > +1 > > creating a tgz at each commit doesn't seems that difficult ... > > R?mi > > ----- Mail original ----- >> De: "Andrew Haley" >> ?: "jdk-dev" >> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >> Objet: hg clone is unbelievably slow > >> Half an hour or more here. AFAIK the problem is due to the >> inefficiency of Mercurial itself and the hg protocol. >> >> Aleksey Shipilev has done an experiment whereby trees are regularly >> cloned and compressed tarballs created; these can be downloaded in a >> couple of minutes. But really we don't want to depend on the largesse >> of one developer: if we could download the OpenJDK trees directly by >> means of wget (or something similar) we would reduce the load on the >> servers and reduce the time taken to download as well. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- 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 thomas.stuefe at gmail.com Tue Feb 6 14:35:10 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Feb 2018 15:35:10 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: Side question, we would only need to tar the .hg folder, no? And revive the workspace with hg update? On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre wrote: > I think it should probably be done on demand, it may be more expensive > to keep a commit based tgz otherwise. > > In fact the most awesome thing would be to have a special repository > that we clone but gives us back only the tgz to unpack locally, with > all the history and correct hg paths. > > Cheers, > Mario > > 2018-02-06 15:04 GMT+01:00 Remi Forax : > > +1 > > > > creating a tgz at each commit doesn't seems that difficult ... > > > > R?mi > > > > ----- Mail original ----- > >> De: "Andrew Haley" > >> ?: "jdk-dev" > >> Envoy?: Mardi 6 F?vrier 2018 11:50:07 > >> Objet: hg clone is unbelievably slow > > > >> Half an hour or more here. AFAIK the problem is due to the > >> inefficiency of Mercurial itself and the hg protocol. > >> > >> Aleksey Shipilev has done an experiment whereby trees are regularly > >> cloned and compressed tarballs created; these can be downloaded in a > >> couple of minutes. But really we don't want to depend on the largesse > >> of one developer: if we could download the OpenJDK trees directly by > >> means of wget (or something similar) we would reduce the load on the > >> servers and reduce the time taken to download as well. > >> > >> -- > >> Andrew Haley > >> Java Platform Lead Engineer > >> Red Hat UK Ltd. > >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > -- > 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 neugens.limasoftware at gmail.com Tue Feb 6 14:42:24 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 6 Feb 2018 15:42:24 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: I think it should be a fully functional mercurial repository once is unpacked. What I have in mind is something that support this workflow (or similar): $ hg clone -r 12345 http://hg.openjdk.java.net/jdk10/client-gz $ tar xvfz client-gz.tgz && cd client-gz (do whatever, then some time later) $ hg log || hg pull -u || commit etc... This should be just a few lines of scripting away. Cheers, Mario 2018-02-06 15:35 GMT+01:00 Thomas St?fe : > Side question, we would only need to tar the .hg folder, no? And revive the > workspace with hg update? > > On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre > wrote: >> >> I think it should probably be done on demand, it may be more expensive >> to keep a commit based tgz otherwise. >> >> In fact the most awesome thing would be to have a special repository >> that we clone but gives us back only the tgz to unpack locally, with >> all the history and correct hg paths. >> >> Cheers, >> Mario >> >> 2018-02-06 15:04 GMT+01:00 Remi Forax : >> > +1 >> > >> > creating a tgz at each commit doesn't seems that difficult ... >> > >> > R?mi >> > >> > ----- Mail original ----- >> >> De: "Andrew Haley" >> >> ?: "jdk-dev" >> >> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >> >> Objet: hg clone is unbelievably slow >> > >> >> Half an hour or more here. AFAIK the problem is due to the >> >> inefficiency of Mercurial itself and the hg protocol. >> >> >> >> Aleksey Shipilev has done an experiment whereby trees are regularly >> >> cloned and compressed tarballs created; these can be downloaded in a >> >> couple of minutes. But really we don't want to depend on the largesse >> >> of one developer: if we could download the OpenJDK trees directly by >> >> means of wget (or something similar) we would reduce the load on the >> >> servers and reduce the time taken to download as well. >> >> >> >> -- >> >> Andrew Haley >> >> Java Platform Lead Engineer >> >> Red Hat UK Ltd. >> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> >> >> -- >> 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/ > > -- 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 ioi.lam at oracle.com Tue Feb 6 15:00:44 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 6 Feb 2018 23:00:44 +0800 Subject: hg clone is unbelievably slow In-Reply-To: <18a0a85d-e70a-9bb7-a6e2-f67720f3be48@redhat.com> References: <18a0a85d-e70a-9bb7-a6e2-f67720f3be48@redhat.com> Message-ID: I used to have a nightly script that syncs and zips up the entire content of the .hg files. Then if I want to clone a new repo, I would just unzip the .hg files, and run hg update -c. All that just takes just a few seconds on SSD. Then just hg pull -u to download the changes in the past day. You will have a fresh repo in less than a minute. Ioi > On Feb 6, 2018, at 7:05 PM, Aleksey Shipilev wrote: > >> On 02/06/2018 11:50 AM, Andrew Haley wrote: >> Half an hour or more here. AFAIK the problem is due to the >> inefficiency of Mercurial itself and the hg protocol. > > The compounding factors are: > - hg.openjdk.java.net is too far from Europe, and bandwidth-delay-product kills TCP performance > with regular-sized buffers (which have to be tuned on both client and server side). It was partially > alleviated by forests where you had several concurrent hg clones (hotspot, jdk, ...) at the same time; > - the Jigsaw and monorepo file moves inflated the repository size dramatically. See > https://builds.shipilev.net/workspaces/: 8u is 240 MB compressed, 9 is 420 MB compressed, 10 is 760 > MB compressed! > >> Aleksey Shipilev has done an experiment whereby trees are regularly >> cloned and compressed tarballs created; these can be downloaded in a >> couple of minutes. But really we don't want to depend on the largesse >> of one developer: if we could download the OpenJDK trees directly by >> means of wget (or something similar) we would reduce the load on the >> servers and reduce the time taken to download as well. > > I second that. Also, we can do Mercurial and compressing tricks to make the compressed archive > easier to download. Happy to share the script that makes the densest .tar.xz without going > full-crazy (maybe other simple tricks missing?): > > function repack-jdk8 { > URL=$1 > NAME=$2 > if [ ! -d $NAME ]; then > hg clone $URL $NAME > fi > cd $NAME > hg pull > hg update > HGFOREST_GLOBALOPTS=" --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1" sh > common/bin/hgforest.sh clone > sh common/bin/hgforest.sh pull > sh common/bin/hgforest.sh update null > hg update null > cd .. > > # Cluster similar files together > find $NAME/ -type f | awk -F '/' '{ print $(NF-2) " " $(NF-1) " " $(NF) " " $L; }' | sort | awk > '{ print $4; }' > list.txt > tar -T list.txt -c -f - | xz -6 > $NAME.tar.xz > > rsync $NAME.tar.xz builds at builds.shipilev.net:~/wwwroot/workspaces/ > } > > function repack-jdk10 { > URL=$1 > NAME=$2 > if [ ! -d $NAME ]; then > hg --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1 clone $URL $NAME > fi > cd $NAME > hg pull > hg update null > cd .. > > # Cluster similar files together > find $NAME/ -type f | awk -F '/' '{ print $(NF-2) " " $(NF-1) " " $(NF) " " $L; }' | sort | awk > '{ print $4; }' > list.txt > > tar -T list.txt -c -f - | xz -6 > $NAME.tar.xz > rsync $NAME.tar.xz builds at builds.shipilev.net:~/wwwroot/workspaces/ > } > > repack-jdk8 http://hg.openjdk.java.net/jdk8u/jdk8u/ jdk8u-jdk8u > repack-jdk10 http://hg.openjdk.java.net/jdk/jdk jdk-jdk > > -Aleksey > From aph at redhat.com Tue Feb 6 15:01:49 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Feb 2018 15:01:49 +0000 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: On 06/02/18 14:35, Thomas St?fe wrote: > Side question, we would only need to tar the .hg folder, no? And revive the > workspace with hg update? The Hg repository in the tarball does not itself need to be checked out, that is true. All we need is the history and metadata. -- 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 Feb 6 15:04:40 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Feb 2018 15:04:40 +0000 Subject: hg clone is unbelievably slow In-Reply-To: References: <18a0a85d-e70a-9bb7-a6e2-f67720f3be48@redhat.com> Message-ID: <5213c258-b3c3-d8be-035b-06ebf2935e16@redhat.com> On 06/02/18 15:00, Ioi Lam wrote: > I used to have a nightly script that syncs and zips up the entire > content of the .hg files. Then if I want to clone a new repo, I > would just unzip the .hg files, and run hg update -c. All that just > takes just a few seconds on SSD. Then just hg pull -u to download > the changes in the past day. You will have a fresh repo in less than > a minute. Exactly. I'm proposing that we share that work so that newcomers to projects can just download the repositories. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.helin at oracle.com Tue Feb 6 15:04:10 2018 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 6 Feb 2018 16:04:10 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: There is no need to re-invent the wheel :) Mercurial (hg) has had support for clonebundles for a some time by now, see [0] for details. If the servers where configured to use clonebundles then users can continue to just use `hg clone` but get the performance of downloading compressed bundles. clonebundles can be stored on various CDN servers, then `hg clone` will download the closest bundle, unpack it and eventually do `hg pull --update` to get the latest commits (that might not be present in the bundle). For more information about clonebundles, just run `hg help -e clonebundles`. Thanks, Erik [0]: https://www.mercurial-scm.org/wiki/ClonebundlesExtension On 02/06/2018 03:42 PM, Mario Torre wrote: > I think it should be a fully functional mercurial repository once is unpacked. > > What I have in mind is something that support this workflow (or similar): > > $ hg clone -r 12345 http://hg.openjdk.java.net/jdk10/client-gz > $ tar xvfz client-gz.tgz && cd client-gz > (do whatever, then some time later) > $ hg log || hg pull -u || commit etc... > > This should be just a few lines of scripting away. > > Cheers, > Mario > > > > 2018-02-06 15:35 GMT+01:00 Thomas St?fe : >> Side question, we would only need to tar the .hg folder, no? And revive the >> workspace with hg update? >> >> On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre >> wrote: >>> >>> I think it should probably be done on demand, it may be more expensive >>> to keep a commit based tgz otherwise. >>> >>> In fact the most awesome thing would be to have a special repository >>> that we clone but gives us back only the tgz to unpack locally, with >>> all the history and correct hg paths. >>> >>> Cheers, >>> Mario >>> >>> 2018-02-06 15:04 GMT+01:00 Remi Forax : >>>> +1 >>>> >>>> creating a tgz at each commit doesn't seems that difficult ... >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Andrew Haley" >>>>> ?: "jdk-dev" >>>>> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >>>>> Objet: hg clone is unbelievably slow >>>> >>>>> Half an hour or more here. AFAIK the problem is due to the >>>>> inefficiency of Mercurial itself and the hg protocol. >>>>> >>>>> Aleksey Shipilev has done an experiment whereby trees are regularly >>>>> cloned and compressed tarballs created; these can be downloaded in a >>>>> couple of minutes. But really we don't want to depend on the largesse >>>>> of one developer: if we could download the OpenJDK trees directly by >>>>> means of wget (or something similar) we would reduce the load on the >>>>> servers and reduce the time taken to download as well. >>>>> >>>>> -- >>>>> Andrew Haley >>>>> Java Platform Lead Engineer >>>>> Red Hat UK Ltd. >>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> >>> >>> >>> -- >>> 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 weijun.wang at oracle.com Tue Feb 6 15:05:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Feb 2018 23:05:17 +0800 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: <3A01F9B8-5868-448F-BACF-2B1EAC9DEB83@oracle.com> I haven't used it but looks like "hg bundle" is prefect for this purpose. > On Feb 6, 2018, at 10:42 PM, Mario Torre wrote: > > I think it should be a fully functional mercurial repository once is unpacked. > > What I have in mind is something that support this workflow (or similar): > > $ hg clone -r 12345 http://hg.openjdk.java.net/jdk10/client-gz > $ tar xvfz client-gz.tgz && cd client-gz > (do whatever, then some time later) > $ hg log || hg pull -u || commit etc... > > This should be just a few lines of scripting away. > > Cheers, > Mario > > > > 2018-02-06 15:35 GMT+01:00 Thomas St?fe : >> Side question, we would only need to tar the .hg folder, no? And revive the >> workspace with hg update? >> >> On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre >> wrote: >>> >>> I think it should probably be done on demand, it may be more expensive >>> to keep a commit based tgz otherwise. >>> >>> In fact the most awesome thing would be to have a special repository >>> that we clone but gives us back only the tgz to unpack locally, with >>> all the history and correct hg paths. >>> >>> Cheers, >>> Mario >>> >>> 2018-02-06 15:04 GMT+01:00 Remi Forax : >>>> +1 >>>> >>>> creating a tgz at each commit doesn't seems that difficult ... >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Andrew Haley" >>>>> ?: "jdk-dev" >>>>> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >>>>> Objet: hg clone is unbelievably slow >>>> >>>>> Half an hour or more here. AFAIK the problem is due to the >>>>> inefficiency of Mercurial itself and the hg protocol. >>>>> >>>>> Aleksey Shipilev has done an experiment whereby trees are regularly >>>>> cloned and compressed tarballs created; these can be downloaded in a >>>>> couple of minutes. But really we don't want to depend on the largesse >>>>> of one developer: if we could download the OpenJDK trees directly by >>>>> means of wget (or something similar) we would reduce the load on the >>>>> servers and reduce the time taken to download as well. >>>>> >>>>> -- >>>>> Andrew Haley >>>>> Java Platform Lead Engineer >>>>> Red Hat UK Ltd. >>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> >>> >>> >>> -- >>> 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/ >> >> > > > > -- > 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 neugens.limasoftware at gmail.com Tue Feb 6 15:18:42 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 6 Feb 2018 16:18:42 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: Nice, I didn't know about that extension, but seems exactly what we are searching for. What would it take to add this support to the repos? From the linked documentation I understand this is transparent for clients, so we should see immediate improvements just by enabling it on the servers. Cheers, Mario 2018-02-06 16:04 GMT+01:00 Erik Helin : > There is no need to re-invent the wheel :) > > Mercurial (hg) has had support for clonebundles for a some time by now, see > [0] for details. If the servers where configured to use clonebundles then > users can continue to just use `hg clone` but get the performance of > downloading compressed bundles. clonebundles can be stored on various CDN > servers, then `hg clone` will download the closest bundle, unpack it and > eventually do `hg pull --update` to get the latest commits (that might not > be present in the bundle). > > For more information about clonebundles, just run > `hg help -e clonebundles`. > > Thanks, > Erik > > [0]: https://www.mercurial-scm.org/wiki/ClonebundlesExtension > > > On 02/06/2018 03:42 PM, Mario Torre wrote: >> >> I think it should be a fully functional mercurial repository once is >> unpacked. >> >> What I have in mind is something that support this workflow (or similar): >> >> $ hg clone -r 12345 http://hg.openjdk.java.net/jdk10/client-gz >> $ tar xvfz client-gz.tgz && cd client-gz >> (do whatever, then some time later) >> $ hg log || hg pull -u || commit etc... >> >> This should be just a few lines of scripting away. >> >> Cheers, >> Mario >> >> >> >> 2018-02-06 15:35 GMT+01:00 Thomas St?fe : >>> >>> Side question, we would only need to tar the .hg folder, no? And revive >>> the >>> workspace with hg update? >>> >>> On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre >>> >>> wrote: >>>> >>>> >>>> I think it should probably be done on demand, it may be more expensive >>>> to keep a commit based tgz otherwise. >>>> >>>> In fact the most awesome thing would be to have a special repository >>>> that we clone but gives us back only the tgz to unpack locally, with >>>> all the history and correct hg paths. >>>> >>>> Cheers, >>>> Mario >>>> >>>> 2018-02-06 15:04 GMT+01:00 Remi Forax : >>>>> >>>>> +1 >>>>> >>>>> creating a tgz at each commit doesn't seems that difficult ... >>>>> >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> >>>>>> De: "Andrew Haley" >>>>>> ?: "jdk-dev" >>>>>> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >>>>>> Objet: hg clone is unbelievably slow >>>>> >>>>> >>>>>> Half an hour or more here. AFAIK the problem is due to the >>>>>> inefficiency of Mercurial itself and the hg protocol. >>>>>> >>>>>> Aleksey Shipilev has done an experiment whereby trees are regularly >>>>>> cloned and compressed tarballs created; these can be downloaded in a >>>>>> couple of minutes. But really we don't want to depend on the largesse >>>>>> of one developer: if we could download the OpenJDK trees directly by >>>>>> means of wget (or something similar) we would reduce the load on the >>>>>> servers and reduce the time taken to download as well. >>>>>> >>>>>> -- >>>>>> Andrew Haley >>>>>> Java Platform Lead Engineer >>>>>> Red Hat UK Ltd. >>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>> >>>> >>>> >>>> >>>> -- >>>> 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/ >>> >>> >>> >> >> >> > -- 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 erik.helin at oracle.com Tue Feb 6 15:58:22 2018 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 6 Feb 2018 16:58:22 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> Message-ID: <19ac1b97-6f87-b601-8f4b-5cd0d11ad2fa@oracle.com> On 02/06/2018 04:18 PM, Mario Torre wrote: > Nice, I didn't know about that extension, but seems exactly what we > are searching for. Yep, it fits this use case perfectly. > What would it take to add this support to the repos? The clonebundles has to be created periodically (via a cron job, Jenkins job or manually), stored somewhere (storing one clonebundle per repository would be sufficient IMO) and the server-side configuration must be updated (see the documentation for details about that). As for who can do that, I would ask ops at openjdk.java.net (I'm not part of ops). > From the linked > documentation I understand this is transparent for clients, so we > should see immediate improvements just by enabling it on the servers. Yes, all hg clients that understand clonebundles will use it (and thereby get the performance improvement) and older hg clients will just continue to use the traditional way of cloning. Thanks, Erik > Cheers, > Mario > > 2018-02-06 16:04 GMT+01:00 Erik Helin : >> There is no need to re-invent the wheel :) >> >> Mercurial (hg) has had support for clonebundles for a some time by now, see >> [0] for details. If the servers where configured to use clonebundles then >> users can continue to just use `hg clone` but get the performance of >> downloading compressed bundles. clonebundles can be stored on various CDN >> servers, then `hg clone` will download the closest bundle, unpack it and >> eventually do `hg pull --update` to get the latest commits (that might not >> be present in the bundle). >> >> For more information about clonebundles, just run >> `hg help -e clonebundles`. >> >> Thanks, >> Erik >> >> [0]: https://www.mercurial-scm.org/wiki/ClonebundlesExtension >> >> >> On 02/06/2018 03:42 PM, Mario Torre wrote: >>> >>> I think it should be a fully functional mercurial repository once is >>> unpacked. >>> >>> What I have in mind is something that support this workflow (or similar): >>> >>> $ hg clone -r 12345 http://hg.openjdk.java.net/jdk10/client-gz >>> $ tar xvfz client-gz.tgz && cd client-gz >>> (do whatever, then some time later) >>> $ hg log || hg pull -u || commit etc... >>> >>> This should be just a few lines of scripting away. >>> >>> Cheers, >>> Mario >>> >>> >>> >>> 2018-02-06 15:35 GMT+01:00 Thomas St?fe : >>>> >>>> Side question, we would only need to tar the .hg folder, no? And revive >>>> the >>>> workspace with hg update? >>>> >>>> On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre >>>> >>>> wrote: >>>>> >>>>> >>>>> I think it should probably be done on demand, it may be more expensive >>>>> to keep a commit based tgz otherwise. >>>>> >>>>> In fact the most awesome thing would be to have a special repository >>>>> that we clone but gives us back only the tgz to unpack locally, with >>>>> all the history and correct hg paths. >>>>> >>>>> Cheers, >>>>> Mario >>>>> >>>>> 2018-02-06 15:04 GMT+01:00 Remi Forax : >>>>>> >>>>>> +1 >>>>>> >>>>>> creating a tgz at each commit doesn't seems that difficult ... >>>>>> >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> >>>>>>> De: "Andrew Haley" >>>>>>> ?: "jdk-dev" >>>>>>> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >>>>>>> Objet: hg clone is unbelievably slow >>>>>> >>>>>> >>>>>>> Half an hour or more here. AFAIK the problem is due to the >>>>>>> inefficiency of Mercurial itself and the hg protocol. >>>>>>> >>>>>>> Aleksey Shipilev has done an experiment whereby trees are regularly >>>>>>> cloned and compressed tarballs created; these can be downloaded in a >>>>>>> couple of minutes. But really we don't want to depend on the largesse >>>>>>> of one developer: if we could download the OpenJDK trees directly by >>>>>>> means of wget (or something similar) we would reduce the load on the >>>>>>> servers and reduce the time taken to download as well. >>>>>>> >>>>>>> -- >>>>>>> Andrew Haley >>>>>>> Java Platform Lead Engineer >>>>>>> Red Hat UK Ltd. >>>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 thomas.stuefe at gmail.com Tue Feb 6 16:08:30 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Feb 2018 17:08:30 +0100 Subject: hg clone is unbelievably slow In-Reply-To: <19ac1b97-6f87-b601-8f4b-5cd0d11ad2fa@oracle.com> References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> <19ac1b97-6f87-b601-8f4b-5cd0d11ad2fa@oracle.com> Message-ID: On Tue, Feb 6, 2018 at 4:58 PM, Erik Helin wrote: > On 02/06/2018 04:18 PM, Mario Torre wrote: > >> Nice, I didn't know about that extension, but seems exactly what we >> are searching for. >> > > Yep, it fits this use case perfectly. > > What would it take to add this support to the repos? >> > > The clonebundles has to be created periodically (via a cron job, Jenkins > job or manually), stored somewhere (storing one clonebundle per repository > would be sufficient IMO) and the server-side configuration must be updated > (see the documentation for details about that). > > As for who can do that, I would ask ops at openjdk.java.net (I'm not part of > ops). > > From the linked >> documentation I understand this is transparent for clients, so we >> should see immediate improvements just by enabling it on the servers. >> > > Yes, all hg clients that understand clonebundles will use it (and thereby > get the performance improvement) and older hg clients will just continue to > use the traditional way of cloning. > This sounds neat. Assuming we would not update the cached bundle for every push, so the cached bundle gets outdated, would the client pull the remaining changes from the real repository? ..Thomas > > Thanks, > Erik > > > Cheers, >> Mario >> >> 2018-02-06 16:04 GMT+01:00 Erik Helin : >> >>> There is no need to re-invent the wheel :) >>> >>> Mercurial (hg) has had support for clonebundles for a some time by now, >>> see >>> [0] for details. If the servers where configured to use clonebundles then >>> users can continue to just use `hg clone` but get the performance of >>> downloading compressed bundles. clonebundles can be stored on various CDN >>> servers, then `hg clone` will download the closest bundle, unpack it and >>> eventually do `hg pull --update` to get the latest commits (that might >>> not >>> be present in the bundle). >>> >>> For more information about clonebundles, just run >>> `hg help -e clonebundles`. >>> >>> Thanks, >>> Erik >>> >>> [0]: https://www.mercurial-scm.org/wiki/ClonebundlesExtension >>> >>> >>> On 02/06/2018 03:42 PM, Mario Torre wrote: >>> >>>> >>>> I think it should be a fully functional mercurial repository once is >>>> unpacked. >>>> >>>> What I have in mind is something that support this workflow (or >>>> similar): >>>> >>>> $ hg clone -r 12345 http://hg.openjdk.java.net/jdk10/client-gz >>>> $ tar xvfz client-gz.tgz && cd client-gz >>>> (do whatever, then some time later) >>>> $ hg log || hg pull -u || commit etc... >>>> >>>> This should be just a few lines of scripting away. >>>> >>>> Cheers, >>>> Mario >>>> >>>> >>>> >>>> 2018-02-06 15:35 GMT+01:00 Thomas St?fe : >>>> >>>>> >>>>> Side question, we would only need to tar the .hg folder, no? And revive >>>>> the >>>>> workspace with hg update? >>>>> >>>>> On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre >>>>> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> I think it should probably be done on demand, it may be more expensive >>>>>> to keep a commit based tgz otherwise. >>>>>> >>>>>> In fact the most awesome thing would be to have a special repository >>>>>> that we clone but gives us back only the tgz to unpack locally, with >>>>>> all the history and correct hg paths. >>>>>> >>>>>> Cheers, >>>>>> Mario >>>>>> >>>>>> 2018-02-06 15:04 GMT+01:00 Remi Forax : >>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> creating a tgz at each commit doesn't seems that difficult ... >>>>>>> >>>>>>> R?mi >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>> >>>>>>>> >>>>>>>> De: "Andrew Haley" >>>>>>>> ?: "jdk-dev" >>>>>>>> Envoy?: Mardi 6 F?vrier 2018 11:50:07 >>>>>>>> Objet: hg clone is unbelievably slow >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Half an hour or more here. AFAIK the problem is due to the >>>>>>>> inefficiency of Mercurial itself and the hg protocol. >>>>>>>> >>>>>>>> Aleksey Shipilev has done an experiment whereby trees are regularly >>>>>>>> cloned and compressed tarballs created; these can be downloaded in a >>>>>>>> couple of minutes. But really we don't want to depend on the >>>>>>>> largesse >>>>>>>> of one developer: if we could download the OpenJDK >>>>>>>> trees >>>>>>>> directly by >>>>>>>> means of wget (or something similar) we would reduce the load on the >>>>>>>> servers and reduce the time taken to download as well. >>>>>>>> >>>>>>>> -- >>>>>>>> Andrew Haley >>>>>>>> Java Platform Lead Engineer >>>>>>>> Red Hat UK Ltd. >>>>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 erik.helin at oracle.com Tue Feb 6 16:08:49 2018 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 6 Feb 2018 17:08:49 +0100 Subject: hg clone is unbelievably slow In-Reply-To: References: <1976239279.867533.1517925884791.JavaMail.zimbra@u-pem.fr> <19ac1b97-6f87-b601-8f4b-5cd0d11ad2fa@oracle.com> Message-ID: <764a28dd-eedf-9fc7-b9b7-a99c1c9fee49@oracle.com> On 02/06/2018 05:08 PM, Thomas St?fe wrote > On Tue, Feb 6, 2018 at 4:58 PM, Erik Helin wrote: > On 02/06/2018 04:18 PM, Mario Torre wrote: > From the linked > documentation I understand this is transparent for clients, so we > should see immediate improvements just by enabling it on the > servers. > > > Yes, all hg clients that understand clonebundles will use it (and > thereby get the performance improvement) and older hg clients will > just continue to use the traditional way of cloning. > > > This sounds neat. Assuming we would not update the cached bundle for > every push, so the cached bundle gets outdated, would the client pull > the remaining changes from the real repository? Yep, that is exactly how it works. Thanks, Erik > ..Thomas > > > Thanks, > Erik > > > Cheers, > Mario > > 2018-02-06 16:04 GMT+01:00 Erik Helin >: > > There is no need to re-invent the wheel :) > > Mercurial (hg) has had support for clonebundles for a some > time by now, see > [0] for details. If the servers where configured to use > clonebundles then > users can continue to just use `hg clone` but get the > performance of > downloading compressed bundles. clonebundles can be stored > on various CDN > servers, then `hg clone` will download the closest bundle, > unpack it and > eventually do `hg pull --update` to get the latest commits > (that might not > be present in the bundle). > > For more information about clonebundles, just run > `hg help -e clonebundles`. > > Thanks, > Erik > > [0]: > https://www.mercurial-scm.org/wiki/ClonebundlesExtension > > > > On 02/06/2018 03:42 PM, Mario Torre wrote: > > > I think it should be a fully functional mercurial > repository once is > unpacked. > > What I have in mind is something that support this > workflow (or similar): > > $ hg clone? -r 12345 > http://hg.openjdk.java.net/jdk10/client-gz > > $ tar xvfz client-gz.tgz && cd client-gz > (do whatever, then some time later) > $ hg log || hg pull -u || commit etc... > > This should be just a few lines of scripting away. > > Cheers, > Mario > > > > 2018-02-06 15:35 GMT+01:00 Thomas St?fe > >: > > > Side question, we would only need to tar the .hg > folder, no? And revive > the > workspace with hg update? > > On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre > > > wrote: > > > > I think it should probably be done on demand, it > may be more expensive > to keep a commit based tgz otherwise. > > In fact the most awesome thing would be to have > a special repository > that we clone but gives us back only the tgz to > unpack locally, with > all the history and correct hg paths. > > Cheers, > Mario > > 2018-02-06 15:04 GMT+01:00 Remi Forax > >: > > > +1 > > creating a tgz at each commit doesn't seems > that difficult ... > > R?mi > > ----- Mail original ----- > > > De: "Andrew Haley" > > ?: "jdk-dev" > > Envoy?: Mardi 6 F?vrier 2018 11:50:07 > Objet: hg clone is unbelievably slow > > > > Half an hour or more here.? AFAIK the > problem is due to the > inefficiency of Mercurial itself and the > hg protocol. > > Aleksey Shipilev has done an experiment > whereby trees are regularly > cloned and compressed tarballs created; > these can be downloaded in a > couple of minutes.? But really we don't > want to depend on the largesse > of one developer: if we could download > the OpenJDK > trees > directly by > means of wget (or something similar) we > would reduce the load on the > servers and reduce the time taken to > download as well. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 > 332F A671 > > > > > > -- > 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 volker.simonis at gmail.com Tue Feb 6 16:34:05 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 6 Feb 2018 17:34:05 +0100 Subject: Informational JEP proposed for review: 12: Incubating Language and VM Features In-Reply-To: <20180131170401.5468515E0BC@eggemoggin.niobe.net> References: <20180131170401.5468515E0BC@eggemoggin.niobe.net> Message-ID: Hi, I've already raised my main concerns here: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000603.html and I still think that making "Incubating" features mandatory in the Java SE specification is the wrong way to go. This proposal also touches the JCP Java SE standardization process so I would suggest to synchronize with the JCP EC and the corresponding Expert Groups before implementing it in order to avoid surprises late in the standardization process. Regards, Volker On Wed, Jan 31, 2018 at 6:04 PM, wrote: > This recently-submitted informational JEP has already been discussed > here in draft form. > > 12: Incubating Language and VM Features > http://openjdk.java.net/jeps/12 > > Further comment is invited. If no objections are raised by 23:00 UTC > on Wednesday, 7 February, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll mark this > informational JEP as active. > > (JBS does not (yet) implement the "informational" part of the JEP > workflow, so the issue itself will be in the completed state for > now.) > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From erik.joelsson at oracle.com Tue Feb 6 17:24:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 09:24:15 -0800 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> Message-ID: <8fadd660-fa9e-80bb-ee5b-efbc4945bf2a@oracle.com> Looks good! /Erik On 2018-02-05 17:25, David Holmes wrote: > It's time to increment the actual version to 11 for JDK 11. > > Joe Darcy and I have worked through numerous test issues that delayed > the update and I've been addressing a number of issues in hotspot > related to obsolete/expired flag warnings. I have tested the update > with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI > failures for either JDK or HS pipelines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 > > Change: > > --- a/make/autoconf/version-numbers > +++ b/make/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > ?# Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_FEATURE=10 > +DEFAULT_VERSION_FEATURE=11 > ?DEFAULT_VERSION_INTERIM=0 > ?DEFAULT_VERSION_UPDATE=0 > ?DEFAULT_VERSION_PATCH=0 > > Thanks, > David From brian.goetz at oracle.com Tue Feb 6 17:37:48 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Feb 2018 12:37:48 -0500 Subject: Informational JEP proposed for review: 12: Incubating Language and VM Features In-Reply-To: References: <20180131170401.5468515E0BC@eggemoggin.niobe.net> Message-ID: <046795f9-d7ad-9bad-05d3-e606bb1b4b5c@oracle.com> > This proposal also > touches the JCP Java SE standardization process so I would suggest to > synchronize with the JCP EC and the corresponding Expert Groups before > implementing it in order to avoid surprises late in the > standardization process. > Of course, we can and will discuss this in the SE platform EG.? But, let me just add now: while the JEP talks about the role of the JCP and the SE platform JSR, it does not do so to suggest changes there -- it does so *to affirm that there are not changes* there.? The JEP takes pains to categorize incubating features as being like other features in almost every possible way -- which allows us to build on the existing JCP process for vetting and ratifying the specification, and for conformance.? This is, in fact, one of the motivations for the "not optional" choice -- it means there is a single, complete, well-defined specification for what it means to be Java SE N, so the process by which that specification is drafted and ratified (and implementations tested for conformance) need not change at all. From maurizio.cimadamore at oracle.com Tue Feb 6 17:39:01 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 6 Feb 2018 17:39:01 +0000 Subject: CFV: New JDK Committer: Liam Miller-Cushon Message-ID: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. Liam has been contributing various fixes and improvements to the langtools team over the last few years, and he definitively helped making javac a better place :-) A list of his contributions can be found in [1]. Votes are due by February 14, 2018. Only current JDK Committers [2] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [3]. Thank you, Maurizio Cimadamore [1] - http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 [2] - http://openjdk.java.net/census [3] - http://openjdk.java.net/projects/#committer-vote From vicente.romero at oracle.com Tue Feb 6 17:40:44 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 6 Feb 2018 12:40:44 -0500 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <5bc47e28-0933-d6bc-5655-66b355650e81@oracle.com> vote: yes Vicente On 02/06/2018 12:39 PM, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From joe.darcy at oracle.com Tue Feb 6 17:41:34 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 6 Feb 2018 09:41:34 -0800 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <3728c709-615f-f160-2a8d-e2c28d4b4dae@oracle.com> Vote: yes -Joe On 2/6/2018 9:39 AM, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From jonathan.gibbons at oracle.com Tue Feb 6 18:23:04 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 06 Feb 2018 10:23:04 -0800 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <5A79F288.7060707@oracle.com> Vote: yes On 02/06/2018 09:39 AM, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From volker.simonis at gmail.com Tue Feb 6 18:34:23 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 6 Feb 2018 19:34:23 +0100 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: Vote: yes On Tue, Feb 6, 2018 at 6:39 PM, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the langtools > team over the last few years, and he definitively helped making javac a > better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From brian.goetz at oracle.com Tue Feb 6 18:43:26 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Feb 2018 13:43:26 -0500 Subject: Incubation Feature Clarifications In-Reply-To: References: <11bb673b-395c-d45c-edd5-a8c38715b513@oracle.com> Message-ID: Note that that *particular* dashboard only tracks JEPs for 10 right now -- but it will probably be revised soon for 11.? But, it is easy to see the queries behind the dashboard, and make your own. On 2/5/2018 11:15 PM, Manoj Palat wrote: > > Thanks Brian, Alan for the clarifications. > The JEP tracking query is quite useful for us - thanks! > > Regards, > Manoj > > > Inactive hide details for Brian Goetz ---02/05/2018 08:24:57 PM---Part > of the goal of the Incubating JEP is to make the incubaBrian Goetz > ---02/05/2018 08:24:57 PM---Part of the goal of the Incubating JEP is > to make the incubation-vs-permanent difference as small a > > From: Brian Goetz > To: Manoj Palat , jdk-dev at openjdk.java.net > Date: 02/05/2018 08:24 PM > Subject: Re: Incubation Feature Clarifications > > ------------------------------------------------------------------------ > > > > Part of the goal of the Incubating JEP is to make the > incubation-vs-permanent difference as small as possible.? For almost > anything not explicitly spelled out in the JEP, the answer is usually > "no different than any other feature."? In that light: > > > Hi, > > ? I am Manoj from the Eclipse Java Development Tools (JDT) and from > Eclipse > > JDT Dev, we have a couple of clarifications regarding the incubation > > features: > > > > ? ? ?Mandatory or Optional:?We understand that when an incubation > feature is > > ? ? included in a release, it should be of production quality. > However, do > > ? ? we, as spec/compiler implementers have the freedom to omit an > incubation > > ? ? feature? In Other words, would we be termed non-compliant if we > do not > > ? ? implement a particular incubation feature? > > This one is spelled out in the JEP, but the answer is: no different than > any other feature.? It's part of the spec, so its part of what the > ecosystem should support.? (This further underscores the fact that > incubating features are not for experimental or risky features.) > > > ? ? ?Timeline:??How much minimum time (in weeks/months) before the > release > > ? ? can we expect a feature to be?categorized as incubation? If it > depends > > ? ? on the feature, what could be a ballpark estimate? > > > > No different than any other feature.? For any feature, incubating or > not, the key milestone is Propose To Target; at this point, a JEP owner > should consider whether including such a feature at this point in the > cycle is the best choice.? (Incubating or not, integrating a risky > feature near the close of the development cycle is not a good idea; > there's another train coming soon.) > > JEPs that affect the platform specification are tagged as Scope: SE. > Language features are tracked in component specification:language; VM > features in specification:vm.? It is easy to create queries that track > JEPs by filtering on these fields; this dashboard, used by the SE 10 EG > (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_secure_Dashboard.jspa-3FselectPageId-3D17511&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=aCW-RWU7-HcE0JNBM5QlTzx-z5oUoU_DWzw9WcCB42Y&s=3eEz0LblF0_PZQIwUtXP4B0_OdAq2DEG-c80Lp4ZNTM&e=), > > is one such example -- you can customize as you like.? So it is easy to > track the lifecycle of JEPs that will affect the language and which will > ultimately need IDE support. > > > > From brian.goetz at oracle.com Tue Feb 6 18:47:33 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Feb 2018 13:47:33 -0500 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <0d92f859-7b51-50b0-4e19-149b6a654a88@oracle.com> Vote: yes On 2/6/2018 12:39 PM, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From yumin.qi at gmail.com Tue Feb 6 18:59:17 2018 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 6 Feb 2018 10:59:17 -0800 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: Vote: yes On Tue, Feb 6, 2018 at 9:39 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the langtools > team over the last few years, and he definitively helped making javac a > better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon > )&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > > From Alan.Bateman at oracle.com Tue Feb 6 19:37:40 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Feb 2018 19:37:40 +0000 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <8523da5d-e05e-3c87-6cb8-d792dbba54dc@oracle.com> Vote: yes From jan.lahoda at oracle.com Tue Feb 6 19:56:25 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 6 Feb 2018 20:56:25 +0100 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <5A7A0869.3030303@oracle.com> vote: yes Jan On 6.2.2018 18:39, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From gnu.andrew at redhat.com Tue Feb 6 20:03:31 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 6 Feb 2018 20:03:31 +0000 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: On 5 February 2018 at 08:21, Magnus Ihse Bursie wrote: > With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in > runnable generated-configure.sh script has been removed. Instead, there's a > new build-time dependency on autoconf. > > For most users, this should not make any difference. You will still initiate > your configuration by running "bash configure". > > If you do not already have autoconf installed, when running configure the > first time after checking out JDK-8195689, this will be detected, and you > will be asked to install autoconf. For most systems, a suggestions on how to > do this is also printed. > > If you have made changes to the build system before, you have probably had a > work flow including a custom-built autoconf, running autogen.sh, and asking > someone in Oracle to sponsor your patch for generation of the closed version > of generated-configure.sh. Neither of this will now be needed. While you can > of course keep a custom-built version of autoconf, you might also delete it. > With the new solution, the exact version of autoconf does not matter. (Note > that it will still be needed for backports, though.) > > The build documentation has been updated to reflect this change. > > /Magnus > Good to see this finally fixed. Having autogenerated files checked in is a pain, especially when merging. -- 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 yumin.qi at gmail.com Tue Feb 6 20:37:21 2018 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 6 Feb 2018 12:37:21 -0800 Subject: JDK submit repo In-Reply-To: References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <20180130073502.342307114@eggemoggin.niobe.net> Message-ID: HI, David and Sean Thanks. After defpath: US-96842M:submit yumin.qi$ hg defpath /Users/yumin.qi/ws/openjdk/submit/submit: default = http://hg.openjdk.java.net/jdk/submit default-push = ssh://minqi at hg.openjdk.java.net/jdk/submit So it is configured correctly I think, then hg push --new-branch pushing to ssh://minqi at hg.openjdk.java.net/jdk/submit remote: Saving password to keychain failed remote: Saving password to keychain failed remote: Saving password to keychain failed remote: Permission denied (publickey). abort: no suitable response from remote hg! It reminded me to input password for id_isa, the id_rsa/id_rsa.pub was created before and installed on remote. I don't know why it requests password? After input password (I did not change that) several times, finally aborted like this. What is the problem here? Is the public key not installed on hg.openjdk.java.net? Mark, do I need regenerate public key? Thanks Yumin On Tue, Feb 6, 2018 at 1:44 AM, David Holmes wrote: > Hi Yumin, > > On 6/02/2018 4:32 PM, yumin qi wrote: > >> Hi, Mark >> >> I pushed with an error returned: >> >> $ hg tip >> changeset: 48771:b458b2ad109d >> branch: JDK-8194154 >> tag: tip >> parent: 48767:4d716bc7ed54 >> user: Yumin.Qi >> date: Mon Feb 05 22:23:38 2018 -0800 >> summary: 8194154: JDK crashes on canonicalization of parsing path >> string contains '//' on linux. >> >> $hg push --new-branch >> pushing to http://hg.openjdk.java.net/jdk/submit >> searching for changes >> abort: HTTP Error 403: Forbidden >> >> I am not sure if I have done correctly. Can you help what is wrong here? I >> am a commiter, but could not do the push to 'submit'. >> > > You need to push using ssh not http. If you have the defpath extension: > > hg defpath -du > > David > > > Thanks >> Yumin >> >> On Tue, Jan 30, 2018 at 7:35 AM, wrote: >> >> 2018/1/30 2:50:45 -0800, Aleksey Shipilev : >>> >>>> So I have submitted JDK-8174901 five days ago, and there was silence >>>> since then. Is *this* the kinds of thing to ask at ops@? >>>> >>> >>> Yes. >>> >>> - Mark >>> >>> From tim.bell at oracle.com Tue Feb 6 21:17:58 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 06 Feb 2018 13:17:58 -0800 Subject: JDK submit repo In-Reply-To: References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <20180130073502.342307114@eggemoggin.niobe.net> Message-ID: <5A7A1B86.7040004@oracle.com> Hello Yumin > Thanks. > After defpath: > US-96842M:submit yumin.qi$ hg defpath > /Users/yumin.qi/ws/openjdk/submit/submit: > default = http://hg.openjdk.java.net/jdk/submit > default-push = ssh://minqi at hg.openjdk.java.net/jdk/submit Your default-push path looks correct. Moving to ops at openjdk.java.net. We can work with you over there to troubleshoot connection problems. Tim Bell From joel.borggren.franck at gmail.com Tue Feb 6 21:43:16 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Tue, 06 Feb 2018 21:43:16 +0000 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: Vote: yes On Tue, 6 Feb 2018 at 18:39, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > > From david.holmes at oracle.com Tue Feb 6 21:49:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Feb 2018 07:49:46 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8fadd660-fa9e-80bb-ee5b-efbc4945bf2a@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> <8fadd660-fa9e-80bb-ee5b-efbc4945bf2a@oracle.com> Message-ID: <72b40012-9914-6972-e5dd-fdc79f1b45cd@oracle.com> Thanks Erik. Pushing now. David On 7/02/2018 3:24 AM, Erik Joelsson wrote: > Looks good! > > /Erik > > > On 2018-02-05 17:25, David Holmes wrote: >> It's time to increment the actual version to 11 for JDK 11. >> >> Joe Darcy and I have worked through numerous test issues that delayed >> the update and I've been addressing a number of issues in hotspot >> related to obsolete/expired flag warnings. I have tested the update >> with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI >> failures for either JDK or HS pipelines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 >> >> Change: >> >> --- a/make/autoconf/version-numbers >> +++ b/make/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> ?# Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_FEATURE=10 >> +DEFAULT_VERSION_FEATURE=11 >> ?DEFAULT_VERSION_INTERIM=0 >> ?DEFAULT_VERSION_UPDATE=0 >> ?DEFAULT_VERSION_PATCH=0 >> >> Thanks, >> David > From lhochet at gmail.com Tue Feb 6 21:57:47 2018 From: lhochet at gmail.com (Ludovic HOCHET) Date: Tue, 6 Feb 2018 22:57:47 +0100 Subject: RFR: 8196383 : JDK 10 L10n resource file update - msg drop 20 In-Reply-To: <2638d679-ed4a-e3c2-439f-f1873f631101@oracle.com> References: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com> <2638d679-ed4a-e3c2-439f-f1873f631101@oracle.com> Message-ID: Hello Johnny, Sorry I wasn't clear. "afficher l'?cran d'accueil avec l'image indiqu?e" is equivalent to "afficher l\u0027\u00E9cran d\u0027accueil avec l\u0027image indiqu\u00E9e" but should be changed to be "afficher l\u0027\u0027\u00E9cran d\u0027\u0027accueil avec l\u0027\u0027image indiqu\u00E9e" for MessageFormat to work properly. By odd to read I meant that this sample is currently displayed as "afficher l?cran daccueil avec limage indiqu?e". Thanks, Ludovic On 6 February 2018 at 07:50, Yue Liu wrote: > Hi Ludovic, > > As I understand, non doubled single quotes ' making the text odd to read > means that all single quotes should be replaced by double quotes ''. > > e.g. "afficher l'?cran d'accueil avec l'image indiqu?e" should be updated > to: "afficher l''?cran d''accueil avec l''image indiqu?e" > > If that's not the case, please providing more specific info and samples. I > create a bug for tracking this: > https://bugs.openjdk.java.net/browse/JDK-8196836 > > If properties file needs update, I'm afraid we couldn't integrate the change > in this drop. > > Thanks, > > Johnny > > > On 2018/2/6 6:30, Ludovic HOCHET wrote: > > Hello Johnny, > > launcher_fr.properties still has non doubled single quotes ', which > breaks MessageFormat parameters replacement, as well as the display of > single quotes (they are not displayed) making the text odd to read. > > Ludovic > > On 31 January 2018 at 07:30, Yue Liu wrote: > > Hi all, > > Please help to review the changes for L10n resource file update message drop > 20. > > Some localized resource files are updated as English resource changed, some > just because of issue fixing > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8196383 > > Webrev: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8196383/webrev.00/ > > Have got build and passed the tier1/2/3 test on all platforms on Mach 5. > > Thanks, > Johnny > > > > -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From david.holmes at oracle.com Tue Feb 6 22:19:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Feb 2018 08:19:21 +1000 Subject: Effect of setting CPU quota on Java performance In-Reply-To: References: <04674F3C-0720-46EB-8F6F-F79BAC1FEF6A@oracle.com> <049D6283-A4B5-40A6-981D-D311B937A187@oracle.com> Message-ID: <8a7a6758-1b3f-f4b5-ff30-7ace776ef600@oracle.com> Just to add, as I've stated in the past when our container support for cpu quotas was being put in, this is really a difficult area. Quotas are deceptively simply, but the devil is in the details - you need to know _exactly_ how a system will implement quotas before you can appropriately size your application in terms of number of threads. For example, if there is a 12 processor system and you request 50% quota then what do you get? You know that over time you will get 50% of the cpu resources but that's not sufficient. You might get 6 processors for 100%, or 12 for 50%. But to take advantage of 12 processors you need 12 threads; whereas if you have only 6 processors you only want 6 threads. So what do you do? You need to know these details. David On 6/02/2018 8:13 PM, Ashutosh Mehra1 wrote: >> Just curious, what would be the use case for running on more cores with > less CPU quota per core? > >> Are you trying to find out ?can I maintain the same level of performance > with lower power usage by plugging in more cores?? > >> Or put it another way ?can I buy power with cores?? > >> I think that would be great, as that would mean your investment in the > extra core can eventually be paid back by power savings. > > Well, my experiment is only to see if CPU quota, which is used quite > extensively in kubernetes and docker environments, has any impact on > performance of applications (especially JVM based). > So, earlier if some one is running their app on 4 CPU system decides to > deploy their app in kubernetes-docker environment which uses cpu quota to > provide the requested "effective" CPUs, then what kind of performance > issues can arise. > The fact that the performance issue I encountered has its roots in kernel > CPU frequency governor for power saving is just plain luck! (or should I > say bad luck!) > > Another (long term) aim of this exercise is to understand how the JVM is > performing in docker container, and if there is any scope of improvement > there. > As part of that, I am checking the impact of CPU quota on various aspects > of JVM. > GC pause time and JIT compilation time are two such quantities that I am > currently measuring when running AcmeAir benchmark. > > Ashutosh > > > > From: Ioi Lam > To: Ashutosh Mehra1 > Cc: jdk-dev at openjdk.java.net, Dinakar Guniguntala > > Date: 02/06/2018 02:44 PM > Subject: Re: Effect of setting CPU quota on Java performance > > > > Just curious, what would be the use case for running on more cores with > less CPU quota per core? > > Are you trying to find out ?can I maintain the same level of performance > with lower power usage by plugging in more cores?? > > Or put it another way ?can I buy power with cores?? > > I think that would be great, as that would mean your investment in the > extra core can eventually be paid back by power savings. > > Ioi > > > On Feb 6, 2018, at 2:43 PM, Ashutosh Mehra1 wrote: > >>> As a control test, maybe you can run a simple multi-threaded C > benchmark >> with the same settings? >> >> Thats a good point. I have also been testing with a simple > multi-threaded >> C program for past few days, and I observed similar difference in >> performance between 4CPU at 100 and 8CPU at 50. >> In fact I asked this question based on that multi-threaded C program > here >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__unix.stackexchange.com_questions_417506_what-2Dis-2Dthe-2Deffect-2Dof-2Dsetting-2Dcpu-2Dcpu-2Dquota-2Dus-2Din-2Dcpu-2Dcgroup&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=EoWnPxdBJetX_MYOuYzlqw_1dBePJ6X_jq9FyiwhTYg&s=pGc13T8qxYnbuyDanEF0tT7DuuzVgGtiwvZ55oB-o2A&e= > >> but didn't get any response. >> >> Yesterday, while testing with that C program we noticed CPU frequency > for >> 4CPU at 100 case was close to maximum, but in case of 8CPU at 50, it was way >> below that. >> On further examination we found the system was using "powersave" as the >> kernel governor for CPU frequency. >> For a quick overview of different kernel governors for CPU frequency see > >> this: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_doc_Documentation_cpu-2Dfreq_governors.txt&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=EoWnPxdBJetX_MYOuYzlqw_1dBePJ6X_jq9FyiwhTYg&s=7j2vI3sWYhJtMXE3T_Twbsggvc84INFKKuPm2Axgq3w&e= > >> When we changed the kernel governor to "performance", we were able to > see >> much better performance with 8CPU at 50 which was very close to 4CPU at 100. >> >> I am going to repeat my experiment with AcmeAir benchmark using >> "performance" kernel governor. >> I expect this should help in bridging the throughput gap I noticed in my > >> earlier experiment. >> >> - Ashutosh >> >> >> >> From: Ioi Lam >> To: Ashutosh Mehra1 >> Cc: jdk-dev at openjdk.java.net, Dinakar Guniguntala >> >> Date: 02/05/2018 11:47 PM >> Subject: Re: Effect of setting CPU quota on Java performance >> >> >> >> As a control test, maybe you can run a simple multi-threaded C benchmark > >> with the same settings? >> >>> On Feb 5, 2018, at 1:48 PM, Ashutosh Mehra1 > wrote: >>> >>> I have been trying to understand if setting CPU quota limit on a docker > >>> container, provided the "effective" CPUs are the same, has any impact > on >> >>> the application performance. >>> As an example, if my app is running on 4 CPUs @ 100% quota, would I get > >>> same performance if my app is running on 8 CPUs at 50% quota? Note that >>> "effective" CPUs is 4 in both cases. >>> >>> Since OpenJDK early access builds for Java 10 have improved support for > >>> docker container ( >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8146115&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=pYU9iHBTE76q-M9IZrQkWIq_LZnocNRTSH1_bJFCGLQ&e= > >> ), I >>> decided to do some measurements using that build. >>> I got the build OpenJDK build jdk-10-ea+40 from >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_10_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=_bL50Git2eGTEuWiDNdtvjIXdgc7499XiPL7JFilAxA&e= > >> . >>> This build by default has container support enabled. >>> The system I used has 32 CPUs including 2 hyperthreads per core. I >> turned >>> off hyperthreading for this experiment. That leaves me with 16 cores on > >> 2 >>> sockets: 0-7 on 1 socket and 8-15 on 2nd socket. >>> System details are: >>> >>> # lsb_release -a >>> No LSB modules are available. >>> Distributor ID: Ubuntu >>> Description: Ubuntu 16.04.2 LTS >>> Release: 16.04 >>> Codename: xenial >>> >>> # uname -r >>> 4.4.0-103-generic >>> >>> For measurements I used AcmeAir benchmark at >>> >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sabkrish_acmeair_tree_microservice-5Fchanges&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=E-YV0z5Ta99mwh3Za06_I769mDNiOgT5HLTiH-9tcIY&m=AF2cyoYVI5rZB4oOzFm7tKN8hqOduv6oKv-ewl5sIbg&s=bkcFfs-e2YzGHlWabfwKyipPqlqDOWXrW6W5-ns1EP8&e= > >> . >>> I ran the AcmeAir benchmark with the said build for following cases: >>> >>> 1) Ran AcmeAir with JVM bound to 4 cpus (8-11) and no limit on quota. >> Lets >>> call this 4CPU at 100. >>> This used following JVM settings: >>> CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 >>> >>> 2) Case 8Cpu50Quota: Ran AcmeAir with JVM bound to 8 cpus (8-15) and > 50% >> >>> quota. Lets call this 8CPU at 50. >>> In this case container support was enabled by default and it used >>> following JVM settings: >>> CICompilerCount = 3, ParallelGCThreads = 4, ConcGCThreads = 1 >>> >>> 3) Ran AcmeAir with JVM bound to 8 cpus (8-15) and 50% quota with >>> -XX:-UseContainerSupport option to disable container support. Lets call > >>> this 8CPU at 50NoCS. >>> This used following JVM settings: >>> CICompilerCount = 4, ParallelGCThreads = 8, ConcGCThreads = 2 >>> >>> Load on the server was applied using JMeter which was running on same >> box >>> but bound to 0-8 CPUs. I applied the load for few minutes to warm up > the >> >>> JVM before starting the final "measure" run. >>> Throughput reported below is for the final "measure" run. All numbers >>> reported below are an average of 10 iterations. >>> >>> Throughput result: >>> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >>> 9621.5 | 6970.6 | 7252.1 >>> >>> I also measured Total compilation time (in seconds) and Total pause > time >> >>> (in seconds) for the duration of the server (which includes warm up >>> phase): >>> >>> Compilation time: >>> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >>> 79.8545 | 76.7041 | 100.085 >>> >>> GC Pasue time: >>> 4Cpu1 at 100 | 8Cpu at 50 | 8Cpu at 50NoCS >>> 1.829 | 1.886 | 1.927 >>> >>> I am quite surprised to see the drop in throughput between 4Cpu100Quota > >>> and 8Cpu50Quota case. >>> Looking deeper into the results, I do notice that numbers for >> 8Cpu50Quota >>> case were not very consistent, but in general I can say they are not >>> matching 4Cpu100Quota case. >>> I will be doing additional runs for this setup (and on different >> OS/kernel >>> version) and increase warm up time for the JVM to see if that improves >> the >>> consistency. >>> >>> Meanwhile, couple of questions I wanted to put forward: >>> 1) Has anyone else noticed this kind of difference in Java >>> application/JVM performance when CPU quota is used? >>> 2) What other open-source benchmarks are available that I can use to >>> verify the behavior I am observing? >>> >>> Any comments/feedback are welcome. >>> >>> Thanks, >>> Ashutosh Mehra >>> >> >> >> >> >> > > > > > From paul.sandoz at oracle.com Tue Feb 6 22:21:24 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Feb 2018 14:21:24 -0800 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <7A0DCAEC-403E-48FA-BA42-16A674F47DE6@oracle.com> Vote: yes Paul. From thomas.stuefe at gmail.com Wed Feb 7 13:52:49 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Feb 2018 14:52:49 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: Hi Magnus, short question, is it possible to overwrite the location of autoconf with a configure setting or similar? Similar to "toolchain-path"? Thanks, Thomas On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in > runnable generated-configure.sh script has been removed. Instead, there's a > new build-time dependency on autoconf. > > For most users, this should not make any difference. You will still > initiate your configuration by running "bash configure". > > If you do not already have autoconf installed, when running configure the > first time after checking out JDK-8195689, this will be detected, and you > will be asked to install autoconf. For most systems, a suggestions on how > to do this is also printed. > > If you have made changes to the build system before, you have probably had > a work flow including a custom-built autoconf, running autogen.sh, and > asking someone in Oracle to sponsor your patch for generation of the closed > version of generated-configure.sh. Neither of this will now be needed. > While you can of course keep a custom-built version of autoconf, you might > also delete it. With the new solution, the exact version of autoconf does > not matter. (Note that it will still be needed for backports, though.) > > The build documentation has been updated to reflect this change. > > /Magnus > > From shade at redhat.com Wed Feb 7 15:01:19 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Feb 2018 16:01:19 +0100 Subject: JDK submit repo In-Reply-To: References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> Message-ID: <6ace9970-d0f9-e45b-5dc8-72984f4c3d93@redhat.com> On 01/30/2018 11:50 AM, Aleksey Shipilev wrote: > On 01/24/2018 01:00 PM, Aleksey Shipilev wrote: >> On 01/23/2018 09:33 PM, mark.reinhold at oracle.com wrote: >>> The submit repo is now open for pushes from any JDK Committer: >>> >>> http://hg.openjdk.java.net/jdk/submit >>> >>> If you push a branch whose name starts with "JDK-" into this repo >>> then it will automatically be built and tested on Oracle's internal >>> build system, and a summary of the results will be e-mailed back to >>> you. This typically takes a couple of hours. If one or more tests >>> fail then you can contact an Oracle engineer to get more information >>> about the failures. >> >> Excellent, thank you! Trying it now! > > So I have submitted JDK-8174901 five days ago, and there was silence since then. Is *this* the kinds > of thing to ask at ops@? Yay! Ops/dev guys have figured out the problem with sending to Red Hat addresses, probably. Got my first notification! Unfortunately, the current report seems to indicate that I have to contact Oracle engineers right away, because there is no actionable diagnostics in those reports. This basically makes the whole thing harder on Oracle guys, and believe the intent was to allow external contributors to test their thing without bothering Oracle people a lot. What do you do if you get the report like below? This does not seem to be a component-specific failure, but just a configure/build failure. It seems wrong to bother ops@ with requests like this. ----- 8< ------------------------------------------------------------------------------------------ Build Details: 2018-02-07-1244081.ashipile.source Mach5 Tasks Results Summary EXECUTED_WITH_FAILURE: 9 PASSED: 0 UNABLE_TO_RUN: 72 NA: 0 FAILED: 0 KILLED: 0 Build 9 Not run build_jdk_linux-linux-x64-linux-x64-OEL-7-0 Error while running 'jib configure', return value: 10 build_jdk_linux-linux-x64-debug-linux-x64-OEL-7-1 Error while running 'jib configure', return value: 10 build_openjdk_linux-linux-x64-open-linux-x64-OEL-7-8 Error while running 'jib configure', return value: 10 build_jdk_macosx-macosx-x64-macosx-x64-anyof_10_9_10_10-2 Error while running 'jib configure', return value: 10 build_jdk_macosx-macosx-x64-debug-macosx-x64-anyof_10_9_10_10-3 Error while running 'jib configure', return value: 10 build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-11_2-4 Error while running 'jib configure', return value: 10 build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-11_2-5 Error while running 'jib configure', return value: 10 build_jdk_windows-windows-x64-windows-x64-2012R2-6 Error while running 'jib configure', return value: 10 build_jdk_windows-windows-x64-debug-windows-x64-2012R2-7 Error while running 'jib configure', return value: 10 Test 72 Not run tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-linux-x64-18 Dependency task failed: mach5...6-build_jdk_linux-linux-x64-linux-x64-OEL-7-0 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-linux-x64-debug-17 Dependency task failed: mach5...d_jdk_linux-linux-x64-debug-linux-x64-OEL-7-1 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-macosx-x64-24 Dependency task failed: mach5...cosx-macosx-x64-macosx-x64-anyof_10_9_10_10-2 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-macosx-x64-debug-23 Dependency task failed: mach5...acosx-x64-debug-macosx-x64-anyof_10_9_10_10-3 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-solaris-sparcv9-22 Dependency task failed: mach5...olaris-solaris-sparcv9-solaris-sparcv9-11_2-4 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-solaris-sparcv9-debug-21 Dependency task failed: mach5...-solaris-sparcv9-debug-solaris-sparcv9-11_2-5 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-windows-x64-20 Dependency task failed: oK0w8SAdOg tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-windows-x64-debug-19 Dependency task failed: oK0w8SAeOg tier1-comp-jdk_closed_test_hotspot_jtreg_hotspot_tier1_compiler_closed-linux-x64-debug-34 Dependency task failed: mach5...d_jdk_linux-linux-x64-debug-linux-x64-OEL-7-1 tier1-comp-jdk_closed_test_hotspot_jtreg_hotspot_tier1_compiler_closed-macosx-x64-debug-36 Dependency task failed: mach5...acosx-x64-debug-macosx-x64-anyof_10_9_10_10-3 See all 72... ----- 8< ------------------------------------------------------------------------------------------ Thanks, -Aleksey From volker.simonis at gmail.com Wed Feb 7 15:04:03 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Feb 2018 16:04:03 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: On Wed, Feb 7, 2018 at 2:52 PM, Thomas St?fe wrote: > Hi Magnus, > > short question, is it possible to overwrite the location of autoconf with a > configure setting or similar? Similar to "toolchain-path"? > I doubt because you need autoconf in order to generate the actual configure script (generated-configure.sh) which evaluates the arguments. We would either need special arguments for the initial configure script or pass it through the environment which I think is both not worth it if we could just as well put autoconf in the regular path. > Thanks, Thomas > > On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in >> runnable generated-configure.sh script has been removed. Instead, there's a >> new build-time dependency on autoconf. >> >> For most users, this should not make any difference. You will still >> initiate your configuration by running "bash configure". >> >> If you do not already have autoconf installed, when running configure the >> first time after checking out JDK-8195689, this will be detected, and you >> will be asked to install autoconf. For most systems, a suggestions on how >> to do this is also printed. >> >> If you have made changes to the build system before, you have probably had >> a work flow including a custom-built autoconf, running autogen.sh, and >> asking someone in Oracle to sponsor your patch for generation of the closed >> version of generated-configure.sh. Neither of this will now be needed. >> While you can of course keep a custom-built version of autoconf, you might >> also delete it. With the new solution, the exact version of autoconf does >> not matter. (Note that it will still be needed for backports, though.) >> >> The build documentation has been updated to reflect this change. >> >> /Magnus >> >> From hohensee at amazon.com Wed Feb 7 15:10:45 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Feb 2018 15:10:45 +0000 Subject: JDK submit repo In-Reply-To: <6ace9970-d0f9-e45b-5dc8-72984f4c3d93@redhat.com> References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <6ace9970-d0f9-e45b-5dc8-72984f4c3d93@redhat.com> Message-ID: <7A0A7283-3764-47C8-8A2D-2FCEFFAD7D55@amazon.com> I got the same result when I failed to sync my branch with the upstream repo before submitting a build request. From https://wiki.openjdk.java.net/display/Build/Submit+Repo, $ hg pull $ hg update $ hg merge default $ hg commit $ hg push # submit build request Paul On 2/7/18, 7:02 AM, "jdk-dev on behalf of Aleksey Shipilev" wrote: On 01/30/2018 11:50 AM, Aleksey Shipilev wrote: > On 01/24/2018 01:00 PM, Aleksey Shipilev wrote: >> On 01/23/2018 09:33 PM, mark.reinhold at oracle.com wrote: >>> The submit repo is now open for pushes from any JDK Committer: >>> >>> http://hg.openjdk.java.net/jdk/submit >>> >>> If you push a branch whose name starts with "JDK-" into this repo >>> then it will automatically be built and tested on Oracle's internal >>> build system, and a summary of the results will be e-mailed back to >>> you. This typically takes a couple of hours. If one or more tests >>> fail then you can contact an Oracle engineer to get more information >>> about the failures. >> >> Excellent, thank you! Trying it now! > > So I have submitted JDK-8174901 five days ago, and there was silence since then. Is *this* the kinds > of thing to ask at ops@? Yay! Ops/dev guys have figured out the problem with sending to Red Hat addresses, probably. Got my first notification! Unfortunately, the current report seems to indicate that I have to contact Oracle engineers right away, because there is no actionable diagnostics in those reports. This basically makes the whole thing harder on Oracle guys, and believe the intent was to allow external contributors to test their thing without bothering Oracle people a lot. What do you do if you get the report like below? This does not seem to be a component-specific failure, but just a configure/build failure. It seems wrong to bother ops@ with requests like this. ----- 8< ------------------------------------------------------------------------------------------ Build Details: 2018-02-07-1244081.ashipile.source Mach5 Tasks Results Summary EXECUTED_WITH_FAILURE: 9 PASSED: 0 UNABLE_TO_RUN: 72 NA: 0 FAILED: 0 KILLED: 0 Build 9 Not run build_jdk_linux-linux-x64-linux-x64-OEL-7-0 Error while running 'jib configure', return value: 10 build_jdk_linux-linux-x64-debug-linux-x64-OEL-7-1 Error while running 'jib configure', return value: 10 build_openjdk_linux-linux-x64-open-linux-x64-OEL-7-8 Error while running 'jib configure', return value: 10 build_jdk_macosx-macosx-x64-macosx-x64-anyof_10_9_10_10-2 Error while running 'jib configure', return value: 10 build_jdk_macosx-macosx-x64-debug-macosx-x64-anyof_10_9_10_10-3 Error while running 'jib configure', return value: 10 build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-11_2-4 Error while running 'jib configure', return value: 10 build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-11_2-5 Error while running 'jib configure', return value: 10 build_jdk_windows-windows-x64-windows-x64-2012R2-6 Error while running 'jib configure', return value: 10 build_jdk_windows-windows-x64-debug-windows-x64-2012R2-7 Error while running 'jib configure', return value: 10 Test 72 Not run tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-linux-x64-18 Dependency task failed: mach5...6-build_jdk_linux-linux-x64-linux-x64-OEL-7-0 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-linux-x64-debug-17 Dependency task failed: mach5...d_jdk_linux-linux-x64-debug-linux-x64-OEL-7-1 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-macosx-x64-24 Dependency task failed: mach5...cosx-macosx-x64-macosx-x64-anyof_10_9_10_10-2 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-macosx-x64-debug-23 Dependency task failed: mach5...acosx-x64-debug-macosx-x64-anyof_10_9_10_10-3 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-solaris-sparcv9-22 Dependency task failed: mach5...olaris-solaris-sparcv9-solaris-sparcv9-11_2-4 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-solaris-sparcv9-debug-21 Dependency task failed: mach5...-solaris-sparcv9-debug-solaris-sparcv9-11_2-5 tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-windows-x64-20 Dependency task failed: oK0w8SAdOg tier1-common-jdk_closed_test_hotspot_jtreg_hotspot_tier1_common-windows-x64-debug-19 Dependency task failed: oK0w8SAeOg tier1-comp-jdk_closed_test_hotspot_jtreg_hotspot_tier1_compiler_closed-linux-x64-debug-34 Dependency task failed: mach5...d_jdk_linux-linux-x64-debug-linux-x64-OEL-7-1 tier1-comp-jdk_closed_test_hotspot_jtreg_hotspot_tier1_compiler_closed-macosx-x64-debug-36 Dependency task failed: mach5...acosx-x64-debug-macosx-x64-anyof_10_9_10_10-3 See all 72... ----- 8< ------------------------------------------------------------------------------------------ Thanks, -Aleksey From shade at redhat.com Wed Feb 7 15:33:07 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Feb 2018 16:33:07 +0100 Subject: JDK submit repo In-Reply-To: <7A0A7283-3764-47C8-8A2D-2FCEFFAD7D55@amazon.com> References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <6ace9970-d0f9-e45b-5dc8-72984f4c3d93@redhat.com> <7A0A7283-3764-47C8-8A2D-2FCEFFAD7D55@amazon.com> Message-ID: <7eea606a-c25d-cd09-f47b-651c36cc4370@redhat.com> On 02/07/2018 04:10 PM, Hohensee, Paul wrote: > I got the same result when I failed to sync my branch with the upstream repo before submitting a build request. That makes some sense: build system probably expects something that is available only in base branch? Merged from default, and pushed again. Let's see if it helps. -Aleksey From yumin.qi at gmail.com Wed Feb 7 20:10:14 2018 From: yumin.qi at gmail.com (yumin qi) Date: Wed, 7 Feb 2018 12:10:14 -0800 Subject: RFR: 8194154: JDK crashes parsing path string contains '//' on linux Message-ID: Hi, Please review the fix (extra small) for: bug 8194154: https://bugs.openjdk.java.net/browse/JDK-8194154 webrev: http://cr.openjdk.java.net/~minqi/8194154/ Summary: canonicalize will check and fold double (or more) slashes, but in function collapsible(char*) and splitNames(char*, char**), it failed to process strings like "//". This results in the former does not give a correct number of substrings and the later does not give a correct array of substrings. The fix add a check if the character is '/' after a '/'. The test case added will crash without the fix. Thanks Yumin From david.holmes at oracle.com Thu Feb 8 03:32:24 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Feb 2018 19:32:24 -0800 (PST) Subject: RFR: 8194154: JDK crashes parsing path string contains '//' on linux In-Reply-To: References: Message-ID: Moving to core-libs-dev. Code reviews don't take place on jdk-dev but on the component area mailing lists. Thanks, David On 8/02/2018 6:10 AM, yumin qi wrote: > Hi, > > Please review the fix (extra small) for: > bug 8194154: https://bugs.openjdk.java.net/browse/JDK-8194154 > webrev: http://cr.openjdk.java.net/~minqi/8194154/ > > Summary: canonicalize will check and fold double (or more) slashes, but > in function collapsible(char*) and splitNames(char*, char**), it failed to > process strings like "//". This results in the former does not give a > correct number of substrings and the later does not give a correct array of > substrings. The fix add a check if the character is '/' after a '/'. > > The test case added will crash without the fix. > > Thanks > Yumin > From Alan.Bateman at oracle.com Thu Feb 8 06:54:32 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Feb 2018 06:54:32 +0000 Subject: RFR: 8194154: JDK crashes parsing path string contains '//' on linux In-Reply-To: References: Message-ID: On 07/02/2018 20:10, yumin qi wrote: > Hi, > > Please review the fix (extra small) for: > bug 8194154: https://bugs.openjdk.java.net/browse/JDK-8194154 > webrev: http://cr.openjdk.java.net/~minqi/8194154/ > > Summary: canonicalize will check and fold double (or more) slashes, but > in function collapsible(char*) and splitNames(char*, char**), it failed to > process strings like "//". This results in the former does not give a > correct number of substrings and the later does not give a correct array of > substrings. The fix add a check if the character is '/' after a '/'. > The JDK has never supported setting user.dir in this way (it breaks several things). There is a thread discussing this on core-libs-dev so best to bring it to that mailing list to discuss again. -Alan From thomas.stuefe at gmail.com Thu Feb 8 07:50:09 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 08:50:09 +0100 Subject: JDK submit repo In-Reply-To: <7eea606a-c25d-cd09-f47b-651c36cc4370@redhat.com> References: <20180123203343.45042150D72@eggemoggin.niobe.net> <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com> <6ace9970-d0f9-e45b-5dc8-72984f4c3d93@redhat.com> <7A0A7283-3764-47C8-8A2D-2FCEFFAD7D55@amazon.com> <7eea606a-c25d-cd09-f47b-651c36cc4370@redhat.com> Message-ID: Hi all, I got my report back yesterday, which is nice. However it does not tell me much beyond that something went well: EXECUTED_WITH_FAILURE: 0 PASSED: 81 UNABLE_TO_RUN: 0 NA: 0 FAILED: 0 KILLED: 0 So, I would like to know on which platforms you build and test, and which tests exactly are executed? I could not find this information in the linked documentation. Thank you! Thomas On Wed, Feb 7, 2018 at 4:33 PM, Aleksey Shipilev wrote: > On 02/07/2018 04:10 PM, Hohensee, Paul wrote: > > I got the same result when I failed to sync my branch with the upstream > repo before submitting a build request. > > That makes some sense: build system probably expects something that is > available only in base > branch? Merged from default, and pushed again. Let's see if it helps. > > -Aleksey > > > From magnus.ihse.bursie at oracle.com Thu Feb 8 12:51:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Feb 2018 13:51:25 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: On 2018-02-07 16:04, Volker Simonis wrote: > On Wed, Feb 7, 2018 at 2:52 PM, Thomas St?fe wrote: >> Hi Magnus, >> >> short question, is it possible to overwrite the location of autoconf with a >> configure setting or similar? Similar to "toolchain-path"? >> > I doubt because you need autoconf in order to generate the actual > configure script (generated-configure.sh) which evaluates the > arguments. Exactly. :) That wouldn't make sense. > We would either need special arguments for the initial configure > script or pass it through the environment which I think is both not > worth it if we could just as well put autoconf in the regular path. What you *can* do is to use the AUTOCONF environment variable. If it's too much bother to put it in the environment, you can just prefix your calls to configure, or create a script that contains this. I'll repost my own "configure" script that I have in ~/bin (which is included in my PATH). I created this since it allows me to write "configure --" to get tab completion from bash, but you can also hijack it to setup a special AUTOCONF variable. --- #!/bin/bash if [ $(pwd) = $(cd $(dirname $0); pwd) ] ; then ? echo >&2 "Abort: Trying to call configure helper recursively" ? exit 1 fi bash $PWD/configure "$@" -- /Magnus > >> Thanks, Thomas >> >> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in >>> runnable generated-configure.sh script has been removed. Instead, there's a >>> new build-time dependency on autoconf. >>> >>> For most users, this should not make any difference. You will still >>> initiate your configuration by running "bash configure". >>> >>> If you do not already have autoconf installed, when running configure the >>> first time after checking out JDK-8195689, this will be detected, and you >>> will be asked to install autoconf. For most systems, a suggestions on how >>> to do this is also printed. >>> >>> If you have made changes to the build system before, you have probably had >>> a work flow including a custom-built autoconf, running autogen.sh, and >>> asking someone in Oracle to sponsor your patch for generation of the closed >>> version of generated-configure.sh. Neither of this will now be needed. >>> While you can of course keep a custom-built version of autoconf, you might >>> also delete it. With the new solution, the exact version of autoconf does >>> not matter. (Note that it will still be needed for backports, though.) >>> >>> The build documentation has been updated to reflect this change. >>> >>> /Magnus >>> >>> From rasbold at google.com Thu Feb 8 21:42:31 2018 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 8 Feb 2018 13:42:31 -0800 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: Vote: yes On Tue, Feb 6, 2018 at 9:39 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the langtools > team over the last few years, and he definitively helped making javac a > better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon > )&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > > From jonathan.gibbons at oracle.com Thu Feb 8 23:18:35 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Feb 2018 15:18:35 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs Message-ID: <5A7CDACB.50103@oracle.com> This draft JEP contains a proposal to enhance the |java| launcher to support running a program supplied as a single file of Java source code. The program will be compiled and run, without the need to explicit invoke javac, or to package up a jar file. For more details, see: http://openjdk.java.net/jeps/8192920 -- Jon From volker.simonis at gmail.com Fri Feb 9 10:51:23 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 9 Feb 2018 11:51:23 +0100 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: Hi Jonathan, that's an interesting proposal. It is just unfortunate that a Java source file starting with "shebang" won't be a legal Java file according to the Java Language Specification. Or do you plan to change the JLS to allow (and ignore) "shebang" in the first line? Thanks, Volker On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the java launcher to support > running a > program supplied as a single file of Java source code. The program will be > compiled > and run, without the need to explicit invoke javac, or to package up a jar > file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 > > -- Jon From robert.zenz at sibvisions.com Fri Feb 9 11:13:17 2018 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Fri, 9 Feb 2018 11:13:17 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <5A7D824E.30007@sibvisions.com> I fail to see why a shebang would be required at all for this proposal, can't `java` figure out that it was handed a source code file (ends with .java and is not a class file or jar)? Or alternately provide a switch to run source files? On 09.02.2018 11:51, Volker Simonis wrote: > Hi Jonathan, > > that's an interesting proposal. It is just unfortunate that a Java > source file starting with "shebang" won't be a legal Java file > according to the Java Language Specification. Or do you plan to change > the JLS to allow (and ignore) "shebang" in the first line? > > Thanks, > Volker > > On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons > wrote: >> This draft JEP contains a proposal to enhance the java launcher to support >> running a >> program supplied as a single file of Java source code. The program will be >> compiled >> and run, without the need to explicit invoke javac, or to package up a jar >> file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 >> >> -- Jon From lennart.borjeson at cinnober.com Fri Feb 9 11:34:43 2018 From: lennart.borjeson at cinnober.com (=?iso-8859-1?Q?Lennart_B=F6rjeson?=) Date: Fri, 9 Feb 2018 11:34:43 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7D824E.30007@sibvisions.com> References: <5A7CDACB.50103@oracle.com> <5A7D824E.30007@sibvisions.com> Message-ID: <9BDC3D89-F4EC-40D8-8477-40C40DF1D092@cinnober.com> > 9 feb. 2018 kl. 12:13 skrev Robert Zenz : > > I fail to see why a shebang would be required at all for this proposal, can't > `java` figure out that it was handed a source code file (ends with .java and is > not a class file or jar)? Or alternately provide a switch to run source files? > > The shebang convention is extremely well established in the unix world. It is simply the mechanism linux/unix provides to select the actual processor for a shell script. If we would like a "java shell script" to be directly executable by its processor on unix/linux, I'd say java must needs support the shebang. A unix/linux user expects it. Best regards, /Lennart From robert.zenz at sibvisions.com Fri Feb 9 12:30:17 2018 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Fri, 9 Feb 2018 12:30:17 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <9BDC3D89-F4EC-40D8-8477-40C40DF1D092@cinnober.com> References: <5A7CDACB.50103@oracle.com> <5A7D824E.30007@sibvisions.com> <9BDC3D89-F4EC-40D8-8477-40C40DF1D092@cinnober.com> Message-ID: <5A7D945A.50204@sibvisions.com> Yes, I know, I just don't understand why it is in the JEP. As far as I know, we can already do that: //usr/bin/env javac "$0" && java -cp . Main; exit $? public final class Main { public static final void main(String[] args) { System.out.println("Test"); } } Which is crude, for sure, but if `java` can determine that it is a source file, that would shrink to: //usr/bin/env java "$0"; exit $? public final class Main { public static final void main(String[] args) { System.out.println("Test"); } } On 09.02.2018 12:34, Lennart B?rjeson wrote: > The shebang convention is extremely well established in the unix world. It is simply the mechanism linux/unix provides to select the actual processor for a shell script. > > If we would like a "java shell script" to be directly executable by its processor on unix/linux, I'd say java must needs support the shebang. A unix/linux user expects it. > > Best regards, > > /Lennart > From lennart.borjeson at cinnober.com Fri Feb 9 12:32:46 2018 From: lennart.borjeson at cinnober.com (=?iso-8859-1?Q?Lennart_B=F6rjeson?=) Date: Fri, 9 Feb 2018 12:32:46 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> > 9 feb. 2018 kl. 00:18 skrev Jonathan Gibbons : > > This draft JEP contains a proposal to enhance the |java| launcher to > support running a > program supplied as a single file of Java source code. The program will > be compiled > and run, without the need to explicit invoke javac, or to package up a > jar file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 > > -- Jon Most welcome! One comment, though: As a linux/unix user, I'd expect the jshell executable to be the processor for jshell scripts, not the compiler ("java"). This would tie in with the established pattern of other shell script processors/repl, e.g. groovysh, or even plain bash. Best regards, /Lennart From dwfranken at gmail.com Fri Feb 9 15:08:45 2018 From: dwfranken at gmail.com (dwfranken at gmail.com) Date: Fri, 9 Feb 2018 16:08:45 +0100 Subject: Weird timezone issues with Timestamp.valueOf(String s) Message-ID: <004c01d3a1b7$e1efe9c0$a5cfbd40$@gmail.com> Not that I encourage using date/time classes from the packages of either java.util or java.sql, but sometimes it happens under the hood. We found a weird issue with timestamps. In our (PostgreSQL) database we have a column of SQL type TIMESTAMP - no timezone. When JPA fills our entity field with a java.sql.Timestamp value, it is given an inherent timezone of the system it's running on; in our case it was CET (UTC +1). Now this timezone isn't immediately obvious, because if you print it to system out, it seems to have the correct time. However when you convert it with .toInstant() the timezone rears its ugly head. I digged deeper and found Timestamp.valueOf(String s), it does a lot of magic, but in the end it calls its own deprecated constructor new Timestamp(int year, int month, int date, int hour, int minute, int second, int nano). That constructor calls the deprecated constructor of java.util.Date(int year, int month, int date, int hour, int minute, int second) and that is the one doing something with the current timezone on the system. The method Timestamp.valueOf(String s) itself however, is not deprecated and I find this odd. More odd is that Timestamp.valueOf(LocalDateTime dateTime) has a @SuppresWarnings("deprecation") annotation. Thus I found that Timestamp.valueOf("2017-10-04 00:00:00") on a system running in CET timezone yields a different result than one running in UTC timezone. Here is some example code where I put the output of the println's in comments. TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("Europe/Amsterdam"))); Timestamp fromStringCet = Timestamp.valueOf("2017-10-04 00:00:00"); System.out.println(fromStringCet); // 2017-10-04 00:00:00.0 System.out.println(fromStringCet.toInstant()); // 2017-10-03T22:00:00Z TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC)); Timestamp fromStringUtc = Timestamp.valueOf("2017-10-04 00:00:00"); System.out.println(fromStringUtc); // 2017-10-04 00:00:00.0 System.out.println(fromStringUtc.toInstant()); // 2017-10-04T00:00:00Z System.out.println(fromStringCet.equals(fromStringUtc)); // false LocalDateTime localDateTime = LocalDateTime.of(2017, 10, 4, 0, 0, 0); TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("Europe/Amsterdam"))); Timestamp fromLocalDateTimeCet = Timestamp.valueOf(localDateTime); System.out.println(fromLocalDateTimeCet.toInstant()); // 2017-10-03T22:00:00Z TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC)); Timestamp fromLocalDateTimeUtc = Timestamp.valueOf(localDateTime); System.out.println(fromLocalDateTimeUtc.toInstant()); // 2017-10-04 00:00:00.0 System.out.println(fromLocalDateTimeCet.equals(fromLocalDateTimeUtc)); // false So what to do? Some options are: * Make Timestamp.valueOf(String s) deprecated? * Always use UTC when doing the implicit conversion Thoughts? Dave Franken From martinrb at google.com Fri Feb 9 17:15:32 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 9 Feb 2018 09:15:32 -0800 Subject: Weird timezone issues with Timestamp.valueOf(String s) In-Reply-To: <004c01d3a1b7$e1efe9c0$a5cfbd40$@gmail.com> References: <004c01d3a1b7$e1efe9c0$a5cfbd40$@gmail.com> Message-ID: [redirect to core-libs-dev] On Fri, Feb 9, 2018 at 7:08 AM, wrote: > Not that I encourage using date/time classes from the packages of either > java.util or java.sql, but sometimes it happens under the hood. > > > > We found a weird issue with timestamps. > > In our (PostgreSQL) database we have a column of SQL type TIMESTAMP - no > timezone. > > > > When JPA fills our entity field with a java.sql.Timestamp value, it is > given > an inherent timezone of the system it's running on; in our case it was CET > (UTC +1). > > Now this timezone isn't immediately obvious, because if you print it to > system out, it seems to have the correct time. However when you convert it > with .toInstant() the timezone rears its ugly head. > > > > I digged deeper and found Timestamp.valueOf(String s), it does a lot of > magic, but in the end it calls its own deprecated constructor new > Timestamp(int year, int month, int date, int hour, int minute, int second, > int nano). > > That constructor calls the deprecated constructor of java.util.Date(int > year, int month, int date, int hour, int minute, int second) and that is > the one doing something with the current timezone on the system. > > The method Timestamp.valueOf(String s) itself however, is not deprecated > and > I find this odd. > > More odd is that Timestamp.valueOf(LocalDateTime dateTime) has a > @SuppresWarnings("deprecation") annotation. > > > > Thus I found that Timestamp.valueOf("2017-10-04 00:00:00") on a system > running in CET timezone yields a different result than one running in UTC > timezone. > > Here is some example code where I put the output of the println's in > comments. > > > > > TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("Europe/Amsterdam"))); > > Timestamp fromStringCet = Timestamp.valueOf("2017-10-04 00:00:00"); > > System.out.println(fromStringCet); // 2017-10-04 00:00:00.0 > > System.out.println(fromStringCet.toInstant()); // 2017-10-03T22:00:00Z > > > > TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC)); > > Timestamp fromStringUtc = Timestamp.valueOf("2017-10-04 00:00:00"); > > System.out.println(fromStringUtc); // 2017-10-04 00:00:00.0 > > System.out.println(fromStringUtc.toInstant()); // 2017-10-04T00:00:00Z > > > > System.out.println(fromStringCet.equals(fromStringUtc)); // false > > > > LocalDateTime localDateTime = LocalDateTime.of(2017, 10, 4, 0, 0, 0); > > > > > TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("Europe/Amsterdam"))); > > Timestamp fromLocalDateTimeCet = Timestamp.valueOf(localDateTime); > > System.out.println(fromLocalDateTimeCet.toInstant()); // > 2017-10-03T22:00:00Z > > > > TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC)); > > Timestamp fromLocalDateTimeUtc = Timestamp.valueOf(localDateTime); > > System.out.println(fromLocalDateTimeUtc.toInstant()); // 2017-10-04 > 00:00:00.0 > > > > System.out.println(fromLocalDateTimeCet.equals(fromLocalDateTimeUtc)); > // false > > > > So what to do? > > > > Some options are: > > * Make Timestamp.valueOf(String s) deprecated? > * Always use UTC when doing the implicit conversion > > > > Thoughts? > > > > Dave Franken > > > > From jonathan.gibbons at oracle.com Fri Feb 9 18:19:45 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Feb 2018 10:19:45 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7D824E.30007@sibvisions.com> References: <5A7CDACB.50103@oracle.com> <5A7D824E.30007@sibvisions.com> Message-ID: <32d096e3-ede6-168f-84d0-ab987b4b6446@oracle.com> Robert, You misunderstand the operation of the `#!` mechanism [1].? This is a general feature provided on Unix-derived systems, including Linux and MacOS. It provides a way of executing many different types of files, both binary files and text files, based on the first two bytes of a file's content, also known as its "magic number". [2]? The characters `#!` happen to a human-readable representation of a magic number which defines a way to determine a program to process the rest of the file. In the context of the JEP, the program to process the rest of the file should be the Java launcher. Although the feature is provided by the operating system (not the Java launcher) it is mentioned in the context of this JEP because we need to take special action to ignore the contents of the first line, because it is not valid Java source code. This is different from some other programming and scripting languages, in which `#` is a character that introduces a comment, meaning that the rest of the line will be ignored anyway by the existing rules for that language. I would emphasize that the `#!` line is only needed when you want to use the shebang mechanism to directly execute the source file, without even specifying the Java launcher on the command line. You do not need to provide a `#!` line in any situation in which you invoke the Java launcher and pass it a source file, such as this: ??? java HelloWorld.java I will update the JEP to clarify these points. -- Jon [1] https://en.wikipedia.org/wiki/Shebang_(Unix) [2] https://en.wikipedia.org/wiki/Magic_number_(programming) On 2/9/18 3:13 AM, Robert Zenz wrote: > I fail to see why a shebang would be required at all for this proposal, can't > `java` figure out that it was handed a source code file (ends with .java and is > not a class file or jar)? Or alternately provide a switch to run source files? > > > On 09.02.2018 11:51, Volker Simonis wrote: >> Hi Jonathan, >> >> that's an interesting proposal. It is just unfortunate that a Java >> source file starting with "shebang" won't be a legal Java file >> according to the Java Language Specification. Or do you plan to change >> the JLS to allow (and ignore) "shebang" in the first line? >> >> Thanks, >> Volker >> >> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >> wrote: >>> This draft JEP contains a proposal to enhance the java launcher to support >>> running a >>> program supplied as a single file of Java source code. The program will be >>> compiled >>> and run, without the need to explicit invoke javac, or to package up a jar >>> file. >>> >>> For more details, see: >>> >>> http://openjdk.java.net/jeps/8192920 >>> >>> -- Jon From mark.reinhold at oracle.com Fri Feb 9 18:24:13 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 09 Feb 2018 10:24:13 -0800 Subject: JDK 10 Release Candidate Phase: Process proposal In-Reply-To: <20180201194038.25FB915E32F@eggemoggin.niobe.net> References: <20180201194038.25FB915E32F@eggemoggin.niobe.net> Message-ID: <20180209102413.194020439@eggemoggin.niobe.net> 2018/2/1 11:40:38 -0800, mark.reinhold at oracle.com: > Per the JDK 10 schedule [1], we'll enter the Release Candidate Phase next > week, on Thursday, 8 February. > > The goal of this phase is the same as it was for JDK 9: Ensure that we > fix the bugs that are absolutely critical to the success of the release. > > I propose that we use the same process as for JDK 9. I've drafted a page > for this phase and posted it here: > > http://openjdk.java.net/projects/jdk/10/rc > > This phase will run from the Initial Release Candidate milestone, on > 8 February, until the end of the release. > > JDK Committers are invited to comment on this process proposal. If no > objections are raised in one week's time, by 23:00 UTC next Thursday, > 8 February, then this is the process that we'll use. Hearing no objections, this is the process that we'll use for the JDK 10 Release-Candidate Phase. - Mark From jonathan.gibbons at oracle.com Fri Feb 9 18:30:29 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Feb 2018 10:30:29 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> References: <5A7CDACB.50103@oracle.com> <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> Message-ID: On 2/9/18 4:32 AM, Lennart B?rjeson wrote: >> 9 feb. 2018 kl. 00:18 skrev Jonathan Gibbons : >> >> This draft JEP contains a proposal to enhance the |java| launcher to >> support running a >> program supplied as a single file of Java source code. The program will >> be compiled >> and run, without the need to explicit invoke javac, or to package up a >> jar file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 >> >> -- Jon > Most welcome! > > One comment, though: As a linux/unix user, I'd expect the jshell executable to be the processor for jshell scripts, not the compiler ("java"). This would tie in with the established pattern of other shell script processors/repl, e.g. groovysh, or even plain bash. > > Best regards, > > /Lennart Lennart, The content of a source file supported by this feature is the source code for a normal Java class containing a normal "public static void main(String[])" method.? It is not the same as the input you might give to jshell, which is a combination of "snippets" of Java code and commands for the JShell tool, which are designed for use in an interactive environment. -- Jon From brian.goetz at oracle.com Fri Feb 9 19:06:59 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 9 Feb 2018 14:06:59 -0500 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> References: <5A7CDACB.50103@oracle.com> <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> Message-ID: <5eac3bd5-2ddf-97bf-f4d2-4a800b56697e@oracle.com> This is a natural (and common) thought, but it turns out to not be the best answer.? The design of JShell is heavily influenced by the goal of offering a good interactive experience.? When we were first designing JShell, we considered whether we also wanted to ask it to do double-duty as a batch runner (i.e., this was our first thought too), and went through the process of enumerating some of the tradeoffs that would entail -- and concluded that doing so risked compromising the primary (interactive) mission. And, we already have a means of running whole Java programs -- the launcher -- which can already accept its input in multiple forms (single classfile, JAR file, module).? Better to teach it how to accept one more variant input.? New users can run programs with ??? java HelloWorld.java and can later learn that if they want to amortize compilation cost over multiple runs, they can do ??? javac HelloWorld.java ??? java HelloWorld On 2/9/2018 7:32 AM, Lennart B?rjeson wrote: > One comment, though: As a linux/unix user, I'd expect the jshell executable to be the processor for jshell scripts, not the compiler ("java"). This would tie in with the established pattern of other shell script processors/repl, e.g. groovysh, or even plain bash. From jonathan.gibbons at oracle.com Sat Feb 10 16:59:31 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 10 Feb 2018 08:59:31 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> Volker, I don't see a compelling need to change the JLS to accommodate "shebang" files. Most Java source files don't need the `#!` line, including any source file passed to an explicit invocation of the Java launcher. The line is only needed when the file is set up to be directly executed by the "shebang" mechanism, in which case the line can be thought of as a "wrapper" supported by the host system to enable such use. If the feature is sufficiently popular, it may even be that editors will recognize and support the use of such lines, in the same way that some editors recognize and support the manipulation of javadoc comments, which are also not defined in the JLS (beyond the basic definition of a comment in JLS 3.7). -- Jon On 2/9/18 2:51 AM, Volker Simonis wrote: > Hi Jonathan, > > that's an interesting proposal. It is just unfortunate that a Java > source file starting with "shebang" won't be a legal Java file > according to the Java Language Specification. Or do you plan to change > the JLS to allow (and ignore) "shebang" in the first line? > > Thanks, > Volker > > On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons > wrote: >> This draft JEP contains a proposal to enhance the java launcher to support >> running a >> program supplied as a single file of Java source code. The program will be >> compiled >> and run, without the need to explicit invoke javac, or to package up a jar >> file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 >> >> -- Jon From magnus.ihse.bursie at oracle.com Mon Feb 12 11:22:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 12:22:41 +0100 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: <2ca8b9bd-c10b-911a-362a-17d28460e093@oracle.com> Jon, Looks awesome! :) /Magnus On 2018-02-09 00:18, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the |java| launcher to > support running a > program supplied as a single file of Java source code. The program > will be compiled > and run, without the need to explicit invoke javac, or to package up a > jar file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 > > -- Jon From maurizio.cimadamore at oracle.com Mon Feb 12 11:58:05 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 12 Feb 2018 11:58:05 +0000 Subject: CFV: New JDK Committer: Liam Miller-Cushon In-Reply-To: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> References: <2328c7d4-ee8e-4b8f-4cc2-e5af481ed219@oracle.com> Message-ID: <3f4d79f8-51c2-9614-67e6-b506aa3a3f0e@oracle.com> Hi, there was a mistake in the original CFV - votes will be open until *February 21, 2018* Maurizio On 06/02/18 17:39, Maurizio Cimadamore wrote: > I hereby nominate Liam Miller-Cushon (cushon) to JDK Committer. > > Liam has been contributing various fixes and improvements to the > langtools team over the last few years, and he definitively helped > making javac a better place :-) > > A list of his contributions can be found in [1]. > > Votes are due by February 14, 2018. > > Only current JDK Committers [2] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > Maurizio Cimadamore > > [1] - > http://hg.openjdk.java.net/jdk/jdk/search/?rev=author(cushon)&revcount=140 > [2] - http://openjdk.java.net/census > [3] - http://openjdk.java.net/projects/#committer-vote > > > From Roger.Riggs at Oracle.com Mon Feb 12 14:22:40 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 12 Feb 2018 09:22:40 -0500 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> Message-ID: <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Hi Jonathan, It would be? a great convenience to developers to NOT to have two types of java source files. Those that can be run directly and those that cannot. According to the JLS, the former can not be called java source files, they are something else. $.02, Roger On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: > Volker, > > I don't see a compelling need to change the JLS to accommodate > "shebang" files. Most Java source files don't need the `#!` line, > including any source file passed to an explicit invocation of the Java > launcher. The line is only needed when the file is set up to be > directly executed by the "shebang" mechanism, in which case the line > can be thought of as a "wrapper" supported by the host system to > enable such use. If the feature is sufficiently popular, it may even > be that editors will recognize and support the use of such lines, in > the same way that some editors recognize and support the manipulation > of javadoc comments, which are also not defined in the JLS (beyond the > basic definition of a comment in JLS 3.7). > > -- Jon > > > On 2/9/18 2:51 AM, Volker Simonis wrote: >> Hi Jonathan, >> >> that's an interesting proposal. It is just unfortunate that a Java >> source file starting with "shebang" won't be a legal Java file >> according to the Java Language Specification. Or do you plan to change >> the JLS to allow (and ignore) "shebang" in the first line? >> >> Thanks, >> Volker >> >> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >> wrote: >>> This draft JEP contains a proposal to enhance the java launcher to >>> support >>> running a >>> program supplied as a single file of Java source code. The program >>> will be >>> compiled >>> and run, without the need to explicit invoke javac, or to package up >>> a jar >>> file. >>> >>> For more details, see: >>> >>> http://openjdk.java.net/jeps/8192920 >>> >>> -- Jon > From volker.simonis at gmail.com Mon Feb 12 14:38:59 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 12 Feb 2018 15:38:59 +0100 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Message-ID: On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: > Hi Jonathan, > > It would be a great convenience to developers to NOT to have two types of > java source files. > Those that can be run directly and those that cannot. According to the JLS, > the former can not > be called java source files, they are something else. > Yes, that's exactly what I actually wanted to say. The JavaDoc analogy can't be applied here because JavaDoc is completely transparent to the JLS (because it is hidden within a comment). Not sure how hard and controversial it would be tough, to change the JLS to allow and ignore a shebang in the first line? > $.02, Roger > > > > > On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >> >> Volker, >> >> I don't see a compelling need to change the JLS to accommodate "shebang" >> files. Most Java source files don't need the `#!` line, including any source >> file passed to an explicit invocation of the Java launcher. The line is only >> needed when the file is set up to be directly executed by the "shebang" >> mechanism, in which case the line can be thought of as a "wrapper" supported >> by the host system to enable such use. If the feature is sufficiently >> popular, it may even be that editors will recognize and support the use of >> such lines, in the same way that some editors recognize and support the >> manipulation of javadoc comments, which are also not defined in the JLS >> (beyond the basic definition of a comment in JLS 3.7). >> >> -- Jon >> >> >> On 2/9/18 2:51 AM, Volker Simonis wrote: >>> >>> Hi Jonathan, >>> >>> that's an interesting proposal. It is just unfortunate that a Java >>> source file starting with "shebang" won't be a legal Java file >>> according to the Java Language Specification. Or do you plan to change >>> the JLS to allow (and ignore) "shebang" in the first line? >>> >>> Thanks, >>> Volker >>> >>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>> wrote: >>>> >>>> This draft JEP contains a proposal to enhance the java launcher to >>>> support >>>> running a >>>> program supplied as a single file of Java source code. The program will >>>> be >>>> compiled >>>> and run, without the need to explicit invoke javac, or to package up a >>>> jar >>>> file. >>>> >>>> For more details, see: >>>> >>>> http://openjdk.java.net/jeps/8192920 >>>> >>>> -- Jon >> >> > From brian.goetz at oracle.com Mon Feb 12 16:07:10 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 12 Feb 2018 08:07:10 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Message-ID: <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) changes to the compiler. This is all in the command-line launcher. This is not a Java language feature. The scope is JDK, not SE. There are really two features here: - Launch Java source files from the java launcher. - Additionally, strip off the #! line (if present) before passing the source to the compiler, so that the compiler sees a normal Java compilation unit when compiling, to interact nicely with native #! support. > On Feb 12, 2018, at 6:38 AM, Volker Simonis wrote: > > On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: >> Hi Jonathan, >> >> It would be a great convenience to developers to NOT to have two types of >> java source files. >> Those that can be run directly and those that cannot. According to the JLS, >> the former can not >> be called java source files, they are something else. >> > > Yes, that's exactly what I actually wanted to say. The JavaDoc analogy > can't be applied here because JavaDoc is completely transparent to the > JLS (because it is hidden within a comment). Not sure how hard and > controversial it would be tough, to change the JLS to allow and ignore > a shebang in the first line? > >> $.02, Roger >> >> >> >> >> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>> >>> Volker, >>> >>> I don't see a compelling need to change the JLS to accommodate "shebang" >>> files. Most Java source files don't need the `#!` line, including any source >>> file passed to an explicit invocation of the Java launcher. The line is only >>> needed when the file is set up to be directly executed by the "shebang" >>> mechanism, in which case the line can be thought of as a "wrapper" supported >>> by the host system to enable such use. If the feature is sufficiently >>> popular, it may even be that editors will recognize and support the use of >>> such lines, in the same way that some editors recognize and support the >>> manipulation of javadoc comments, which are also not defined in the JLS >>> (beyond the basic definition of a comment in JLS 3.7). >>> >>> -- Jon >>> >>> >>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>> >>>> Hi Jonathan, >>>> >>>> that's an interesting proposal. It is just unfortunate that a Java >>>> source file starting with "shebang" won't be a legal Java file >>>> according to the Java Language Specification. Or do you plan to change >>>> the JLS to allow (and ignore) "shebang" in the first line? >>>> >>>> Thanks, >>>> Volker >>>> >>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>> wrote: >>>>> >>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>> support >>>>> running a >>>>> program supplied as a single file of Java source code. The program will >>>>> be >>>>> compiled >>>>> and run, without the need to explicit invoke javac, or to package up a >>>>> jar >>>>> file. >>>>> >>>>> For more details, see: >>>>> >>>>> http://openjdk.java.net/jeps/8192920 >>>>> >>>>> -- Jon >>> >>> >> From forax at univ-mlv.fr Mon Feb 12 16:26:32 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 Feb 2018 17:26:32 +0100 (CET) Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> Message-ID: <450936868.485966.1518452792838.JavaMail.zimbra@u-pem.fr> I think that stripping the #! should be part of the JLS, so all tools that takes a source code as an input will strip the line and not just the java launcher. And in the future, jshell should also support stripping the first line but that should be done as another JEP or another bug/rfe because this is not directly related to this JEP. R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Volker Simonis" > Cc: "jdk-dev" > Envoy?: Lundi 12 F?vrier 2018 17:07:10 > Objet: Re: Draft JEP: Launch Single-File Source-Code Programs > Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) > changes to the compiler. This is all in the command-line launcher. This is > not a Java language feature. The scope is JDK, not SE. > > There are really two features here: > - Launch Java source files from the java launcher. > - Additionally, strip off the #! line (if present) before passing the source to > the compiler, so that the compiler sees a normal Java compilation unit when > compiling, to interact nicely with native #! support. > > > > >> On Feb 12, 2018, at 6:38 AM, Volker Simonis wrote: >> >> On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: >>> Hi Jonathan, >>> >>> It would be a great convenience to developers to NOT to have two types of >>> java source files. >>> Those that can be run directly and those that cannot. According to the JLS, >>> the former can not >>> be called java source files, they are something else. >>> >> >> Yes, that's exactly what I actually wanted to say. The JavaDoc analogy >> can't be applied here because JavaDoc is completely transparent to the >> JLS (because it is hidden within a comment). Not sure how hard and >> controversial it would be tough, to change the JLS to allow and ignore >> a shebang in the first line? >> >>> $.02, Roger >>> >>> >>> >>> >>> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>>> >>>> Volker, >>>> >>>> I don't see a compelling need to change the JLS to accommodate "shebang" >>>> files. Most Java source files don't need the `#!` line, including any source >>>> file passed to an explicit invocation of the Java launcher. The line is only >>>> needed when the file is set up to be directly executed by the "shebang" >>>> mechanism, in which case the line can be thought of as a "wrapper" supported >>>> by the host system to enable such use. If the feature is sufficiently >>>> popular, it may even be that editors will recognize and support the use of >>>> such lines, in the same way that some editors recognize and support the >>>> manipulation of javadoc comments, which are also not defined in the JLS >>>> (beyond the basic definition of a comment in JLS 3.7). >>>> >>>> -- Jon >>>> >>>> >>>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>>> >>>>> Hi Jonathan, >>>>> >>>>> that's an interesting proposal. It is just unfortunate that a Java >>>>> source file starting with "shebang" won't be a legal Java file >>>>> according to the Java Language Specification. Or do you plan to change >>>>> the JLS to allow (and ignore) "shebang" in the first line? >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>>> wrote: >>>>>> >>>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>>> support >>>>>> running a >>>>>> program supplied as a single file of Java source code. The program will >>>>>> be >>>>>> compiled >>>>>> and run, without the need to explicit invoke javac, or to package up a >>>>>> jar >>>>>> file. >>>>>> >>>>>> For more details, see: >>>>>> >>>>>> http://openjdk.java.net/jeps/8192920 >>>>>> >>>>>> -- Jon >>>> >>>> From jonathan.gibbons at oracle.com Mon Feb 12 16:40:21 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Feb 2018 08:40:21 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Message-ID: <9ca0e93e-f273-69d9-05f0-2e3f3f3d7309@oracle.com> The JLS is primarily concerned about the abstract content of compilation units, and generally stays clear of any issues related to how and where compilation units are actually stored. From the earliest days, it has admitted the possibility that compilation units may be stored in "non-traditional" storage formats such as a database.? So, it is not fair to say that "according to the JLS [they] cannot be called Java source files." In the current JLS, it goes so far as to say: 7.2. Host Support for Modules and Packages Each host system determines how modules, packages, and compilation units are created and stored. But even that assurance does not need to come into play here. Since JDK 6, with the introduction of the Compiler API (javax.tools.*, JSR 199) the compiler has permitted a compilation unit to be provided in a "JavaFileObject". Using JavaFileObjects, you can provide compilation units to a compiler that come from traditional source files, entries in zip files, or from in-memory objects like Strings and more complex representations like the buffers for IDE editor windows.? That ability can come into play here: the source file launcher can create a JavaFileObject containing the compilation unit found in the file, and can pass that JavaFileObject to the compiler via the standard javax.tools API, with no changes required to the compiler at all. So, I agree that the "shebang" files we are talking about are not regular Java source files, and cannot be passed in their entirety to a Java compiler. Maybe we need to come up with a more specific name for such files. But as far as as their content is concerned, the compilation unit passed by the source launcher to the compiler is a standard compilation unit, as defined in the JLS. -- Jon On 2/12/18 6:22 AM, Roger Riggs wrote: > Hi Jonathan, > > It would be? a great convenience to developers to NOT to have two > types of java source files. > Those that can be run directly and those that cannot. According to the > JLS, the former can not > be called java source files, they are something else. > > $.02, Roger > > > > On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >> Volker, >> >> I don't see a compelling need to change the JLS to accommodate >> "shebang" files. Most Java source files don't need the `#!` line, >> including any source file passed to an explicit invocation of the >> Java launcher. The line is only needed when the file is set up to be >> directly executed by the "shebang" mechanism, in which case the line >> can be thought of as a "wrapper" supported by the host system to >> enable such use. If the feature is sufficiently popular, it may even >> be that editors will recognize and support the use of such lines, in >> the same way that some editors recognize and support the manipulation >> of javadoc comments, which are also not defined in the JLS (beyond >> the basic definition of a comment in JLS 3.7). >> >> -- Jon >> >> >> On 2/9/18 2:51 AM, Volker Simonis wrote: >>> Hi Jonathan, >>> >>> that's an interesting proposal. It is just unfortunate that a Java >>> source file starting with "shebang" won't be a legal Java file >>> according to the Java Language Specification. Or do you plan to change >>> the JLS to allow (and ignore) "shebang" in the first line? >>> >>> Thanks, >>> Volker >>> >>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>> wrote: >>>> This draft JEP contains a proposal to enhance the java launcher to >>>> support >>>> running a >>>> program supplied as a single file of Java source code. The program >>>> will be >>>> compiled >>>> and run, without the need to explicit invoke javac, or to package >>>> up a jar >>>> file. >>>> >>>> For more details, see: >>>> >>>> http://openjdk.java.net/jeps/8192920 >>>> >>>> -- Jon >> > From Roger.Riggs at Oracle.com Mon Feb 12 16:42:25 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 12 Feb 2018 11:42:25 -0500 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> Message-ID: <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> Hi Brian, Yes, that works fine if that shebang? .java file is used with the launcher. But what does not work is using that same .java file with javac. Not a debilitating restriction but an asymmetry and a bump in the road for some. And it might backflow into the build system, where some .java files should be compiled with the java launcher and others with javac. Thanks, Roger On 2/12/2018 11:07 AM, Brian Goetz wrote: > Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) changes to the compiler. This is all in the command-line launcher. This is not a Java language feature. The scope is JDK, not SE. > > There are really two features here: > - Launch Java source files from the java launcher. > - Additionally, strip off the #! line (if present) before passing the source to the compiler, so that the compiler sees a normal Java compilation unit when compiling, to interact nicely with native #! support. > > > > >> On Feb 12, 2018, at 6:38 AM, Volker Simonis wrote: >> >> On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: >>> Hi Jonathan, >>> >>> It would be a great convenience to developers to NOT to have two types of >>> java source files. >>> Those that can be run directly and those that cannot. According to the JLS, >>> the former can not >>> be called java source files, they are something else. >>> >> Yes, that's exactly what I actually wanted to say. The JavaDoc analogy >> can't be applied here because JavaDoc is completely transparent to the >> JLS (because it is hidden within a comment). Not sure how hard and >> controversial it would be tough, to change the JLS to allow and ignore >> a shebang in the first line? >> >>> $.02, Roger >>> >>> >>> >>> >>> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>>> Volker, >>>> >>>> I don't see a compelling need to change the JLS to accommodate "shebang" >>>> files. Most Java source files don't need the `#!` line, including any source >>>> file passed to an explicit invocation of the Java launcher. The line is only >>>> needed when the file is set up to be directly executed by the "shebang" >>>> mechanism, in which case the line can be thought of as a "wrapper" supported >>>> by the host system to enable such use. If the feature is sufficiently >>>> popular, it may even be that editors will recognize and support the use of >>>> such lines, in the same way that some editors recognize and support the >>>> manipulation of javadoc comments, which are also not defined in the JLS >>>> (beyond the basic definition of a comment in JLS 3.7). >>>> >>>> -- Jon >>>> >>>> >>>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>>> Hi Jonathan, >>>>> >>>>> that's an interesting proposal. It is just unfortunate that a Java >>>>> source file starting with "shebang" won't be a legal Java file >>>>> according to the Java Language Specification. Or do you plan to change >>>>> the JLS to allow (and ignore) "shebang" in the first line? >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>>> wrote: >>>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>>> support >>>>>> running a >>>>>> program supplied as a single file of Java source code. The program will >>>>>> be >>>>>> compiled >>>>>> and run, without the need to explicit invoke javac, or to package up a >>>>>> jar >>>>>> file. >>>>>> >>>>>> For more details, see: >>>>>> >>>>>> http://openjdk.java.net/jeps/8192920 >>>>>> >>>>>> -- Jon >>>> From sean.mullan at oracle.com Mon Feb 12 16:47:57 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Feb 2018 11:47:57 -0500 Subject: Fwd: SecurityManager Survey In-Reply-To: References: Message-ID: Hello, Just a reminder that the SecurityManager survey will be open through Friday, February 16. Please consider taking the survey if you have not yet and you use the SecurityManager as described below. Thanks to everyone that has completed the survey so far. --Sean -------- Forwarded Message -------- Subject: SecurityManager Survey Date: Mon, 5 Feb 2018 11:31:37 -0500 From: Sean Mullan Organization: Oracle Corporation To: sean.mullan at oracle.com, jdk-dev at openjdk.java.net Hello, The SecurityManager has been in Java SE for a long time, but we don't have a lot of data about how it is used in practice, especially outside of applets and Web Start apps. Thus, we have created an initial survey to gather more information and help us evaluate and understand how others are using it. If you have written or maintain code that uses the SecurityManager or related APIs such as the AccessController, then we would appreciate if you would complete this survey: https://www.surveymonkey.com/r/RSGMF3K We are specifically interested in use-cases other than applets or Web Start applications; for example, server applications, tools and libraries that have been designed to run properly when a SecurityManager is enabled. The survey will remain open through February 16th. The results of the survey will be made public after the survey closes. Thank you, Sean Mullan OpenJDK Security Group Lead http://openjdk.java.net/groups/security/ From jonathan.gibbons at oracle.com Mon Feb 12 16:51:47 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Feb 2018 08:51:47 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> Message-ID: <7bb89230-f847-aa54-94ac-e644fcfe3805@oracle.com> On 2/12/18 8:07 AM, Brian Goetz wrote: > Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) changes to the compiler. This is all in the command-line launcher. This is not a Java language feature. The scope is JDK, not SE. > > There are really two features here: > - Launch Java source files from the java launcher. > - Additionally, strip off the #! line (if present) before passing the source to the compiler, so that the compiler sees a normal Java compilation unit when compiling, to interact nicely with native #! support. Yes.? It has always been possible for anyone to write and provide an executable that could be specified in a #! line, that would strip the first line, and compile and run the class declared in the rest of the file.? That could be done by anyone, for any Java compiler and VM, and without needing to change JLS. The novelty here is to do it in the Java launcher, where, among other benefits, we have access to VM options that may be relevant for the compilation, such as the classpath and related options. -- Jon > > > >> On Feb 12, 2018, at 6:38 AM, Volker Simonis wrote: >> >> On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: >>> Hi Jonathan, >>> >>> It would be a great convenience to developers to NOT to have two types of >>> java source files. >>> Those that can be run directly and those that cannot. According to the JLS, >>> the former can not >>> be called java source files, they are something else. >>> >> Yes, that's exactly what I actually wanted to say. The JavaDoc analogy >> can't be applied here because JavaDoc is completely transparent to the >> JLS (because it is hidden within a comment). Not sure how hard and >> controversial it would be tough, to change the JLS to allow and ignore >> a shebang in the first line? >> >>> $.02, Roger >>> >>> >>> >>> >>> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>>> Volker, >>>> >>>> I don't see a compelling need to change the JLS to accommodate "shebang" >>>> files. Most Java source files don't need the `#!` line, including any source >>>> file passed to an explicit invocation of the Java launcher. The line is only >>>> needed when the file is set up to be directly executed by the "shebang" >>>> mechanism, in which case the line can be thought of as a "wrapper" supported >>>> by the host system to enable such use. If the feature is sufficiently >>>> popular, it may even be that editors will recognize and support the use of >>>> such lines, in the same way that some editors recognize and support the >>>> manipulation of javadoc comments, which are also not defined in the JLS >>>> (beyond the basic definition of a comment in JLS 3.7). >>>> >>>> -- Jon >>>> >>>> >>>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>>> Hi Jonathan, >>>>> >>>>> that's an interesting proposal. It is just unfortunate that a Java >>>>> source file starting with "shebang" won't be a legal Java file >>>>> according to the Java Language Specification. Or do you plan to change >>>>> the JLS to allow (and ignore) "shebang" in the first line? >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>>> wrote: >>>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>>> support >>>>>> running a >>>>>> program supplied as a single file of Java source code. The program will >>>>>> be >>>>>> compiled >>>>>> and run, without the need to explicit invoke javac, or to package up a >>>>>> jar >>>>>> file. >>>>>> >>>>>> For more details, see: >>>>>> >>>>>> http://openjdk.java.net/jeps/8192920 >>>>>> >>>>>> -- Jon >>>> From brian.goetz at oracle.com Mon Feb 12 16:47:29 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 12 Feb 2018 08:47:29 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> Message-ID: <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> I don?t think that?s a concern worth worrying about. Think about why people use shebang in the first place; they want to launch the file from the shell without saying ?java? (or ?python? or ?bash? or ?) At this point, the file has likely entered the terminal phase of its life ? it is installed as a script. The use case of ?I might want to run it standalone as a script, or compile it as part of a larger source base? seems somewhat contrived. And for those cases, fine ? run it with ?java ?source?, rather than shebang. I don?t think its a bump that anyone who actually uses will be surprised at. The alternative ? intruding this convention on the Java language syntax ? is certainly a worse tradeoff. Think of this as ?launcher 90% full? rather than ?language 10% empty? :) > On Feb 12, 2018, at 8:42 AM, Roger Riggs wrote: > > Hi Brian, > > Yes, that works fine if that shebang .java file is used with the launcher. > But what does not work is using that same .java file with javac. > Not a debilitating restriction but an asymmetry and a bump in the road for some. > And it might backflow into the build system, where some .java files should be compiled > with the java launcher and others with javac. > > Thanks, Roger > > On 2/12/2018 11:07 AM, Brian Goetz wrote: >> Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) changes to the compiler. This is all in the command-line launcher. This is not a Java language feature. The scope is JDK, not SE. >> >> There are really two features here: >> - Launch Java source files from the java launcher. >> - Additionally, strip off the #! line (if present) before passing the source to the compiler, so that the compiler sees a normal Java compilation unit when compiling, to interact nicely with native #! support. >> >> >> >> >>> On Feb 12, 2018, at 6:38 AM, Volker Simonis wrote: >>> >>> On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: >>>> Hi Jonathan, >>>> >>>> It would be a great convenience to developers to NOT to have two types of >>>> java source files. >>>> Those that can be run directly and those that cannot. According to the JLS, >>>> the former can not >>>> be called java source files, they are something else. >>>> >>> Yes, that's exactly what I actually wanted to say. The JavaDoc analogy >>> can't be applied here because JavaDoc is completely transparent to the >>> JLS (because it is hidden within a comment). Not sure how hard and >>> controversial it would be tough, to change the JLS to allow and ignore >>> a shebang in the first line? >>> >>>> $.02, Roger >>>> >>>> >>>> >>>> >>>> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>>>> Volker, >>>>> >>>>> I don't see a compelling need to change the JLS to accommodate "shebang" >>>>> files. Most Java source files don't need the `#!` line, including any source >>>>> file passed to an explicit invocation of the Java launcher. The line is only >>>>> needed when the file is set up to be directly executed by the "shebang" >>>>> mechanism, in which case the line can be thought of as a "wrapper" supported >>>>> by the host system to enable such use. If the feature is sufficiently >>>>> popular, it may even be that editors will recognize and support the use of >>>>> such lines, in the same way that some editors recognize and support the >>>>> manipulation of javadoc comments, which are also not defined in the JLS >>>>> (beyond the basic definition of a comment in JLS 3.7). >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>>>> Hi Jonathan, >>>>>> >>>>>> that's an interesting proposal. It is just unfortunate that a Java >>>>>> source file starting with "shebang" won't be a legal Java file >>>>>> according to the Java Language Specification. Or do you plan to change >>>>>> the JLS to allow (and ignore) "shebang" in the first line? >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>>>> wrote: >>>>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>>>> support >>>>>>> running a >>>>>>> program supplied as a single file of Java source code. The program will >>>>>>> be >>>>>>> compiled >>>>>>> and run, without the need to explicit invoke javac, or to package up a >>>>>>> jar >>>>>>> file. >>>>>>> >>>>>>> For more details, see: >>>>>>> >>>>>>> http://openjdk.java.net/jeps/8192920 >>>>>>> >>>>>>> -- Jon >>>>> > From john.r.rose at oracle.com Mon Feb 12 18:42:49 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 12 Feb 2018 10:42:49 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> Message-ID: On Feb 12, 2018, at 8:47 AM, Brian Goetz wrote: > The alternative ? intruding this convention on the Java language syntax ? is certainly a worse tradeoff. Think of this as ?launcher 90% full? rather than ?language 10% empty? :) This is all good, and I agree that we don't need to add shebang to the JLS. (See argument below.) But, the proposal doesn't fully match the design of shebang processing. I'd like to discuss that and propose a slight tweak. The purpose of the shebang is to allow a Unix command to be implemented by a script file with a designated script interpreter. This only works if the file is executable and is implemented by the system call execve[1]. BTW, marking a file executable without a shebang sends it to /bin/sh, but by a higher layer[2] of the system, not used in all cases. [1] https://linux.die.net/man/2/execve (OS-level definition of shebang) [2] https://linux.die.net/man/3/execl (library function adds implicit #! /bin/sh) This predates modern mechanisms, such as desktop launchers, which systematically recognize file extensions and map them to content types. This is important: Shebang doesn't care about file name extensions. The optional argument to the script interpreter, as supported by shebang, allows the interpreter to be run in a non-default scripting mode which accepts the two oddities which come from shebang: 1. the file starts with a shebang (which otherwise might be unexpected by the interpreter), 2. the file name might not have an extension expected by the interpreter (because it is a nondescript command name, implemented by a script). The dtrace '-s' option does this, and so (I presume) would the java '--source' option. Higher-level launchers, above the level of the "exec*" families, look at file extensions, such as "*.jar" or "*.app". These do not integrate as directly with Unix shell scripting, since "exec*" won't launch them. The net: The design of shebang expects the interpreter to (sometimes) require nonstandard invocation modes to process the shebang file. The physical form of the file name is insignificant to shebang processing, although it may (of course) be significant to the interpreter. A quick survey of shebangs on my Mac show the following interpreters used on my $PATH: /bin/*sh [-vepf], *python [-OR], /usr/bin/env *, perl* [-w], ruby, *lua, dtrace -[q]s. Only dtrace uses a specific script flag in all cases. At least one language (lua) documents shebang stripping as lexical exception, but only in a particular invocation mode. We can get the same effect by factoring the exception into the launcher, not the JLS. The applications to the present case: From the point of view of the design and use of shebang, it is reasonable to treat shebang as an extra-linguistic construct, to be stripped by a special mode of the script language processor (java). From the same point of view, it is not reasonable to require a special file extension (such as *.java) to the shebang file, since that removes the main use case of shebang, building arbitrary Unix commands on top of scripts. So, if we want to properly integrate with the shebang, we need to drop the requirement that the file name end with ".java", in the presence of the "--source" option. If the "--source" option is missing, it's fine to require the "*.java" file name extension, as a nod to EOU. And it's fine to have non-standard file processing (shebang removal) under a special invocation mode ("java --source"). We might forbid shebang unless the "--source" option is present. That would make it clearer that a non-standard mode is present. It would be even more pedantically correct if there were a special "--shebang" mode (not its real name), leaving "--source" to accept only standard Java without shebang. My bottom line suggestions: allow "java --source any-path" not just "java --source path.java" and strip shebang in that case; this enables full-range use of shebang in Unix. Allow also "java path.java", but take a moment to reconsider whether shebang makes sense in that case. ? John From mark.reinhold at oracle.com Mon Feb 12 18:51:50 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 12 Feb 2018 10:51:50 -0800 (PST) Subject: JDK 10: First Release Candidate Message-ID: <20180212185150.8318A15F4AC@eggemoggin.niobe.net> There are no unresolved P1 bugs in build 43, so that is our first JDK 10 Release Candidate. Binaries available here, as usual: http://jdk.java.net/10 - Mark From david.lloyd at redhat.com Mon Feb 12 19:43:37 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 12 Feb 2018 13:43:37 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the java launcher to support > running a > program supplied as a single file of Java source code. The program will be > compiled > and run, without the need to explicit invoke javac, or to package up a jar > file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 Sorry if I just missed this somehow, but how would one set the Java source version in use? This seems like it would be necessary in order to ensure forwards-compatibility. Other scripting languages that launch in this way allow for printing (or disabling) compilation warnings, so maybe that should also be a consideration? I assume that the annotation processing pipeline would explicitly be excluded in this mode? Also I'm finding it really hard to avoid saying "Java script". /me slaps self briskly -- - DML From jonathan.gibbons at oracle.com Mon Feb 12 20:01:07 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Feb 2018 12:01:07 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> Message-ID: <5A81F283.2030208@oracle.com> On 02/12/2018 10:42 AM, John Rose wrote: > On Feb 12, 2018, at 8:47 AM, Brian Goetz wrote: > >> The alternative ? intruding this convention on the Java language syntax ? is certainly a worse tradeoff. Think of this as ?launcher 90% full? rather than ?language 10% empty? :) > > This is all good, and I agree that we don't need to add shebang to > the JLS. (See argument below.) But, the proposal doesn't fully > match the design of shebang processing. I'd like to discuss that > and propose a slight tweak. > > The purpose of the shebang is to allow a Unix command to be > implemented by a script file with a designated script interpreter. > This only works if the file is executable and is implemented by > the system call execve[1]. BTW, marking a file executable without a > shebang sends it to /bin/sh, but by a higher layer[2] of the system, > not used in all cases. > > [1] https://linux.die.net/man/2/execve (OS-level definition of shebang) > [2] https://linux.die.net/man/3/execl (library function adds implicit #! /bin/sh) > > This predates modern mechanisms, such as desktop launchers, > which systematically recognize file extensions and map them to > content types. This is important: Shebang doesn't care about > file name extensions. > > The optional argument to the script interpreter, as supported by > shebang, allows the interpreter to be run in a non-default scripting > mode which accepts the two oddities which come from shebang: > 1. the file starts with a shebang (which otherwise might be unexpected > by the interpreter), 2. the file name might not have an extension > expected by the interpreter (because it is a nondescript command > name, implemented by a script). The dtrace '-s' option does this, > and so (I presume) would the java '--source' option. > > Higher-level launchers, above the level of the "exec*" families, > look at file extensions, such as "*.jar" or "*.app". These do > not integrate as directly with Unix shell scripting, since "exec*" > won't launch them. > > The net: The design of shebang expects the interpreter to (sometimes) > require nonstandard invocation modes to process the shebang file. > The physical form of the file name is insignificant to shebang processing, > although it may (of course) be significant to the interpreter. > > A quick survey of shebangs on my Mac show the following interpreters > used on my $PATH: /bin/*sh [-vepf], *python [-OR], /usr/bin/env *, > perl* [-w], ruby, *lua, dtrace -[q]s. Only dtrace uses a specific script flag > in all cases. > > At least one language (lua) documents shebang stripping as lexical > exception, but only in a particular invocation mode. We can get the > same effect by factoring the exception into the launcher, not the JLS. > > The applications to the present case: From the point of view of the > design and use of shebang, it is reasonable to treat shebang > as an extra-linguistic construct, to be stripped by a special mode > of the script language processor (java). From the same point of view, > it is not reasonable to require a special file extension (such as *.java) > to the shebang file, since that removes the main use case of shebang, > building arbitrary Unix commands on top of scripts. > > So, if we want to properly integrate with the shebang, we need to drop > the requirement that the file name end with ".java", in the presence > of the "--source" option. If the "--source" option is missing, it's fine > to require the "*.java" file name extension, as a nod to EOU. > > And it's fine to have non-standard file processing (shebang removal) > under a special invocation mode ("java --source"). > > We might forbid shebang unless the "--source" option is present. That > would make it clearer that a non-standard mode is present. It would be > even more pedantically correct if there were a special "--shebang" mode > (not its real name), leaving "--source" to accept only standard Java > without shebang. > > My bottom line suggestions: allow "java --source any-path" not just > "java --source path.java" and strip shebang in that case; this enables > full-range use of shebang in Unix. Allow also "java path.java", but > take a moment to reconsider whether shebang makes sense in that > case. > > ? John John, Thank you for your detailed analysis of the landscape of the "shebang" mechanism and files. With respect to your bottom-line suggestions, it is definitely the intent to allow "java --source any-path", to facilitate full-range use of shebang in Unix. It would be easy to go either way with regarding to permitting shebang lines when the --source option is not used. I'll admit to some attraction to restricting the use of shebang lines to those cases where the --source option is used. While I note your pedantry with regard to having two options, --shebang (not its real name) and --source, it is not clear there is enough benefit to making a distinction here ... in other words, there is merit in having a special option to invoke special behavior for files with a non-standard naming and possible shebang first line, but there is not enough merit in having an additional option for source files that follow the naming convention and which just contain a standard compilation unit. -- Jon From jonathan.gibbons at oracle.com Mon Feb 12 20:26:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Feb 2018 12:26:42 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <5A81F882.70004@oracle.com> On 02/12/2018 11:43 AM, David Lloyd wrote: > On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons > wrote: >> This draft JEP contains a proposal to enhance the java launcher to support >> running a >> program supplied as a single file of Java source code. The program will be >> compiled >> and run, without the need to explicit invoke javac, or to package up a jar >> file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 > Sorry if I just missed this somehow, but how would one set the Java > source version in use? This seems like it would be necessary in order > to ensure forwards-compatibility. This would only be an issue for shebang files; if you are using the Java launcher explicitly, the source version would be the default version for the Java launcher. For shebang files, it is normal practice to put an absolute pathname for the executable. If you are concerned about long term compatibility, you could use the path for a specific version of JDK. > > Other scripting languages that launch in this way allow for printing > (or disabling) compilation warnings, so maybe that should also be a > consideration? It's an interesting issue that merits discussion. JLS does mandate that warnings should be generated in some circumstances, but allows them to be suppressed with @SuppressWarnings. javac does generate some warnings that cannot be suppressed with @SuppressWarnings, but in all such cases, it is possible to change the source code to avoid the warning without changing the underlying functionality. The bottom line is that it should always be possible to compile a program without warnings, and so there should be no need to provide any extra mechanisms in this area in the Java launcher. > > I assume that the annotation processing pipeline would explicitly be > excluded in this mode? It is not clear to me that there is an inherent need to disable the annotation processing pipeline, but it is true that if it is not disabled, its use would be severely restricted, not least by the inability to specify any custom options for annotation processing. Performing annotation processing would seem to be way beyond the anticipated use cases, and so it may end up being desirable, for simplicity, to disable annotation processing in this mode. The general rule here is, if you need to pass options to the compiler, you should be invoking the compiler directly, in the standard manner. > > Also I'm finding it really hard to avoid saying "Java script". /me > slaps self briskly > From david.lloyd at redhat.com Mon Feb 12 20:59:42 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 12 Feb 2018 14:59:42 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A81F882.70004@oracle.com> References: <5A7CDACB.50103@oracle.com> <5A81F882.70004@oracle.com> Message-ID: On Mon, Feb 12, 2018 at 2:26 PM, Jonathan Gibbons wrote: > On 02/12/2018 11:43 AM, David Lloyd wrote: >> Sorry if I just missed this somehow, but how would one set the Java >> source version in use? This seems like it would be necessary in order >> to ensure forwards-compatibility. > > This would only be an issue for shebang files; if you are using the Java > launcher explicitly, the source version would be the default version > for the Java launcher. For shebang files, it is normal practice to put > an absolute pathname for the executable. If you are concerned about > long term compatibility, you could use the path for a specific version > of JDK. I don't think you can really assume that specific versions of the JDK will always be present at specific locations on most operating systems and installations. Probably what is going to happen in reality is that there will be scripts out there, and some hapless user will upgrade their OS JDK, and everything will break. I think that specifying a source version will probably be necessary. -- - DML From david.lloyd at redhat.com Mon Feb 12 21:37:45 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 12 Feb 2018 15:37:45 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the java launcher to support > running a > program supplied as a single file of Java source code. The program will be > compiled > and run, without the need to explicit invoke javac, or to package up a jar > file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 It was pointed out on IRC that it would seem almost more fitting to fit this in to javax.script as a ScriptEngine, using the existing jrunscript as a launcher instead of java. Weird but also not weird at all! It would be worth explaining why this shouldn't be the case in the JEP (if indeed it shouldn't be the case). -- - DML From jonathan.gibbons at oracle.com Mon Feb 12 23:07:30 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Feb 2018 15:07:30 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: On 2/12/18 1:37 PM, David Lloyd wrote: > On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons > wrote: >> This draft JEP contains a proposal to enhance the java launcher to support >> running a >> program supplied as a single file of Java source code. The program will be >> compiled >> and run, without the need to explicit invoke javac, or to package up a jar >> file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 > It was pointed out on IRC that it would seem almost more fitting to > fit this in to javax.script as a ScriptEngine, using the existing > jrunscript as a launcher instead of java. Weird but also not weird at > all! > > It would be worth explaining why this shouldn't be the case in the JEP > (if indeed it shouldn't be the case). Good question. I note that jrunscript is listed as "Note: This tool isexperimental?and unsupported.". Also, it does not appear to be shebang-friendly, since it would require a number of options to configure, and shebang lines should generally contain at most a single option after the path for the executable. -- Jon From david.holmes at oracle.com Tue Feb 13 00:29:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Feb 2018 10:29:46 +1000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> Message-ID: <7b2bedc5-f863-fbaa-0d28-cb06160b8f21@oracle.com> On 13/02/2018 2:47 AM, Brian Goetz wrote: > I don?t think that?s a concern worth worrying about. Think about why people use shebang in the first place; they want to launch the file from the shell without saying ?java? (or ?python? or ?bash? or ?) At this point, the file has likely entered the terminal phase of its life ? it is installed as a script. The use case of ?I might want to run it standalone as a script, or compile it as part of a larger source base? seems somewhat contrived. And for those cases, fine ? run it with ?java ?source?, rather than shebang. I don?t think its a bump that anyone who actually uses will be surprised at. Ironically(?) I find that most of the files I have to execute that contain shebangs do not have the execute bit set (all scripts in our repos!) and so I have to say "bash ...". > The alternative ? intruding this convention on the Java language syntax ? is certainly a worse tradeoff. Think of this as ?launcher 90% full? rather than ?language 10% empty? :) IMHO it's a wart to have javac barf on what appears to be a regular Java source file because of a shebang line. Even if this is outside the scope of JLS, any tools in OpenJDK that can process "Java source files" should be specified to skip the shebang line. Cheers, David > > >> On Feb 12, 2018, at 8:42 AM, Roger Riggs wrote: >> >> Hi Brian, >> >> Yes, that works fine if that shebang .java file is used with the launcher. >> But what does not work is using that same .java file with javac. >> Not a debilitating restriction but an asymmetry and a bump in the road for some. >> And it might backflow into the build system, where some .java files should be compiled >> with the java launcher and others with javac. >> >> Thanks, Roger >> >> On 2/12/2018 11:07 AM, Brian Goetz wrote: >>> Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) changes to the compiler. This is all in the command-line launcher. This is not a Java language feature. The scope is JDK, not SE. >>> >>> There are really two features here: >>> - Launch Java source files from the java launcher. >>> - Additionally, strip off the #! line (if present) before passing the source to the compiler, so that the compiler sees a normal Java compilation unit when compiling, to interact nicely with native #! support. >>> >>> >>> >>> >>>> On Feb 12, 2018, at 6:38 AM, Volker Simonis wrote: >>>> >>>> On Mon, Feb 12, 2018 at 3:22 PM, Roger Riggs wrote: >>>>> Hi Jonathan, >>>>> >>>>> It would be a great convenience to developers to NOT to have two types of >>>>> java source files. >>>>> Those that can be run directly and those that cannot. According to the JLS, >>>>> the former can not >>>>> be called java source files, they are something else. >>>>> >>>> Yes, that's exactly what I actually wanted to say. The JavaDoc analogy >>>> can't be applied here because JavaDoc is completely transparent to the >>>> JLS (because it is hidden within a comment). Not sure how hard and >>>> controversial it would be tough, to change the JLS to allow and ignore >>>> a shebang in the first line? >>>> >>>>> $.02, Roger >>>>> >>>>> >>>>> >>>>> >>>>> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>>>>> Volker, >>>>>> >>>>>> I don't see a compelling need to change the JLS to accommodate "shebang" >>>>>> files. Most Java source files don't need the `#!` line, including any source >>>>>> file passed to an explicit invocation of the Java launcher. The line is only >>>>>> needed when the file is set up to be directly executed by the "shebang" >>>>>> mechanism, in which case the line can be thought of as a "wrapper" supported >>>>>> by the host system to enable such use. If the feature is sufficiently >>>>>> popular, it may even be that editors will recognize and support the use of >>>>>> such lines, in the same way that some editors recognize and support the >>>>>> manipulation of javadoc comments, which are also not defined in the JLS >>>>>> (beyond the basic definition of a comment in JLS 3.7). >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> that's an interesting proposal. It is just unfortunate that a Java >>>>>>> source file starting with "shebang" won't be a legal Java file >>>>>>> according to the Java Language Specification. Or do you plan to change >>>>>>> the JLS to allow (and ignore) "shebang" in the first line? >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>>>>> wrote: >>>>>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>>>>> support >>>>>>>> running a >>>>>>>> program supplied as a single file of Java source code. The program will >>>>>>>> be >>>>>>>> compiled >>>>>>>> and run, without the need to explicit invoke javac, or to package up a >>>>>>>> jar >>>>>>>> file. >>>>>>>> >>>>>>>> For more details, see: >>>>>>>> >>>>>>>> http://openjdk.java.net/jeps/8192920 >>>>>>>> >>>>>>>> -- Jon >>>>>> >> > From jai.forums2013 at gmail.com Tue Feb 13 04:19:32 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 13 Feb 2018 09:49:32 +0530 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Message-ID: Hi Jonathan, The motivation behind this feature, as noted in the motivation section, IMO is good - to allow developers getting started with Java to be able to try out small utility programs without having to go through multiple different tools/commands. As such, the first part of the JEP which states that the java tool would be enhanced to support this feature sounds reasonable. However, the additional change/enhancement to support shebang files, IMO, just adds more complexities to support, what I think, is a non-existent requirement. Complexities/questions like: - Given that the feature is mostly targeted towards new users, what purpose would a shebang serve for such users, if they are on a Windows OS. Not starting a OS war, but it still is the most used OS for development, which effectively would mean that not many will use this shebang feature, IMO. - What happens when the user moves one step forward in learning Java and now wants to use this existing class (which has a shebang) along with some other newer class(es) and wants to compile and build the application? How would other tools like (javac) react to it? Would those tools too now understand the shebang mechanism? - I'm not an expert on compilers, but AFAIK, Eclipse IDE uses its own compiler. Would that mean that these external compilers too will have to now understand and support the shebang support? Personally, except for the proposal to support shebang, the JEP looks good. -Jaikiran On 12/02/18 7:52 PM, Roger Riggs wrote: > Hi Jonathan, > > It would be? a great convenience to developers to NOT to have two > types of java source files. > Those that can be run directly and those that cannot. According to the > JLS, the former can not > be called java source files, they are something else. > > $.02, Roger > > > > On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >> Volker, >> >> I don't see a compelling need to change the JLS to accommodate >> "shebang" files. Most Java source files don't need the `#!` line, >> including any source file passed to an explicit invocation of the >> Java launcher. The line is only needed when the file is set up to be >> directly executed by the "shebang" mechanism, in which case the line >> can be thought of as a "wrapper" supported by the host system to >> enable such use. If the feature is sufficiently popular, it may even >> be that editors will recognize and support the use of such lines, in >> the same way that some editors recognize and support the manipulation >> of javadoc comments, which are also not defined in the JLS (beyond >> the basic definition of a comment in JLS 3.7). >> >> -- Jon >> >> >> On 2/9/18 2:51 AM, Volker Simonis wrote: >>> Hi Jonathan, >>> >>> that's an interesting proposal. It is just unfortunate that a Java >>> source file starting with "shebang" won't be a legal Java file >>> according to the Java Language Specification. Or do you plan to change >>> the JLS to allow (and ignore) "shebang" in the first line? >>> >>> Thanks, >>> Volker >>> >>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>> wrote: >>>> This draft JEP contains a proposal to enhance the java launcher to >>>> support >>>> running a >>>> program supplied as a single file of Java source code. The program >>>> will be >>>> compiled >>>> and run, without the need to explicit invoke javac, or to package >>>> up a jar >>>> file. >>>> >>>> For more details, see: >>>> >>>> http://openjdk.java.net/jeps/8192920 >>>> >>>> -- Jon >> > From thomas.stuefe at gmail.com Tue Feb 13 08:35:40 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Feb 2018 09:35:40 +0100 Subject: Some questions about the jdk-submit process Message-ID: Hello all, The jdk-submit tests are potentially quite useful but I am still confused about a lot of things: - Last week I pushed twice and received seven result mails. Is that normal (e.g. do you execute multiple test suites per push)? Or was that just a fluke and I should expect just one test result mail per push? - Is there any way to tie a result mail to a push? If not, would it be possible to add the changeset id of the branch head to the mail? - As background information, on what platforms do you build and test, and what are the jvm build configurations? - Also, which tests are executed? Is they related to the "tierxxx" tests I read about on the lists, and if yes, is that internal Oracle lingo or does exist documentation somewhere what these tests are? - Related to that, were I to add new jtreg of gtest tests to my branch, would they be executed? - Finally, what do I do with the errors in my tests? Is there a way to get information, more test output or similar? Because right now all I see is is information like that: "tier1-comp-jdk_open_test_hotspot_jtreg_hotspot_tier1_compiler_2-linux-x64-debug-28 Results: total: 243, passed: 242; failed: 1" I assume you keep the result mail sparse due to security considerations. But unfortunately I can very little do to fix these tests without knowing more. Thanks a lot! Kind Regards, Thomas From aph at redhat.com Tue Feb 13 09:04:06 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 09:04:06 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <7b2bedc5-f863-fbaa-0d28-cb06160b8f21@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> <7b2bedc5-f863-fbaa-0d28-cb06160b8f21@oracle.com> Message-ID: On 13/02/18 00:29, David Holmes wrote: > On 13/02/2018 2:47 AM, Brian Goetz wrote: >> I don?t think that?s a concern worth worrying about. Think about why people use shebang in the first place; they want to launch the file from the shell without saying ?java? (or ?python? or ?bash? or ?) At this point, the file has likely entered the terminal phase of its life ? it is installed as a script. The use case of ?I might want to run it standalone as a script, or compile it as part of a larger source base? seems somewhat contrived. And for those cases, fine ? run it with ?java ?source?, rather than shebang. I don?t think its a bump that anyone who actually uses will be surprised at. > > Ironically(?) I find that most of the files I have to execute that > contain shebangs do not have the execute bit set (all scripts in our > repos!) and so I have to say "bash ...". That's a bug, though: I remember asking about getting this fixed (by setting the x bits on the files in the repo) but apparently it's "because security." Every other project I know sets the x bits in shell scripts. >> The alternative ? intruding this convention on the Java language syntax ? is certainly a worse tradeoff. Think of this as ?launcher 90% full? rather than ?language 10% empty? :) > > IMHO it's a wart to have javac barf on what appears to be a regular Java > source file because of a shebang line. Even if this is outside the scope > of JLS, any tools in OpenJDK that can process "Java source files" should > be specified to skip the shebang line. There is, I admit, some sense to that. -- 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 Feb 13 09:06:06 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 09:06:06 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Message-ID: <85eaa412-f945-d7c7-7f15-11ca1db1c682@redhat.com> On 13/02/18 04:19, Jaikiran Pai wrote: > As such, the first part of the JEP which states that the java tool would > be enhanced to support this feature sounds reasonable. However, the > additional change/enhancement to support shebang files, IMO, just adds > more complexities to support, what I think, is a non-existent > requirement. I believe not. Today, we have all manner of scripts in our build system which are written in all manner of bad languages. It would be nice to write them in a good scripting language, if we had one. Now we do. -- 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 Feb 13 09:12:24 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 09:12:24 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: There looks like an omission in the proposal. In files launched with a shebang, the first line shouldn't be ignored: it should be parsed as arguments. But the proposal doesn't explicitly say that. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gerd.mueller-schramm at hexagongeospatial.com Tue Feb 13 10:32:38 2018 From: gerd.mueller-schramm at hexagongeospatial.com (MUELLER-SCHRAMM Gerd) Date: Tue, 13 Feb 2018 10:32:38 +0000 Subject: Bug JDK-8196763 Message-ID: Hi all, I've reported bug JDK-8197481 which was marked as duplicate of JDK-8196763 but for some reason I can't access this bug. What's the state of JDK-8196763? Already fixed? Will it be fixed? Regards, Gerd Gerd M?ller-Schramm Software Developer, GeoMedia Smart Client Kommunal T: +49 341 92 60 30 47 E: gerd.mueller-schramm at hexagongeospatial.com Hexagon Geospatial Wittenberger Stra?e 15B 04129 Leipzig, Germany hexagongeospatial.com From david.lloyd at redhat.com Tue Feb 13 13:24:00 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 13 Feb 2018 07:24:00 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: I think the shell takes care of that bit... though it does seem to pass in the entire argument string as one big argument, so in this case the arguments will have to be re-parsed out of that. On Tue, Feb 13, 2018 at 3:12 AM, Andrew Haley wrote: > There looks like an omission in the proposal. In files launched > with a shebang, the first line shouldn't be ignored: it should be > parsed as arguments. But the proposal doesn't explicitly say that. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- - DML From aph at redhat.com Tue Feb 13 14:48:05 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 14:48:05 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> On 13/02/18 13:24, David Lloyd wrote: > I think the shell takes care of that bit... It does, but we do need to say what gets passed. jvm arguments, in particular, would be very useful. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From john.r.rose at oracle.com Tue Feb 13 16:00:22 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 13 Feb 2018 08:00:22 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A81F283.2030208@oracle.com> References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> <5A81F283.2030208@oracle.com> Message-ID: <06DC006C-5F6D-4C1C-BEBE-8788935F5768@oracle.com> On Feb 12, 2018, at 12:01 PM, Jonathan Gibbons wrote: > > Thank you for your detailed analysis of the landscape of the "shebang" > mechanism and files. You're welcome. > With respect to your bottom-line suggestions, it is definitely the intent > to allow "java --source any-path", to facilitate full-range use of shebang > in Unix. I now see that the JEP says this explicitly; I missed this line on first reading: > If the file does not have the .java extension, the --source option may be used to force source-file mode. (I agree that we don't need a pedantic --shebang option. That would be what I call a "splitting" design move, but Java usually favors "lumping" design moves.) It looks good! ? John From volker.simonis at gmail.com Tue Feb 13 16:48:11 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 Feb 2018 17:48:11 +0100 Subject: JDK 10: First Release Candidate In-Reply-To: <20180212185150.8318A15F4AC@eggemoggin.niobe.net> References: <20180212185150.8318A15F4AC@eggemoggin.niobe.net> Message-ID: Hi, I found the following problem with the JDK 10 Release Candidate: 1. JEP 322 [1] specifies: java.vendor.version - ... If not assigned at build time then it has no value; otherwise, its value is a non-empty string that matches the regular expression \p{Graph}+ 2. The new Java 10 API doc for java.lang.System [2] specifies the following: getProperties() ... This set of system properties always includes values for the following keys: ... java.vendor.version Java vendor version These two specifications contradict each other. JEP 322 allows for "java.vendor.version" having no value (i.e. being NULL or not defined) if not set at build time, while the API doc requires that System.getProperty("java.vendor.version") always returns a value (i.e. the property must be defined and not NULL). The current sources in jdk/jdk10 implement the behavior defined in JEP 322. If '--with-vendor-version' isn't given while configuring the build (or is given with an empty string as argument) the System properties won't have an entry for "java.vendor.version". How can we fix this? 1. We could remove "java.vendor.version" from the set of system properties which are required to always have a value. 2. We could rephrase JEP 322 to something like "If not assigned at build time then it's value is the empty string; otherwise, ..." I think I'd prefer the second solution, although that would also require a tiny change to Version.java.template to set the "java.vendor.version" unconditionally. What do you think? Regards, Volker [1] http://openjdk.java.net/jeps/322 [2] http://cr.openjdk.java.net/~mr/jeps/322/specdiff/java/lang/System-report.html#method:getProperties() On Mon, Feb 12, 2018 at 7:51 PM, wrote: > There are no unresolved P1 bugs in build 43, so that is our > first JDK 10 Release Candidate. > > Binaries available here, as usual: http://jdk.java.net/10 > > - Mark From jonathan.gibbons at oracle.com Tue Feb 13 17:56:45 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Feb 2018 09:56:45 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> References: <5A7CDACB.50103@oracle.com> <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> Message-ID: <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> On 2/13/18 6:48 AM, Andrew Haley wrote: > On 13/02/18 13:24, David Lloyd wrote: >> I think the shell takes care of that bit... > It does, but we do need to say what gets passed. jvm arguments, > in particular, would be very useful. > The problem here is that it seems that shells are inconsistent with how they handle arguments on the first line. This is specifically called out as a portability problem in [1]. That makes it difficult for the main Java launcher to handle these arguments. It would be wrong to make a general change to the Java launcher to reparse arguments containing spaces as individual options. -- Jon [1] https://en.wikipedia.org/wiki/Shebang_(Unix) From aph at redhat.com Tue Feb 13 18:42:23 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 18:42:23 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> References: <5A7CDACB.50103@oracle.com> <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> Message-ID: <1e1017ef-f595-0d09-310f-2233e4dccd97@redhat.com> On 13/02/18 17:56, Jonathan Gibbons wrote: > > > On 2/13/18 6:48 AM, Andrew Haley wrote: >> On 13/02/18 13:24, David Lloyd wrote: >>> I think the shell takes care of that bit... >> It does, but we do need to say what gets passed. jvm arguments, >> in particular, would be very useful. > > The problem here is that it seems that shells are inconsistent with how > they handle arguments on the first line. This is specifically called out > as a portability problem in [1]. > > That makes it difficult for the main Java launcher to handle these > arguments. It would be wrong to make a general change to the Java > launcher to reparse arguments containing spaces as individual options. OK, I see what you mean. I had thought that Python did this properly, but I just tried it and it doesn't work. Well, it works kinda-sorta but exactly one argument can be passed on the command line. Eww. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alexander.zuev at oracle.com Tue Feb 13 19:22:25 2018 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 13 Feb 2018 11:22:25 -0800 Subject: Bug JDK-8196763 In-Reply-To: References: Message-ID: <45354434-444a-ad09-77f7-205fdc49280f@oracle.com> Hi Gerd, ? the JDK-8196763 is reported as being fixed. /Alex On 13/02/2018 02:32, MUELLER-SCHRAMM Gerd wrote: > Hi all, > > I've reported bug JDK-8197481 which was marked as duplicate of JDK-8196763 but for some reason I can't access this bug. > What's the state of JDK-8196763? Already fixed? Will it be fixed? > > Regards, > Gerd > > Gerd M?ller-Schramm > Software Developer, GeoMedia Smart Client Kommunal > T: +49 341 92 60 30 47 > E: gerd.mueller-schramm at hexagongeospatial.com > > Hexagon Geospatial > Wittenberger Stra?e 15B > 04129 Leipzig, Germany > hexagongeospatial.com > > From jonathan.gibbons at oracle.com Tue Feb 13 22:06:37 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Feb 2018 14:06:37 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> Message-ID: <5A83616D.30002@oracle.com> Jaikiran, There is no need to use the shebang feature (meaning a line beginning #!) if you are a new user or if you are on a system that does not support its use. I regard the shebang feature as a feature for advanced users. If you recognize it, and know how to use it, you'll welcome it; if you don't recognize it, you don't have to learn to use it. For many users, the ability to specify the source file for their program on the java command line will be good enough. -- Jon On 02/12/2018 08:19 PM, Jaikiran Pai wrote: > Hi Jonathan, > > The motivation behind this feature, as noted in the motivation > section, IMO is good - to allow developers getting started with Java > to be able to try out small utility programs without having to go > through multiple different tools/commands. > > As such, the first part of the JEP which states that the java tool > would be enhanced to support this feature sounds reasonable. However, > the additional change/enhancement to support shebang files, IMO, just > adds more complexities to support, what I think, is a non-existent > requirement. Complexities/questions like: > > - Given that the feature is mostly targeted towards new users, what > purpose would a shebang serve for such users, if they are on a Windows > OS. Not starting a OS war, but it still is the most used OS for > development, which effectively would mean that not many will use this > shebang feature, IMO. > > - What happens when the user moves one step forward in learning Java > and now wants to use this existing class (which has a shebang) along > with some other newer class(es) and wants to compile and build the > application? How would other tools like (javac) react to it? Would > those tools too now understand the shebang mechanism? > > - I'm not an expert on compilers, but AFAIK, Eclipse IDE uses its own > compiler. Would that mean that these external compilers too will have > to now understand and support the shebang support? > > Personally, except for the proposal to support shebang, the JEP looks > good. > > -Jaikiran > > On 12/02/18 7:52 PM, Roger Riggs wrote: >> Hi Jonathan, >> >> It would be a great convenience to developers to NOT to have two >> types of java source files. >> Those that can be run directly and those that cannot. According to >> the JLS, the former can not >> be called java source files, they are something else. >> >> $.02, Roger >> >> >> >> On 2/10/2018 11:59 AM, Jonathan Gibbons wrote: >>> Volker, >>> >>> I don't see a compelling need to change the JLS to accommodate >>> "shebang" files. Most Java source files don't need the `#!` line, >>> including any source file passed to an explicit invocation of the >>> Java launcher. The line is only needed when the file is set up to be >>> directly executed by the "shebang" mechanism, in which case the line >>> can be thought of as a "wrapper" supported by the host system to >>> enable such use. If the feature is sufficiently popular, it may even >>> be that editors will recognize and support the use of such lines, in >>> the same way that some editors recognize and support the >>> manipulation of javadoc comments, which are also not defined in the >>> JLS (beyond the basic definition of a comment in JLS 3.7). >>> >>> -- Jon >>> >>> >>> On 2/9/18 2:51 AM, Volker Simonis wrote: >>>> Hi Jonathan, >>>> >>>> that's an interesting proposal. It is just unfortunate that a Java >>>> source file starting with "shebang" won't be a legal Java file >>>> according to the Java Language Specification. Or do you plan to change >>>> the JLS to allow (and ignore) "shebang" in the first line? >>>> >>>> Thanks, >>>> Volker >>>> >>>> On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons >>>> wrote: >>>>> This draft JEP contains a proposal to enhance the java launcher to >>>>> support >>>>> running a >>>>> program supplied as a single file of Java source code. The program >>>>> will be >>>>> compiled >>>>> and run, without the need to explicit invoke javac, or to package >>>>> up a jar >>>>> file. >>>>> >>>>> For more details, see: >>>>> >>>>> http://openjdk.java.net/jeps/8192920 >>>>> >>>>> -- Jon >>> >> > From Roger.Riggs at Oracle.com Tue Feb 13 22:12:12 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Feb 2018 17:12:12 -0500 Subject: CFV: New JDK Reviewer: Jayathirth D V In-Reply-To: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com> References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com> Message-ID: <5cb289c4-62f0-72f8-3767-729e7aff81c0@Oracle.com> Vote: yes On 1/30/2018 2:02 PM, Phil Race wrote: > I hereby nominate Jayathirth D V? (openjdk id jdv) to the role of JDK > reviewer. > From john.r.rose at oracle.com Tue Feb 13 22:37:23 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 13 Feb 2018 14:37:23 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <1e1017ef-f595-0d09-310f-2233e4dccd97@redhat.com> References: <5A7CDACB.50103@oracle.com> <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> <1e1017ef-f595-0d09-310f-2233e4dccd97@redhat.com> Message-ID: On Feb 13, 2018, at 10:42 AM, Andrew Haley wrote: > > OK, I see what you mean. I had thought that Python did this properly, > but I just tried it and it doesn't work. Well, it works kinda-sorta > but exactly one argument can be passed on the command line. Eww. :-) It's not Python's fault! The OS gets in there and launches python with the required arguments. The rules are very narrow. The OS doesn't do command line parsing at that level. See http://man7.org/linux/man-pages/man2/execve.2.html Here's what it says about parsing the shebang line: > A maximum line length of 127 characters is allowed for the first line > in an interpreter script. > > The semantics of the optional-arg argument of an interpreter script > vary across implementations. On Linux, the entire string following > the interpreter name is passed as a single argument to the > interpreter, and this string can include white space. However, > behavior differs on some other systems. Some systems use the first > white space to terminate optional-arg. On some systems, an > interpreter script can have multiple arguments, and white spaces in > optional-arg are used to delimit the arguments. Yum! From john.r.rose at oracle.com Tue Feb 13 22:40:22 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 13 Feb 2018 14:40:22 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> <94a58adb-ba9a-d0dd-7e33-0d21f8742526@Oracle.com> <73924674-E35C-4220-8A33-C706988CC4C7@oracle.com> <83a95689-7e5f-1afd-13c5-688a77b14d39@Oracle.com> <2363A22B-05B3-4CAB-9F96-380B9C71D6F7@oracle.com> <7b2bedc5-f863-fbaa-0d28-cb06160b8f21@oracle.com> Message-ID: On Feb 13, 2018, at 1:04 AM, Andrew Haley wrote: > >> Even if this is outside the scope >> of JLS, any tools in OpenJDK that can process "Java source files" should >> be specified to skip the shebang line. > > There is, I admit, some sense to that. +1 It's a packaging feature, like "javac -encoding", outside the JLS, but inside the Java ecosystem. Perhaps it makes sense for any tool that knows about Java source *and* encodings to *also* know about shebang. From gerd.mueller-schramm at hexagongeospatial.com Wed Feb 14 08:35:39 2018 From: gerd.mueller-schramm at hexagongeospatial.com (MUELLER-SCHRAMM Gerd) Date: Wed, 14 Feb 2018 08:35:39 +0000 Subject: AW: Bug JDK-8196763 In-Reply-To: <45354434-444a-ad09-77f7-205fdc49280f@oracle.com> References: <45354434-444a-ad09-77f7-205fdc49280f@oracle.com> Message-ID: Hi Alex, Is the fix already included in the latest JDK version? I've tried it with jdk-10+43 and the problem still occurs. Regards, Gerd Gerd M?ller-Schramm Software Developer, GeoMedia Smart Client Kommunal T: +49 341 92 60 30 47? E:?gerd.mueller-schramm at hexagongeospatial.com Hexagon Geospatial Wittenberger Stra?e 15B 04129 Leipzig, Germany hexagongeospatial.com -----Urspr?ngliche Nachricht----- Von: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] Im Auftrag von Alexander Zuev Gesendet: Dienstag, 13. Februar 2018 20:22 An: jdk-dev at openjdk.java.net Betreff: Re: Bug JDK-8196763 Hi Gerd, ? the JDK-8196763 is reported as being fixed. /Alex On 13/02/2018 02:32, MUELLER-SCHRAMM Gerd wrote: > Hi all, > > I've reported bug JDK-8197481 which was marked as duplicate of JDK-8196763 but for some reason I can't access this bug. > What's the state of JDK-8196763? Already fixed? Will it be fixed? > > Regards, > Gerd > > Gerd M?ller-Schramm > Software Developer, GeoMedia Smart Client Kommunal > T: +49 341 92 60 30 47 > E: gerd.mueller-schramm at hexagongeospatial.com > > Hexagon Geospatial > Wittenberger Stra?e 15B > 04129 Leipzig, Germany > hexagongeospatial.com > > From Alan.Bateman at oracle.com Wed Feb 14 08:47:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Feb 2018 08:47:35 +0000 Subject: AW: Bug JDK-8196763 In-Reply-To: References: <45354434-444a-ad09-77f7-205fdc49280f@oracle.com> Message-ID: <2edd04d5-6440-f450-6c63-d299a7498534@oracle.com> On 14/02/2018 08:35, MUELLER-SCHRAMM Gerd wrote: > Hi Alex, > > Is the fix already included in the latest JDK version? I've tried it with jdk-10+43 and the problem still occurs. > This is Java Web Start rather than an OpenJDK issue.? You can track the issue yourself [1], just follow the backport issue that targets 10. The current status says that it is fixed in master which means the change has been pushed, just not in a promoted (RC) build yet. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8196763 From prasanta.sadhukhan at oracle.com Wed Feb 14 09:16:48 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 14 Feb 2018 14:46:48 +0530 Subject: CFV: New JDK Reviewer: Jayathirth D V In-Reply-To: References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com> Message-ID: <8a11d2f4-ac7f-36fd-d0c2-cb31afbfc2ca@oracle.com> Vote: yes > On 1/31/2018 12:32 AM, Phil Race wrote: >> I hereby nominate Jayathirth D V? (openjdk id jdv) to the role of JDK >> reviewer. >> >> Vadim has worked in the JDK client team for well over 2 years, >> focusing mostly on Java 2D, and in particular Java Image IO. >> >> Jay is currently a JDK committer [1] and has contributed at least 44 >> changesets to OpenJDK [2]. >> >> And has already been active in helping act as a reviewer on the >> 2d-dev [3] mailing list. >> >> Votes are due by Feb 14, 2018. >> >> Only current JDK Reviewers [4] are eligible to vote on this nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [5]. >> >> -phil. >> >> [1] http://openjdk.java.net/census#jdv >> >> [2] >> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22))+and+not+merge() >> >> [3] http://mail.openjdk.java.net/pipermail/2d-dev/ >> >> [4] http://openjdk.java.net/census >> >> [5] http://openjdk.java.net/projects/#reviewer-vote > From jesper.wilhelmsson at oracle.com Wed Feb 14 15:44:21 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 16:44:21 +0100 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests Message-ID: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> Hi, Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 Diff: diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -282,6 +282,9 @@ java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all + ############################################################################ # jdk_instrument Thanks, /Jesper From jesper.wilhelmsson at oracle.com Wed Feb 14 16:14:41 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 17:14:41 +0100 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> Message-ID: +hotspot_dev > On 14 Feb 2018, at 16:44, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 > Diff: > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -282,6 +282,9 @@ > > java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all > > +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all > +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all > + > ############################################################################ > > # jdk_instrument > > > > Thanks, > /Jesper > From coleen.phillimore at oracle.com Wed Feb 14 16:19:50 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 14 Feb 2018 11:19:50 -0500 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> Message-ID: <06067521-e770-f9cf-6bd3-d172fdfa6102@oracle.com> Looks good. Coleen On 2/14/18 11:14 AM, jesper.wilhelmsson at oracle.com wrote: > +hotspot_dev > >> On 14 Feb 2018, at 16:44, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 >> Diff: >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -282,6 +282,9 @@ >> >> java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all >> >> +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all >> +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all >> + >> ############################################################################ >> >> # jdk_instrument >> >> >> >> Thanks, >> /Jesper >> From lois.foltan at oracle.com Wed Feb 14 16:46:59 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 14 Feb 2018 11:46:59 -0500 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> Message-ID: <17e27ce5-6743-1a62-e7d9-0886c063524d@oracle.com> Looks good. Lois On 2/14/2018 10:44 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 > Diff: > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -282,6 +282,9 @@ > > java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all > > +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all > +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all > + > ############################################################################ > > # jdk_instrument > > > > Thanks, > /Jesper > From kim.barrett at oracle.com Wed Feb 14 17:19:38 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 14 Feb 2018 12:19:38 -0500 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> Message-ID: <7A9FAFB0-0A95-4D0F-BED5-C73ACC4D7015@oracle.com> > On Feb 14, 2018, at 11:14 AM, jesper.wilhelmsson at oracle.com wrote: > > +hotspot_dev > >> On 14 Feb 2018, at 16:44, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 >> Diff: >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -282,6 +282,9 @@ >> >> java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all >> >> +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all >> +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all >> + >> ############################################################################ >> >> # jdk_instrument >> >> >> >> Thanks, >> /Jesper Looks good. From jesper.wilhelmsson at oracle.com Wed Feb 14 19:59:23 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 20:59:23 +0100 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: <06067521-e770-f9cf-6bd3-d172fdfa6102@oracle.com> References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> <06067521-e770-f9cf-6bd3-d172fdfa6102@oracle.com> Message-ID: Thanks! /Jesper > On 14 Feb 2018, at 17:19, coleen.phillimore at oracle.com wrote: > > Looks good. > Coleen > > On 2/14/18 11:14 AM, jesper.wilhelmsson at oracle.com wrote: >> +hotspot_dev >> >>> On 14 Feb 2018, at 16:44, jesper.wilhelmsson at oracle.com wrote: >>> >>> Hi, >>> >>> Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 >>> Diff: >>> >>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt >>> +++ b/test/jdk/ProblemList.txt >>> @@ -282,6 +282,9 @@ >>> >>> java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all >>> >>> +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all >>> +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all >>> + >>> ############################################################################ >>> >>> # jdk_instrument >>> >>> >>> >>> Thanks, >>> /Jesper >>> > From jesper.wilhelmsson at oracle.com Wed Feb 14 19:59:31 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 20:59:31 +0100 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: <17e27ce5-6743-1a62-e7d9-0886c063524d@oracle.com> References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> <17e27ce5-6743-1a62-e7d9-0886c063524d@oracle.com> Message-ID: <95900E47-60C2-410E-91CA-459149DC96A3@oracle.com> Thanks! /Jesper > On 14 Feb 2018, at 17:46, Lois Foltan wrote: > > Looks good. > Lois > > On 2/14/2018 10:44 AM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 >> Diff: >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -282,6 +282,9 @@ >> >> java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all >> >> +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all >> +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all >> + >> ############################################################################ >> >> # jdk_instrument >> >> >> >> Thanks, >> /Jesper >> > From jesper.wilhelmsson at oracle.com Wed Feb 14 19:59:39 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 20:59:39 +0100 Subject: RFR: JDK-8197945 - Qurarantine failing condy tests In-Reply-To: <7A9FAFB0-0A95-4D0F-BED5-C73ACC4D7015@oracle.com> References: <1B69958B-4133-4448-9EFA-ED81B8F4170C@oracle.com> <7A9FAFB0-0A95-4D0F-BED5-C73ACC4D7015@oracle.com> Message-ID: <3D5D6E07-3228-453E-A754-CEAE471364BC@oracle.com> Thanks! /Jesper > On 14 Feb 2018, at 18:19, Kim Barrett wrote: > >> On Feb 14, 2018, at 11:14 AM, jesper.wilhelmsson at oracle.com wrote: >> >> +hotspot_dev >> >>> On 14 Feb 2018, at 16:44, jesper.wilhelmsson at oracle.com wrote: >>> >>> Hi, >>> >>> Please review this tiny fix to quarantine two tests that are failing in HS Tier 1. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8197945 >>> Diff: >>> >>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt >>> +++ b/test/jdk/ProblemList.txt >>> @@ -282,6 +282,9 @@ >>> >>> java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all >>> >>> +java/lang/invoke/condy/CondyRepeatFailedResolution.java 8197944 windows-all >>> +java/lang/invoke/condy/CondyReturnPrimitiveTest.java 8197944 windows-all >>> + >>> ############################################################################ >>> >>> # jdk_instrument >>> >>> >>> >>> Thanks, >>> /Jesper > > Looks good. > From jesper.wilhelmsson at oracle.com Wed Feb 14 20:31:39 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 21:31:39 +0100 Subject: Some questions about the jdk-submit process In-Reply-To: References: Message-ID: Hi Thomas, The tier definitions can be found in the TEST.groups files that are in the different test directories. Do a grep for tier1 and you will find where to start looking. It will give some hint of what is run but unfortunately it won't help you figure out what test that actually failed in your run. /Jesper > On 13 Feb 2018, at 09:35, Thomas St?fe wrote: > > Hello all, > > The jdk-submit tests are potentially quite useful but I am still confused > about a lot of things: > > - Last week I pushed twice and received seven result mails. Is that normal > (e.g. do you execute multiple test suites per push)? Or was that just a > fluke and I should expect just one test result mail per push? > > - Is there any way to tie a result mail to a push? If not, would it be > possible to add the changeset id of the branch head to the mail? > > - As background information, on what platforms do you build and test, and > what are the jvm build configurations? > > - Also, which tests are executed? Is they related to the "tierxxx" tests I > read about on the lists, and if yes, is that internal Oracle lingo or does > exist documentation somewhere what these tests are? > > - Related to that, were I to add new jtreg of gtest tests to my branch, > would they be executed? > > - Finally, what do I do with the errors in my tests? Is there a way to get > information, more test output or similar? Because right now all I see is is > information like that: > > "tier1-comp-jdk_open_test_hotspot_jtreg_hotspot_tier1_compiler_2-linux-x64-debug-28 > Results: total: 243, passed: 242; failed: 1" > > I assume you keep the result mail sparse due to security considerations. > But unfortunately I can very little do to fix these tests without knowing > more. > > Thanks a lot! > > Kind Regards, Thomas From thomas.stuefe at gmail.com Wed Feb 14 20:44:32 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Feb 2018 21:44:32 +0100 Subject: Some questions about the jdk-submit process In-Reply-To: References: Message-ID: Thanks, Jesper! On Wed, Feb 14, 2018 at 9:31 PM, wrote: > Hi Thomas, > > The tier definitions can be found in the TEST.groups files that are in the > different test directories. Do a grep for tier1 and you will find where to > start looking. It will give some hint of what is run but unfortunately it > won't help you figure out what test that actually failed in your run. > /Jesper > > > On 13 Feb 2018, at 09:35, Thomas St?fe wrote: > > > > Hello all, > > > > The jdk-submit tests are potentially quite useful but I am still confused > > about a lot of things: > > > > - Last week I pushed twice and received seven result mails. Is that > normal > > (e.g. do you execute multiple test suites per push)? Or was that just a > > fluke and I should expect just one test result mail per push? > > > > - Is there any way to tie a result mail to a push? If not, would it be > > possible to add the changeset id of the branch head to the mail? > > > > - As background information, on what platforms do you build and test, and > > what are the jvm build configurations? > > > > - Also, which tests are executed? Is they related to the "tierxxx" tests > I > > read about on the lists, and if yes, is that internal Oracle lingo or > does > > exist documentation somewhere what these tests are? > > > > - Related to that, were I to add new jtreg of gtest tests to my branch, > > would they be executed? > > > > - Finally, what do I do with the errors in my tests? Is there a way to > get > > information, more test output or similar? Because right now all I see is > is > > information like that: > > > > "tier1-comp-jdk_open_test_hotspot_jtreg_hotspot_tier1_ > compiler_2-linux-x64-debug-28 > > Results: total: 243, passed: 242; failed: 1" > > > > I assume you keep the result mail sparse due to security considerations. > > But unfortunately I can very little do to fix these tests without knowing > > more. > > > > Thanks a lot! > > > > Kind Regards, Thomas > > From chris.hegarty at oracle.com Thu Feb 15 14:02:17 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Feb 2018 14:02:17 +0000 Subject: JDK Sandbox Development Repository Message-ID: The JDK Sandbox Development Repository guidelines and recipes have been updated to reflect the consolidated repository layout and the move to the JDK Project for main-line development. http://cr.openjdk.java.net/~chegar/docs/sandbox.html -Chris. From volker.simonis at gmail.com Thu Feb 15 15:48:58 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 15 Feb 2018 16:48:58 +0100 Subject: Why do "Oracle JDK 10 builds" not support AppCDS? Message-ID: Hi, I know that this is an OpenJDK mailing list but maybe this is still interesting for some of us :) I'm a little surprised to see that the "Oracle JDK 10" early access builds from http://jdk.java.net/10 do not support AppCDS: ./jre-10-ea+43/bin/java -version java version "10" 2018-03-20 Java(TM) SE Runtime Environment 18.3 (build 10+43) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode) ./jre-10-ea+43/bin/java -XX:+UseAppCDS -version Error: Trying to use 'UseAppCDS', but commercial features are not available in this VM. while the OpenJDK builds do support it: ./jdk-10/bin/java -XX:+UseAppCDS -version openjdk version "10" 2018-03-20 OpenJDK Runtime Environment 18.3 (build 10+43) OpenJDK 64-Bit Server VM 18.3 (build 10+43, mixed mode) Is this intentional or a mistake? I thought the goal was that Oracle and OpenJDK builds should be the same apart from the license under which they are provided. AppCDS is on the list of JEPs included in OpenJDK 10 and it seems strange if some of them will not be in Oracle JDK 10 (until now it was usually t he other way round :) Regards, Volker From philip.race at oracle.com Thu Feb 15 17:55:31 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Feb 2018 09:55:31 -0800 Subject: Result: New JDK Reviewer: Jayathirth DV Message-ID: <92797abc-aac5-afbf-279e-2169dab442f2@oracle.com> Voting for Jayathirth DV [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus [2], this is sufficient to approve the nomination as JDK Reviewer [3]. [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000627.html [2] http://openjdk.java.net/bylaws#three-vote-consensus [3] http://openjdk.java.net/bylaws#reviewer From jiangli.zhou at Oracle.COM Thu Feb 15 18:44:01 2018 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Thu, 15 Feb 2018 10:44:01 -0800 Subject: Why do "Oracle JDK 10 builds" not support AppCDS? In-Reply-To: References: Message-ID: Hi Volker, This is intentional for JDK 10. According to the license of Oracle JDK 10, the UseAppCDS option requires -XX:+UnlockCommercialFeatures. For OpenJDK, UseAppCDS can be enabled without -XX:+UnlockCommercialFeatures. The CDS/AppCDS functionality in both Oracle JDK 10 and OpenJDK 10 are identical. Thanks, Jiangli > On Feb 15, 2018, at 7:48 AM, Volker Simonis wrote: > > Hi, > > I know that this is an OpenJDK mailing list but maybe this is still > interesting for some of us :) > > I'm a little surprised to see that the "Oracle JDK 10" early access > builds from http://jdk.java.net/10 do not support AppCDS: > > ./jre-10-ea+43/bin/java -version > java version "10" 2018-03-20 > Java(TM) SE Runtime Environment 18.3 (build 10+43) > Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode) > > ./jre-10-ea+43/bin/java -XX:+UseAppCDS -version > Error: Trying to use 'UseAppCDS', but commercial features are not > available in this VM. > > while the OpenJDK builds do support it: > > ./jdk-10/bin/java -XX:+UseAppCDS -version > openjdk version "10" 2018-03-20 > OpenJDK Runtime Environment 18.3 (build 10+43) > OpenJDK 64-Bit Server VM 18.3 (build 10+43, mixed mode) > > Is this intentional or a mistake? I thought the goal was that Oracle > and OpenJDK builds should be the same apart from the license under > which they are provided. AppCDS is on the list of JEPs included in > OpenJDK 10 and it seems strange if some of them will not be in Oracle > JDK 10 (until now it was usually t he other way round :) > > Regards, > Volker From volker.simonis at gmail.com Thu Feb 15 19:16:18 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 15 Feb 2018 20:16:18 +0100 Subject: Why do "Oracle JDK 10 builds" not support AppCDS? In-Reply-To: References: Message-ID: But -XX:+UnlockCommercialFeatures doesn't work either: ./jre-10-ea+43/bin/java -XX:+UnlockCommercialFeatures -XX:+UseAppCDS -version Error: Trying to use 'UnlockCommercialFeatures', but commercial features are not available in this VM. So the commercial features don't seem to be available in the Oracle JDK 10 build On Thu, Feb 15, 2018 at 7:44 PM, Jiangli Zhou wrote: > Hi Volker, > > This is intentional for JDK 10. According to the license of Oracle JDK 10, > the UseAppCDS option requires -XX:+UnlockCommercialFeatures. For OpenJDK, > UseAppCDS can be enabled without -XX:+UnlockCommercialFeatures. The > CDS/AppCDS functionality in both Oracle JDK 10 and OpenJDK 10 are identical. > > Thanks, > Jiangli > > On Feb 15, 2018, at 7:48 AM, Volker Simonis > wrote: > > Hi, > > I know that this is an OpenJDK mailing list but maybe this is still > interesting for some of us :) > > I'm a little surprised to see that the "Oracle JDK 10" early access > builds from http://jdk.java.net/10 do not support AppCDS: > > ./jre-10-ea+43/bin/java -version > java version "10" 2018-03-20 > Java(TM) SE Runtime Environment 18.3 (build 10+43) > Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode) > > ./jre-10-ea+43/bin/java -XX:+UseAppCDS -version > Error: Trying to use 'UseAppCDS', but commercial features are not > available in this VM. > > while the OpenJDK builds do support it: > > ./jdk-10/bin/java -XX:+UseAppCDS -version > openjdk version "10" 2018-03-20 > OpenJDK Runtime Environment 18.3 (build 10+43) > OpenJDK 64-Bit Server VM 18.3 (build 10+43, mixed mode) > > Is this intentional or a mistake? I thought the goal was that Oracle > and OpenJDK builds should be the same apart from the license under > which they are provided. AppCDS is on the list of JEPs included in > OpenJDK 10 and it seems strange if some of them will not be in Oracle > JDK 10 (until now it was usually t he other way round :) > > Regards, > Volker > > From mikhailo.seledtsov at oracle.com Thu Feb 15 19:23:47 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 15 Feb 2018 11:23:47 -0800 Subject: Why do "Oracle JDK 10 builds" not support AppCDS? In-Reply-To: References: Message-ID: <5A85DE43.3060609@oracle.com> I am not 100% sure, but I believe that UnlockCommercialFeatures is not available in EA Oracle JDK builds, only in GA builds. Thank you, Misha On 2/15/18, 11:16 AM, Volker Simonis wrote: > But -XX:+UnlockCommercialFeatures doesn't work either: > > ./jre-10-ea+43/bin/java -XX:+UnlockCommercialFeatures -XX:+UseAppCDS -version > Error: Trying to use 'UnlockCommercialFeatures', but commercial > features are not available in this VM. > > So the commercial features don't seem to be available in the Oracle JDK 10 build > > > On Thu, Feb 15, 2018 at 7:44 PM, Jiangli Zhou wrote: >> Hi Volker, >> >> This is intentional for JDK 10. According to the license of Oracle JDK 10, >> the UseAppCDS option requires -XX:+UnlockCommercialFeatures. For OpenJDK, >> UseAppCDS can be enabled without -XX:+UnlockCommercialFeatures. The >> CDS/AppCDS functionality in both Oracle JDK 10 and OpenJDK 10 are identical. >> >> Thanks, >> Jiangli >> >> On Feb 15, 2018, at 7:48 AM, Volker Simonis >> wrote: >> >> Hi, >> >> I know that this is an OpenJDK mailing list but maybe this is still >> interesting for some of us :) >> >> I'm a little surprised to see that the "Oracle JDK 10" early access >> builds from http://jdk.java.net/10 do not support AppCDS: >> >> ./jre-10-ea+43/bin/java -version >> java version "10" 2018-03-20 >> Java(TM) SE Runtime Environment 18.3 (build 10+43) >> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode) >> >> ./jre-10-ea+43/bin/java -XX:+UseAppCDS -version >> Error: Trying to use 'UseAppCDS', but commercial features are not >> available in this VM. >> >> while the OpenJDK builds do support it: >> >> ./jdk-10/bin/java -XX:+UseAppCDS -version >> openjdk version "10" 2018-03-20 >> OpenJDK Runtime Environment 18.3 (build 10+43) >> OpenJDK 64-Bit Server VM 18.3 (build 10+43, mixed mode) >> >> Is this intentional or a mistake? I thought the goal was that Oracle >> and OpenJDK builds should be the same apart from the license under >> which they are provided. AppCDS is on the list of JEPs included in >> OpenJDK 10 and it seems strange if some of them will not be in Oracle >> JDK 10 (until now it was usually t he other way round :) >> >> Regards, >> Volker >> >> From martinrb at google.com Fri Feb 16 02:09:04 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Feb 2018 18:09:04 -0800 Subject: Why do "Oracle JDK 10 builds" not support AppCDS? In-Reply-To: <5A85DE43.3060609@oracle.com> References: <5A85DE43.3060609@oracle.com> Message-ID: On Thu, Feb 15, 2018 at 11:23 AM, Mikhailo Seledtsov < mikhailo.seledtsov at oracle.com> wrote: > I am not 100% sure, but I believe that UnlockCommercialFeatures is not > available in EA Oracle JDK builds, only in GA builds. > But ... jdk-10+43 is a release candidate and so should be suitable as the final GA binary. Accordingly, jdk-10+43 reports java full version "10+43" while +42 reports java full version "10-ea+42" From jai.forums2013 at gmail.com Fri Feb 16 13:08:43 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 16 Feb 2018 18:38:43 +0530 Subject: XMLStreamWriter - ability to stream a CDATA section? Message-ID: I'm looking for some information regarding the APIs on javax.xml.stream.XMLStreamWriter which allows streaming of XML content to a target output. Most of the APIs on it allow for streaming the content out. However, there's the writeCData[1] API which takes a String object as a param and writes out the content as one whole CDATA section. I don't see a way where I can avoid loading the entire content, which in some cases can be large, in memory. Is there a reason why such a construct hasn't been made available for writing out CDATA? Something like: ??? ?writeStartCData() - starts a CDATA section ??? ?for(....) { ??? ???? // incrementally write out the CDATA content ??? ???? writeCData(char[], off, len) // or something similar ??? ?} ??? ?writeEndCData() - ends a CDATA section that was previous started Would it make sense to add such an API to that class? [1] https://docs.oracle.com/javase/7/docs/api/javax/xml/stream/XMLStreamWriter.html#writeCData(java.lang.String) -Jaikiran From xueming.shen at oracle.com Wed Feb 21 06:31:54 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 20 Feb 2018 22:31:54 -0800 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. Message-ID: <5A8D125A.5030205@oracle.com> This draft JEP contains a proposal to use UTF-8 as the default charset for the JVM, so that APIs that depend on the default charset behave consistently cross all platforms. For more details, please see: https://bugs.openjdk.java.net/browse/JDK-8187041 Sherman From uschindler at apache.org Wed Feb 21 08:53:54 2018 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 21 Feb 2018 09:53:54 +0100 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. In-Reply-To: <5A8D125A.5030205@oracle.com> References: <5A8D125A.5030205@oracle.com> Message-ID: <001301d3aaf1$827285a0$875790e0$@apache.org> Hi, > This draft JEP contains a proposal to use UTF-8 as the default charset > for the JVM, so that > APIs that depend on the default charset behave consistently cross all > platforms. > > For more details, please see: > https://bugs.openjdk.java.net/browse/JDK-8187041 Thanks for finally adding a JEP like this. Thanks also to Robert Muir for always insisting in fixing this problem! I have a few comments: The JEP should NOT cause that new APIs, which may convert between characters and bytes to no longer explicitly accept a charset. One example is the proposed ByteBuffer methods taking String. The default ones would work with UTF-8, but it should still be possible to an API user to always add a charset whenever there is a conversion between bytes and chars. This is especially important as the user may still change the default and breaking your app. Because the rule is still: Only YOU, the developer, know the charset of your stuff when you load a JAR resource file or pass a String to the network in a ByteBuffer! The biggest offenders on this is also given as an example: FileReader and FileWriter. Although both classes subclass InputStreamReader/OutputStreamWriter and just pass the right delegate to the superclass in the ctor, both classes are missing the possibility to specify a charset. Because of this, the use of FileReader and FileWriter is completely forbidden in many Apache projects (Apache Lucene, Solr, Elasticsearch, Apache TIKA,...). So I'd suggest to also fix the API here and just add the missing ctors. The Java 7+ methods in java.nio.file.Files already ignore the default charset and always use UTF-8. How to proceed with those? Should they be changed to behave to the new mechanisms? I'd suggest to not do this, as its part of the spec (to use UTF-8) and should not rely on external forces, but I wanted to bring this in. Changing the default would help many users, if they are actually using newer JDKs. For those with older versions (and compiling their code against older versions), you still have to avoid the default charsets. In addition, as you still can change the "default charset", any library developer reading resources from its own JAR file or passing Strings to network protocols cannot rely on the fact, that the default charset is really UTF-8! (a user may have changed it to something else). Because of this, Apache libraries will forbid usage of all methods using default charsets (and locales + timezones). The "changeable default" does not affect application developers (because they have in most cases control about the environment), but library developers should always be explicit! For this to work, I also want to do some "advertisement": All library projects should use the Forbidden-Apis Maven/Gradle/Ant plugin to scan their bytecode for offenders using default charsets, default locales or relying on default timezones. See the blog post about it [1] and the project page [2]. The tool is also useful to replace "jdeps" in projects with Java versions before 8, as it can scan your code for access to internal JDK APIs, too. See the documentation [3] and github wiki pages for useful examples. It may also be a good idea to mention it in the JEP as a "workaround" or "further reading". Finally: Because one can still change the default, I'd propose to deprecate all methods that use a default charset (unrelated to actually changing the default). Only if you do this, it would make tools like "forbiddenapis" irrelevant for library developers. And finally, finally: I'd also propose to change the default Locale to Locale.ROOT (same issues). The String.toLowerCase() in Turkish locales still break thousands of apps! But that's a different JEP - but I would strongly support it! Uwe [1] http://blog.thetaphi.de/2012/07/default-locales-default-charsets-and.html [2] https://github.com/policeman-tools/forbidden-apis [3] https://jenkins.thetaphi.de/job/Forbidden-APIs/javadoc/ ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From forax at univ-mlv.fr Wed Feb 21 11:04:19 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 21 Feb 2018 11:04:19 +0000 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. In-Reply-To: <001301d3aaf1$827285a0$875790e0$@apache.org> References: <5A8D125A.5030205@oracle.com> <001301d3aaf1$827285a0$875790e0$@apache.org> Message-ID: I agree with Uwe, we should deprecate all methods/constructors that relies on the default charset. And we should do that before changing to use UTF-8 by default. Remi On February 21, 2018 8:53:54 AM UTC, Uwe Schindler wrote: >Hi, > >> This draft JEP contains a proposal to use UTF-8 as the default >charset >> for the JVM, so that >> APIs that depend on the default charset behave consistently cross all >> platforms. >> >> For more details, please see: >> https://bugs.openjdk.java.net/browse/JDK-8187041 > >Thanks for finally adding a JEP like this. Thanks also to Robert Muir >for always insisting in fixing this problem! I have a few comments: > >The JEP should NOT cause that new APIs, which may convert between >characters and bytes to no longer explicitly accept a charset. One >example is the proposed ByteBuffer methods taking String. The default >ones would work with UTF-8, but it should still be possible to an API >user to always add a charset whenever there is a conversion between >bytes and chars. This is especially important as the user may still >change the default and breaking your app. Because the rule is still: >Only YOU, the developer, know the charset of your stuff when you load a >JAR resource file or pass a String to the network in a ByteBuffer! > >The biggest offenders on this is also given as an example: FileReader >and FileWriter. Although both classes subclass >InputStreamReader/OutputStreamWriter and just pass the right delegate >to the superclass in the ctor, both classes are missing the possibility >to specify a charset. Because of this, the use of FileReader and >FileWriter is completely forbidden in many Apache projects (Apache >Lucene, Solr, Elasticsearch, Apache TIKA,...). So I'd suggest to also >fix the API here and just add the missing ctors. > >The Java 7+ methods in java.nio.file.Files already ignore the default >charset and always use UTF-8. How to proceed with those? Should they be >changed to behave to the new mechanisms? I'd suggest to not do this, as >its part of the spec (to use UTF-8) and should not rely on external >forces, but I wanted to bring this in. > >Changing the default would help many users, if they are actually using >newer JDKs. For those with older versions (and compiling their code >against older versions), you still have to avoid the default charsets. >In addition, as you still can change the "default charset", any library >developer reading resources from its own JAR file or passing Strings to >network protocols cannot rely on the fact, that the default charset is >really UTF-8! (a user may have changed it to something else). Because >of this, Apache libraries will forbid usage of all methods using >default charsets (and locales + timezones). The "changeable default" >does not affect application developers (because they have in most cases >control about the environment), but library developers should always be >explicit! > >For this to work, I also want to do some "advertisement": All library >projects should use the Forbidden-Apis Maven/Gradle/Ant plugin to scan >their bytecode for offenders using default charsets, default locales or >relying on default timezones. See the blog post about it [1] and the >project page [2]. The tool is also useful to replace "jdeps" in >projects with Java versions before 8, as it can scan your code for >access to internal JDK APIs, too. See the documentation [3] and github >wiki pages for useful examples. It may also be a good idea to mention >it in the JEP as a "workaround" or "further reading". > >Finally: Because one can still change the default, I'd propose to >deprecate all methods that use a default charset (unrelated to actually >changing the default). Only if you do this, it would make tools like >"forbiddenapis" irrelevant for library developers. > >And finally, finally: I'd also propose to change the default Locale to >Locale.ROOT (same issues). The String.toLowerCase() in Turkish locales >still break thousands of apps! But that's a different JEP - but I would >strongly support it! > >Uwe > >[1] >http://blog.thetaphi.de/2012/07/default-locales-default-charsets-and.html >[2] https://github.com/policeman-tools/forbidden-apis >[3] https://jenkins.thetaphi.de/job/Forbidden-APIs/javadoc/ > >----- >Uwe Schindler >uschindler at apache.org >ASF Member, Apache Lucene PMC / Committer >Bremen, Germany >http://lucene.apache.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From david.lloyd at redhat.com Wed Feb 21 13:19:13 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 21 Feb 2018 07:19:13 -0600 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. In-Reply-To: <5A8D125A.5030205@oracle.com> References: <5A8D125A.5030205@oracle.com> Message-ID: I agree with Uwe and Remi; if the default is still changeable, the problem doesn't go away, it simply becomes slightly more insidious. On Wed, Feb 21, 2018 at 12:31 AM, Xueming Shen wrote: > This draft JEP contains a proposal to use UTF-8 as the default charset for > the JVM, so that > APIs that depend on the default charset behave consistently cross all > platforms. > > For more details, please see: > https://bugs.openjdk.java.net/browse/JDK-8187041 > > Sherman -- - DML From Alan.Bateman at oracle.com Wed Feb 21 13:37:26 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Feb 2018 13:37:26 +0000 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. In-Reply-To: References: <5A8D125A.5030205@oracle.com> Message-ID: <22bca8a4-5548-7af9-9770-ad7b749191c9@oracle.com> On 21/02/2018 13:19, David Lloyd wrote: > I agree with Uwe and Remi; if the default is still changeable, the > problem doesn't go away, it simply becomes slightly more insidious. > The proposal is to eventually get to the point that the default charset cannot be changed. It will take several releases to get there due to the potential compatibility impact. This draft JEP is the first step to switch to UTF-8 by default. A first step has to allow it be changed in order to keep some existing code/deployments working. Sorry this isn't clear in the JEP yet, there several clarifications to this JEP that haven't been included yet (on my list, I didn't realize it would be discussed here this week). -Alan From maurizio.cimadamore at oracle.com Wed Feb 21 16:04:30 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Feb 2018 16:04:30 +0000 Subject: Result: New JDK Committer: Liam Miller-Cushon Message-ID: <68bf98de-7f4c-bc53-54ee-668540fdaf01@oracle.com> Voting for Liam Miller-Cushon [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. thanks, Maurizio [1] - http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000688.html From volker.simonis at gmail.com Wed Feb 21 16:11:03 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 21 Feb 2018 17:11:03 +0100 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. In-Reply-To: <5A8D125A.5030205@oracle.com> References: <5A8D125A.5030205@oracle.com> Message-ID: Hi Sherman, the tricky part is really "sun.jnu.encoding" and how the VM interacts with the underlying OS. You may remember that we had an interesting discussion about this topic some time ago [1]. As far as I understand, the JEP doesn't plan to change the handling of "sun.jnu.encoding". So does this mean that the VM will still correctly start and work on system with a platform encoding different from UTF-8? I.e. will starting the VM from a path which contains characters in that special platform encoding or classpath/argument settings with characters in that special character encoding still work? If the answer will be yes (which I expect) maybe you could explain that a little more detailed in the JEP. I.e. the JEP should say that it changes the default encoding for the Java API classes and not the default encoding for natively accessing system resources. Maybe the JEP should also mention that "sun.jnu.encoding" is more or less a "read-only" property which can not be reliable set by the user on the command line (it's a chicken-egg problem: for the parsing of the command line we need the correct encoding, so it can not be reliably set on the command line). For these reasons the Summary "Use UTF-8 as the Java virtual machine's default charset ..." is a little misleading. Maybe you could rephrase to something like "Use UTF-8 as the default charset so that Java APIs that depend on the default charset behave consistently across all platforms." Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/thread.html#37516 On Wed, Feb 21, 2018 at 7:31 AM, Xueming Shen wrote: > This draft JEP contains a proposal to use UTF-8 as the default charset for > the JVM, so that > APIs that depend on the default charset behave consistently cross all > platforms. > > For more details, please see: > https://bugs.openjdk.java.net/browse/JDK-8187041 > > Sherman From xueming.shen at oracle.com Wed Feb 21 16:42:40 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 21 Feb 2018 08:42:40 -0800 Subject: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine. In-Reply-To: References: <5A8D125A.5030205@oracle.com> Message-ID: <5A8DA180.5090004@oracle.com> Hi Volker, Yes, the handing of sun.jnu.encoding will not be changed. It will remain as a read-only/informative system property. sun.jnu.encoding is really an implementation details (as well as file.encoding, though in this JEP file.encoding might be used to provide a mechanism to fallback to the current/old/existing behavior, so might become a public/official interface/ system property). From API perspective the Charset.defaultCharset() is the only place to obtain the "Java virtual machine's default charset". As Alan said in previous comment, clarifications will be included in the final version based on feedback/suggestion -Sherman On 2/21/18, 8:11 AM, Volker Simonis wrote: > Hi Sherman, > > the tricky part is really "sun.jnu.encoding" and how the VM interacts > with the underlying OS. You may remember that we had an interesting > discussion about this topic some time ago [1]. > > As far as I understand, the JEP doesn't plan to change the handling of > "sun.jnu.encoding". So does this mean that the VM will still correctly > start and work on system with a platform encoding different from > UTF-8? I.e. will starting the VM from a path which contains characters > in that special platform encoding or classpath/argument settings with > characters in that special character encoding still work? If the > answer will be yes (which I expect) maybe you could explain that a > little more detailed in the JEP. I.e. the JEP should say that it > changes the default encoding for the Java API classes and not the > default encoding for natively accessing system resources. > > Maybe the JEP should also mention that "sun.jnu.encoding" is more or > less a "read-only" property which can not be reliable set by the user > on the command line (it's a chicken-egg problem: for the parsing of > the command line we need the correct encoding, so it can not be > reliably set on the command line). > > For these reasons the Summary "Use UTF-8 as the Java virtual machine's > default charset ..." is a little misleading. Maybe you could rephrase > to something like "Use UTF-8 as the default charset so that Java APIs > that depend on the default charset behave consistently across all > platforms." > > Thank you and best regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/thread.html#37516 > > On Wed, Feb 21, 2018 at 7:31 AM, Xueming Shen wrote: >> This draft JEP contains a proposal to use UTF-8 as the default charset for >> the JVM, so that >> APIs that depend on the default charset behave consistently cross all >> platforms. >> >> For more details, please see: >> https://bugs.openjdk.java.net/browse/JDK-8187041 >> >> Sherman From mark.reinhold at oracle.com Tue Feb 27 16:30:27 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 27 Feb 2018 08:30:27 -0800 Subject: JDK 11 early-access builds Message-ID: <20180227083027.510722150@eggemoggin.niobe.net> JDK 11 EA builds, under both the GPL and Oracle EA licenses, are now available at http://jdk.java.net/11 . These builds include JEP 320 (Remove the Java EE and CORBA Modules) [1], so they're significantly smaller (nine fewer modules, 22 fewer megabytes on Linux/x64). - Mark [1] http://openjdk.java.net/jeps/320 From coleen.phillimore at oracle.com Tue Feb 27 18:24:54 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 27 Feb 2018 13:24:54 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn Message-ID: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1].? The significant contributions so far are changes for Hotspot unified logging (UL), thread local handshakes (TLH) and safe memory reclaimation (SMR).? Also various bug and performance fixes including serviceability changes for safepoint logging and event based tracing.? Robbin is currently working on a concurrent hash table and is introducing a global counter to implement RCU semantics. Votes are due by March 13, 2018. Only current JDK Reviewers [2] are eligible to vote on this nomination.?? Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [3]. Coleen [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#reviewer-vote From claes.redestad at oracle.com Tue Feb 27 18:30:49 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Feb 2018 19:30:49 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: Vote: yes /Claes From jiangli.zhou at oracle.com Tue Feb 27 18:31:39 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 27 Feb 2018 10:31:39 -0800 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <2CA0CE59-8D33-404B-B972-6EB93E70F82F@oracle.com> Vote: yes Thanks, Jiangli > On Feb 27, 2018, at 10:24 AM, coleen.phillimore at oracle.com wrote: > > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1]. The significant contributions so far are changes for Hotspot unified logging (UL), thread local handshakes (TLH) and safe memory reclaimation (SMR). Also various bug and performance fixes including serviceability changes for safepoint logging and event based tracing. Robbin is currently working on a concurrent hash table and is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From vladimir.kozlov at oracle.com Tue Feb 27 18:33:44 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Feb 2018 10:33:44 -0800 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <8ca863c5-d306-e348-5b0a-9aeb57762f95@oracle.com> Vote: yes On 2/27/18 10:24 AM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1].? The significant contributions so > far are changes for Hotspot unified logging (UL), thread local handshakes (TLH) and safe memory reclaimation (SMR). > Also various bug and performance fixes including serviceability changes for safepoint logging and event based tracing. > Robbin is currently working on a concurrent hash table and is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination.?? Votes must be cast in the open by replying to > this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From harold.seigel at oracle.com Tue Feb 27 18:34:20 2018 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 27 Feb 2018 13:34:20 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <56f58804-b760-24b1-fa50-4d276e5c35fe@oracle.com> Vote: yes Harold On 2/27/2018 1:24 PM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From kim.barrett at oracle.com Tue Feb 27 18:50:39 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 27 Feb 2018 13:50:39 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <46B89C92-8302-46C7-8356-EB38BB87F9EF@oracle.com> vote: yes > On Feb 27, 2018, at 1:24 PM, coleen.phillimore at oracle.com wrote: > > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1]. The significant contributions so far are changes for Hotspot unified logging (UL), thread local handshakes (TLH) and safe memory reclaimation (SMR). Also various bug and performance fixes including serviceability changes for safepoint logging and event based tracing. Robbin is currently working on a concurrent hash table and is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From thomas.stuefe at gmail.com Tue Feb 27 18:52:31 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 27 Feb 2018 18:52:31 +0000 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: Vote: yes. Regards, Thomas On Tue 27. Feb 2018 at 19:25, wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1]. The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR). Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing. Robbin is currently working on a concurrent hash table and is > introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From jesper.wilhelmsson at oracle.com Tue Feb 27 19:10:37 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 27 Feb 2018 20:10:37 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <15D903A5-284C-4F19-B81E-79B693406D39@oracle.com> Vote: yes /Jesper > On 27 Feb 2018, at 19:24, coleen.phillimore at oracle.com wrote: > > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1]. The significant contributions so far are changes for Hotspot unified logging (UL), thread local handshakes (TLH) and safe memory reclaimation (SMR). Also various bug and performance fixes including serviceability changes for safepoint logging and event based tracing. Robbin is currently working on a concurrent hash table and is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From thomas.schatzl at oracle.com Tue Feb 27 19:16:35 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 27 Feb 2018 20:16:35 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <1519758995.3155.0.camel@oracle.com> Vote: yes On Tue, 2018-02-27 at 13:24 -0500, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed > 64 > changesets[1]. The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR). Also various bug and performance fixes > including serviceability changes for safepoint logging and event > based > tracing. Robbin is currently working on a concurrent hash table and > is > introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing > list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin > .ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From daniel.daugherty at oracle.com Tue Feb 27 19:50:17 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Feb 2018 14:50:17 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <1d3548db-ed6e-ff16-21cf-c98e193b3af1@oracle.com> Vote: yes Dan On 2/27/18 1:24 PM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From alex.buckley at oracle.com Tue Feb 27 20:51:11 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 27 Feb 2018 12:51:11 -0800 Subject: Rename "incubating" language/VM features to "preview" Message-ID: <5A95C4BF.1070701@oracle.com> Members of the Expert Group for JSR 384 (Java SE 11) have indicated to the Spec Lead that they support the goal of releasing non-final language/VM features in order to gain developer feedback, but also feel that the "incubating" terminology is too confusing. I have some sympathy with this. We were initially guided by the principles and terminology of incubating APIs [1], but there have turned out to be significant differences between incubating APIs (delivered in incubator modules) and incubating language/VM features (delivered in Java compilers and JVM implementations) :- 1. Incubating APIs are specific to OpenJDK-derived implementations, while incubating language/VM features exist in all Java SE implementations. 2. Incubating APIs are "just" APIs in pre-defined namespaces; they receive neither support from JDK tools [2] nor acknowledgement in the JLS and JVMS. In contrast, incubating language/VM features need support from high-profile JDK tools (`javac`, the `java` launcher, `javadoc`, `jshell`) and are specified fully in the JLS and JVMS. 3. A non-trivial number of people interpret "incubating" as "not fully baked", or as "experimental". These interpretations might sometimes be appropriate for incubating APIs, but they are never appropriate for incubating language/VM features intended to be 99% stable and complete. Consequently, some renaming is in order. We like "preview language/VM features" for a number of reasons: - "Preview" is a common, simple word. No compound phrasing ("early-access") or negative emphasis ("non-final"). - Instead of focusing on where a feature is at the moment ("incubating in Java SE $N"), it focuses on where the feature is going ("a preview of what will be final in Java SE $N+1"). The sense of forthcoming is strong. - It makes for a nice hierarchy of language/VM features: - Production (Specified and final) - Preview (Specified and not final) - Experimental (Not specified) A wrinkle arises in the notional command-line flag offered by JDK 11. Simply renaming it from: javac --incubating 11 Foo.java to: javac --preview 11 Foo.java is confusing: if you're compiling on JDK 11, how can you also be previewing 11? This goes double if you habitually specify --release 11 to demand the Java SE 11 source language + class file version + API. We are reluctant to allow this: javac --preview 12 Foo.java because we do NOT commit to Java SE 12 containing exactly the feature previewed in Java SE 11. We propose dropping the operand to --preview, and then to maintain clarity, allowing preview features only when --release is specified :- javac --release 11 --enable-preview Foo.java // OK javac --enable-preview Foo.java // Not OK Alex [1] http://openjdk.java.net/jeps/11 [2] Setting aside an obscure flag to `jmod`. From karen.kinnear at oracle.com Tue Feb 27 21:56:40 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 27 Feb 2018 16:56:40 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: vote: yes thanks, Karen > On Feb 27, 2018, at 1:24 PM, coleen.phillimore at oracle.com wrote: > > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1]. The significant contributions so far are changes for Hotspot unified logging (UL), thread local handshakes (TLH) and safe memory reclaimation (SMR). Also various bug and performance fixes including serviceability changes for safepoint logging and event based tracing. Robbin is currently working on a concurrent hash table and is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From dean.long at oracle.com Wed Feb 28 00:47:19 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 27 Feb 2018 16:47:19 -0800 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <8914d7e9-2f9e-0d32-6b6e-571258ad1d6f@oracle.com> Vote: yes dl On 2/27/18 10:24 AM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From david.holmes at oracle.com Wed Feb 28 00:54:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Feb 2018 10:54:57 +1000 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: Vote: yes David On 28/02/2018 4:24 AM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and is > introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From erik.helin at oracle.com Wed Feb 28 06:37:54 2018 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 28 Feb 2018 07:37:54 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <55479e36-70bf-741e-d405-0028cd982091@oracle.com> Vote: yes Thanks, Erik On 02/27/2018 07:24 PM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and is > introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From marcus.larsson at oracle.com Wed Feb 28 08:36:33 2018 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 28 Feb 2018 09:36:33 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <63636c2a-c585-4311-1311-fce7e450d7ca@oracle.com> Vote: yes On 2018-02-27 19:24, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From markus.gronlund at oracle.com Wed Feb 28 08:39:50 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 28 Feb 2018 00:39:50 -0800 (PST) Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <8eff2540-2975-4f3c-ba0f-0ef7560e4bbc@default> Vote: yes Thanks Markus From tobias.hartmann at oracle.com Wed Feb 28 08:48:43 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 28 Feb 2018 09:48:43 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <3287f898-0af0-cc65-07dc-5efe0d00fcdd@oracle.com> Vote: yes Best regards, Tobias On 27.02.2018 19:24, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 changesets[1].? The > significant contributions so far are changes for Hotspot unified logging (UL), thread local > handshakes (TLH) and safe memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based tracing.? Robbin is currently > working on a concurrent hash table and is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination.?? Votes must be cast in the > open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From stefan.johansson at oracle.com Wed Feb 28 09:27:23 2018 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 28 Feb 2018 10:27:23 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <5bca36f3-7ed3-2522-72d4-299f198403a7@oracle.com> Vote: yes On 2018-02-27 19:24, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From martin.doerr at sap.com Wed Feb 28 10:17:26 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 28 Feb 2018 10:17:26 +0000 Subject: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <8f8ce1da97e54a6f92814efda6f7e03b@sap.com> Vote: yes Regards, Martin From volker.simonis at gmail.com Wed Feb 28 10:41:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Feb 2018 11:41:56 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: Vote: yes On Tue, Feb 27, 2018 at 7:24 PM, wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1]. The significant contributions so far are changes for Hotspot > unified logging (UL), thread local handshakes (TLH) and safe memory > reclaimation (SMR). Also various bug and performance fixes including > serviceability changes for safepoint logging and event based tracing. > Robbin is currently working on a concurrent hash table and is introducing a > global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From adinn at redhat.com Wed Feb 28 11:12:42 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 28 Feb 2018 11:12:42 +0000 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <6fd89fcc-aab7-68b4-5e34-3128270b231a@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 From coleen.phillimore at oracle.com Wed Feb 28 12:41:40 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 28 Feb 2018 07:41:40 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <691c4791-ab61-d58a-de9e-81824054ec90@oracle.com> Vote: yes On 2/27/18 1:24 PM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From zgu at redhat.com Wed Feb 28 13:29:38 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 28 Feb 2018 08:29:38 -0500 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: Vote: yes. -Zhengyu On 02/27/2018 01:24 PM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and is > introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From vladimir.x.ivanov at oracle.com Wed Feb 28 14:45:34 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 Feb 2018 17:45:34 +0300 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <11f5cf37-2353-af1f-a7a6-7240385c6f9c@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/27/18 9:24 PM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. From rachmato at redhat.com Wed Feb 28 15:20:22 2018 From: rachmato at redhat.com (Richard Achmatowicz) Date: Wed, 28 Feb 2018 10:20:22 -0500 Subject: Enabling use of hugepages with java Message-ID: Hi I hope that I am directing this question to the correct mailing list. I have a question concerning the OS setup on Linux required for correct use of the java option -XX:+UseLargePages in JDK 8. Official Oracle documentation (http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html) suggests that in order to make use of large memory pages, in addition to setting the flag -XX:+UseLargePages, an OS option shmmax needs to be tuned to be larger than the java heap size. From looking at the java documentation, there are various ways of enabling the use of huge pages: -XX:+UseHugeTLBFS, -XX:+UseTransparentHugePages, -XX:+UseSHM and, if I understand correctly, these correspond in part to making use of different OS-level APIs for accessing huge pages (via shared memory, hugetlbfs, and other means). My question is this: is setting the shmmax OS value only relevant if we are using -XX:+UseSHM? In other words, if we are using -XX:+UseHugeTLBFS to enable use of hugepages by the JVM, is it the case that setting the shmmax OS setting has no effect on the use of hugepages by the JVM? Thanks in advance Richard From calvin.cheung at oracle.com Wed Feb 28 18:02:03 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 28 Feb 2018 10:02:03 -0800 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <5A96EE9B.20202@oracle.com> Vote: yes On 2/27/18, 10:24 AM, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1]. The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR). Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing. Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From david.holmes at oracle.com Wed Feb 28 22:04:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Mar 2018 08:04:03 +1000 Subject: Enabling use of hugepages with java In-Reply-To: References: Message-ID: <9e71448b-2d3d-acb6-79e8-47d1d0987da3@oracle.com> Hi Richard, Moving to hotspot-dev as the appropriate list. David On 1/03/2018 1:20 AM, Richard Achmatowicz wrote: > Hi > > I hope that I am directing this question to the correct mailing list. > > I have a question concerning the OS setup on Linux required for correct > use of the java option -XX:+UseLargePages in JDK 8. > > Official Oracle documentation > (http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html) > suggests that in order to make use of large memory pages, in addition to > setting the flag -XX:+UseLargePages, an OS option shmmax needs to be > tuned to be larger than the java heap size. > > From looking at the java documentation, there are various ways of > enabling the use of huge pages: -XX:+UseHugeTLBFS, > -XX:+UseTransparentHugePages, -XX:+UseSHM and, if I understand > correctly, these correspond in part to making use of different OS-level > APIs for accessing huge pages (via shared memory, hugetlbfs, and other > means). > > My question is this: is setting the shmmax OS value only relevant if we > are using -XX:+UseSHM? In other words, if we are using -XX:+UseHugeTLBFS > to enable use of hugepages by the JVM, is it the case that setting the > shmmax OS setting has no effect on the use of hugepages by the JVM? > > Thanks in advance > > Richard > From magnus.ihse.bursie at oracle.com Wed Feb 28 23:29:09 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Mar 2018 00:29:09 +0100 Subject: CFV: New JDK Reviewer: Robbin Ehn In-Reply-To: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> References: <70081461-2314-6a39-bb7c-5791192a95d2@oracle.com> Message-ID: <6d6eb44b-784f-932e-97bb-87221923d259@oracle.com> Vote: yes /Magnus On 2018-02-27 19:24, coleen.phillimore at oracle.com wrote: > I hearby nominate Robbin Ehn (rehn) to JDK Project Reviewer. > > Robbin is a member of the Hotspot Runtime group and has contributed 64 > changesets[1].? The significant contributions so far are changes for > Hotspot unified logging (UL), thread local handshakes (TLH) and safe > memory reclaimation (SMR).? Also various bug and performance fixes > including serviceability changes for safepoint logging and event based > tracing.? Robbin is currently working on a concurrent hash table and > is introducing a global counter to implement RCU semantics. > > Votes are due by March 13, 2018. > > Only current JDK Reviewers [2] are eligible to vote on this > nomination.?? Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [3]. > > Coleen > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22robbin.ehn%40oracle.com%22%29%20or%20author%28rehn%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote