From tibokruse at googlemail.com  Fri Jun  1 03:06:33 2018
From: tibokruse at googlemail.com (Thibault Kruse)
Date: Fri, 1 Jun 2018 12:06:33 +0900
Subject: JEP proposed to target JDK 11: 330: Launch Single-File,
 Source-Code Programs
In-Reply-To: <5B10422D.6080403@oracle.com>
References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net>
 <bf267441-b5e0-2705-2626-f73203a79b9b@gmail.com> <5B10422D.6080403@oracle.com>
Message-ID: <CAByu6UV5BVT+TNPONa3pmRUn9A5pmYiSJNqxBrAAe4_wK1Fz7w@mail.gmail.com>

On Fri, Jun 1, 2018 at 3:42 AM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 05/31/2018 06:01 AM, Thibault Kruse wrote:
>>
>> The effort of typing
>>
>>     java HelloWorld.java
>>     vs.
>>     java HelloWorld -sourcepath HelloWorld.java
>>
>> seems small enough to be suffered for this first day of learning java,...
>
> This would be an incompatible change, since all parameters after the main
> class are specified to be passed as arguments to the main class.

Ok, sorry, The options would have to come before the class name, like

java -sourcepath HelloWorld.java HelloWorld

Note module notation also allows disambiguating classes:
java [options] -m <module>[/<mainclass>]


The point being the structure could be made flexible enough to specify
a class to run in several ways, and java could simply error out if
there were multiple top-level classes to run instead of picking the
first. I am not passionate about the exact alternative syntax, I would
just like to know why disambiguating the class to run instead of
picking the first one found in the file was chosen as the best
solution. This is not mentioned in the JEP I think.


>>
>> # Regarding the single-file restriction
>>
>> Why not allow users to modularize their first few classes in java and load
>> them all to run a main method? Teaching them to put all classes in a single
>> file does not seem java-like. A source-path option could well point to a
>> folder or a list of folders to load sources from.
>
>
> While we permit multiple top level classes in the file, I would not
> recommend it as a style. The use cases here are for beginners writing
> initial small programs, and for use of Java in scripts. Anything beyond
> those use cases is better addressed by existing tools for building programs
> composed of many source files.

Initial small programs may still span multiple files. Many online java
tutorials will use multiple files.
Even for the purpose of scripting, it can make good sense to spread
code over multiple script files.

A similar scenario is to have teams where some members will
appropriate tools, but some team-members don't (As an example, teams
of Java-experts and newcomers deciding on the language to use for a
new project).
In that case, just to allow the non-tool-users to run the main class,
all team members would be forced to work on the source as a single
file.
By allowing multiple files, you enable easier cooperation between such users.

>> # Regarding the source filename
>>
>> JEP330 (2018/05/30) currently also states: "The compiler does not enforce
>> the optional restriction defined at the end of JLS ?7.6, [...] the type name
>> followed by the .java extension. [...] If the file does not have
>> the|.java|extension..."
>> I see no significant benefit in allowing users to use a different filename
>> (unless for the shebang line / scripting issue), and IDEs will again
>> struggle to turn off compiler errors for such files. I believe it is better
>> to keep the experience consistent.
>
> The desire to disable the file name check is specifically to support the
> shebang/scripting use case.

So if the shebang support were declared a non-goal, the filename check
would be kept intact?
I believe files needing to be run with the java command should have a
standard java filename extension.

From martin.doerr at sap.com  Fri Jun  1 08:27:02 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 1 Jun 2018 08:27:02 +0000
Subject: Is jdk-submit down again?
Message-ID: <57141c19d8ff4042a6ff04ae964f2f1c@sap.com>

Hi,

I had pushed JDK-8203669 about 48 hours ago, but didn't get any results:
changeset:   50531:306270e46922 JDK-8203669tip50527:fd2fccf3b079
user:        gromero
date:        Mon May 21 13:23:55 2018 -0400
summary:     8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM detection for enabling RTM on Linux / POWER9"
Reviewed-by: mdoerr, goetz

Can somebody take a look, please?

Best regards,
Martin


From david.holmes at oracle.com  Fri Jun  1 08:53:00 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 1 Jun 2018 18:53:00 +1000
Subject: Is jdk-submit down again?
In-Reply-To: <57141c19d8ff4042a6ff04ae964f2f1c@sap.com>
References: <57141c19d8ff4042a6ff04ae964f2f1c@sap.com>
Message-ID: <a496a94b-3fcf-259d-81bf-5c2494cb63e0@oracle.com>

Hi Martin,

Can you please email ops at openjdk.java.net if you think there is an 
issue. That's more likely to reach someone who can actually do something.

Thanks,
David

On 1/06/2018 6:27 PM, Doerr, Martin wrote:
> Hi,
> 
> I had pushed JDK-8203669 about 48 hours ago, but didn't get any results:
> changeset:   50531:306270e46922 JDK-8203669tip50527:fd2fccf3b079
> user:        gromero
> date:        Mon May 21 13:23:55 2018 -0400
> summary:     8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM detection for enabling RTM on Linux / POWER9"
> Reviewed-by: mdoerr, goetz
> 
> Can somebody take a look, please?
> 
> Best regards,
> Martin
> 

From eag2001 at gmail.com  Fri Jun  1 14:29:44 2018
From: eag2001 at gmail.com (=?UTF-8?Q?Emilio_Aguilar_Guti=C3=A9rrez?=)
Date: Fri, 1 Jun 2018 15:29:44 +0100
Subject: OpenJDK Project insatisfaction
Message-ID: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>

Hello

I have enrolled in this posting list to make receive to everybody my
insatisfaction message (ohh)...

I am 49 years old and I am in the IT Development world since the 80's...
I started with Spectrum 64...

I have learned Pascal, C, C++, SQL, Java, Javascript, and the list
continues...

And I like the JVM idea (multiplatform virtual machine architecture)

But I got very dissapointed when I realized that to get OpenJDK from the
source code, I have to install a previous JDK...

This means that I cannot get JDK just from a source code and a external
tool...

So, I thought that JDK source code was useless... Because, If I have de
JDK, why do I have to compile the JDK?... It is only worthy to make an
upgrade... But... where is the seed? How can I get the initial seed?

In C world the things are different... You can build everything in some few
steps:
1) Get a OS (FreeDos or Minimal Linux)
            ^----This is an Achilles heel...
2) Get an Asembler tool for that OS and CPU
           ^----This is an Achilles heel...
3) Get an Assembler code for a C/C++ Compiler-Linker
4) Generate a C/C++ Compiler-Linker
5) Start Building C/C++ Compiler-Linker Better (DJGCC or GCC)
6) Build all the libraries you need
7) Create everything...

That should include:
1) Java Clases and Libraries
1) JVM
2) javac
3) JDK complete

Unfortunately... OpenJDK is not in this sequence...

And I feel that is need to solve the gap...
Because, now, source-code is useless (except for upgrade)

I hope being able to express my idea clearly...
And to convince somebody to review the current way of evolving... Because
it have lost the connection with the origins.

Regards,
Emilio Aguilar Guti?rrez
Software Engineer & IT Teacher

From jonathan.gibbons at oracle.com  Fri Jun  1 14:54:15 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 1 Jun 2018 07:54:15 -0700
Subject: JEP proposed to target JDK 11: 330: Launch Single-File,
 Source-Code Programs
In-Reply-To: <CAByu6UV5BVT+TNPONa3pmRUn9A5pmYiSJNqxBrAAe4_wK1Fz7w@mail.gmail.com>
References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net>
 <bf267441-b5e0-2705-2626-f73203a79b9b@gmail.com>
 <5B10422D.6080403@oracle.com>
 <CAByu6UV5BVT+TNPONa3pmRUn9A5pmYiSJNqxBrAAe4_wK1Fz7w@mail.gmail.com>
Message-ID: <f484c112-457a-71ef-a087-1a12694adfb9@oracle.com>



On 5/31/18 8:06 PM, Thibault Kruse wrote:
> On Fri, Jun 1, 2018 at 3:42 AM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>>
>> On 05/31/2018 06:01 AM, Thibault Kruse wrote:
>>> The effort of typing
>>>
>>>      java HelloWorld.java
>>>      vs.
>>>      java HelloWorld -sourcepath HelloWorld.java
>>>
>>> seems small enough to be suffered for this first day of learning java,...
>> This would be an incompatible change, since all parameters after the main
>> class are specified to be passed as arguments to the main class.
> Ok, sorry, The options would have to come before the class name, like
>
> java -sourcepath HelloWorld.java HelloWorld
>
> Note module notation also allows disambiguating classes:
> java [options] -m <module>[/<mainclass>]
Adding more compilation-related options to the JVM-launcher command
is a slippery slope that is best avoided..

>
>
> The point being the structure could be made flexible enough to specify
> a class to run in several ways, and java could simply error out if
> there were multiple top-level classes to run instead of picking the
> first. I am not passionate about the exact alternative syntax, I would
> just like to know why disambiguating the class to run instead of
> picking the first one found in the file was chosen as the best
> solution. This is not mentioned in the JEP I think.
>
>
>>> # Regarding the single-file restriction
>>>
>>> Why not allow users to modularize their first few classes in java and load
>>> them all to run a main method? Teaching them to put all classes in a single
>>> file does not seem java-like. A source-path option could well point to a
>>> folder or a list of folders to load sources from.
>>
>> While we permit multiple top level classes in the file, I would not
>> recommend it as a style. The use cases here are for beginners writing
>> initial small programs, and for use of Java in scripts. Anything beyond
>> those use cases is better addressed by existing tools for building programs
>> composed of many source files.
> Initial small programs may still span multiple files. Many online java
> tutorials will use multiple files.
> Even for the purpose of scripting, it can make good sense to spread
> code over multiple script files.
>
> A similar scenario is to have teams where some members will
> appropriate tools, but some team-members don't (As an example, teams
> of Java-experts and newcomers deciding on the language to use for a
> new project).
> In that case, just to allow the non-tool-users to run the main class,
> all team members would be forced to work on the source as a single
> file.
> By allowing multiple files, you enable easier cooperation between such users.
If you want to develop small programs spanning multiple files, it is better
to use existing tools (javac, jar, java).

>
>>> # Regarding the source filename
>>>
>>> JEP330 (2018/05/30) currently also states: "The compiler does not enforce
>>> the optional restriction defined at the end of JLS ?7.6, [...] the type name
>>> followed by the .java extension. [...] If the file does not have
>>> the|.java|extension..."
>>> I see no significant benefit in allowing users to use a different filename
>>> (unless for the shebang line / scripting issue), and IDEs will again
>>> struggle to turn off compiler errors for such files. I believe it is better
>>> to keep the experience consistent.
>> The desire to disable the file name check is specifically to support the
>> shebang/scripting use case.
> So if the shebang support were declared a non-goal, the filename check
> would be kept intact?
> I believe files needing to be run with the java command should have a
> standard java filename extension.

If you are just using "java <filename>", the file must have a .java 
extension.

-- Jon

From neugens at redhat.com  Fri Jun  1 14:59:52 2018
From: neugens at redhat.com (Mario Torre)
Date: Fri, 1 Jun 2018 16:59:52 +0200
Subject: JEP proposed to target JDK 11: 330: Launch Single-File
 Source-Code Programs
In-Reply-To: <5a492211-f213-202d-b29f-56888a5c9c78@oracle.com>
References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net>
 <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com>
 <CAJwKKmZpa1d-pr6kdYMd97vpCyYZHTvMHcTu3VJZoq3tCsFU+A@mail.gmail.com>
 <0d1f2b8a-a0cd-ae55-3092-f30bfa34c592@oracle.com>
 <CAJwKKmb0FdENudkywtyQ192dF6rJi4bBWcPEyyLMnhk8Tsz9Rw@mail.gmail.com>
 <5a492211-f213-202d-b29f-56888a5c9c78@oracle.com>
Message-ID: <CAJwKKmZGF81MteLLnoVQN7LQCC0OadX9=mUTjLx9tKCMzYCWtQ@mail.gmail.com>

Hi Jonathan,

I would like to give a bit of feedback following the last discussions
and as a closure since I understand you would like to proceed with the
JEP submission.

My main concern is still with the shebang proposal, even in the
current form I find it weird that we need special casing and while I
agree with the points that the JSL (and to some extent the compiler)
should be left out of the equation, at the same time I can't help
thinking that allowing Java code to be run and interpreted as script
should be somewhat regulated. Nevertheless, this is a much better
alternative than the original version so if the strong opinion is to
move forward then I do prefer this version and I won't object further.
Also, the benefit of not touching the spec is that we can revisit this
JEP in the future if we understand more side effects or concerns.

Cheers,
Mario

On Fri, May 25, 2018 at 3:55 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 5/25/18 3:18 AM, Mario Torre wrote:
>>
>>   On Fri, May 25, 2018 at 1:23 AM, Jonathan Gibbons
>> <jonathan.gibbons at oracle.com> wrote:
>>>
>>> Mario,
>>> Regarding your specific proposal for using "here" documents, I do not
>>> follow
>>> your argument that your example is better for being "proper Java, with
>>> all
>>> the benefits like debugging, IDE support etc.". At least to a casual
>>> observer, the shebang line and the couple of lines to invoke java using a
>>> "here" document look very similar: in both cases, there is a cryptic
>>> header
>>> followed by some Java source code. In both cases the file can be seen as
>>> a
>>> script that contains Java source code, as compared to a Java source file
>>> that is a script.
>>
>> The difference is subtle, with the shebang the "#!" is part of the
>> java file, with the here syntax it isn't, that means every single line
>> you write is actually proper java. One is an invalid .java file
>> unrecognized by IDE and compilers, the other is a shell script.
>
>
> Mario,
>
> I agree with your general concern about polluting Java source files,
> which is why we have suggested modifying the feature to prohibit the use
> of shebang lines in Java source files, as identified by a filename ending
> in ".java". [1]   With this proposed change, the source-file launcher
> will only remove shebang lines in files which are not identified as
> Java source files, thus drawing a clear distinction between files which
> are Java source files and those which are not.   In particular, there
> will not be any invalid .java files, unrecognized by IDEs and compilers,
> to be worried about.
>
> -- Jon
>
>
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html
>>
>>
>> The implication is that a developer that wants to embed it in a shell
>> script is more forced to think about the embedding as part of the
>> process of writing the utility, but can do so at a later stage with no
>> modifications and without introducing an incompatible java artefact
>> (which is great for reuse for instance).
>>
>> You are right there's not much difference from an IDE point of view
>> though, except that again a .java class that is loaded in an IDE but
>> contains the "#!"line won't be valid and will be unrecognized, while a
>> shell script will be essentially seen as a shell script. I suspect
>> that java code that is mean to be embedded like this will likely be
>> small utilities, but there's nothing stopping someone from creating a
>> full applications in the IDE and then just embed it in a script. The
>> shebang in this case would be tying the two process too tightly, if we
>> only support the here documents we are decoupling things which is
>> better imho.
>>
>>> As to the possible ways forward:
>>>
>>> * Support for "//!" is attractive but requires a manual or automated
>>> update
>>> to the underlying system, which is beyond our control.
>>>
>>> * Support for using "here" documents as you suggest is possible: it is
>>> ultimately more flexible than shebang lines, and should be advertised in
>>> the
>>> JEP, but it requires a more advanced understanding of shell, when much of
>>> the current focus is about simplifying the on-ramp to Java.
>>
>> I would go with that and drop the shebang, I strongly suspect that
>> shebang will create long term problems we are not carefully
>> considering at this stage.
>>
>> Cheers,
>> Mario
>
>



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From forax at univ-mlv.fr  Fri Jun  1 16:15:50 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 1 Jun 2018 18:15:50 +0200 (CEST)
Subject: OpenJDK Project insatisfaction
In-Reply-To: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>
References: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>
Message-ID: <259241832.2386781.1527869750186.JavaMail.zimbra@u-pem.fr>

Any non trivial languages have a self hosting compiler, javac or gcc has been bootstrapped the same way.
  https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

R?mi

----- Mail original -----
> De: "Emilio Aguilar Guti?rrez" <eag2001 at gmail.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Vendredi 1 Juin 2018 16:29:44
> Objet: OpenJDK Project insatisfaction

> Hello
> 
> I have enrolled in this posting list to make receive to everybody my
> insatisfaction message (ohh)...
> 
> I am 49 years old and I am in the IT Development world since the 80's...
> I started with Spectrum 64...
> 
> I have learned Pascal, C, C++, SQL, Java, Javascript, and the list
> continues...
> 
> And I like the JVM idea (multiplatform virtual machine architecture)
> 
> But I got very dissapointed when I realized that to get OpenJDK from the
> source code, I have to install a previous JDK...
> 
> This means that I cannot get JDK just from a source code and a external
> tool...
> 
> So, I thought that JDK source code was useless... Because, If I have de
> JDK, why do I have to compile the JDK?... It is only worthy to make an
> upgrade... But... where is the seed? How can I get the initial seed?
> 
> In C world the things are different... You can build everything in some few
> steps:
> 1) Get a OS (FreeDos or Minimal Linux)
>            ^----This is an Achilles heel...
> 2) Get an Asembler tool for that OS and CPU
>           ^----This is an Achilles heel...
> 3) Get an Assembler code for a C/C++ Compiler-Linker
> 4) Generate a C/C++ Compiler-Linker
> 5) Start Building C/C++ Compiler-Linker Better (DJGCC or GCC)
> 6) Build all the libraries you need
> 7) Create everything...
> 
> That should include:
> 1) Java Clases and Libraries
> 1) JVM
> 2) javac
> 3) JDK complete
> 
> Unfortunately... OpenJDK is not in this sequence...
> 
> And I feel that is need to solve the gap...
> Because, now, source-code is useless (except for upgrade)
> 
> I hope being able to express my idea clearly...
> And to convince somebody to review the current way of evolving... Because
> it have lost the connection with the origins.
> 
> Regards,
> Emilio Aguilar Guti?rrez
> Software Engineer & IT Teacher

From eag2001 at gmail.com  Fri Jun  1 18:30:55 2018
From: eag2001 at gmail.com (=?UTF-8?Q?Emilio_Aguilar_Guti=C3=A9rrez?=)
Date: Fri, 1 Jun 2018 19:30:55 +0100
Subject: OpenJDK Project insatisfaction
In-Reply-To: <259241832.2386781.1527869750186.JavaMail.zimbra@u-pem.fr>
References: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>
 <259241832.2386781.1527869750186.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAAhmFofdCUSBN3JTYmd5=+Uyw6VgQ1z8v__b6m9xq5qS4-t=Zg@mail.gmail.com>

Hello.

I understand the benefit of proving a complier can regenerate itself...
It is a great demostration of "non triviality"...

But in relation with my concern... Everybody should also have access to the
original compiler development... which was written in other language
(because the targeted one did not existed yet).

I would like to recover the first development source code of it.

Then, I could have all the complet chain...

1- First JDK (perhaps written in C / C++)
2- JDK self compiled
3- All the next enhancements.

But... without the point 1... the beginning is lost... and also any other
beginning that could learn from the first one...

Does anybody have the source code of OpenJDK 0.0 in a programming language
other than Java?

I am very interested....

Thank a lot for your answers.

Emilio Aguilar Guti?rrez

2018-06-01 17:15 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:

> Any non trivial languages have a self hosting compiler, javac or gcc has
> been bootstrapped the same way.
>   https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
>
> R?mi
>
> ----- Mail original -----
> > De: "Emilio Aguilar Guti?rrez" <eag2001 at gmail.com>
> > ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> > Envoy?: Vendredi 1 Juin 2018 16:29:44
> > Objet: OpenJDK Project insatisfaction
>
> > Hello
> >
> > I have enrolled in this posting list to make receive to everybody my
> > insatisfaction message (ohh)...
> >
> > I am 49 years old and I am in the IT Development world since the 80's...
> > I started with Spectrum 64...
> >
> > I have learned Pascal, C, C++, SQL, Java, Javascript, and the list
> > continues...
> >
> > And I like the JVM idea (multiplatform virtual machine architecture)
> >
> > But I got very dissapointed when I realized that to get OpenJDK from the
> > source code, I have to install a previous JDK...
> >
> > This means that I cannot get JDK just from a source code and a external
> > tool...
> >
> > So, I thought that JDK source code was useless... Because, If I have de
> > JDK, why do I have to compile the JDK?... It is only worthy to make an
> > upgrade... But... where is the seed? How can I get the initial seed?
> >
> > In C world the things are different... You can build everything in some
> few
> > steps:
> > 1) Get a OS (FreeDos or Minimal Linux)
> >            ^----This is an Achilles heel...
> > 2) Get an Asembler tool for that OS and CPU
> >           ^----This is an Achilles heel...
> > 3) Get an Assembler code for a C/C++ Compiler-Linker
> > 4) Generate a C/C++ Compiler-Linker
> > 5) Start Building C/C++ Compiler-Linker Better (DJGCC or GCC)
> > 6) Build all the libraries you need
> > 7) Create everything...
> >
> > That should include:
> > 1) Java Clases and Libraries
> > 1) JVM
> > 2) javac
> > 3) JDK complete
> >
> > Unfortunately... OpenJDK is not in this sequence...
> >
> > And I feel that is need to solve the gap...
> > Because, now, source-code is useless (except for upgrade)
> >
> > I hope being able to express my idea clearly...
> > And to convince somebody to review the current way of evolving... Because
> > it have lost the connection with the origins.
> >
> > Regards,
> > Emilio Aguilar Guti?rrez
> > Software Engineer & IT Teacher
>

From roman at kennke.org  Fri Jun  1 19:22:56 2018
From: roman at kennke.org (Roman Kennke)
Date: Fri, 1 Jun 2018 21:22:56 +0200
Subject: OpenJDK Project insatisfaction
In-Reply-To: <CAAhmFofdCUSBN3JTYmd5=+Uyw6VgQ1z8v__b6m9xq5qS4-t=Zg@mail.gmail.com>
References: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>
 <259241832.2386781.1527869750186.JavaMail.zimbra@u-pem.fr>
 <CAAhmFofdCUSBN3JTYmd5=+Uyw6VgQ1z8v__b6m9xq5qS4-t=Zg@mail.gmail.com>
Message-ID: <140b7241-bebb-786e-de51-aee216fd24d1@kennke.org>

Hello Emilio,

OpenJDK was open sourced when JDK6 was already released as closed source
JDK. Back then it was indeed problematic to build it with only open
source tool chain, because of this chicken-and-egg problem. There have
been efforts to compile it with other Free Java implementations then,
using gcj or other GNU Classpath based compilers. However, nowadays this
does not seem necessary anymore because every major Linux distro ships
with a recent enough OpenJDK, and on other platforms there are pre-built
OpenJDK binaries to build OpenJDK as well. If you want to trace OpenJDK
to its origins you either have to dig through the somewhat tangled
history of Free Java, or ask Oracle to give you the very first source
code (in other words, forget it).

Roman

> I understand the benefit of proving a complier can regenerate itself...
> It is a great demostration of "non triviality"...
> 
> But in relation with my concern... Everybody should also have access to the
> original compiler development... which was written in other language
> (because the targeted one did not existed yet).
> 
> I would like to recover the first development source code of it.
> 
> Then, I could have all the complet chain...
> 
> 1- First JDK (perhaps written in C / C++)
> 2- JDK self compiled
> 3- All the next enhancements.
> 
> But... without the point 1... the beginning is lost... and also any other
> beginning that could learn from the first one...
> 
> Does anybody have the source code of OpenJDK 0.0 in a programming language
> other than Java?
> 
> I am very interested....
> 
> Thank a lot for your answers.
> 
> Emilio Aguilar Guti?rrez
> 
> 2018-06-01 17:15 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:
> 
>> Any non trivial languages have a self hosting compiler, javac or gcc has
>> been bootstrapped the same way.
>>   https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
>>
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Emilio Aguilar Guti?rrez" <eag2001 at gmail.com>
>>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>>> Envoy?: Vendredi 1 Juin 2018 16:29:44
>>> Objet: OpenJDK Project insatisfaction
>>
>>> Hello
>>>
>>> I have enrolled in this posting list to make receive to everybody my
>>> insatisfaction message (ohh)...
>>>
>>> I am 49 years old and I am in the IT Development world since the 80's...
>>> I started with Spectrum 64...
>>>
>>> I have learned Pascal, C, C++, SQL, Java, Javascript, and the list
>>> continues...
>>>
>>> And I like the JVM idea (multiplatform virtual machine architecture)
>>>
>>> But I got very dissapointed when I realized that to get OpenJDK from the
>>> source code, I have to install a previous JDK...
>>>
>>> This means that I cannot get JDK just from a source code and a external
>>> tool...
>>>
>>> So, I thought that JDK source code was useless... Because, If I have de
>>> JDK, why do I have to compile the JDK?... It is only worthy to make an
>>> upgrade... But... where is the seed? How can I get the initial seed?
>>>
>>> In C world the things are different... You can build everything in some
>> few
>>> steps:
>>> 1) Get a OS (FreeDos or Minimal Linux)
>>>            ^----This is an Achilles heel...
>>> 2) Get an Asembler tool for that OS and CPU
>>>           ^----This is an Achilles heel...
>>> 3) Get an Assembler code for a C/C++ Compiler-Linker
>>> 4) Generate a C/C++ Compiler-Linker
>>> 5) Start Building C/C++ Compiler-Linker Better (DJGCC or GCC)
>>> 6) Build all the libraries you need
>>> 7) Create everything...
>>>
>>> That should include:
>>> 1) Java Clases and Libraries
>>> 1) JVM
>>> 2) javac
>>> 3) JDK complete
>>>
>>> Unfortunately... OpenJDK is not in this sequence...
>>>
>>> And I feel that is need to solve the gap...
>>> Because, now, source-code is useless (except for upgrade)
>>>
>>> I hope being able to express my idea clearly...
>>> And to convince somebody to review the current way of evolving... Because
>>> it have lost the connection with the origins.
>>>
>>> Regards,
>>> Emilio Aguilar Guti?rrez
>>> Software Engineer & IT Teacher
>>
> 



From mark.reinhold at oracle.com  Fri Jun  1 19:55:48 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 01 Jun 2018 12:55:48 -0700
Subject: JEP proposed to target JDK 11: 330: Launch Single-File
 Source-Code Programs
In-Reply-To: <20180524160524.266587816@eggemoggin.niobe.net>
References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net>
 <20180524160524.266587816@eggemoggin.niobe.net>
Message-ID: <20180601125548.31766339@eggemoggin.niobe.net>

2018/5/24 16:05:24 -0700, mark.reinhold at oracle.com:
> 2018/5/17 13:12:04 -0700, mark.reinhold at oracle.com:
>> The following JEP is proposed to target JDK 11:
>> 
>>  330: Launch Single-File Source-Code Programs
>>       http://openjdk.java.net/jeps/330
>> 
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Thursday,
>> 24 May, 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.
> 
> Thanks to all who?ve contributed to the vigorous discussion of this JEP.
> Let?s extend the review period to 23:00 UTC on Thursday, 31 May, to make
> sure that all concerns are addressed.

At this point not every Committer is completely happy with this JEP, but
it appears to me that Jon has satisfactorily addressed the issues raised
thus far and updated the JEP accordingly.  I?ve therefore targeted this
JEP to JDK 11.

- Mark

From sean.mullan at oracle.com  Fri Jun  1 20:17:03 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 1 Jun 2018 16:17:03 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
Message-ID: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>

I hereby nominate Rajan Halade to JDK Reviewer.

Rajan is the SQE Security Team Lead at Oracle. He has been working on 
the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. 
Rajan was also the owner of JEP 319 (Root Certificates) which was 
successfully delivered in JDK 10. His other responsibilities include 
handling static analysis, fuzzing and reviewing vulnerabilities.

Votes are due by 20:30 GMT June 15, 2018.

Only current JDK Reviewers [1] 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 [2].

Sean Mullan

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#reviewer-vote
[3] 
http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()

From xuelei.fan at oracle.com  Fri Jun  1 20:20:44 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 1 Jun 2018 13:20:44 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <af65fdbc-07ab-2f24-27a5-940ebaa35042@oracle.com>

Vote: Yes.

Xuelei

On 6/1/2018 1:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. 
> Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 
> 

From sean.mullan at oracle.com  Fri Jun  1 20:28:43 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 1 Jun 2018 16:28:43 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <74a6c96c-44e8-b196-e5e1-5e14668f34bf@oracle.com>

Vote: Yes

--Sean

On 6/1/18 4:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. 
> Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 
> 

From harold.seigel at oracle.com  Fri Jun  1 20:30:04 2018
From: harold.seigel at oracle.com (Harold David Seigel)
Date: Fri, 1 Jun 2018 16:30:04 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <45f41229-9562-bf50-45de-a7061a19cc4b@oracle.com>

Vote: Yes

Harold

On 6/1/2018 4:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
>
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK 
> [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
>
> Votes are due by 20:30 GMT June 15, 2018.
>
> Only current JDK Reviewers [1] 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 [2].
>
> Sean Mullan
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From igor.ignatyev at oracle.com  Fri Jun  1 20:30:39 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 1 Jun 2018 13:30:39 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <42917E59-2AF2-4A7B-9021-C688E9AB12EB@oracle.com>

> On Jun 1, 2018, at 1:17 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I hereby nominate Rajan Halade to JDK Reviewer.

Vote: Yes

-- Igor


From anthony.scarpino at oracle.com  Fri Jun  1 20:59:13 2018
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 1 Jun 2018 13:59:13 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <43c6aa74-dfc5-c2e6-ecdb-23c2f920ac20@oracle.com>

Vote: Yes

Tony

On 06/01/2018 01:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. 
> Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 
> 


From ivan.gerasimov at oracle.com  Fri Jun  1 21:10:49 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 1 Jun 2018 14:10:49 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <687bf696-6b55-9275-7d58-518e53de6616@oracle.com>

Vote: Yes

-- 
With kind regards,
Ivan Gerasimov


From stuart.marks at oracle.com  Fri Jun  1 21:21:59 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 1 Jun 2018 14:21:59 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <eee7ed71-2964-9356-abd8-eb1173c35a3d@oracle.com>

Vote: yes

On 6/1/18 1:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on the JDK 
> for 4-5 years. He has contributed 35 changesets to the JDK [3]. Rajan was also 
> the owner of JEP 319 (Root Certificates) which was successfully delivered in JDK 
> 10. His other responsibilities include handling static analysis, fuzzing and 
> reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 
> 

From lois.foltan at oracle.com  Fri Jun  1 21:24:28 2018
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 1 Jun 2018 17:24:28 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <e378cd61-a4aa-4ad0-28be-9ce629e05135@oracle.com>

Vote: yes

Lois

On 6/1/2018 4:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
>
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK 
> [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
>
> Votes are due by 20:30 GMT June 15, 2018.
>
> Only current JDK Reviewers [1] 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 [2].
>
> Sean Mullan
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From artem.smotrakov at gmail.com  Fri Jun  1 21:36:05 2018
From: artem.smotrakov at gmail.com (Artem Smotrakov)
Date: Fri, 1 Jun 2018 23:36:05 +0200
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <CANu7eQFk9Pb3DiKudxhhf66XoFPa4g28bK-V9sJo-hfK=hTs5Q@mail.gmail.com>

Vote: Yes

Artem

??, 1 ???. 2018 ?. ? 22:17, Sean Mullan <sean.mullan at oracle.com>:

> I hereby nominate Rajan Halade to JDK Reviewer.
>
> Rajan is the SQE Security Team Lead at Oracle. He has been working on
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3].
> Rajan was also the owner of JEP 319 (Root Certificates) which was
> successfully delivered in JDK 10. His other responsibilities include
> handling static analysis, fuzzing and reviewing vulnerabilities.
>
> Votes are due by 20:30 GMT June 15, 2018.
>
> Only current JDK Reviewers [1] 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 [2].
>
> Sean Mullan
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3]
>
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()
>

From david.holmes at oracle.com  Fri Jun  1 23:21:46 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 2 Jun 2018 09:21:46 +1000
Subject: OpenJDK Project insatisfaction
In-Reply-To: <CAAhmFofdCUSBN3JTYmd5=+Uyw6VgQ1z8v__b6m9xq5qS4-t=Zg@mail.gmail.com>
References: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>
 <259241832.2386781.1527869750186.JavaMail.zimbra@u-pem.fr>
 <CAAhmFofdCUSBN3JTYmd5=+Uyw6VgQ1z8v__b6m9xq5qS4-t=Zg@mail.gmail.com>
Message-ID: <303261af-3186-7f5a-ec04-341d635889e7@oracle.com>

On 2/06/2018 4:30 AM, Emilio Aguilar Guti?rrez wrote:
> Hello.
> 
> I understand the benefit of proving a complier can regenerate itself...
> It is a great demostration of "non triviality"...
> 
> But in relation with my concern... Everybody should also have access to the
> original compiler development... which was written in other language
> (because the targeted one did not existed yet).
> 
> I would like to recover the first development source code of it.
> 
> Then, I could have all the complet chain...
> 
> 1- First JDK (perhaps written in C / C++)

I doubt it ever existed. There would have been a basic parser/generator 
tool using the tools of the day back in the mid 80's to bootstrap the 
initial prototype but that would have become self-hosting years before 
such a thing as a "JDK" existed.

David
-----

> 2- JDK self compiled
> 3- All the next enhancements.
> 
> But... without the point 1... the beginning is lost... and also any other
> beginning that could learn from the first one...
> Does anybody have the source code of OpenJDK 0.0 in a programming language
> other than Java?
> 
> I am very interested....
> 
> Thank a lot for your answers.
> 
> Emilio Aguilar Guti?rrez
> 
> 2018-06-01 17:15 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:
> 
>> Any non trivial languages have a self hosting compiler, javac or gcc has
>> been bootstrapped the same way.
>>    https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
>>
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Emilio Aguilar Guti?rrez" <eag2001 at gmail.com>
>>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>>> Envoy?: Vendredi 1 Juin 2018 16:29:44
>>> Objet: OpenJDK Project insatisfaction
>>
>>> Hello
>>>
>>> I have enrolled in this posting list to make receive to everybody my
>>> insatisfaction message (ohh)...
>>>
>>> I am 49 years old and I am in the IT Development world since the 80's...
>>> I started with Spectrum 64...
>>>
>>> I have learned Pascal, C, C++, SQL, Java, Javascript, and the list
>>> continues...
>>>
>>> And I like the JVM idea (multiplatform virtual machine architecture)
>>>
>>> But I got very dissapointed when I realized that to get OpenJDK from the
>>> source code, I have to install a previous JDK...
>>>
>>> This means that I cannot get JDK just from a source code and a external
>>> tool...
>>>
>>> So, I thought that JDK source code was useless... Because, If I have de
>>> JDK, why do I have to compile the JDK?... It is only worthy to make an
>>> upgrade... But... where is the seed? How can I get the initial seed?
>>>
>>> In C world the things are different... You can build everything in some
>> few
>>> steps:
>>> 1) Get a OS (FreeDos or Minimal Linux)
>>>             ^----This is an Achilles heel...
>>> 2) Get an Asembler tool for that OS and CPU
>>>            ^----This is an Achilles heel...
>>> 3) Get an Assembler code for a C/C++ Compiler-Linker
>>> 4) Generate a C/C++ Compiler-Linker
>>> 5) Start Building C/C++ Compiler-Linker Better (DJGCC or GCC)
>>> 6) Build all the libraries you need
>>> 7) Create everything...
>>>
>>> That should include:
>>> 1) Java Clases and Libraries
>>> 1) JVM
>>> 2) javac
>>> 3) JDK complete
>>>
>>> Unfortunately... OpenJDK is not in this sequence...
>>>
>>> And I feel that is need to solve the gap...
>>> Because, now, source-code is useless (except for upgrade)
>>>
>>> I hope being able to express my idea clearly...
>>> And to convince somebody to review the current way of evolving... Because
>>> it have lost the connection with the origins.
>>>
>>> Regards,
>>> Emilio Aguilar Guti?rrez
>>> Software Engineer & IT Teacher
>>

From jonathan.gibbons at oracle.com  Fri Jun  1 23:35:19 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 01 Jun 2018 16:35:19 -0700
Subject: OpenJDK Project insatisfaction
In-Reply-To: <303261af-3186-7f5a-ec04-341d635889e7@oracle.com>
References: <CAAhmFodu=Xf1os_J7ifYD7ifg+gGTAXBfcFHr4chp+D2PmeQJQ@mail.gmail.com>
 <259241832.2386781.1527869750186.JavaMail.zimbra@u-pem.fr>
 <CAAhmFofdCUSBN3JTYmd5=+Uyw6VgQ1z8v__b6m9xq5qS4-t=Zg@mail.gmail.com>
 <303261af-3186-7f5a-ec04-341d635889e7@oracle.com>
Message-ID: <5B11D837.3050009@oracle.com>



On 06/01/2018 04:21 PM, David Holmes wrote:
> On 2/06/2018 4:30 AM, Emilio Aguilar Guti?rrez wrote:
>> Hello.
>>
>> I understand the benefit of proving a complier can regenerate itself...
>> It is a great demostration of "non triviality"...
>>
>> But in relation with my concern... Everybody should also have access 
>> to the
>> original compiler development... which was written in other language
>> (because the targeted one did not existed yet).
>>
>> I would like to recover the first development source code of it.
>>
>> Then, I could have all the complet chain...
>>
>> 1- First JDK (perhaps written in C / C++)
>
> I doubt it ever existed. There would have been a basic 
> parser/generator tool using the tools of the day back in the mid 80's 
> to bootstrap the initial prototype but that would have become 
> self-hosting years before such a thing as a "JDK" existed.

It wasn't even Java and JDK back then;  it was Oak and Green

https://web.archive.org/web/20070618074030/https://duke.dev.java.net/green/

-- Jon

>
> David
> -----
>
>> 2- JDK self compiled
>> 3- All the next enhancements.
>>
>> But... without the point 1... the beginning is lost... and also any 
>> other
>> beginning that could learn from the first one...
>> Does anybody have the source code of OpenJDK 0.0 in a programming 
>> language
>> other than Java?
>>
>> I am very interested....
>>
>> Thank a lot for your answers.
>>
>> Emilio Aguilar Guti?rrez
>>
>> 2018-06-01 17:15 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:
>>
>>> Any non trivial languages have a self hosting compiler, javac or gcc 
>>> has
>>> been bootstrapped the same way.
>>>    https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
>>>
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Emilio Aguilar Guti?rrez" <eag2001 at gmail.com>
>>>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>>>> Envoy?: Vendredi 1 Juin 2018 16:29:44
>>>> Objet: OpenJDK Project insatisfaction
>>>
>>>> Hello
>>>>
>>>> I have enrolled in this posting list to make receive to everybody my
>>>> insatisfaction message (ohh)...
>>>>
>>>> I am 49 years old and I am in the IT Development world since the 
>>>> 80's...
>>>> I started with Spectrum 64...
>>>>
>>>> I have learned Pascal, C, C++, SQL, Java, Javascript, and the list
>>>> continues...
>>>>
>>>> And I like the JVM idea (multiplatform virtual machine architecture)
>>>>
>>>> But I got very dissapointed when I realized that to get OpenJDK 
>>>> from the
>>>> source code, I have to install a previous JDK...
>>>>
>>>> This means that I cannot get JDK just from a source code and a 
>>>> external
>>>> tool...
>>>>
>>>> So, I thought that JDK source code was useless... Because, If I 
>>>> have de
>>>> JDK, why do I have to compile the JDK?... It is only worthy to make an
>>>> upgrade... But... where is the seed? How can I get the initial seed?
>>>>
>>>> In C world the things are different... You can build everything in 
>>>> some
>>> few
>>>> steps:
>>>> 1) Get a OS (FreeDos or Minimal Linux)
>>>>             ^----This is an Achilles heel...
>>>> 2) Get an Asembler tool for that OS and CPU
>>>>            ^----This is an Achilles heel...
>>>> 3) Get an Assembler code for a C/C++ Compiler-Linker
>>>> 4) Generate a C/C++ Compiler-Linker
>>>> 5) Start Building C/C++ Compiler-Linker Better (DJGCC or GCC)
>>>> 6) Build all the libraries you need
>>>> 7) Create everything...
>>>>
>>>> That should include:
>>>> 1) Java Clases and Libraries
>>>> 1) JVM
>>>> 2) javac
>>>> 3) JDK complete
>>>>
>>>> Unfortunately... OpenJDK is not in this sequence...
>>>>
>>>> And I feel that is need to solve the gap...
>>>> Because, now, source-code is useless (except for upgrade)
>>>>
>>>> I hope being able to express my idea clearly...
>>>> And to convince somebody to review the current way of evolving... 
>>>> Because
>>>> it have lost the connection with the origins.
>>>>
>>>> Regards,
>>>> Emilio Aguilar Guti?rrez
>>>> Software Engineer & IT Teacher
>>>


From valerie.peng at oracle.com  Sat Jun  2 00:04:59 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 1 Jun 2018 17:04:59 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <856dcdd8-3ebc-ac8f-c7c9-8bbed267a68c@oracle.com>

Vote: Yes

Valerie

On 6/1/2018 1:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
>
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK 
> [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
>
> Votes are due by 20:30 GMT June 15, 2018.
>
> Only current JDK Reviewers [1] 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 [2].
>
> Sean Mullan
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From weijun.wang at oracle.com  Sat Jun  2 14:47:26 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 2 Jun 2018 22:47:26 +0800
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <37B17CF4-C001-4BD1-9458-C11AF79FAE7F@oracle.com>

Vote: Yes

-weijun

> On Jun 2, 2018, at 4:17 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was successfully delivered in JDK 10. His other responsibilities include handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From tobias.hartmann at oracle.com  Mon Jun  4 06:33:30 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 4 Jun 2018 08:33:30 +0200
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <73eaadbe-5e7d-dfe9-6086-3e78a24bc58c@oracle.com>

Vote: yes

Tobias

On 01.06.2018 22:17, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on the JDK for 4-5 years. He has
> contributed 35 changesets to the JDK [3]. Rajan was also the owner of JEP 319 (Root Certificates)
> which was successfully delivered in JDK 10. His other responsibilities include handling static
> analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()
> 

From coleen.phillimore at oracle.com  Mon Jun  4 13:13:39 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Jun 2018 09:13:39 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <5ba083c2-9903-14d6-c3ef-b113fa8fcc78@oracle.com>

Vote: yes

On 6/1/18 4:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
>
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK 
> [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
>
> Votes are due by 20:30 GMT June 15, 2018.
>
> Only current JDK Reviewers [1] 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 [2].
>
> Sean Mullan
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From Roger.Riggs at Oracle.com  Mon Jun  4 13:34:54 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 4 Jun 2018 09:34:54 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <6d3fa24b-0691-c4b2-0ecf-7ccdabb0f784@Oracle.com>

Vote: Yes

On 6/1/2018 4:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.


From karen.kinnear at oracle.com  Mon Jun  4 14:11:59 2018
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 4 Jun 2018 10:11:59 -0400
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <EFECDB6B-4F47-4FA3-A73B-11C5B8BD843C@oracle.com>

Vote: yes

thanks,
Karen

> On Jun 1, 2018, at 4:17 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was successfully delivered in JDK 10. His other responsibilities include handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From jesper.wilhelmsson at oracle.com  Mon Jun  4 14:26:06 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Mon, 4 Jun 2018 16:26:06 +0200
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <48861F1E-8BBB-4142-9B6E-53865EC3BBB8@oracle.com>

Vote: Yes
/Jesper

> On 1 Jun 2018, at 22:17, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was successfully delivered in JDK 10. His other responsibilities include handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From bradford.wetmore at oracle.com  Mon Jun  4 17:13:15 2018
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 4 Jun 2018 10:13:15 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <6b7ffd46-338c-3cdf-bd18-c2fe15310938@oracle.com>

Vote:  Yes.

Brad


On 6/1/2018 1:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. 
> Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 
> 

From saha.abhijit at gmail.com  Tue Jun  5 00:07:40 2018
From: saha.abhijit at gmail.com (Abhijit Saha)
Date: Mon, 4 Jun 2018 17:07:40 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <6b7ffd46-338c-3cdf-bd18-c2fe15310938@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
 <6b7ffd46-338c-3cdf-bd18-c2fe15310938@oracle.com>
Message-ID: <1C439637-F12D-4D32-B39B-CE34FA3A7045@gmail.com>

Vote: Yes.

-Abhijit

> 
> 
> On 6/1/2018 1:17 PM, Sean Mullan wrote:
>> I hereby nominate Rajan Halade to JDK Reviewer.
>> Rajan is the SQE Security Team Lead at Oracle. He has been working on the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was successfully delivered in JDK 10. His other responsibilities include handling static analysis, fuzzing and reviewing vulnerabilities.
>> Votes are due by 20:30 GMT June 15, 2018.
>> Only current JDK Reviewers [1] 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 [2].
>> Sean Mullan
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#reviewer-vote
>> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 


From sean.coffey at oracle.com  Tue Jun  5 07:32:27 2018
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 5 Jun 2018 08:32:27 +0100
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <de674d93-c028-8bab-528c-1ca7a901c4a6@oracle.com>

Vote: Yes

regards,
Sean.


On 01/06/2018 21:17, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
>
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK 
> [3]. Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
>
> Votes are due by 20:30 GMT June 15, 2018.
>
> Only current JDK Reviewers [1] 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 [2].
>
> Sean Mullan
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()


From serguei.spitsyn at oracle.com  Tue Jun  5 08:13:50 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 5 Jun 2018 01:13:50 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <492cb588-aeac-cb10-a00b-b97f6f214d93@oracle.com>

Vote: yes

From mark.reinhold at oracle.com  Tue Jun  5 23:02:32 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 05 Jun 2018 16:02:32 -0700
Subject: JEP proposed to target JDK 11: 315: Improve Aarch64 Intrinsics
In-Reply-To: <20180529173835.249260702@eggemoggin.niobe.net>
References: <20180529225816.D41691DB3A7@eggemoggin.niobe.net>
 <20180529173835.249260702@eggemoggin.niobe.net>
Message-ID: <20180605160232.434420543@eggemoggin.niobe.net>

2018/5/29 17:38:35 -0700, mark.reinhold at oracle.com:
> 2018/5/29 15:58:16 -0700, mark.reinhold at oracle.com:
>> The following JEP is proposed to target JDK 11:
>> 
>>  315: Improve Aarch64 Intrinsics
>>       http://openjdk.java.net/jeps/315
>> 
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Friday,
>> 5 January, ...
> 
> D?oh!  I meant 23:00 UTC next Thursday, 5 June, of course.

Well, really I meant 23:00 UTC today, 5 June ...

At any rate: Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark

From Sergey.Bylokhov at oracle.com  Tue Jun  5 23:37:20 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Jun 2018 16:37:20 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <101413e3-e9ae-238b-d751-58ad59c5109d@oracle.com>

Vote: yes

On 01/06/2018 13:17, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3]. 
> Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rhalade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge() 
> 


-- 
Best regards, Sergey.

From erik.joelsson at oracle.com  Wed Jun  6 00:15:44 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Jun 2018 17:15:44 -0700
Subject: Heads up concerning the jre image in JDK 11
Message-ID: <de7c91b2-a519-43dc-cded-4bda08504ba5@oracle.com>

Hello,

I would like to make everyone aware of an impending change to JDK 11 
concerning the images we build. In [1], currently under review [2], the 
jre-image will no longer be built by the "images" make target. Oracle 
intends to no longer ship the JRE in its current form and so we do no 
longer wish to build it. It will still be possible to build it using the 
make target "legacy-jre-image" (and "mac-legacy-jre-bundle" for the 
macos specific image). This should serve the need of any OpenJDK 
distributor that still wants to produce the legacy jre, while making it 
clear that it is slated for complete removal in a future release. The 
"product-bundles" target will no longer produce bundles of the legacy jre.

/Erik

[1] https://bugs.openjdk.java.net/browse/JDK-8200132
[2] http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022274.html

From jayathirth.d.v at oracle.com  Wed Jun  6 05:45:30 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 5 Jun 2018 22:45:30 -0700 (PDT)
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <101413e3-e9ae-238b-d751-58ad59c5109d@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
 <101413e3-e9ae-238b-d751-58ad59c5109d@oracle.com>
Message-ID: <d026e121-56d9-4657-a0ba-11a3317269d6@default>

Vote : Yes

On 01/06/2018 13:17, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.
> 
> Rajan is the SQE Security Team Lead at Oracle. He has been working on 
> the JDK for 4-5 years. He has contributed 35 changesets to the JDK [3].
> Rajan was also the owner of JEP 319 (Root Certificates) which was 
> successfully delivered in JDK 10. His other responsibilities include 
> handling static analysis, fuzzing and reviewing vulnerabilities.
> 
> Votes are due by 20:30 GMT June 15, 2018.
> 
> Only current JDK Reviewers [1] 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 [2].
> 
> Sean Mullan
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22rh
> alade%22)+or+desc(%22rajan.halade%40oracle.com%22))+and+not+merge()
>

From mark.reinhold at oracle.com  Wed Jun  6 18:16:03 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed,  6 Jun 2018 11:16:03 -0700 (PDT)
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
Message-ID: <20180606181603.B65891DC34A@eggemoggin.niobe.net>

http://openjdk.java.net/jeps/335

- Mark

From darrelross.java at gmail.com  Wed Jun  6 20:18:02 2018
From: darrelross.java at gmail.com (Darrel Ross)
Date: Wed, 6 Jun 2018 14:18:02 -0600
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
Message-ID: <CACRjcPjdBscQqvfzKcVHb=9rL7ehevFDOV-n8RYVFXHJzASFkQ@mail.gmail.com>

If we remove Nashorn are we seeking to replace with something else (like
V8) or dropping support for running JavaScript in Java altogether?

I would be much more willing to give up Nashorn if it was going to be
replaced with something better, but I have worked on projects that would
have failed had we not been able to utilize Nashorn/Rhino.

It is a great way to integrate Java and JavaScript code.

Simply saying JavaScript is a fast changing environment is not, in my
opinion, an argument to drop support.   Tools like Babel exist to help make
the quickly changing landscape easier to navigate. I think a much stronger
solution would be to find ways to allow users to use these tools rather
than cut support altogether.

JavaScript is perhaps the most ubiquitous language in the programmer's
toolbox.  All a user needs to have installed is a browser to run it.  Java
being able to run it makes it a much stronger platform.  I am not saying
Java should seek to compete with Node, and would argue that a JS
application should probably not be run on the JRE, but there are strong use
cases for a hybrid approach.

If I am misreading the JEP please clarify.  But dropping a feature that
already exists, unless its existence prevents future development and
features, is hardly ever a good idea.

On Wed, Jun 6, 2018 at 12:16 PM, <mark.reinhold at oracle.com> wrote:

> http://openjdk.java.net/jeps/335
>
> - Mark
>

From mark.reinhold at oracle.com  Wed Jun  6 20:54:52 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed,  6 Jun 2018 13:54:52 -0700 (PDT)
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
Message-ID: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>

http://openjdk.java.net/jeps/336

- Mark

From simone.bordet at gmail.com  Wed Jun  6 22:07:49 2018
From: simone.bordet at gmail.com (Simone Bordet)
Date: Thu, 7 Jun 2018 00:07:49 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <CACRjcPjdBscQqvfzKcVHb=9rL7ehevFDOV-n8RYVFXHJzASFkQ@mail.gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <CACRjcPjdBscQqvfzKcVHb=9rL7ehevFDOV-n8RYVFXHJzASFkQ@mail.gmail.com>
Message-ID: <CAFWmRJ3uN8LEv9PzPeJ9ftOg4Zr+1hec4jnr40Pvv6=Wz7VEig@mail.gmail.com>

Hi,

On Wed, Jun 6, 2018 at 10:18 PM, Darrel Ross <darrelross.java at gmail.com> wrote:
> If we remove Nashorn are we seeking to replace with something else (like
> V8) or dropping support for running JavaScript in Java altogether?
>
> I would be much more willing to give up Nashorn if it was going to be
> replaced with something better, but I have worked on projects that would
> have failed had we not been able to utilize Nashorn/Rhino.
>
> It is a great way to integrate Java and JavaScript code.
>
> Simply saying JavaScript is a fast changing environment is not, in my
> opinion, an argument to drop support.   Tools like Babel exist to help make
> the quickly changing landscape easier to navigate. I think a much stronger
> solution would be to find ways to allow users to use these tools rather
> than cut support altogether.
>
> JavaScript is perhaps the most ubiquitous language in the programmer's
> toolbox.  All a user needs to have installed is a browser to run it.  Java
> being able to run it makes it a much stronger platform.  I am not saying
> Java should seek to compete with Node, and would argue that a JS
> application should probably not be run on the JRE, but there are strong use
> cases for a hybrid approach.
>
> If I am misreading the JEP please clarify.  But dropping a feature that
> already exists, unless its existence prevents future development and
> features, is hardly ever a good idea.

The JEP *hints* that it *may* be replaced with GraalJS.

I maintain a library that uses heavily Rhino/Nashorn, and I second
Darrel that I would not like to see such functionality just go away
without replacement.
It would be good if a precise statement about a replacement is made in
the JEP rather than a possibilistic one.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From mark.reinhold at oracle.com  Wed Jun  6 23:34:54 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 06 Jun 2018 16:34:54 -0700
Subject: JEP proposed to target JDK 11: 181: Nest-Based Access Control
In-Reply-To: <20180530224917.507061DB59E@eggemoggin.niobe.net>
References: <20180530224917.507061DB59E@eggemoggin.niobe.net>
Message-ID: <20180606163454.455684224@eggemoggin.niobe.net>

2018/5/30 15:49:17 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   181: Nest-Based Access Control
>        http://openjdk.java.net/jeps/181
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Wednesday,
> 6 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark

From mark.reinhold at oracle.com  Wed Jun  6 23:34:57 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 06 Jun 2018 16:34:57 -0700
Subject: JEP proposed to target JDK 11: 333: ZGC: A Scalable Low-Latency
 Garbage Collector (Experimental)
In-Reply-To: <20180530224918.6DA371DB5A0@eggemoggin.niobe.net>
References: <20180530224918.6DA371DB5A0@eggemoggin.niobe.net>
Message-ID: <20180606163457.679808237@eggemoggin.niobe.net>

2018/5/30 15:49:18 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
>        http://openjdk.java.net/jeps/333
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Wednesday,
> 6 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark

From serguei.spitsyn at oracle.com  Thu Jun  7 00:32:51 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 6 Jun 2018 17:32:51 -0700
Subject: Result: New JDK Reviewer: Chris Plummer
Message-ID: <55d84c93-9394-eff5-86a1-ea1a2789f341@oracle.com>

Voting for Chris Plummer [1] is now closed.

Yes: 30
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is
sufficient to approve the nomination.

Serguei Spitsyn

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001250.html


From vitz.michael at googlemail.com  Thu Jun  7 07:20:18 2018
From: vitz.michael at googlemail.com (Michael Vitz)
Date: Thu, 7 Jun 2018 09:20:18 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
Message-ID: <23031193-B1AB-40E1-B240-CF57D6AE5D67@googlemail.com>

Hi,

some of my colleagues and I also rely on Nashorn for server side JSX rendering.
Removing Nashorn without any replacement would really hurt us. We would
therefore like to see a precise statement about replacement in the JEP, too.

Thanks!

?
Michael Vitz

From luigi.dellaquila at gmail.com  Thu Jun  7 07:48:03 2018
From: luigi.dellaquila at gmail.com (Luigi Dell'Aquila)
Date: Thu, 7 Jun 2018 09:48:03 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <23031193-B1AB-40E1-B240-CF57D6AE5D67@googlemail.com>
References: <23031193-B1AB-40E1-B240-CF57D6AE5D67@googlemail.com>
Message-ID: <CAFZLH8kjXFCmJReTfQnOrj8JQ3Ag447J0H8+Di3mDoi0kOvG_g@mail.gmail.com>

Hi,

Same here, OrientDB stored procedures (we refer to them as functions) are
executed using Nashorn.
We also supported Rhino in the past, so as long as we have an alternative
it should not be a big issue.
Anyway, having more precise information about the replacement will help a
lot

Thanks

Luigi

2018-06-07 9:20 GMT+02:00 Michael Vitz <vitz.michael at googlemail.com>:

> Hi,
>
> some of my colleagues and I also rely on Nashorn for server side JSX
> rendering.
> Removing Nashorn without any replacement would really hurt us. We would
> therefore like to see a precise statement about replacement in the JEP,
> too.
>
> Thanks!
>
> ?
> Michael Vitz

From mario at datenwort.at  Thu Jun  7 08:28:12 2018
From: mario at datenwort.at (Mario Ivankovits)
Date: Thu, 7 Jun 2018 08:28:12 +0000
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
Message-ID: <A96A2601-56C3-478E-BFF8-8DE884D305B6@datenwort.at>

Hi!

We too use it in our application to allow to configure highly non-standard processes which is not easy to build a configuration for and also not worth to clutter the codebase.
Just very small code snippets, but still ...

Best regards,
Mario


> Am 06.06.2018 um 20:16 schrieb mark.reinhold at oracle.com:
> 
> http://openjdk.java.net/jeps/335
> 
> - Mark


From benjamin.john.evans at gmail.com  Thu Jun  7 08:39:13 2018
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Thu, 7 Jun 2018 10:39:13 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <A96A2601-56C3-478E-BFF8-8DE884D305B6@datenwort.at>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <A96A2601-56C3-478E-BFF8-8DE884D305B6@datenwort.at>
Message-ID: <CABKW8Rhp2ntmGV_AXmKzQye-fQPdXSsb-CEGOfuKWTywJKrcqw@mail.gmail.com>

I don't really understand the concern here - presumably the modules
will simply be removed from core, and the community will be at liberty
to change the module name and re-release the Nashorn component as GPL
on Maven Central?

Even in the absence of an Oracle-blessed upgrade path (whether that's
TruffleJS on HotSpot, or a full-blown move to GraalVM), the community
surely always has this option?

Thanks,

Ben

On Thu, Jun 7, 2018 at 10:28 AM, Mario Ivankovits <mario at datenwort.at> wrote:
> Hi!
>
> We too use it in our application to allow to configure highly non-standard processes which is not easy to build a configuration for and also not worth to clutter the codebase.
> Just very small code snippets, but still ...
>
> Best regards,
> Mario
>
>
>> Am 06.06.2018 um 20:16 schrieb mark.reinhold at oracle.com:
>>
>> http://openjdk.java.net/jeps/335
>>
>> - Mark
>

From mario at datenwort.at  Thu Jun  7 08:48:23 2018
From: mario at datenwort.at (Mario Ivankovits)
Date: Thu, 7 Jun 2018 08:48:23 +0000
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <CABKW8Rhp2ntmGV_AXmKzQye-fQPdXSsb-CEGOfuKWTywJKrcqw@mail.gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <A96A2601-56C3-478E-BFF8-8DE884D305B6@datenwort.at>
 <CABKW8Rhp2ntmGV_AXmKzQye-fQPdXSsb-CEGOfuKWTywJKrcqw@mail.gmail.com>
Message-ID: <93A5F843-F692-4DD4-BFCE-2F7929C0DE52@datenwort.at>

Well, I don?t wanted to express any concern.
It is just, in den JEP they write:

"The breadth of Nashorn usage has not been easy to track. It is hoped that feedback for this JEP might provide better insight into actual Nashorn usage."

? and that is what happens now. We give feedback.

I am fine with whatever solution we might come up.


Best regards,
Mario



Am 07.06.2018 um 10:39 schrieb Ben Evans <benjamin.john.evans at gmail.com<mailto:benjamin.john.evans at gmail.com>>:

I don't really understand the concern here - presumably the modules
will simply be removed from core, and the community will be at liberty
to change the module name and re-release the Nashorn component as GPL
on Maven Central?

Even in the absence of an Oracle-blessed upgrade path (whether that's
TruffleJS on HotSpot, or a full-blown move to GraalVM), the community
surely always has this option?

Thanks,

Ben

On Thu, Jun 7, 2018 at 10:28 AM, Mario Ivankovits <mario at datenwort.at<mailto:mario at datenwort.at>> wrote:
Hi!

We too use it in our application to allow to configure highly non-standard processes which is not easy to build a configuration for and also not worth to clutter the codebase.
Just very small code snippets, but still ...

Best regards,
Mario


Am 06.06.2018 um 20:16 schrieb mark.reinhold at oracle.com<mailto:mark.reinhold at oracle.com>:

http://openjdk.java.net/jeps/335

- Mark



From johan.vos at gluonhq.com  Thu Jun  7 08:56:57 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 7 Jun 2018 10:56:57 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <CABKW8Rhp2ntmGV_AXmKzQye-fQPdXSsb-CEGOfuKWTywJKrcqw@mail.gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <A96A2601-56C3-478E-BFF8-8DE884D305B6@datenwort.at>
 <CABKW8Rhp2ntmGV_AXmKzQye-fQPdXSsb-CEGOfuKWTywJKrcqw@mail.gmail.com>
Message-ID: <CABxFH2HmhDb+Gr2H2aCN9DoARVYZML=7oh5hKeVEGvS6WSgwgA@mail.gmail.com>

I agree with Ben.

If there is enough interest for a particular technology, the community will
pick it up, and with the help of Oracle (engineering and non-engineering)
make sure it can be continued.

The same happened with JavaFX. I'm almost certain the JavaFX 11 modules
will be in Maven Central by 2018-09-25 (java -version). There was enough
community interest, so it happened (outside the core OpenJDK release).

- Johan

On Thu, Jun 7, 2018 at 10:49 AM Ben Evans <benjamin.john.evans at gmail.com>
wrote:

> I don't really understand the concern here - presumably the modules
> will simply be removed from core, and the community will be at liberty
> to change the module name and re-release the Nashorn component as GPL
> on Maven Central?
>
> Even in the absence of an Oracle-blessed upgrade path (whether that's
> TruffleJS on HotSpot, or a full-blown move to GraalVM), the community
> surely always has this option?
>
> Thanks,
>
> Ben
>
> On Thu, Jun 7, 2018 at 10:28 AM, Mario Ivankovits <mario at datenwort.at>
> wrote:
> > Hi!
> >
> > We too use it in our application to allow to configure highly
> non-standard processes which is not easy to build a configuration for and
> also not worth to clutter the codebase.
> > Just very small code snippets, but still ...
> >
> > Best regards,
> > Mario
> >
> >
> >> Am 06.06.2018 um 20:16 schrieb mark.reinhold at oracle.com:
> >>
> >> http://openjdk.java.net/jeps/335
> >>
> >> - Mark
> >
>

From luigi.dellaquila at gmail.com  Thu Jun  7 10:18:31 2018
From: luigi.dellaquila at gmail.com (Luigi Dell'Aquila)
Date: Thu, 7 Jun 2018 12:18:31 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <93A5F843-F692-4DD4-BFCE-2F7929C0DE52@datenwort.at>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <A96A2601-56C3-478E-BFF8-8DE884D305B6@datenwort.at>
 <CABKW8Rhp2ntmGV_AXmKzQye-fQPdXSsb-CEGOfuKWTywJKrcqw@mail.gmail.com>
 <93A5F843-F692-4DD4-BFCE-2F7929C0DE52@datenwort.at>
Message-ID: <CAFZLH8nKnSSHtpBy5DMVdW+xHacDxZbWqJqDFarTW6n+iVwJhw@mail.gmail.com>

To answer Johan and Ben,

OrientDB is released as a bundle, compatible with Java8, with Apache2
license, if Nashorn is separately released with GPL license we won't be
able to use it.
Moreover, it is distributed as a binary package and it is compatible with
Java 8, so we should see how to bundle Nashorn in the distribution without
creating conflicts with the classpath in Java 8.

Thanks

Luigi




2018-06-07 10:48 GMT+02:00 Mario Ivankovits <mario at datenwort.at>:

> Well, I don?t wanted to express any concern.
> It is just, in den JEP they write:
>
> "The breadth of Nashorn usage has not been easy to track. It is hoped that
> feedback for this JEP might provide better insight into actual Nashorn
> usage."
>
> ? and that is what happens now. We give feedback.
>
> I am fine with whatever solution we might come up.
>
>
> Best regards,
> Mario
>
>
>
> Am 07.06.2018 um 10:39 schrieb Ben Evans <benjamin.john.evans at gmail.com
> <mailto:benjamin.john.evans at gmail.com>>:
>
> I don't really understand the concern here - presumably the modules
> will simply be removed from core, and the community will be at liberty
> to change the module name and re-release the Nashorn component as GPL
> on Maven Central?
>
> Even in the absence of an Oracle-blessed upgrade path (whether that's
> TruffleJS on HotSpot, or a full-blown move to GraalVM), the community
> surely always has this option?
>
> Thanks,
>
> Ben
>
> On Thu, Jun 7, 2018 at 10:28 AM, Mario Ivankovits <mario at datenwort.at
> <mailto:mario at datenwort.at>> wrote:
> Hi!
>
> We too use it in our application to allow to configure highly non-standard
> processes which is not easy to build a configuration for and also not worth
> to clutter the codebase.
> Just very small code snippets, but still ...
>
> Best regards,
> Mario
>
>
> Am 06.06.2018 um 20:16 schrieb mark.reinhold at oracle.com<mailto:
> mark.reinhold at oracle.com>:
>
> http://openjdk.java.net/jeps/335
>
> - Mark
>
>
>

From Alan.Bateman at oracle.com  Thu Jun  7 10:35:25 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 7 Jun 2018 11:35:25 +0100
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
Message-ID: <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>


There are several replies from people that are using Nashorn but one 
thing that is not clear from any of the mails so far is whether these 
usages are via the javax.script API or by code making direct usage of 
Nashorn APIs. I assume it is mostly the former, in which case the 
applications or libraries concerned might not care (EMCAScript version 
support/compliance details aside) if the JavaScript implementation is 
deployed on the class path or module path. If this assumption is 
correct, and if the jdk.scripting.nashorn module is removed as envisaged 
by the draft JEP, then the disruption should be mostly around moving the 
reliance on the version bundled with the JDK to needing it be deployed 
on the class or module path.

Jim - one small bit of feedback on the draft is that most developers 
aren't going to see the deprecation warnings (I assume very few modules 
will `requires jdk.scripting.nashorn` or `requires jdk.dynalink`). They 
will see warnings if they use the `jjs` tool but I assume many usages 
will be via the scripting API so there won't be any warning. You might 
have looked at this already but having some way to run an application so 
that it emits a warning if Nashorn is used could be useful, esp. in 
large environments where it might not be immediately obvious if one of 
the libraries is using it. One recent example of this type of thing was 
the misfeature know as extension mechanism. In JDK 8 there was a VM 
option to detect usages of the then-deprecated feature before it was 
finally removed in JDK 9.

-Alan

From luigi.dellaquila at gmail.com  Thu Jun  7 10:44:56 2018
From: luigi.dellaquila at gmail.com (Luigi Dell'Aquila)
Date: Thu, 7 Jun 2018 12:44:56 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
Message-ID: <CAFZLH8kNStR6LY0nXGeHq_L-D8WfwWh6_3QkfY4PsdA6aBCNLA@mail.gmail.com>

Hi Alan,

I think most of the panic here comes from the sentence "The risk of
removing Nashorn is that certain applications will no longer run because of
the expectation that JavaScript is present".
Until now we gave it for granted, if it's not going to be the case in the
future we really would like to know it...

Thanks

Luigi



2018-06-07 12:35 GMT+02:00 Alan Bateman <Alan.Bateman at oracle.com>:

>
> There are several replies from people that are using Nashorn but one thing
> that is not clear from any of the mails so far is whether these usages are
> via the javax.script API or by code making direct usage of Nashorn APIs. I
> assume it is mostly the former, in which case the applications or libraries
> concerned might not care (EMCAScript version support/compliance details
> aside) if the JavaScript implementation is deployed on the class path or
> module path. If this assumption is correct, and if the
> jdk.scripting.nashorn module is removed as envisaged by the draft JEP, then
> the disruption should be mostly around moving the reliance on the version
> bundled with the JDK to needing it be deployed on the class or module path.
>
> Jim - one small bit of feedback on the draft is that most developers
> aren't going to see the deprecation warnings (I assume very few modules
> will `requires jdk.scripting.nashorn` or `requires jdk.dynalink`). They
> will see warnings if they use the `jjs` tool but I assume many usages will
> be via the scripting API so there won't be any warning. You might have
> looked at this already but having some way to run an application so that it
> emits a warning if Nashorn is used could be useful, esp. in large
> environments where it might not be immediately obvious if one of the
> libraries is using it. One recent example of this type of thing was the
> misfeature know as extension mechanism. In JDK 8 there was a VM option to
> detect usages of the then-deprecated feature before it was finally removed
> in JDK 9.
>
> -Alan
>

From simone.bordet at gmail.com  Thu Jun  7 10:44:55 2018
From: simone.bordet at gmail.com (Simone Bordet)
Date: Thu, 7 Jun 2018 12:44:55 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
Message-ID: <CAFWmRJ3YoS_Zk28q_YpFZawMUFmBems4DTWye2Oq+LfTwZ4NfA@mail.gmail.com>

Hi,

On Thu, Jun 7, 2018 at 12:35 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> There are several replies from people that are using Nashorn but one thing
> that is not clear from any of the mails so far is whether these usages are
> via the javax.script API or by code making direct usage of Nashorn APIs.

I use JSObject and ScriptObjectMirror from jdk.nashorn.api.scripting.

I will be willing to change those usages to the GraalJS equivalents if
it's going to be a long term solution (which I thought Nashorn was).

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From luigi.dellaquila at gmail.com  Thu Jun  7 10:46:37 2018
From: luigi.dellaquila at gmail.com (Luigi Dell'Aquila)
Date: Thu, 7 Jun 2018 12:46:37 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <CAFWmRJ3YoS_Zk28q_YpFZawMUFmBems4DTWye2Oq+LfTwZ4NfA@mail.gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
 <CAFWmRJ3YoS_Zk28q_YpFZawMUFmBems4DTWye2Oq+LfTwZ4NfA@mail.gmail.com>
Message-ID: <CAFZLH8kDLVPcWEao5xULbZW+zURYAoS4CUFVNngRivnk0ZKDAw@mail.gmail.com>

Same for OrientDB, we use JSObject and ScriptObjectMirror

2018-06-07 12:44 GMT+02:00 Simone Bordet <simone.bordet at gmail.com>:

> Hi,
>
> On Thu, Jun 7, 2018 at 12:35 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> > There are several replies from people that are using Nashorn but one
> thing
> > that is not clear from any of the mails so far is whether these usages
> are
> > via the javax.script API or by code making direct usage of Nashorn APIs.
>
> I use JSObject and ScriptObjectMirror from jdk.nashorn.api.scripting.
>
> I will be willing to change those usages to the GraalJS equivalents if
> it's going to be a long term solution (which I thought Nashorn was).
>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>

From mark.reinhold at oracle.com  Thu Jun  7 16:30:34 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  7 Jun 2018 09:30:34 -0700 (PDT)
Subject: JEP proposed to target JDK 11: 331: Low-Overhead Heap Profiling
Message-ID: <20180607163034.CA69C1DC583@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  331: Low-Overhead Heap Profiling
       http://openjdk.java.net/jeps/331

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Thursday,
14 June, 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.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From jbluettduncan at gmail.com  Thu Jun  7 17:05:10 2018
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Thu, 7 Jun 2018 18:05:10 +0100
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
Message-ID: <CAPMys87j=uZJyRKeaiohAd0uKKq5TtagJ7K3axoxGByPWVFYaw@mail.gmail.com>

Hi Alan and James,

JUnit 5 allows users to disable tests using @DisableIf
<https://junit.org/junit5/docs/5.2.0/user-guide/#writing-tests-conditional-execution-scripts>,
which AFAICT depends on the javax.script API and chooses Nashorn as the
default scripting engine. However, @DisableIf is currently an experimental
feature, and I don't think JUnit 5 depends on Nashorn's internals, so it's
not clear to me how important it is to the JUnit 5 developers that Nashorn
or some other JavaScript engine exists in Java 11+...

Just my 2 cents. :)

Cheers,
Jonathan

On 7 June 2018 at 11:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
> There are several replies from people that are using Nashorn but one thing
> that is not clear from any of the mails so far is whether these usages are
> via the javax.script API or by code making direct usage of Nashorn APIs. I
> assume it is mostly the former, in which case the applications or libraries
> concerned might not care (EMCAScript version support/compliance details
> aside) if the JavaScript implementation is deployed on the class path or
> module path. If this assumption is correct, and if the
> jdk.scripting.nashorn module is removed as envisaged by the draft JEP, then
> the disruption should be mostly around moving the reliance on the version
> bundled with the JDK to needing it be deployed on the class or module path.
>
> Jim - one small bit of feedback on the draft is that most developers
> aren't going to see the deprecation warnings (I assume very few modules
> will `requires jdk.scripting.nashorn` or `requires jdk.dynalink`). They
> will see warnings if they use the `jjs` tool but I assume many usages will
> be via the scripting API so there won't be any warning. You might have
> looked at this already but having some way to run an application so that it
> emits a warning if Nashorn is used could be useful, esp. in large
> environments where it might not be immediately obvious if one of the
> libraries is using it. One recent example of this type of thing was the
> misfeature know as extension mechanism. In JDK 8 there was a VM option to
> detect usages of the then-deprecated feature before it was finally removed
> in JDK 9.
>
> -Alan
>

From mark.reinhold at oracle.com  Thu Jun  7 22:35:15 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  7 Jun 2018 15:35:15 -0700 (PDT)
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools and
 API
Message-ID: <20180607223515.C8A861DC639@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  336: Deprecate the Pack200 Tools and API
       http://openjdk.java.net/jeps/336

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Thursday,
14 June, 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.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From claudiovaliense at gmail.com  Fri Jun  8 12:50:36 2018
From: claudiovaliense at gmail.com (=?UTF-8?Q?Cl=C3=A1udio_Valiense?=)
Date: Fri, 8 Jun 2018 09:50:36 -0300
Subject: New member wants to contribute OPENJDK
Message-ID: <CAHnVHxZ3q24zZA_rq_sOV6sXiPXzLtZPEpgn2oKhnwyU_NoFqA@mail.gmail.com>

Good Morning,

my name is Cl?udio Mois?s Valiense de Andrade, I am a student of the
masters in applied computing in Brazil, I am currently involved in research
that works with spatial data. Creating new queries and performing several
experiments with them. Initially how can I contribute to the OPENJDK
community? I have been working with Java for some years.

-- 
*Atenciosamente,*

*Cl?udio Mois?s Valiense de Andrade*
*Mestrando em Computa??o Aplicada - Universidade Estadual de Feira de
Santana*
*Bacharel em Ci?ncia da Computa??o - Universidade Estadual de Santa Cruz*
www.claudiovaliense.com

*A imagina??o ? mais importante que o conhecimento.*
*Albert Einsten*

From pavel.rappo at oracle.com  Fri Jun  8 13:14:54 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 8 Jun 2018 14:14:54 +0100
Subject: New member wants to contribute OPENJDK
In-Reply-To: <CAHnVHxZ3q24zZA_rq_sOV6sXiPXzLtZPEpgn2oKhnwyU_NoFqA@mail.gmail.com>
References: <CAHnVHxZ3q24zZA_rq_sOV6sXiPXzLtZPEpgn2oKhnwyU_NoFqA@mail.gmail.com>
Message-ID: <B950A4D4-228D-4214-96D3-F1EB8CBD82F4@oracle.com>

You could start from here:

    http://openjdk.java.net/contribute/

-Pavel


From szegedia at gmail.com  Fri Jun  8 19:42:23 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 8 Jun 2018 21:42:23 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
Message-ID: <EFF62561-28BA-433A-9A2F-6DEA19EFBEFF@gmail.com>

I?m going to chime in with some thoughts, with the understanding that I?m obviously fairly biased having spent quite a few years working on all the mentioned technologies. With that:

On Nashorn:
---

Nashorn is still a complete implementation of ECMAScript 5.1 standard. The fact that ECMAScript has gone through further development since 5.1 doesn?t invalidate Nashorn as a runtime for programs written for ECMAScript 5.1, which are still a very large chunk of world?s JavaScript codebase. What is the maintenance burden for just keeping it as it is in the JDK and what are the perceived benefits of the removal?

But in any case, wouldn't it make sense to keep Nashorn until at least GraalJS can ship with JRE as its replacement, and thus not get into a situation where requesting a scripting engine for JS yields nothing in an out-of-the box JRE, which would be a situation unprecedented since Java 1.6. 

The JEP also states that "GraalJS provides most of the same functionality as Nashorn along with better performance? but at the same time "With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.? Is it presumed GraalJS developers will make a better job of maintaining it and tracking ECMAScript changes?

On Dynalink:
?

I?m frankly surprised at the suggestion to also deprecate Dynalink. Even in the case where removal of Nashorn would be justified, Dynalink is not a Nashorn-specific technology; it?s a higher-level language interoperability framework itself building on top of method handles. It has wider applicability than Nashorn. It just debuted as public API in Java 9, and hardly had enough time to prove itself on whether it?ll achieve adoption by language developers (as they need to opt in for a Java 9+ compatibility for it case.)

Speaking of adoption: Dynalink is already being adopted by Scala for its dynamic typing features. This would pull the rug from under that effort.
(If Java were ever to extend to support a similar feature ? never say never ? Dynalink would be in a great position to provide the underpinnings of such a feature, just as method handles did for lambda factories.)

I will allow that Dynalink could be obsolete in a world where all language interop happens under coordination of GraalVM, but that would obsolete method handles too. If the underlying intent is that GraalVM is supposed to become a mandatory part of Java and take over all such responsibilities, that?s a different issue, but there should be an open discussion about that instead.

Dynalink is also feature complete as it is; its maintenance burden should be zero. I have, upon being recently asked by former colleagues within Oracle, explicitly expressed willingness to work on any further enhancement requests for it in OpenJDK, so I?m here to answer any maintenance needs for it.

On releasing these technologies from OpenJDK
?

Finally, there could be arguments for liberating Nashorn from the core OpenJDK. If it were split off, it could be developed and released independently. Nashorn is not tied into any other JDK code, so it?s very easy to separate. Of course, any such code being moved out of OpenJDK with GPL license would have somewhat limited adoption, as the reality of the industry is that people are wary of GPL and prefer more liberal licenses (Apache, BSD, and such).

Dynalink on the other hand, being designed as an interop focal point would be significantly less useful if it were not in the JDK. It provides services to other language systems. That was the whole point of the work I undertook to shepherd it from a standalone project to a JDK component.

Attila.

> On 2018. Jun 6., at 20:16, mark.reinhold at oracle.com wrote:
> 
> http://openjdk.java.net/jeps/335
> 
> - Mark


From stuart.marks at oracle.com  Fri Jun  8 22:30:49 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 8 Jun 2018 15:30:49 -0700
Subject: FYI: removal of long-deprecated Thread.destroy() and
 Thread.stop(Throwable) methods
Message-ID: <f5202b78-01a9-1863-a524-a327996d37d4@oracle.com>

Hi all,

I wanted to mention that I'm nearly ready to push the changeset for JDK-8204243 
[1] which removes the long-deprecated methods Thread.destroy() and 
Thread.stop(Throwable). The review thread is on core-libs-dev. [2] The methods 
have been deprecated for many years, and in Java 9 they were both deprecated for 
removal.

The Thread.destroy() method never actually destroyed a thread in any release; 
instead, it would throw NoSuchMethodError to the caller.

The Thread.stop(Throwable) method had been implemented in the past, but in JDK 8 
the implementation was changed not to stop the target thread, but instead to 
throw UnsuppportedOperationException to the caller.

Note that the no-arg Thread.stop() method still works and won't be removed by 
this changeset. It remains deprecated (though not for removal) and there are no 
plans to remove it at this time.

I'll probably push early next week.

s'marks

[1] https://bugs.openjdk.java.net/browse/JDK-8204243

[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053536.html


From martinrb at google.com  Sat Jun  9 00:24:09 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 8 Jun 2018 17:24:09 -0700
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <da05630a-ae31-94ab-eebc-c14241fa2b63@oracle.com>
Message-ID: <CA+kOe08UEbM2QmF9YjRkCz3hRZB1fAtr2M9hohCeWmYoXmOK7Q@mail.gmail.com>

Some developers at Google are concerned about nashorn possibly going away.
A naive search of Google's (very large) monorepo gives 1767 occurrences of
"import jdk.nashorn".
 I guess that number is ... "not huge" (?)

From henry.jen at oracle.com  Sat Jun  9 01:56:36 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 8 Jun 2018 18:56:36 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
Message-ID: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>

Hi,

Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.

The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.

For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/

From john.r.rose at oracle.com  Sat Jun  9 03:20:12 2018
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 8 Jun 2018 20:20:12 -0700
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <EFF62561-28BA-433A-9A2F-6DEA19EFBEFF@gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <EFF62561-28BA-433A-9A2F-6DEA19EFBEFF@gmail.com>
Message-ID: <F6311CD6-1DEC-48F1-A550-A24047551576@oracle.com>

On Jun 8, 2018, at 12:42 PM, Attila Szegedi <szegedia at gmail.com> wrote:
> 
> Dynalink on the other hand, being designed as an interop focal point would be significantly less useful if it were not in the JDK. It provides services to other language systems. That was the whole point of the work I undertook to shepherd it from a standalone project to a JDK component.

This is a good point.  Dynalink is closer to the core, and correspondingly
less likely to need maintenance due to changes in non-core standards like JS.

? John

From jini at zeus.net.au  Sat Jun  9 09:05:16 2018
From: jini at zeus.net.au (Peter)
Date: Sat, 09 Jun 2018 19:05:16 +1000
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>
References: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>
Message-ID: <5B1B984C.3000808@zeus.net.au>

On 7/06/2018 6:54 AM, mark.reinhold at oracle.com wrote:
> http://openjdk.java.net/jeps/336
>
> - Mark

Hmm, a bit dissapointing, I would have liked to see its support 
continued.  Small and compact jar files are still important for 
distributed systems, although now we tend to maintain local mirror 
repositories, it's a change we'll have to live with I guess.

How long before it will be removed completely?

We ran tests on Java 9 pre releases, but haven't migrated from Java 8 yet.

Peter.





From henry.jen at oracle.com  Sat Jun  9 16:16:31 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Sat, 9 Jun 2018 09:16:31 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
Message-ID: <84F9D20B-201E-4E16-B5F1-7A885343E29D@oracle.com>

I revised the webrev to have warning only executable name for unpack200 instead of full path on Windows, which I believe is what was intended all along, the test is also revised to take unpack200.exe on the Windows platform.

The updated version is at http://cr.openjdk.java.net/~henryjen/jdk11/8199871/1/webrev/

Cheers,
Henry


> On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Hi,
> 
> Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.
> 
> The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.
> 
> For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.
> 
> Cheers,
> Henry
> 
> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/


From jini at zeus.net.au  Sat Jun  9 23:41:57 2018
From: jini at zeus.net.au (Peter)
Date: Sun, 10 Jun 2018 09:41:57 +1000
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <5B1B984C.3000808@zeus.net.au>
References: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>
 <5B1B984C.3000808@zeus.net.au>
Message-ID: <5B1C65C5.3080205@zeus.net.au>

Could this tool be supported by the community, separate from the Java 
release cycle?

We'd certainly adopt it over at Apache if you'd consider relicensing it?

Only since IPv6 adoption has in increased, has it been practical to use 
distributed peer to peer computing over the internet.   This isn't just 
for clients like java webstart.

Some recent developments in our software (an evolution / refactoring of 
Jini):

    * IPv6 Multicast discovery (including global multicast announcement,
      but not request, to avoid DOS).
    * Https discovery
    * A safe lookup service, allows authentication and delayed
      unmarshalling of service proxy's.
    * A security focused reimplementation of Java Serialization.
    * RFC3986 URI support.
    * An Invocation Layer Factory (AtomicILFactory) that utilises secure
      deserialization, and supports OSGi and other modular environments,
      class resolution is determined by ClassLoader's, codebase
      annotations are no longer used for determining class visibility,
      only to located and download code.   AtomicILFactory is used by
      Jini Extensible Remote Invocation - based on JSR 76 and JSR78


Regards,

Peter.

On 9/06/2018 7:05 PM, Peter wrote:
> On 7/06/2018 6:54 AM, mark.reinhold at oracle.com wrote:
>> http://openjdk.java.net/jeps/336
>>
>> - Mark
>
> Hmm, a bit dissapointing, I would have liked to see its support 
> continued.  Small and compact jar files are still important for 
> distributed systems, although now we tend to maintain local mirror 
> repositories, it's a change we'll have to live with I guess.
>
> How long before it will be removed completely?
>
> We ran tests on Java 9 pre releases, but haven't migrated from Java 8 
> yet.
>
> Peter.
>
>
>
>


From jini at zeus.net.au  Mon Jun 11 02:48:40 2018
From: jini at zeus.net.au (Peter)
Date: Mon, 11 Jun 2018 12:48:40 +1000
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <5B1C65C5.3080205@zeus.net.au>
References: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>
 <5B1B984C.3000808@zeus.net.au> <5B1C65C5.3080205@zeus.net.au>
Message-ID: <5B1DE308.2020907@zeus.net.au>

It's also worth mentioning that pack200 is the preferred format for 
Eclipse P2 repositories.

This isn't about webstart and applets, it's going to have an impact, 
developers may be hesitant to adopt new language features that aren't 
supported by the pack200 format.

The timing isn't great, given we don't have compatibility between the 
various module systems at this time.  I mean you can't use jrt as an 
OSGi bundle yet, can you?

When we can use jrt for other module systems, then this makes a lot more 
sense.

Thank you for listening.

Peter.

On 10/06/2018 9:41 AM, Peter wrote:
> Could this tool be supported by the community, separate from the Java 
> release cycle?
>
> We'd certainly adopt it over at Apache if you'd consider relicensing it?
>
> Only since IPv6 adoption has in increased, has it been practical to 
> use distributed peer to peer computing over the internet.   This isn't 
> just for clients like java webstart.
>
> Some recent developments in our software (an evolution / refactoring 
> of Jini):
>
>    * IPv6 Multicast discovery (including global multicast announcement,
>      but not request, to avoid DOS).
>    * Https discovery
>    * A safe lookup service, allows authentication and delayed
>      unmarshalling of service proxy's.
>    * A security focused reimplementation of Java Serialization.
>    * RFC3986 URI support.
>    * An Invocation Layer Factory (AtomicILFactory) that utilises secure
>      deserialization, and supports OSGi and other modular environments,
>      class resolution is determined by ClassLoader's, codebase
>      annotations are no longer used for determining class visibility,
>      only to located and download code.   AtomicILFactory is used by
>      Jini Extensible Remote Invocation - based on JSR 76 and JSR78
>
>
> Regards,
>
> Peter.
>
> On 9/06/2018 7:05 PM, Peter wrote:
>> On 7/06/2018 6:54 AM, mark.reinhold at oracle.com wrote:
>>> http://openjdk.java.net/jeps/336
>>>
>>> - Mark
>>
>> Hmm, a bit dissapointing, I would have liked to see its support 
>> continued.  Small and compact jar files are still important for 
>> distributed systems, although now we tend to maintain local mirror 
>> repositories, it's a change we'll have to live with I guess.
>>
>> How long before it will be removed completely?
>>
>> We ran tests on Java 9 pre releases, but haven't migrated from Java 8 
>> yet.
>>
>> Peter.
>>
>>
>>
>>
>


From daniel.fuchs at oracle.com  Mon Jun 11 10:46:23 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 11 Jun 2018 11:46:23 +0100
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <c7883992-69b0-4b52-0606-e953fe604b84@oracle.com>

Vote: yes

best regards,

-- daniel

On 01/06/2018 21:17, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer.

From peter.firmstone at zeus.net.au  Sat Jun  9 08:29:40 2018
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 09 Jun 2018 18:29:40 +1000
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>
References: <20180606205452.5CBB41DC399@eggemoggin.niobe.net>
Message-ID: <5B1B8FF4.4020100@zeus.net.au>

On 7/06/2018 6:54 AM, mark.reinhold at oracle.com wrote:
> http://openjdk.java.net/jeps/336
>
> - Mark

Hmm, a bit dissapointing, I would have liked to see its support 
continued.  Small and compact jar files are still important for 
distributed systems, although now we tend to maintain local mirror 
repositories, still it's a change we'll have to live with I guess.

How long before it will be removed completely?

We ran tests on Java 9 pre releases, but haven't migrated from Java 8 yet.

Peter.





From paul.sandoz at oracle.com  Mon Jun 11 16:07:00 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 11 Jun 2018 09:07:00 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
Message-ID: <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>

Hi Henry,

I am unsure if the warning messages are copying a pattern of previous warning messages for other for removal deprecations but i would like to suggest some stronger language e.g.:

  Warning: The {0} option is deprecated for removal and will be removed in a future JDK release\n

Thoughts?

Paul.

> On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Hi,
> 
> Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.
> 
> The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.
> 
> For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.
> 
> Cheers,
> Henry
> 
> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/


From henry.jen at oracle.com  Mon Jun 11 17:19:16 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 11 Jun 2018 10:19:16 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
Message-ID: <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com>

Sounds good to me. If no objections, I?ll change this for pack200 and unpack200 as well.

Cheers,
Henry

> On Jun 11, 2018, at 9:07 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Henry,
> 
> I am unsure if the warning messages are copying a pattern of previous warning messages for other for removal deprecations but i would like to suggest some stronger language e.g.:
> 
>  Warning: The {0} option is deprecated for removal and will be removed in a future JDK release\n
> 
> Thoughts?
> 
> Paul.
> 
>> On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.
>> 
>> The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.
>> 
>> For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/
> 


From alex.buckley at oracle.com  Mon Jun 11 17:59:43 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 11 Jun 2018 10:59:43 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
 <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com>
Message-ID: <5B1EB88F.50804@oracle.com>

The warning message gives us just enough room to expand on the terse and 
still-new-to-most-people phrase "deprecated for removal". Using the 
phrase "planned to be removed" is desirable, because it gives a tiny bit 
more wriggle room than "will be removed". So, I propose this for warnings:

   The THING is deprecated, and is planned for removal in a future JDK 
release.

And for `jar --help-extra`:  (-n is like an API element, so the d-f-r 
phrase is OK)

   -n, --normalize      (Deprecated for removal) Normalize information
                        in the new jar archive after creation

Also, since JEP 336 is now proposed to target JDK 11, I think it's OK to 
add `since="11"` to the annotation in class Pack200.

Alex

On 6/11/2018 10:19 AM, Henry Jen wrote:
> Sounds good to me. If no objections, I?ll change this for pack200 and unpack200 as well.
>
> Cheers,
> Henry
>
>> On Jun 11, 2018, at 9:07 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>> Hi Henry,
>>
>> I am unsure if the warning messages are copying a pattern of previous warning messages for other for removal deprecations but i would like to suggest some stronger language e.g.:
>>
>>   Warning: The {0} option is deprecated for removal and will be removed in a future JDK release\n
>>
>> Thoughts?
>>
>> Paul.
>>
>>> On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.
>>>
>>> The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.
>>>
>>> For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.
>>>
>>> Cheers,
>>> Henry
>>>
>>> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/
>>
>

From paul.sandoz at oracle.com  Mon Jun 11 21:02:39 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 11 Jun 2018 14:02:39 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <5B1EB88F.50804@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
 <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com> <5B1EB88F.50804@oracle.com>
Message-ID: <DEAF7DD9-4D20-420D-8F9B-01DBEFC39B8D@oracle.com>



> On Jun 11, 2018, at 10:59 AM, Alex Buckley <alex.buckley at Oracle.COM> wrote:
> 
> The warning message gives us just enough room to expand on the terse and still-new-to-most-people phrase "deprecated for removal". Using the phrase "planned to be removed" is desirable, because it gives a tiny bit more wriggle room than "will be removed". So, I propose this for warnings:
> 
>  The THING is deprecated, and is planned for removal in a future JDK release.
> 

+1

Paul.

> And for `jar --help-extra`:  (-n is like an API element, so the d-f-r phrase is OK)
> 
>  -n, --normalize      (Deprecated for removal) Normalize information
>                       in the new jar archive after creation
> 
> Also, since JEP 336 is now proposed to target JDK 11, I think it's OK to add `since="11"` to the annotation in class Pack200.
> 
> Alex
> 
> On 6/11/2018 10:19 AM, Henry Jen wrote:
>> Sounds good to me. If no objections, I?ll change this for pack200 and unpack200 as well.
>> 
>> Cheers,
>> Henry
>> 
>>> On Jun 11, 2018, at 9:07 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> 
>>> Hi Henry,
>>> 
>>> I am unsure if the warning messages are copying a pattern of previous warning messages for other for removal deprecations but i would like to suggest some stronger language e.g.:
>>> 
>>>  Warning: The {0} option is deprecated for removal and will be removed in a future JDK release\n
>>> 
>>> Thoughts?
>>> 
>>> Paul.
>>> 
>>>> On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.
>>>> 
>>>> The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.
>>>> 
>>>> For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.
>>>> 
>>>> Cheers,
>>>> Henry
>>>> 
>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/
>>> 
>> 


From jluzon at riotgames.com  Mon Jun 11 22:03:24 2018
From: jluzon at riotgames.com (Jesus Luzon)
Date: Mon, 11 Jun 2018 15:03:24 -0700
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
Message-ID: <CAJ_jK4=xgtPrKNmoVB68XKmmPLsRE=HaQmjZo3g54NY-A=Gg2w@mail.gmail.com>

We use Nashorn heavily in our Edge at Riot for what we call our
transformation layer, where users wanting to expose their applications can
tranforms request and/or responses by writing JS snippets. Losing Nashorn
without any viable replacement would destroy much of the work we've done in
the past year and a half to make our Ecosystem highly configurable, so an
at the very least actual ETA on deprecation and an expected replacement
path would be ideal.

From joaovarandas at inpaas.com  Mon Jun 11 22:27:37 2018
From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=)
Date: Mon, 11 Jun 2018 19:27:37 -0300
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <CAJ_jK4=xgtPrKNmoVB68XKmmPLsRE=HaQmjZo3g54NY-A=Gg2w@mail.gmail.com>
References: <CAJ_jK4=xgtPrKNmoVB68XKmmPLsRE=HaQmjZo3g54NY-A=Gg2w@mail.gmail.com>
Message-ID: <CACoP5y1s_s53JKh4BP3dKFXy8uui5RA4N_BsB=HEN9u3+JtT1Q@mail.gmail.com>

I share the same concern with our product.

?In the past? 3+ years we have relied upon Nashorn to build
?our
 low code development platform. People can write business logic, APIs,
intercept database logic with Triggers and render front-end content with
code written in ES.

The application is created via a no-code interface, drag'n drop components
and also dynamic database entities (based on meta-data), this is all java
abstract code. But w
hen it comes to business logic for the applications, everything runs inside
Nashorn(including multi-threading)
? context
?via
 a ScriptEngine(per Thread) and some helpers
? injected?
into the javax.script.bindings
? for that execution?
?
there's a "transparent layer"
?here ?
between scripts and java code
? so they can easily interact?
?
?
?.
We have built a "require" function to load modules (also written in
JavaScript) so developers can encapsulate code.

?Basically, the success of our product lies within the integration of
no-code (drag n drop / components part)? and the JavaScript part, where it
doesn't matter if we update our platform, your code simply runs and that's
it. When it comes to a JDK upgrade, where Nashorn will no longer be there,
even if we have a replacement (such as GraalVM), this might bring not only
breaking changes to our product, but also to software written within our
platform, since some code "may not run seamlessly" ...



The ETA on deprecation and also a clear statement for the replacement would
be ideal
?, thus we can prepare ourselves and advise our users to not use code that
may not be supported in the long run...
?
?
Also, if
? there's a replacement (such as GraalVM)
, what are the plans to make it more compatible with Nashorn.

?

?



?

On Mon, Jun 11, 2018 at 7:03 PM, Jesus Luzon <jluzon at riotgames.com> wrote:

> We use Nashorn heavily in our Edge at Riot for what we call our
> transformation layer, where users wanting to expose their applications can
> tranforms request and/or responses by writing JS snippets. Losing Nashorn
> without any viable replacement would destroy much of the work we've done in
> the past year and a half to make our Ecosystem highly configurable, so an
> at the very least actual ETA on deprecation and an expected replacement
> path would be ideal.
>

-- 
"Esta mensagem, incluindo seus anexos, pode conter informacoes 
confidenciais e privilegiadas.?
Se voce a recebeu por engano, solicitamos 
que a apague e avise o remetente imediatamente.?
Opinioes ou informacoes 
aqui contidas nao refletem necessariamente a posicao oficial da Plusoft."



"Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO 
AMBIENTE"



From pmartins at redhat.com  Tue Jun 12 07:18:20 2018
From: pmartins at redhat.com (Paulo Lopes)
Date: Tue, 12 Jun 2018 09:18:20 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <CACoP5y1s_s53JKh4BP3dKFXy8uui5RA4N_BsB=HEN9u3+JtT1Q@mail.gmail.com>
Message-ID: <cb809fa52e1ee65c0ac32a8347a220c35ec07f11.camel@redhat.com>

Hi all,

I'll try to join the thread now. I'm the "core" developer of JS support
of Eclipse Vert.x and Nashorn is the key component to get this support.
Recently I've been working on getting both Nashorn and Graal working on
the same code base and I've observed that Graal isn't quite there yet.

Just to name a couple of things Graal support for multithreaded code is
not available in scripting mode, and is in Nashorn; dynalink allows
definining custom type casts that are used by Nashorn when crossing
language boundaries (this is quite nice as it reduces the boilerplate
code at the scripting side, thus not having it, kind of defeats the
point of scripting for the convenience using a script as lots of
boilerplate needs to be added).

So in a nutshell, removing Nashorn without having a proper stable
alternative (be it project Detroit V8) or a fully functional GraalVM.js
should not be done without having some leeway time to projects to adapt
to the alternatives.

Just my 2cts,

Paulo

From jesper.wilhelmsson at oracle.com  Tue Jun 12 08:59:37 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 12 Jun 2018 10:59:37 +0200
Subject: RFR: JDK-8203927 - Update version string to identify which VM is
 being used
Message-ID: <F534E3C2-B01C-400F-8DB3-382F249A05A9@oracle.com>

Hi,

Please review this change to make the version string to identify which JVM is being used in the presence of a hardened JVM. This change relates to JDK-8202384 which is currently out for review as well.

Testing: Local verification and tier 1.

Bug: https://bugs.openjdk.java.net/browse/JDK-8203927
Webrev: http://cr.openjdk.java.net/~jwilhelm/8203927/webrev.00/

Thanks,
/Jesper


From david.holmes at oracle.com  Tue Jun 12 09:24:36 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jun 2018 19:24:36 +1000
Subject: RFR: JDK-8203927 - Update version string to identify which VM is
 being used
In-Reply-To: <F534E3C2-B01C-400F-8DB3-382F249A05A9@oracle.com>
References: <F534E3C2-B01C-400F-8DB3-382F249A05A9@oracle.com>
Message-ID: <1254ccb6-4b6b-a6e1-7e03-721707f88d38@oracle.com>

Hi Jesper,

Looks fine.

(I wish there was a better way to combine string literals to avoid the 
repetition - but I don't know of one.)

Thanks,
David

On 12/06/2018 6:59 PM, jesper.wilhelmsson at oracle.com wrote:
> Hi,
> 
> Please review this change to make the version string to identify which JVM is being used in the presence of a hardened JVM. This change relates to JDK-8202384 which is currently out for review as well.
> 
> Testing: Local verification and tier 1.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203927
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8203927/webrev.00/
> 
> Thanks,
> /Jesper
> 

From mark.reinhold at oracle.com  Tue Jun 12 14:55:32 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 12 Jun 2018 07:55:32 -0700 (PDT)
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
Message-ID: <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>

I?d like to clarify two points about this JEP [1].

First, this is not a proposal to remove Nashorn in any particular JDK
release -- it?s just a proposal to deprecate Nashorn, most likely in JDK
11, to enable its potential removal in some later release, yet to be
determined.  No one needs to worry that applications that use Nashorn
won?t run on JDK 11.

Second, the principal purpose of this JEP was to prompt a wide discussion
about the future of Nashorn -- as indeed it has.  (Could this have been
done more gracefully?  Sure.  We?ll remember that for next time.)

Most of the developers who originally built Nashorn are now working on
even newer features, so naturally they?re trying to reduce the amount of
time that they spend maintaining Nashorn.

The question behind JEP 335 is, simply, this: Does anyone wish to take
on the maintenance of Nashorn after JDK 11?  (We asked much the same
question about the CMS garbage collector, almost a year ago [2]).

If a set of credible developers expresses a clear desire to maintain
Nashorn after JDK 11 then all of us who work on this code base will find
a way to make that happen.  Maybe Nashorn stays in the JDK, or maybe it?s
removed from the JDK and maintained in some other OpenJDK Project and
published to Maven Central, or maybe some completely different approach
is taken.  Exactly what happens depends, mostly, on who shows up.

So ... any takers?

- Mark


[1] http://openjdk.java.net/jeps/335
[2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-July/018545.html

From daniel_megert at ch.ibm.com  Tue Jun 12 20:50:37 2018
From: daniel_megert at ch.ibm.com (Daniel Megert)
Date: Tue, 12 Jun 2018 22:50:37 +0200
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
Message-ID: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>

pack200 is used by the Eclipse update manager a.k.a. p2. The JARed 
plug-ins are compressed with pack200 and put into a p2 repository. 
Removing pack200 will make the download (and hence install) of plug-ins 
much slower. Eclipse would therefore like to keep this technology. If 
that's not an option, then we would like that the removal does not happen 
before Java 13.

Dani
Eclipse PMC


From huizhe.wang at oracle.com  Tue Jun 12 21:17:45 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 12 Jun 2018 14:17:45 -0700
Subject: CFV: New JDK Reviewer: Rajan Halade
In-Reply-To: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
References: <60c61d85-0b49-7fa8-7a67-682151a4ff49@oracle.com>
Message-ID: <5B203879.8020605@oracle.com>

Vote: yes

Best,
Joe

On 6/1/18, 1:17 PM, Sean Mullan wrote:
> I hereby nominate Rajan Halade to JDK Reviewer. 

From henry.jen at oracle.com  Tue Jun 12 23:52:02 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 12 Jun 2018 16:52:02 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <DEAF7DD9-4D20-420D-8F9B-01DBEFC39B8D@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
 <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com> <5B1EB88F.50804@oracle.com>
 <DEAF7DD9-4D20-420D-8F9B-01DBEFC39B8D@oracle.com>
Message-ID: <257FFD8E-19C8-4CCC-8955-561FA6FD9401@oracle.com>

OK, I have updated the webrev[1] based on the feedback. All the messages are changes, and added since=?11? for Deprecated.

[1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/2/webrev/

Cheers,
Henry


> On Jun 11, 2018, at 2:02 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
> 
>> On Jun 11, 2018, at 10:59 AM, Alex Buckley <alex.buckley at Oracle.COM> wrote:
>> 
>> The warning message gives us just enough room to expand on the terse and still-new-to-most-people phrase "deprecated for removal". Using the phrase "planned to be removed" is desirable, because it gives a tiny bit more wriggle room than "will be removed". So, I propose this for warnings:
>> 
>> The THING is deprecated, and is planned for removal in a future JDK release.
>> 
> 
> +1
> 
> Paul.
> 
>> And for `jar --help-extra`:  (-n is like an API element, so the d-f-r phrase is OK)
>> 
>> -n, --normalize      (Deprecated for removal) Normalize information
>>                      in the new jar archive after creation
>> 
>> Also, since JEP 336 is now proposed to target JDK 11, I think it's OK to add `since="11"` to the annotation in class Pack200.
>> 
>> Alex
>> 
>> On 6/11/2018 10:19 AM, Henry Jen wrote:
>>> Sounds good to me. If no objections, I?ll change this for pack200 and unpack200 as well.
>>> 
>>> Cheers,
>>> Henry
>>> 
>>>> On Jun 11, 2018, at 9:07 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>> 
>>>> Hi Henry,
>>>> 
>>>> I am unsure if the warning messages are copying a pattern of previous warning messages for other for removal deprecations but i would like to suggest some stronger language e.g.:
>>>> 
>>>> Warning: The {0} option is deprecated for removal and will be removed in a future JDK release\n
>>>> 
>>>> Thoughts?
>>>> 
>>>> Paul.
>>>> 
>>>>> On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message.
>>>>> 
>>>>> The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that.
>>>>> 
>>>>> For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue.
>>>>> 
>>>>> Cheers,
>>>>> Henry
>>>>> 
>>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/
>>>> 
>>> 
> 


From peter.firmstone at zeus.net.au  Wed Jun 13 10:17:59 2018
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 13 Jun 2018 20:17:59 +1000
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
References: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
Message-ID: <5B20EF57.4070704@zeus.net.au>

Hi Daniel,

I had a look at the pack200 code in openjdk, it's written in c++, and 
looks a little painful to maintain.  I also had a look at Apache 
Harmony's implementation, written in Java, it uses the ASM byte code 
library and it's also already an OSGi Bundle.  It's still only at 
bytecode version 1.6, but it's going to be a lot easier to maintain in 
the long term.

https://github.com/pfirmstone/pack200

Cheers,

Peter.

On 13/06/2018 6:50 AM, Daniel Megert wrote:
> pack200 is used by the Eclipse update manager a.k.a. p2. The JARed
> plug-ins are compressed with pack200 and put into a p2 repository.
> Removing pack200 will make the download (and hence install) of plug-ins
> much slower. Eclipse would therefore like to keep this technology. If
> that's not an option, then we would like that the removal does not happen
> before Java 13.
>
> Dani
> Eclipse PMC
>


From mandy.chung at oracle.com  Wed Jun 13 16:32:16 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 13 Jun 2018 09:32:16 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <257FFD8E-19C8-4CCC-8955-561FA6FD9401@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
 <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com> <5B1EB88F.50804@oracle.com>
 <DEAF7DD9-4D20-420D-8F9B-01DBEFC39B8D@oracle.com>
 <257FFD8E-19C8-4CCC-8955-561FA6FD9401@oracle.com>
Message-ID: <5abcb652-ba3f-dc52-a78c-a7c818e277ae@oracle.com>



On 6/12/18 4:52 PM, Henry Jen wrote:
> OK, I have updated the webrev[1] based on the feedback. All the messages are changes, and added since=?11? for Deprecated.
> 
> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/2/webrev/

src/java.base/share/classes/java/util/jar/Pack200.java
   104  * @deprecated This class has been deprecated

@deprecated is missing in Pack200.Packer and Pack200.Unpacker. You can 
use the consistent message in @deprecated as well.

Otherwise, the change looks fine to me.

Mandy

From volker.simonis at gmail.com  Wed Jun 13 16:40:40 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 Jun 2018 18:40:40 +0200
Subject: CFV: New JDK Committer: Gustavo Romero
Message-ID: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>

I hereby nominate Gustavo Romero (gromero) to JDK Committer.

Gustavo works for the Linux on Power team at IBM and has contributed
16 changes within the last two years, mostly related to supporting
hardware transactional memory and NUMA support on ppc64. A full list
of his contributions can be found at [3].

Votes are due by 19:00 CET June 27, 2018.

Only current JDK Committers [1] 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 [2].

Thank you and best regards,
Volker

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote
[3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()

8164987: RTM jtreg tests failing due to unnamed module unable to
access class jdk.internal.misc.Unsafe
8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
non-optimized compilation
8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
non-optimized compilation
8171236: RTM/HTM jtreg tests regression after transition to the new
GNU-style options
8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
bootstrap.url
8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
8201218: PPC64: Avoid use of yield instruction on spinlock
8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
detection for enabling RTM on Linux / POWER9"
8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
8204134: jtreg: Fix RTM abort provoker for various tests after
"8149159: Clean up Unsafe"
8150353: PPC64LE: Support RTM on linux
8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
illegal instructions
8154156: PPC64: improve array copy stubs by using vector instructions
8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section

From adinn at redhat.com  Wed Jun 13 16:47:45 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 13 Jun 2018 17:47:45 +0100
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <73ec6365-45c7-36a0-033f-72654b10795e@redhat.com>

Vote: yes

On 13/06/18 17:40, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section
> 

-- 
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 neugens.limasoftware at gmail.com  Wed Jun 13 16:48:27 2018
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 13 Jun 2018 18:48:27 +0200
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <CAGUMyaTT7LZ8F_K0pa+aq=WYRbkV0k_G5J3Uz5J1shsPfr7ZaA@mail.gmail.com>

Vote: yes,

Cheers,
Mario
On Wed 13. Jun 2018 at 18:40, Volker Simonis <volker.simonis at gmail.com>
wrote:

> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
>
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
>
> Votes are due by 19:00 CET June 27, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Volker
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
>
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical
> section
>

From thomas.stuefe at gmail.com  Wed Jun 13 16:51:01 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jun 2018 18:51:01 +0200
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <CAA-vtUyV6LSvqna6ee2cF8CRwpwExybXvduZik3h7x80mKoyQg@mail.gmail.com>

Vote: Yes

On Wed, Jun 13, 2018, 18:41 Volker Simonis <volker.simonis at gmail.com> wrote:

> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
>
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
>
> Votes are due by 19:00 CET June 27, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Volker
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
>
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical
> section
>

From vladimir.kozlov at oracle.com  Wed Jun 13 17:01:20 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Jun 2018 10:01:20 -0700
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <88cc58d0-0e1f-c140-00ec-2fa56312a8fe@oracle.com>

Vote: yes

On 6/13/18 9:40 AM, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section
> 

From zgu at redhat.com  Wed Jun 13 17:05:21 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 13 Jun 2018 13:05:21 -0400
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <2547fc5f-2472-6e68-5bcf-95be9ddd38f3@redhat.com>

Vote: yes

-Zhengyu

On 06/13/2018 12:40 PM, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section
> 

From vladimir.x.ivanov at oracle.com  Wed Jun 13 17:29:49 2018
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 13 Jun 2018 20:29:49 +0300
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <bada688e-ab08-ca5b-22be-1c0e2af4d1cf@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 13/06/2018 19:40, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section
> 

From jamsheed.c.m at oracle.com  Wed Jun 13 17:43:08 2018
From: jamsheed.c.m at oracle.com (jamsheed)
Date: Wed, 13 Jun 2018 23:13:08 +0530
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <c9dda672-b00a-b676-da59-4833029181dd@oracle.com>

Vote: Yes

Best regards,

Jamsheed



From igor.ignatyev at oracle.com  Wed Jun 13 17:43:35 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 13 Jun 2018 10:43:35 -0700
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <F9542AD2-0FED-4E1B-AA4C-A74B292CB556@oracle.com>

Vote: yes

-- Igor

> On Jun 13, 2018, at 9:40 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.


From jesper.wilhelmsson at oracle.com  Wed Jun 13 18:33:28 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 13 Jun 2018 20:33:28 +0200
Subject: RFR: JDK-8203927 - Update version string to identify which VM is
 being used
In-Reply-To: <1254ccb6-4b6b-a6e1-7e03-721707f88d38@oracle.com>
References: <F534E3C2-B01C-400F-8DB3-382F249A05A9@oracle.com>
 <1254ccb6-4b6b-a6e1-7e03-721707f88d38@oracle.com>
Message-ID: <F1D887A2-41B1-4E88-B16F-8F12F380E0E8@oracle.com>

Thank you for the review David!
/Jesper

> On 12 Jun 2018, at 11:24, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Jesper,
> 
> Looks fine.
> 
> (I wish there was a better way to combine string literals to avoid the repetition - but I don't know of one.)
> 
> Thanks,
> David
> 
> On 12/06/2018 6:59 PM, jesper.wilhelmsson at oracle.com wrote:
>> Hi,
>> Please review this change to make the version string to identify which JVM is being used in the presence of a hardened JVM. This change relates to JDK-8202384 which is currently out for review as well.
>> Testing: Local verification and tier 1.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203927
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8203927/webrev.00/
>> Thanks,
>> /Jesper


From thomas.stuefe at gmail.com  Wed Jun 13 18:44:51 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jun 2018 20:44:51 +0200
Subject: RFR: JDK-8203927 - Update version string to identify which VM is
 being used
In-Reply-To: <F1D887A2-41B1-4E88-B16F-8F12F380E0E8@oracle.com>
References: <F534E3C2-B01C-400F-8DB3-382F249A05A9@oracle.com>
 <1254ccb6-4b6b-a6e1-7e03-721707f88d38@oracle.com>
 <F1D887A2-41B1-4E88-B16F-8F12F380E0E8@oracle.com>
Message-ID: <CAA-vtUzfF=XJKoXeBMgfM7jr=Tv=ddSc2-MxSj1iguLOynBHVQ@mail.gmail.com>

Looks fine to me too.

I was surprised to see though that the vm info string is actually
dependent on runtime settings.

Thanks, Thomas

On Wed, Jun 13, 2018 at 8:33 PM,  <jesper.wilhelmsson at oracle.com> wrote:
> Thank you for the review David!
> /Jesper
>
>> On 12 Jun 2018, at 11:24, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Jesper,
>>
>> Looks fine.
>>
>> (I wish there was a better way to combine string literals to avoid the repetition - but I don't know of one.)
>>
>> Thanks,
>> David
>>
>> On 12/06/2018 6:59 PM, jesper.wilhelmsson at oracle.com wrote:
>>> Hi,
>>> Please review this change to make the version string to identify which JVM is being used in the presence of a hardened JVM. This change relates to JDK-8202384 which is currently out for review as well.
>>> Testing: Local verification and tier 1.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203927
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8203927/webrev.00/
>>> Thanks,
>>> /Jesper
>

From jesper.wilhelmsson at oracle.com  Wed Jun 13 18:49:46 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 13 Jun 2018 20:49:46 +0200
Subject: RFR: JDK-8203927 - Update version string to identify which VM is
 being used
In-Reply-To: <CAA-vtUzfF=XJKoXeBMgfM7jr=Tv=ddSc2-MxSj1iguLOynBHVQ@mail.gmail.com>
References: <F534E3C2-B01C-400F-8DB3-382F249A05A9@oracle.com>
 <1254ccb6-4b6b-a6e1-7e03-721707f88d38@oracle.com>
 <F1D887A2-41B1-4E88-B16F-8F12F380E0E8@oracle.com>
 <CAA-vtUzfF=XJKoXeBMgfM7jr=Tv=ddSc2-MxSj1iguLOynBHVQ@mail.gmail.com>
Message-ID: <C5272231-0B58-4292-A1B3-5BEC5157E09E@oracle.com>

Thank you Thomas!

Yes, the runtime dependent part is very useful when debugging installations where you have limited knowledge about the configuration.

Thanks,
/Jesper

> On 13 Jun 2018, at 20:44, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Looks fine to me too.
> 
> I was surprised to see though that the vm info string is actually
> dependent on runtime settings.
> 
> Thanks, Thomas
> 
> On Wed, Jun 13, 2018 at 8:33 PM,  <jesper.wilhelmsson at oracle.com> wrote:
>> Thank you for the review David!
>> /Jesper
>> 
>>> On 12 Jun 2018, at 11:24, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Jesper,
>>> 
>>> Looks fine.
>>> 
>>> (I wish there was a better way to combine string literals to avoid the repetition - but I don't know of one.)
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 12/06/2018 6:59 PM, jesper.wilhelmsson at oracle.com wrote:
>>>> Hi,
>>>> Please review this change to make the version string to identify which JVM is being used in the presence of a hardened JVM. This change relates to JDK-8202384 which is currently out for review as well.
>>>> Testing: Local verification and tier 1.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203927
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8203927/webrev.00/
>>>> Thanks,
>>>> /Jesper
>> 


From serguei.spitsyn at oracle.com  Wed Jun 13 23:04:13 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 13 Jun 2018 16:04:13 -0700
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <c91724b3-86f3-4531-c0cc-09f9703d9dc3@oracle.com>

Vote: yes

From david.holmes at oracle.com  Thu Jun 14 04:42:53 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Jun 2018 14:42:53 +1000
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <b712f5d0-cf31-4574-8d3e-a8cb854563ea@oracle.com>

Vote: yes

David

On 14/06/2018 2:40 AM, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.

From tobias.hartmann at oracle.com  Thu Jun 14 07:10:25 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 14 Jun 2018 09:10:25 +0200
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <b255227f-9252-2c5d-7fff-8a67b34f4507@oracle.com>

Vote: yes

Tobias

On 13.06.2018 18:40, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section
> 

From erik.osterlund at oracle.com  Thu Jun 14 07:15:01 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 14 Jun 2018 09:15:01 +0200
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <588BC454-4D0A-421A-9808-24C26597C54F@oracle.com>

Vote: yes

/Erik

> On 13 Jun 2018, at 18:40, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section


From martin.doerr at sap.com  Thu Jun 14 08:05:03 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 14 Jun 2018 08:05:03 +0000
Subject: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <fc6787ae721f4405aefe278c19fd55c5@sap.com>

Vote: Yes

Best regards,
Martin


-----Original Message-----
From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis
Sent: Mittwoch, 13. Juni 2018 18:41
To: jdk-dev <jdk-dev at openjdk.java.net>
Subject: CFV: New JDK Committer: Gustavo Romero

I hereby nominate Gustavo Romero (gromero) to JDK Committer.

Gustavo works for the Linux on Power team at IBM and has contributed
16 changes within the last two years, mostly related to supporting
hardware transactional memory and NUMA support on ppc64. A full list
of his contributions can be found at [3].

Votes are due by 19:00 CET June 27, 2018.

Only current JDK Committers [1] 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 [2].

Thank you and best regards,
Volker

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote
[3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()

8164987: RTM jtreg tests failing due to unnamed module unable to
access class jdk.internal.misc.Unsafe
8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
non-optimized compilation
8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
non-optimized compilation
8171236: RTM/HTM jtreg tests regression after transition to the new
GNU-style options
8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
bootstrap.url
8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
8201218: PPC64: Avoid use of yield instruction on spinlock
8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
detection for enabling RTM on Linux / POWER9"
8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
8204134: jtreg: Fix RTM abort provoker for various tests after
"8149159: Clean up Unsafe"
8150353: PPC64LE: Support RTM on linux
8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
illegal instructions
8154156: PPC64: improve array copy stubs by using vector instructions
8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section

From ashipile at redhat.com  Thu Jun 14 08:06:45 2018
From: ashipile at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Jun 2018 10:06:45 +0200
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <db89fe47-abb5-2816-0cb9-571bedf6f0dd@redhat.com>

Vote: yes

On 06/13/2018 06:40 PM, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.

From christoph.langer at sap.com  Thu Jun 14 13:36:24 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Jun 2018 13:36:24 +0000
Subject: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <2457fda30c9a412eaad0b541f4493670@sap.com>

Vote: yes

Best regards
Christoph

> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of
> Volker Simonis
> Sent: Mittwoch, 13. Juni 2018 18:41
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Gustavo Romero
> 
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromer
> o)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical
> section

From karen.kinnear at oracle.com  Thu Jun 14 13:39:56 2018
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 14 Jun 2018 09:39:56 -0400
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <317B5C26-44EE-42C6-8220-F70FAF53DECF@oracle.com>

Vote: yes

Thanks,
Karen

> On Jun 13, 2018, at 12:40 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section


From Derek.White at cavium.com  Thu Jun 14 18:49:11 2018
From: Derek.White at cavium.com (White, Derek)
Date: Thu, 14 Jun 2018 18:49:11 +0000
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <317B5C26-44EE-42C6-8220-F70FAF53DECF@oracle.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
 <317B5C26-44EE-42C6-8220-F70FAF53DECF@oracle.com>
Message-ID: <BL0PR07MB3890AF823435FBFAD54D9AB0847D0@BL0PR07MB3890.namprd07.prod.outlook.com>


Vote: yes

 - Derek
 
> > On Jun 13, 2018, at 12:40 PM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
> >
> > I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> >
> > Gustavo works for the Linux on Power team at IBM and has contributed
> > 16 changes within the last two years, mostly related to supporting
> > hardware transactional memory and NUMA support on ppc64. A full list
> > of his contributions can be found at [3].
> >
> > Votes are due by 19:00 CET June 27, 2018.
> >
> > Only current JDK Committers [1] 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 [2].
> >
> > Thank you and best regards,
> > Volker
> >
> > [1] http://openjdk.java.net/census
> > [2] http://openjdk.java.net/projects/#committer-vote
> > [3]
> > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromer
> > o)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> >
> > 8164987: RTM jtreg tests failing due to unnamed module unable to
> > access class jdk.internal.misc.Unsafe
> > 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> > non-optimized compilation
> > 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> > non-optimized compilation
> > 8171236: RTM/HTM jtreg tests regression after transition to the new
> > GNU-style options
> > 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> > 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> > 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> > bootstrap.url
> > 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> > 8201218: PPC64: Avoid use of yield instruction on spinlock
> > 8203305: PPC64: Improve TM detection for enabling RTM on Linux /
> > POWER9
> > 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> > detection for enabling RTM on Linux / POWER9"
> > 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> > 8204134: jtreg: Fix RTM abort provoker for various tests after
> > "8149159: Clean up Unsafe"
> > 8150353: PPC64LE: Support RTM on linux
> > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> > illegal instructions
> > 8154156: PPC64: improve array copy stubs by using vector instructions
> > 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM
> > critical section


From mark.reinhold at oracle.com  Thu Jun 14 22:01:09 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 14 Jun 2018 15:01:09 -0700 (PDT)
Subject: JEP proposed to target JDK 11: 332: Transport Layer Security (TLS) 1.3
Message-ID: <20180614220109.74F231DD1B1@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  332: Transport Layer Security (TLS) 1.3
       http://openjdk.java.net/jeps/332

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Thursday,
21 June, 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.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Thu Jun 14 23:05:59 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 14 Jun 2018 16:05:59 -0700
Subject: JEP proposed to target JDK 11: 331: Low-Overhead Heap Profiling
In-Reply-To: <20180607163034.CA69C1DC583@eggemoggin.niobe.net>
References: <20180607163034.CA69C1DC583@eggemoggin.niobe.net>
Message-ID: <20180614160559.271165959@eggemoggin.niobe.net>

2018/6/7 9:30:34 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   331: Low-Overhead Heap Profiling
>        http://openjdk.java.net/jeps/331
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 14 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark

From mark.reinhold at oracle.com  Thu Jun 14 23:06:23 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 14 Jun 2018 16:06:23 -0700
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
Message-ID: <20180614160623.855585027@eggemoggin.niobe.net>

2018/6/7 15:35:15 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   336: Deprecate the Pack200 Tools and API
>        http://openjdk.java.net/jeps/336
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 14 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark

From ebourg at apache.org  Thu Jun 14 23:56:41 2018
From: ebourg at apache.org (Emmanuel Bourg)
Date: Fri, 15 Jun 2018 01:56:41 +0200
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <20180614160623.855585027@eggemoggin.niobe.net>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
Message-ID: <1010c549-d58b-6ce9-b570-868d2831e0be@apache.org>

Le 15/06/2018 ? 01:06, mark.reinhold at oracle.com a ?crit?:

> Hearing no objections, I?ve targeted this JEP to JDK 11.

Hi Mark, there was a couple of replies on this topic though:

http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001371.html
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001382.html

Do I understand correctly that pack200 will be in JDK 11 but might be
removed in a later release?

If maintaining this technology is a burden for Oracle, could community
involvement help reverse this decision?

Emmanuel Bourg

From fridrich.strba at suse.com  Fri Jun 15 07:31:03 2018
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Fri, 15 Jun 2018 09:31:03 +0200
Subject: Build breakage with system jpeg and lcms and jdk-11+18
Message-ID: <7fc9e39e-16a0-d4e5-d10e-453511c4d25f@suse.com>

Hello, good people,

Since I cannot submit anything to bugzilla, I spam this list with this
patch that I needed to be able to build jdk-11+18.

I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
the way the headers are included, but in my analysis, the generated
headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
the new way of doing. The patch makes it build for me. Do what you want
with it :)

Fridrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generated-headers.patch
Type: text/x-patch
Size: 932 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jdk-dev/attachments/20180615/14c4ec02/generated-headers.patch>

From fridrich.strba at suse.com  Fri Jun 15 07:35:55 2018
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Fri, 15 Jun 2018 09:35:55 +0200
Subject: Build breakage with system jpeg and lcms and jdk-11+18
In-Reply-To: <7fc9e39e-16a0-d4e5-d10e-453511c4d25f@suse.com>
References: <7fc9e39e-16a0-d4e5-d10e-453511c4d25f@suse.com>
Message-ID: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>

Just for the completeness, this is a normal openSUSE package build with
--with-system-jpeg and --with-system-lcms. Maybe the
LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
able to build jdk-11+18 with bundled jpeg and lcms without problems.

Cheers

Fridrich

On 15/06/18 09:31, Fridrich Strba wrote:
> Hello, good people,
> 
> Since I cannot submit anything to bugzilla, I spam this list with this
> patch that I needed to be able to build jdk-11+18.
> 
> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
> the way the headers are included, but in my analysis, the generated
> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
> the new way of doing. The patch makes it build for me. Do what you want
> with it :)
> 
> Fridrich
> 



From doko at ubuntu.com  Fri Jun 15 11:06:46 2018
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 15 Jun 2018 13:06:46 +0200
Subject: Build breakage with system jpeg and lcms and jdk-11+18
In-Reply-To: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
References: <7fc9e39e-16a0-d4e5-d10e-453511c4d25f@suse.com>
 <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
Message-ID: <1d2b56e4-85ee-fec0-d77d-e7486a01d7a6@ubuntu.com>

seen as well. The fix is good enough to finish the build.

On 15.06.2018 09:35, Fridrich Strba wrote:
> Just for the completeness, this is a normal openSUSE package build with
> --with-system-jpeg and --with-system-lcms. Maybe the
> LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
> able to build jdk-11+18 with bundled jpeg and lcms without problems.
> 
> Cheers
> 
> Fridrich
> 
> On 15/06/18 09:31, Fridrich Strba wrote:
>> Hello, good people,
>>
>> Since I cannot submit anything to bugzilla, I spam this list with this
>> patch that I needed to be able to build jdk-11+18.
>>
>> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
>> the way the headers are included, but in my analysis, the generated
>> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
>> the new way of doing. The patch makes it build for me. Do what you want
>> with it :)
>>
>> Fridrich
>>
> 
> 


From szegedia at gmail.com  Fri Jun 15 11:40:47 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 15 Jun 2018 13:40:47 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
Message-ID: <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>

On 2018. Jun 12., at 16:55, mark.reinhold at oracle.com wrote:
> 
> [?]
> If a set of credible developers expresses a clear desire to maintain
> Nashorn after JDK 11 then all of us who work on this code base will find
> a way to make that happen.  Maybe Nashorn stays in the JDK, or maybe it?s
> removed from the JDK and maintained in some other OpenJDK Project and
> published to Maven Central, or maybe some completely different approach
> is taken.  Exactly what happens depends, mostly, on who shows up.
> 
> So ... any takers?

I have expressed previously that I am willing to keep maintaining Dynalink, and that I believe it needs to stay in the JDK in order to be effective. John Rose seemed to agree in an earlier reply in this thread.

It?d be great if we could conceptually unbundle Dynalink from Nashorn for the purpose of this discussion. (For historical reasons, its source code is colocated with Nashorn's, but it can be easily moved elsewhere and there?s no technical reason for keeping it there.)

Attila.

> 
> - Mark
> 
> 
> [1] http://openjdk.java.net/jeps/335
> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-July/018545.html


From Alan.Bateman at oracle.com  Fri Jun 15 12:07:15 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Jun 2018 13:07:15 +0100
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
 <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
Message-ID: <b995311b-98d6-c8c7-bb5f-4c1439354d19@oracle.com>

On 15/06/2018 12:40, Attila Szegedi wrote:
> :
> It?d be great if we could conceptually unbundle Dynalink from Nashorn for the purpose of this discussion. (For historical reasons, its source code is colocated with Nashorn's, but it can be easily moved elsewhere and there?s no technical reason for keeping it there.)
>
This has already been done, in JDK 9 as part of the JEP 201 effort to 
reorganize the source code into modules. So while it may have been 
originally developed along with Nashorn, it is its own module now.

I suspect the only impediment to it working outside of the JDK is the 
special handling for @CS methods.

-Alan

From szegedia at gmail.com  Fri Jun 15 12:25:03 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 15 Jun 2018 14:25:03 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <b995311b-98d6-c8c7-bb5f-4c1439354d19@oracle.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
 <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
 <b995311b-98d6-c8c7-bb5f-4c1439354d19@oracle.com>
Message-ID: <05348221-E3C6-4643-A236-9AB1ACF49632@gmail.com>

On 2018. Jun 15., at 14:07, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 15/06/2018 12:40, Attila Szegedi wrote:
>> :
>> It?d be great if we could conceptually unbundle Dynalink from Nashorn for the purpose of this discussion. (For historical reasons, its source code is colocated with Nashorn's, but it can be easily moved elsewhere and there?s no technical reason for keeping it there.)
>> 
> This has already been done, in JDK 9 as part of the JEP 201 effort to reorganize the source code into modules. So while it may have been originally developed along with Nashorn, it is its own module now.
> 
> I suspect the only impediment to it working outside of the JDK is the special handling for @CS methods.

FWIW, @CS is not an issue. Untrusted code can somewhat more weakly detect the @CS annotation by its name instead of by its class.

It?s not so much about it being able to work outside the JDK, but rather about its adoption if every language runtime that wishes to use it would have to carry it as a dependency, and that deters people; e.g. see the effort to use Dynalink as the solution for dynamic invocation in Scala[1]. To quote from there:

"The need to add a runtime dependency was a little off-putting (tilting the balance from "no brainer, let's use this" to "nice to have, but I'd rather not touch our build") , so I welcome the move to standardize the API.?

I suspect there could also be subtle issues if multiple instances of Dynalink through multiple class loaders are floating around instead of a single one (which is guaranteed if it?s in the JDK) (not sure about it though).

Attila.

[1] https://groups.google.com/forum/#!msg/jvm-languages/WGq4BiQ7oz8/-WbMnQOvDgAJ

> 
> -Alan


From Alan.Bateman at oracle.com  Fri Jun 15 12:40:22 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Jun 2018 13:40:22 +0100
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <05348221-E3C6-4643-A236-9AB1ACF49632@gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
 <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
 <b995311b-98d6-c8c7-bb5f-4c1439354d19@oracle.com>
 <05348221-E3C6-4643-A236-9AB1ACF49632@gmail.com>
Message-ID: <bec8fa44-7b00-8417-6430-d51fa66484de@oracle.com>

On 15/06/2018 13:25, Attila Szegedi wrote:
> :
> FWIW, @CS is not an issue. Untrusted code can somewhat more weakly detect the @CS annotation by its name instead of by its class.
Sure, I'm just pointing out that it currently has both a compile-time 
and run time dependency on @CS and that would need attention in the 
event that it were to be jettisoned and maintained outside of the JDK.

BTW: I do think you are are right to ask why jdk.dynalink is listed in 
JEP 335, that isn't fully explained in the motivation section at this time.

-Alan

From mark.reinhold at oracle.com  Fri Jun 15 14:23:11 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 15 Jun 2018 07:23:11 -0700
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <1010c549-d58b-6ce9-b570-868d2831e0be@apache.org>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
 <1010c549-d58b-6ce9-b570-868d2831e0be@apache.org>
Message-ID: <20180615072311.28689533@eggemoggin.niobe.net>

2018/6/14 16:56:41 -0700, Emmanuel Bourg <ebourg at apache.org>:
> ...
> 
> Do I understand correctly that pack200 will be in JDK 11 but might be
> removed in a later release?

Yes.

> If maintaining this technology is a burden for Oracle, could community
> involvement help reverse this decision?

Possibly.  As noted in the JEP, however, Pack200 is a complex and
elaborate technology that?s tightly coupled to the class-file format
and the JAR-file format, both of which continue to evolve.  This isn?t
a reasonably-separable component that can be maintained more or less
at its own pace.  If one or more non-Oracle contributors were to step
up to maintain Pack200 then they?d need to commit to staying on top of
it and participating in most every six-month feature release.

- Mark

From mark.reinhold at oracle.com  Fri Jun 15 14:25:17 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 15 Jun 2018 07:25:17 -0700
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
References: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
Message-ID: <20180615072517.55245716@eggemoggin.niobe.net>

2018/6/12 13:50:37 -0700, Daniel Megert <daniel_megert at ch.ibm.com>:
> pack200 is used by the Eclipse update manager a.k.a. p2. The JARed 
> plug-ins are compressed with pack200 and put into a p2 repository. 
> Removing pack200 will make the download (and hence install) of plug-ins 
> much slower. Eclipse would therefore like to keep this technology.

Is Eclipse willing to sign up to maintain this technology?

>                                                                    If 
> that's not an option, then we would like that the removal does not happen 
> before Java 13.

Request noted.

- Mark

From tony at kodaris.com  Fri Jun 15 20:26:03 2018
From: tony at kodaris.com (Tony Zakula)
Date: Fri, 15 Jun 2018 16:26:03 -0400
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
Message-ID: <CA+EtG02Pmz4YYH1btfhCX-Aie3+G2XcN63cvqJBhGuLbODou-g@mail.gmail.com>

We also use this Nashorn as a core part of our platform.  Would like to see
it stay and be maintained.

Thanks,

Tony

From henry.jen at oracle.com  Fri Jun 15 22:38:54 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 15 Jun 2018 15:38:54 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <5abcb652-ba3f-dc52-a78c-a7c818e277ae@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
 <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com> <5B1EB88F.50804@oracle.com>
 <DEAF7DD9-4D20-420D-8F9B-01DBEFC39B8D@oracle.com>
 <257FFD8E-19C8-4CCC-8955-561FA6FD9401@oracle.com>
 <5abcb652-ba3f-dc52-a78c-a7c818e277ae@oracle.com>
Message-ID: <F35E2115-B5ED-4EE5-A0CC-A9DB7E1E2924@oracle.com>

Updated the @deprecated message, the webrev is at

http://cr.openjdk.java.net/~henryjen/jdk11/8199871/4/webrev/

Cheers,
Henry


> On Jun 13, 2018, at 9:32 AM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 6/12/18 4:52 PM, Henry Jen wrote:
>> OK, I have updated the webrev[1] based on the feedback. All the messages are changes, and added since=?11? for Deprecated.
>> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/2/webrev/
> 
> src/java.base/share/classes/java/util/jar/Pack200.java
>  104  * @deprecated This class has been deprecated
> 
> @deprecated is missing in Pack200.Packer and Pack200.Unpacker. You can use the consistent message in @deprecated as well.
> 
> Otherwise, the change looks fine to me.
> 
> Mandy


From mandy.chung at oracle.com  Fri Jun 15 23:21:26 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 15 Jun 2018 16:21:26 -0700
Subject: RFR: 8199871: Deprecate pack200 and unpack200 tools
In-Reply-To: <F35E2115-B5ED-4EE5-A0CC-A9DB7E1E2924@oracle.com>
References: <78256921-225B-4AEF-8313-42E135BDB886@oracle.com>
 <D037ED9F-6D9A-4579-8CA2-7304DA256925@oracle.com>
 <9A578E52-8BFD-481F-A09E-EAC912696DA0@oracle.com> <5B1EB88F.50804@oracle.com>
 <DEAF7DD9-4D20-420D-8F9B-01DBEFC39B8D@oracle.com>
 <257FFD8E-19C8-4CCC-8955-561FA6FD9401@oracle.com>
 <5abcb652-ba3f-dc52-a78c-a7c818e277ae@oracle.com>
 <F35E2115-B5ED-4EE5-A0CC-A9DB7E1E2924@oracle.com>
Message-ID: <7e296623-1c26-187a-39a0-bcf4a7d989f4@oracle.com>

+1

Mandy

On 6/15/18 3:38 PM, Henry Jen wrote:
> Updated the @deprecated message, the webrev is at
> 
> http://cr.openjdk.java.net/~henryjen/jdk11/8199871/4/webrev/
> 
> Cheers,
> Henry
> 
> 
>> On Jun 13, 2018, at 9:32 AM, mandy chung <mandy.chung at oracle.com> wrote:
>>
>>
>>
>> On 6/12/18 4:52 PM, Henry Jen wrote:
>>> OK, I have updated the webrev[1] based on the feedback. All the messages are changes, and added since=?11? for Deprecated.
>>> [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/2/webrev/
>>
>> src/java.base/share/classes/java/util/jar/Pack200.java
>>   104  * @deprecated This class has been deprecated
>>
>> @deprecated is missing in Pack200.Packer and Pack200.Unpacker. You can use the consistent message in @deprecated as well.
>>
>> Otherwise, the change looks fine to me.
>>
>> Mandy
> 

From jini at zeus.net.au  Sat Jun 16 10:32:54 2018
From: jini at zeus.net.au (Peter)
Date: Sat, 16 Jun 2018 20:32:54 +1000
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <20180615072311.28689533@eggemoggin.niobe.net>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
 <1010c549-d58b-6ce9-b570-868d2831e0be@apache.org>
 <20180615072311.28689533@eggemoggin.niobe.net>
Message-ID: <5B24E756.9000804@zeus.net.au>

Hi Mark,

Might Oracle consider donating only the specification doc's and jtreg 
tests to Apache?   We don't need the implementation.

I've started working on  Emmanual's Pack200 implemetation from Apache 
Harmony, so far I've got it working and all tests passing with ASM6.2.  
I'd like to get it up to date with the latest jvm bytecode features, the 
tests would certainly help, as it currently only supports java 1.5 and 
some 1.6 features.   This implementation of Pack200 is modular, 
separable and should be relatively easy to maintain, external to the 
JVM.  Perhaps Oracle / OpenJDK could retain the api within the jvm, but 
drop the implementation in a future release, we could use the existing 
provider mechanism.

Thanks,

Peter.

On 16/06/2018 12:23 AM, mark.reinhold at oracle.com wrote:
> 2018/6/14 16:56:41 -0700, Emmanuel Bourg<ebourg at apache.org>:
>> ...
>>
>> Do I understand correctly that pack200 will be in JDK 11 but might be
>> removed in a later release?
> Yes.
>
>> If maintaining this technology is a burden for Oracle, could community
>> involvement help reverse this decision?
> Possibly.  As noted in the JEP, however, Pack200 is a complex and
> elaborate technology that?s tightly coupled to the class-file format
> and the JAR-file format, both of which continue to evolve.  This isn?t
> a reasonably-separable component that can be maintained more or less
> at its own pace.  If one or more non-Oracle contributors were to step
> up to maintain Pack200 then they?d need to commit to staying on top of
> it and participating in most every six-month feature release.
>
> - Mark


From jai.forums2013 at gmail.com  Sun Jun 17 10:56:34 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 17 Jun 2018 16:26:34 +0530
Subject: Launching single file source code program - "error: class found on
 application class path"
Message-ID: <01a63440-f5d0-aa6e-7744-ccca3127d563@gmail.com>

Consider this very simple class:


public class A {
 ??? public static void main(final String[] args) throws Exception {
 ??? ??? System.out.println("Passed");
 ??? }
}

I built the latest JDK from source and used the "launch single file 
source program" feature as follows:

 > cd /tmp/foo-bar

(this dir contains just A.java file)

 > java A.java

The output is as follows (as expected):

Passed

Then I went ahead and did an explicit compilation of this Java file:

 > javac A.java

The /tmp/foo-bar directory now consists of A.class and A.java. I then 
went ahead and (tried) to launch the A.java using the new feature as 
previously:

 > java A.java

I now get this error message:

error: class found on application class path: A

1. That error message isn't clear about what the problem is. I guess 
it's trying to convey that there's already a compiled class for the same 
source class, in the application classpath?

2. Why is this an error? Is it intentional?

-Jaikiran



From manoj.palat at in.ibm.com  Mon Jun 18 04:25:48 2018
From: manoj.palat at in.ibm.com (Manoj Palat)
Date: Mon, 18 Jun 2018 09:55:48 +0530
Subject: Expected Early Access Build with JEP 181: Nest-Based Access Control?
Message-ID: <OF3AF7E073.090E618D-ON652582B0.00163834-652582B0.001855C5@notes.na.collabserv.com>



Hi,

 When can we expect an early access build that contains Nest-Based Access
Control? We are interested more in the JRE/runtime part that recognizes
nestmate attributes in the classfile than the javac part that involves the
nest attribute generation/bridge method elision.

Regards,
Manoj
Eclipse Java Dev,
IBM.

From benjamin.john.evans at gmail.com  Mon Jun 18 06:23:10 2018
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Mon, 18 Jun 2018 08:23:10 +0200
Subject: Expected Early Access Build with JEP 181: Nest-Based Access
 Control?
In-Reply-To: <OF3AF7E073.090E618D-ON652582B0.00163834-652582B0.001855C5@notes.na.collabserv.com>
References: <OF3AF7E073.090E618D-ON652582B0.00163834-652582B0.001855C5@notes.na.collabserv.com>
Message-ID: <CABKW8Ri30+Mfm74YY2Y1Mz5tv1TUFyE56M=BgR490wvFOSHEMA@mail.gmail.com>

[+Martijn for Build Farm]
Hi Manoj,

I think the AdoptOpenJDK build farm (collaboration between various
community folks, including IBM) are planning to start building this
project.

Martijn - what's the status of this? Were there any blockers? Do we
need any additional help from anyone at IBM?

Thanks,

Ben


On Mon, Jun 18, 2018 at 6:25 AM, Manoj Palat <manoj.palat at in.ibm.com> wrote:
>
>
> Hi,
>
>  When can we expect an early access build that contains Nest-Based Access
> Control? We are interested more in the JRE/runtime part that recognizes
> nestmate attributes in the classfile than the javac part that involves the
> nest attribute generation/bridge method elision.
>
> Regards,
> Manoj
> Eclipse Java Dev,
> IBM.

From david.holmes at oracle.com  Mon Jun 18 07:52:05 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 18 Jun 2018 17:52:05 +1000
Subject: Expected Early Access Build with JEP 181: Nest-Based Access
 Control?
In-Reply-To: <OF3AF7E073.090E618D-ON652582B0.00163834-652582B0.001855C5@notes.na.collabserv.com>
References: <OF3AF7E073.090E618D-ON652582B0.00163834-652582B0.001855C5@notes.na.collabserv.com>
Message-ID: <a4210e64-94d7-1d8f-e187-2d2f3545d575@oracle.com>

Hi Manoj,

On 18/06/2018 2:25 PM, Manoj Palat wrote:
> Hi,
> 
>   When can we expect an early access build that contains Nest-Based Access
> Control? We are interested more in the JRE/runtime part that recognizes
> nestmate attributes in the classfile than the javac part that involves the
> nest attribute generation/bridge method elision.

I had hoped to have JEP-181 integrated by now but it has been delayed 
while some documentation issues in java.lang.Class are resolved prior to 
the CSR being approved. I would hope to have this integrated by 
Wednesday or Thursday this week and it would then appear in the next 
promoted build.

If you are able to do your own build then the (near final) patch is 
available from:

http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v5/

David
-----

> Regards,
> Manoj
> Eclipse Java Dev,
> IBM.
> 

From martijnverburg at gmail.com  Mon Jun 18 08:33:49 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 18 Jun 2018 09:33:49 +0100
Subject: Expected Early Access Build with JEP 181: Nest-Based Access
 Control?
In-Reply-To: <CABKW8Ri30+Mfm74YY2Y1Mz5tv1TUFyE56M=BgR490wvFOSHEMA@mail.gmail.com>
References: <OF3AF7E073.090E618D-ON652582B0.00163834-652582B0.001855C5@notes.na.collabserv.com>
 <CABKW8Ri30+Mfm74YY2Y1Mz5tv1TUFyE56M=BgR490wvFOSHEMA@mail.gmail.com>
Message-ID: <CAP7YuAR1HNZkTj8fekQyGyQzHH21j86u2JJuHEiEKiOzvCoitg@mail.gmail.com>

Hi Manoj,

You can make a request at GitHub/AdoptOpenJDK/TSC and we will start
spinning up the infra for the build.

On Mon, 18 Jun 2018 at 07:23, Ben Evans <benjamin.john.evans at gmail.com>
wrote:

> [+Martijn for Build Farm]
> Hi Manoj,
>
> I think the AdoptOpenJDK build farm (collaboration between various
> community folks, including IBM) are planning to start building this
> project.
>
> Martijn - what's the status of this? Were there any blockers? Do we
> need any additional help from anyone at IBM?
>
> Thanks,
>
> Ben
>
>
> On Mon, Jun 18, 2018 at 6:25 AM, Manoj Palat <manoj.palat at in.ibm.com>
> wrote:
> >
> >
> > Hi,
> >
> >  When can we expect an early access build that contains Nest-Based Access
> > Control? We are interested more in the JRE/runtime part that recognizes
> > nestmate attributes in the classfile than the javac part that involves
> the
> > nest attribute generation/bridge method elision.
> >
> > Regards,
> > Manoj
> > Eclipse Java Dev,
> > IBM.
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From mark.reinhold at oracle.com  Mon Jun 18 15:07:06 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 18 Jun 2018 08:07:06 -0700
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
 <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
Message-ID: <20180618080706.109269703@eggemoggin.niobe.net>

2018/6/15 4:40:47 -0700, Attila Szegedi <szegedia at gmail.com>:
> On 2018. Jun 12., at 16:55, mark.reinhold at oracle.com wrote:
>> 
>> [?]
>> If a set of credible developers expresses a clear desire to maintain
>> Nashorn after JDK 11 then all of us who work on this code base will find
>> a way to make that happen.  Maybe Nashorn stays in the JDK, or maybe it?s
>> removed from the JDK and maintained in some other OpenJDK Project and
>> published to Maven Central, or maybe some completely different approach
>> is taken.  Exactly what happens depends, mostly, on who shows up.
>> 
>> So ... any takers?
> 
> I have expressed previously that I am willing to keep maintaining
> Dynalink, and that I believe it needs to stay in the JDK in order to
> be effective. John Rose seemed to agree in an earlier reply in this
> thread.

As the creator of Dynalink you?re obviously qualified to take this on,
so thanks for volunteering!  I agree that much of Dynalink?s value rests
in its continued availability in the JDK.

Jim -- what do you think?

> It?d be great if we could conceptually unbundle Dynalink from Nashorn
> for the purpose of this discussion. (For historical reasons, its
> source code is colocated with Nashorn's, but it can be easily moved
> elsewhere and there?s no technical reason for keeping it there.)

As Alan noted, Dynalink is already in its own module, so this isn?t an
issue.

- Mark

From james.laskey at oracle.com  Mon Jun 18 15:10:37 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 18 Jun 2018 12:10:37 -0300
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <20180618080706.109269703@eggemoggin.niobe.net>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
 <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
 <20180618080706.109269703@eggemoggin.niobe.net>
Message-ID: <E1DD0570-3670-4E82-AE76-9C907D4C08E8@oracle.com>

I think this is an excellent outcome. Thank you Attila.

I will revise JEP 335 accordingly.

Cheers,

? Jim



> On Jun 18, 2018, at 12:07 PM, mark.reinhold at oracle.com wrote:
> 
> 2018/6/15 4:40:47 -0700, Attila Szegedi <szegedia at gmail.com>:
>> On 2018. Jun 12., at 16:55, mark.reinhold at oracle.com wrote:
>>> 
>>> [?]
>>> If a set of credible developers expresses a clear desire to maintain
>>> Nashorn after JDK 11 then all of us who work on this code base will find
>>> a way to make that happen.  Maybe Nashorn stays in the JDK, or maybe it?s
>>> removed from the JDK and maintained in some other OpenJDK Project and
>>> published to Maven Central, or maybe some completely different approach
>>> is taken.  Exactly what happens depends, mostly, on who shows up.
>>> 
>>> So ... any takers?
>> 
>> I have expressed previously that I am willing to keep maintaining
>> Dynalink, and that I believe it needs to stay in the JDK in order to
>> be effective. John Rose seemed to agree in an earlier reply in this
>> thread.
> 
> As the creator of Dynalink you?re obviously qualified to take this on,
> so thanks for volunteering!  I agree that much of Dynalink?s value rests
> in its continued availability in the JDK.
> 
> Jim -- what do you think?
> 
>> It?d be great if we could conceptually unbundle Dynalink from Nashorn
>> for the purpose of this discussion. (For historical reasons, its
>> source code is colocated with Nashorn's, but it can be easily moved
>> elsewhere and there?s no technical reason for keeping it there.)
> 
> As Alan noted, Dynalink is already in its own module, so this isn?t an
> issue.
> 
> - Mark


From szegedia at gmail.com  Mon Jun 18 15:17:46 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 18 Jun 2018 17:17:46 +0200
Subject: New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
In-Reply-To: <E1DD0570-3670-4E82-AE76-9C907D4C08E8@oracle.com>
References: <20180606181603.B65891DC34A@eggemoggin.niobe.net>
 <20180612145532.6B5EB1DCCC4@eggemoggin.niobe.net>
 <F3E56FC4-E37A-41A9-8099-BEC1D5DAA257@gmail.com>
 <20180618080706.109269703@eggemoggin.niobe.net>
 <E1DD0570-3670-4E82-AE76-9C907D4C08E8@oracle.com>
Message-ID: <241856EE-105D-4633-BFBB-FB94EDF24981@gmail.com>

Well, thank you for the consideration! I?m pretty happy with this outcome.

Attila.

> On 2018. Jun 18., at 17:10, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> I think this is an excellent outcome. Thank you Attila.
> 
> I will revise JEP 335 accordingly.
> 
> Cheers,
> 
> ? Jim
> 
> 
> 
>> On Jun 18, 2018, at 12:07 PM, mark.reinhold at oracle.com wrote:
>> 
>> 2018/6/15 4:40:47 -0700, Attila Szegedi <szegedia at gmail.com>:
>>> On 2018. Jun 12., at 16:55, mark.reinhold at oracle.com wrote:
>>>> 
>>>> [?]
>>>> If a set of credible developers expresses a clear desire to maintain
>>>> Nashorn after JDK 11 then all of us who work on this code base will find
>>>> a way to make that happen.  Maybe Nashorn stays in the JDK, or maybe it?s
>>>> removed from the JDK and maintained in some other OpenJDK Project and
>>>> published to Maven Central, or maybe some completely different approach
>>>> is taken.  Exactly what happens depends, mostly, on who shows up.
>>>> 
>>>> So ... any takers?
>>> 
>>> I have expressed previously that I am willing to keep maintaining
>>> Dynalink, and that I believe it needs to stay in the JDK in order to
>>> be effective. John Rose seemed to agree in an earlier reply in this
>>> thread.
>> 
>> As the creator of Dynalink you?re obviously qualified to take this on,
>> so thanks for volunteering!  I agree that much of Dynalink?s value rests
>> in its continued availability in the JDK.
>> 
>> Jim -- what do you think?
>> 
>>> It?d be great if we could conceptually unbundle Dynalink from Nashorn
>>> for the purpose of this discussion. (For historical reasons, its
>>> source code is colocated with Nashorn's, but it can be easily moved
>>> elsewhere and there?s no technical reason for keeping it there.)
>> 
>> As Alan noted, Dynalink is already in its own module, so this isn?t an
>> issue.
>> 
>> - Mark
> 


From jonathan.gibbons at oracle.com  Mon Jun 18 17:52:25 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Jun 2018 10:52:25 -0700
Subject: Launching single file source code program - "error: class found
 on application class path"
In-Reply-To: <01a63440-f5d0-aa6e-7744-ccca3127d563@gmail.com>
References: <01a63440-f5d0-aa6e-7744-ccca3127d563@gmail.com>
Message-ID: <5B27F159.2020009@oracle.com>



On 06/17/2018 03:56 AM, Jaikiran Pai wrote:
> Consider this very simple class:
>
>
> public class A {
>     public static void main(final String[] args) throws Exception {
>         System.out.println("Passed");
>     }
> }
>
> I built the latest JDK from source and used the "launch single file 
> source program" feature as follows:
>
> > cd /tmp/foo-bar
>
> (this dir contains just A.java file)
>
> > java A.java
>
> The output is as follows (as expected):
>
> Passed
>
> Then I went ahead and did an explicit compilation of this Java file:
>
> > javac A.java
>
> The /tmp/foo-bar directory now consists of A.class and A.java. I then 
> went ahead and (tried) to launch the A.java using the new feature as 
> previously:
>
> > java A.java
>
> I now get this error message:
>
> error: class found on application class path: A
>
> 1. That error message isn't clear about what the problem is. I guess 
> it's trying to convey that there's already a compiled class for the 
> same source class, in the application classpath?

Yes, that is what the message is saying.

>
> 2. Why is this an error? Is it intentional?

This is the intended behavior, to avoid the ambiguity of having the 
class on the classpath (which defaults to the current directory) and the 
internally-compiled class generated from the source file.

>
> -Jaikiran
>
>


From szegedia at gmail.com  Mon Jun 18 21:33:57 2018
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 18 Jun 2018 23:33:57 +0200
Subject: Launching single file source code program - "error: class found
 on application class path"
In-Reply-To: <5B27F159.2020009@oracle.com>
References: <01a63440-f5d0-aa6e-7744-ccca3127d563@gmail.com>
 <5B27F159.2020009@oracle.com>
Message-ID: <C300E278-3F66-4223-863A-CE625BD82716@gmail.com>

On 2018. Jun 18., at 19:52, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> On 06/17/2018 03:56 AM, Jaikiran Pai wrote:
>> [?]
>> 
>> The /tmp/foo-bar directory now consists of A.class and A.java. I then went ahead and (tried) to launch the A.java using the new feature as previously:
>> 
>> > java A.java
>> 
>> I now get this error message:
>> 
>> error: class found on application class path: A
>> [?]
> 
>> 
>> 2. Why is this an error? Is it intentional?
> 
> This is the intended behavior, to avoid the ambiguity of having the class on the classpath (which defaults to the current directory) and the internally-compiled class generated from the source file.

Is this really ambiguous?

If the user runs ?java A.java?, their intent is clearly to run the source code file. The file name is explicitly spelt out in the command.

If the user runs "java A?, then ? if only from a purely backwards-compatible perspective ? it should run the precompiled class; same way ?java? command worked before this feature existed. I can see how one might argue user's intent was ambiguous in this case, though. (But then, it isn't the case original poster asked about.)

Attila.


From jonathan.gibbons at oracle.com  Mon Jun 18 21:42:52 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Jun 2018 14:42:52 -0700
Subject: Launching single file source code program - "error: class found
 on application class path"
In-Reply-To: <C300E278-3F66-4223-863A-CE625BD82716@gmail.com>
References: <01a63440-f5d0-aa6e-7744-ccca3127d563@gmail.com>
 <5B27F159.2020009@oracle.com>
 <C300E278-3F66-4223-863A-CE625BD82716@gmail.com>
Message-ID: <932b537b-e09d-b857-6e24-42f9ec13ea23@oracle.com>



On 6/18/18 2:33 PM, Attila Szegedi wrote:
> On 2018. Jun 18., at 19:52, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>> On 06/17/2018 03:56 AM, Jaikiran Pai wrote:
>>> [?]
>>>
>>> The /tmp/foo-bar directory now consists of A.class and A.java. I then went ahead and (tried) to launch the A.java using the new feature as previously:
>>>
>>>> java A.java
>>> I now get this error message:
>>>
>>> error: class found on application class path: A
>>> [?]
>>> 2. Why is this an error? Is it intentional?
>> This is the intended behavior, to avoid the ambiguity of having the class on the classpath (which defaults to the current directory) and the internally-compiled class generated from the source file.
> Is this really ambiguous?
>
> If the user runs ?java A.java?, their intent is clearly to run the source code file. The file name is explicitly spelt out in the command.
>
> If the user runs "java A?, then ? if only from a purely backwards-compatible perspective ? it should run the precompiled class; same way ?java? command worked before this feature existed. I can see how one might argue user's intent was ambiguous in this case, though. (But then, it isn't the case original poster asked about.)
>
> Attila.
>

Yes, we wanted to avoid any confusion between the possibility of the 
class being on the classpath and being specified as a source file.

-- Jon

From vivek.r.deshpande at intel.com  Mon Jun 18 23:49:32 2018
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Mon, 18 Jun 2018 23:49:32 +0000
Subject: RFR(S): 8205194: Improve the Array Comparison when there is a
 mismatch at first element.
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A9074835D@ORSMSX106.amr.corp.intel.com>

Hi All

I would like to contribute a patch which improves the array comparison when there is a mismatch for the first element.
This avoids call to vectorizedMismatch method and gives ~80x speed up.
Please review and sponsor the patch.

Regards,
Vivek


From vivek.r.deshpande at intel.com  Mon Jun 18 23:52:55 2018
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Mon, 18 Jun 2018 23:52:55 +0000
Subject: RFR(S): 8205194: Improve the Array Comparison when there is a
 mismatch at first element.
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A90748395@ORSMSX106.amr.corp.intel.com>

Hi All

Forgot to add the links:
https://bugs.openjdk.java.net/browse/JDK-8205194
webrev:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.00/

Regards.
Vivek

From: Deshpande, Vivek R
Sent: Monday, June 18, 2018 4:50 PM
To: 'jdk-dev at openjdk.java.net' <jdk-dev at openjdk.java.net>
Cc: 'Paul Sandoz' <paul.sandoz at oracle.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Subject: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

Hi All

I would like to contribute a patch which improves the array comparison when there is a mismatch for the first element.
This avoids call to vectorizedMismatch method and gives ~80x speed up.
Please review and sponsor the patch.

Regards,
Vivek


From jai.forums2013 at gmail.com  Tue Jun 19 00:43:40 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 19 Jun 2018 06:13:40 +0530
Subject: Launching single file source code program - "error: class found
 on application class path"
In-Reply-To: <932b537b-e09d-b857-6e24-42f9ec13ea23@oracle.com>
References: <01a63440-f5d0-aa6e-7744-ccca3127d563@gmail.com>
 <5B27F159.2020009@oracle.com>
 <C300E278-3F66-4223-863A-CE625BD82716@gmail.com>
 <932b537b-e09d-b857-6e24-42f9ec13ea23@oracle.com>
Message-ID: <2c215ba5-e8b6-5e3b-ea16-89062ae9e98c@gmail.com>

Hi Jonathan,

If this is intentional and if there's no plan to change this behaviour, 
would it be possible to make that error message a bit more 
clear/verbose. The first few times when I kept seeing:

"error: class found on application class path: A"

I kept reading it as "class *not* found" (given the numerous occasions 
I'm used to seeing class not found exceptions in logs). Furthermore, the 
message in its current form, at least to me, feels more like a debug log 
than an error notification. Would it be possible to change it to 
something along the lines of:

"error: A compiled class <fully qualified class name> already exists on 
the application classpath and as a result the same class cannot be used 
as a source for launching single-file source code program".

As for the reason why this is intentionally marked as an error, is it 
because the execution of the auto-compiled source file can no longer be 
guaranteed to pick up the "right" class file if there's more than one 
instance of the fully qualified classname in the application classpath? 
At this point, I'm just curious about the reasoning and not really 
asking for this to be supported. I can understand that, since this is a 
source file that the user is executing and since they will have access 
to it and furthermore, since it's just going to be one single file, it's 
reasonable to expect the user to edit the file to use a different 
classname, if at all they run into such issues due to the content of 
their application classpath.

-Jaikiran


On 19/06/18 3:12 AM, Jonathan Gibbons wrote:
>
>
> On 6/18/18 2:33 PM, Attila Szegedi wrote:
>> On 2018. Jun 18., at 19:52, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com> wrote:
>>> On 06/17/2018 03:56 AM, Jaikiran Pai wrote:
>>>> [?]
>>>>
>>>> The /tmp/foo-bar directory now consists of A.class and A.java. I 
>>>> then went ahead and (tried) to launch the A.java using the new 
>>>> feature as previously:
>>>>
>>>>> java A.java
>>>> I now get this error message:
>>>>
>>>> error: class found on application class path: A
>>>> [?]
>>>> 2. Why is this an error? Is it intentional?
>>> This is the intended behavior, to avoid the ambiguity of having the 
>>> class on the classpath (which defaults to the current directory) and 
>>> the internally-compiled class generated from the source file.
>> Is this really ambiguous?
>>
>> If the user runs ?java A.java?, their intent is clearly to run the 
>> source code file. The file name is explicitly spelt out in the command.
>>
>> If the user runs "java A?, then ? if only from a purely 
>> backwards-compatible perspective ? it should run the precompiled 
>> class; same way ?java? command worked before this feature existed. I 
>> can see how one might argue user's intent was ambiguous in this case, 
>> though. (But then, it isn't the case original poster asked about.)
>>
>> Attila.
>>
>
> Yes, we wanted to avoid any confusion between the possibility of the 
> class being on the classpath and being specified as a source file.
>
> -- Jon


From david.holmes at oracle.com  Tue Jun 19 05:31:40 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jun 2018 15:31:40 +1000
Subject: RFR(S): 8205194: Improve the Array Comparison when there is a
 mismatch at first element.
In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A90748395@ORSMSX106.amr.corp.intel.com>
References: <53E8E64DB2403849AFD89B7D4DAC8B2A90748395@ORSMSX106.amr.corp.intel.com>
Message-ID: <dab09c0b-3023-95c1-36e2-a448db6e98dc@oracle.com>

Hi Vivek,

Reviews should take place on the appropriate mailing list for the code 
being changed, not on the jdk-dev list. Please takes this to core-libs-dev.

Thanks,
David

On 19/06/2018 9:52 AM, Deshpande, Vivek R wrote:
> Hi All
> 
> Forgot to add the links:
> https://bugs.openjdk.java.net/browse/JDK-8205194
> webrev:
> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.00/
> 
> Regards.
> Vivek
> 
> From: Deshpande, Vivek R
> Sent: Monday, June 18, 2018 4:50 PM
> To: 'jdk-dev at openjdk.java.net' <jdk-dev at openjdk.java.net>
> Cc: 'Paul Sandoz' <paul.sandoz at oracle.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
> Subject: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.
> 
> Hi All
> 
> I would like to contribute a patch which improves the array comparison when there is a mismatch for the first element.
> This avoids call to vectorizedMismatch method and gives ~80x speed up.
> Please review and sponsor the patch.
> 
> Regards,
> Vivek
> 

From mark.reinhold at oracle.com  Tue Jun 19 17:24:25 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 19 Jun 2018 10:24:25 -0700
Subject: Draft process JEP: JDK Release Process
Message-ID: <20180619102425.37532384@eggemoggin.niobe.net>

We?re fast approaching the Rampdown Phase One milestone for JDK 11 [1].
In preparation for that phase, and the phases that follow, I?ve updated,
generalized, and consolidated the various process pages that we used for
JDK 10 [2] into a draft process JEP for use with JDK 11 and beyond:

  http://openjdk.java.net/jeps/8205352

To ease understanding I refactored the text to present one set of
actions whose parameters are adjusted for each phase, but the intent
is that the guidance given here is essentially the same as that spread
across the JDK 10 process pages.

Comments welcome!

- Mark


[1] http://openjdk.java.net/projects/jdk/11/
[2] http://openjdk.java.net/projects/jdk/10/rdp-1
    http://openjdk.java.net/projects/jdk/10/rdp-2
    http://openjdk.java.net/projects/jdk/10/rc
    http://openjdk.java.net/projects/jdk/10/bug-deferral-process
    http://openjdk.java.net/projects/jdk/10/fix-request-process
    http://openjdk.java.net/projects/jdk/10/late-enhancement-process

From mark.reinhold at oracle.com  Tue Jun 19 21:06:32 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 19 Jun 2018 14:06:32 -0700 (PDT)
Subject: JEP proposed to target JDK 11: 335: Deprecate the Nashorn JavaScript
 Engine
Message-ID: <20180619210632.A1D801DDAB6@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  335: Deprecate the Nashorn JavaScript Engine
       http://openjdk.java.net/jeps/335

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Tuesday,
26 June, 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.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From jini at zeus.net.au  Tue Jun 19 23:41:02 2018
From: jini at zeus.net.au (Peter)
Date: Wed, 20 Jun 2018 09:41:02 +1000
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <20180615072517.55245716@eggemoggin.niobe.net>
References: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
 <20180615072517.55245716@eggemoggin.niobe.net>
Message-ID: <5B29948E.5060400@zeus.net.au>

Mark,

Can Oracle deprecate the implementation but allow the development of the 
specification to continue?

For example, I'm currently working out how to support the Java 9 
constant pool entries, Module_info and Package_info.

Bit 13 in #archive_options would need to be have_cp_module_counts 
cp_module_counts contains counts

If Java can retain the api and specification (and support the 
specification) while deprecating the current implmentation, then the 
community can use the existing provider mechanism to load any 
implementation.

The #archive_options word is interpreted bitwise. Certain bits are given 
symbolic names as follows, where the LSB is numbered as bit
zero:
Bit Name Meaning if set in #archive_options
0 have_special_formats archive_special_counts contains counts
1 have_cp_numbers cp_number_counts contains counts
2 have_all_code_flags code_flags_lo contains an element for every code
3 have_cp_extra_counts cp_extra_counts contains counts
4 have_file_headers archive_file_counts contains counts
5 deflate_hint request compressed JAR file for all elements
6 have_file_modtime file_modtime contains modtimes
7 have_file_options file_options contains option bits
8 have_file_size_hi file_size_hi contains high-order size words
9 have_class_flags_hi class_flags_hi contains extra attribute flags
10 have_field_flags_hi field_flags_hi contains extra attribute flags
11 have_method_flags_hi method_flags_hi contains extra attribute flags
12 have_code_flags_hi code_flags_hi contains extra attribute flags
13 (unused, must be zero)
... (unused, must be zero)
31 (unused, must be zero)


On 16/06/2018 12:25 AM, mark.reinhold at oracle.com wrote:
> 2018/6/12 13:50:37 -0700, Daniel Megert<daniel_megert at ch.ibm.com>:
>> pack200 is used by the Eclipse update manager a.k.a. p2. The JARed
>> plug-ins are compressed with pack200 and put into a p2 repository.
>> Removing pack200 will make the download (and hence install) of plug-ins
>> much slower. Eclipse would therefore like to keep this technology.
> Is Eclipse willing to sign up to maintain this technology?
>
>>                                                                     If
>> that's not an option, then we would like that the removal does not happen
>> before Java 13.
> Request noted.
>
> - Mark


From jai.forums2013 at gmail.com  Wed Jun 20 05:13:50 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 20 Jun 2018 10:43:50 +0530
Subject: Comment about JDK-8204458 - BigDecimal toString() return different
 value when use idea run and debug
Message-ID: <d275037d-cf3a-6773-8004-7e4e6cdd7832@gmail.com>

(I don't have permissions to comment on the JIRA nor do I see a way to 
submit a comment, as a casual observer, to a bug opened by someone else 
through https://bugs.java.com/. So posting it here. I thought of sending 
it to "discuss" list instead of this one, but this felt more 
appropriate. I hope that's OK.)

As noted in the JIRA https://bugs.openjdk.java.net/browse/JDK-8204458 
the following simple code:

public static void main(final String[] args) throws Exception {
 ??????? final BigDecimal bd = new BigDecimal("1");
 ??????? System.out.println(bd.toString());
}

returns an "incorrect" output ("0") when run in debug mode with a 
breakpoint in IntelliJ IDE. Apparently not reproducible in other IDEs. I 
use IntelliJ, so gave it a quick try and indeed it does return "0" in a 
specific scenario. What actually triggers this and reproduces this, is 
the combination of 2 things:

- The breakpoint has to be in the constructor of the BigDecimal class 
(which is what the OP has done in that JIRA)
- The fact that the toString() implementation of this class uses a 
"stringCache"

What's really happening (in IntelliJ) is that when the IDE stops at that 
breakpoint, i.e. when the class instance isn't yet fully initialized, 
the IDE tries to render a IDE specific "Variables" view/window, where it 
displays the object instance details. To do so, it internally (in the 
background) appears to be triggering a toString() call on that instance 
being displayed. Effectively, what's happening is that the toString() 
implementation of this BigDecimal class goes and builds up a 
"stringCache" using an uninitialized/partially initialized state of this 
instance (which is still not finished in its constructor) and ends up 
storing an incorrect value of "0" to this "stringCache". As a result, 
the subsequent calls to toString(), even after the object is fully 
initialized return this incorrectly computed/cached value.

This appears to be something the IntelliJ team might have to handle 
better in their debug view/rendering, I guess. I see this as neither 
specific to BigDecimal nor as a bug in this implementation. I believe 
any similar class will run into similar problems for cases like these 
where the instance isn't yet fully initialized to be presented in the 
debug view.

-Jaikiran



From david.holmes at oracle.com  Wed Jun 20 06:19:50 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Jun 2018 16:19:50 +1000
Subject: Comment about JDK-8204458 - BigDecimal toString() return
 different value when use idea run and debug
In-Reply-To: <d275037d-cf3a-6773-8004-7e4e6cdd7832@gmail.com>
References: <d275037d-cf3a-6773-8004-7e4e6cdd7832@gmail.com>
Message-ID: <b2333151-d414-7082-8ee6-15ec1373c9a1@oracle.com>

Thanks for that analysis Jaikiran! Very helpful.

I've added your mail in full as a comment on the JIRA issue. You need to 
be an OpenJDK Author (and so have an OpenJDK user name) to comment 
directly in bugs.openjdk.java.net

BTW the best email list to comment on JBS issues is the one that 
corresponds to the bug category in JBS. In this case 
core-libs-dev at openjdk.java.net

Cheers,
David

On 20/06/2018 3:13 PM, Jaikiran Pai wrote:
> (I don't have permissions to comment on the JIRA nor do I see a way to 
> submit a comment, as a casual observer, to a bug opened by someone else 
> through https://bugs.java.com/. So posting it here. I thought of sending 
> it to "discuss" list instead of this one, but this felt more 
> appropriate. I hope that's OK.)
> 
> As noted in the JIRA https://bugs.openjdk.java.net/browse/JDK-8204458 
> the following simple code:
> 
> public static void main(final String[] args) throws Exception {
>  ??????? final BigDecimal bd = new BigDecimal("1");
>  ??????? System.out.println(bd.toString());
> }
> 
> returns an "incorrect" output ("0") when run in debug mode with a 
> breakpoint in IntelliJ IDE. Apparently not reproducible in other IDEs. I 
> use IntelliJ, so gave it a quick try and indeed it does return "0" in a 
> specific scenario. What actually triggers this and reproduces this, is 
> the combination of 2 things:
> 
> - The breakpoint has to be in the constructor of the BigDecimal class 
> (which is what the OP has done in that JIRA)
> - The fact that the toString() implementation of this class uses a 
> "stringCache"
> 
> What's really happening (in IntelliJ) is that when the IDE stops at that 
> breakpoint, i.e. when the class instance isn't yet fully initialized, 
> the IDE tries to render a IDE specific "Variables" view/window, where it 
> displays the object instance details. To do so, it internally (in the 
> background) appears to be triggering a toString() call on that instance 
> being displayed. Effectively, what's happening is that the toString() 
> implementation of this BigDecimal class goes and builds up a 
> "stringCache" using an uninitialized/partially initialized state of this 
> instance (which is still not finished in its constructor) and ends up 
> storing an incorrect value of "0" to this "stringCache". As a result, 
> the subsequent calls to toString(), even after the object is fully 
> initialized return this incorrectly computed/cached value.
> 
> This appears to be something the IntelliJ team might have to handle 
> better in their debug view/rendering, I guess. I see this as neither 
> specific to BigDecimal nor as a bug in this implementation. I believe 
> any similar class will run into similar problems for cases like these 
> where the instance isn't yet fully initialized to be presented in the 
> debug view.
> 
> -Jaikiran
> 
> 

From jai.forums2013 at gmail.com  Wed Jun 20 06:30:55 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 20 Jun 2018 12:00:55 +0530
Subject: Comment about JDK-8204458 - BigDecimal toString() return
 different value when use idea run and debug
In-Reply-To: <b2333151-d414-7082-8ee6-15ec1373c9a1@oracle.com>
References: <d275037d-cf3a-6773-8004-7e4e6cdd7832@gmail.com>
 <b2333151-d414-7082-8ee6-15ec1373c9a1@oracle.com>
Message-ID: <6fde6330-e12c-dd8a-96ec-0fc5fc87dee3@gmail.com>


On 20/06/18 11:49 AM, David Holmes wrote:
> Thanks for that analysis Jaikiran! Very helpful.
>
> I've added your mail in full as a comment on the JIRA issue. 

Thanks David!

>
> BTW the best email list to comment on JBS issues is the one that 
> corresponds to the bug category in JBS.
That's helpful, thank you!

-Jaikiran


> In this case core-libs-dev at openjdk.java.net
>
> Cheers,
> David
>
> On 20/06/2018 3:13 PM, Jaikiran Pai wrote:
>> (I don't have permissions to comment on the JIRA nor do I see a way 
>> to submit a comment, as a casual observer, to a bug opened by someone 
>> else through https://bugs.java.com/. So posting it here. I thought of 
>> sending it to "discuss" list instead of this one, but this felt more 
>> appropriate. I hope that's OK.)
>>
>> As noted in the JIRA https://bugs.openjdk.java.net/browse/JDK-8204458 
>> the following simple code:
>>
>> public static void main(final String[] args) throws Exception {
>> ???????? final BigDecimal bd = new BigDecimal("1");
>> ???????? System.out.println(bd.toString());
>> }
>>
>> returns an "incorrect" output ("0") when run in debug mode with a 
>> breakpoint in IntelliJ IDE. Apparently not reproducible in other 
>> IDEs. I use IntelliJ, so gave it a quick try and indeed it does 
>> return "0" in a specific scenario. What actually triggers this and 
>> reproduces this, is the combination of 2 things:
>>
>> - The breakpoint has to be in the constructor of the BigDecimal class 
>> (which is what the OP has done in that JIRA)
>> - The fact that the toString() implementation of this class uses a 
>> "stringCache"
>>
>> What's really happening (in IntelliJ) is that when the IDE stops at 
>> that breakpoint, i.e. when the class instance isn't yet fully 
>> initialized, the IDE tries to render a IDE specific "Variables" 
>> view/window, where it displays the object instance details. To do so, 
>> it internally (in the background) appears to be triggering a 
>> toString() call on that instance being displayed. Effectively, what's 
>> happening is that the toString() implementation of this BigDecimal 
>> class goes and builds up a "stringCache" using an 
>> uninitialized/partially initialized state of this instance (which is 
>> still not finished in its constructor) and ends up storing an 
>> incorrect value of "0" to this "stringCache". As a result, the 
>> subsequent calls to toString(), even after the object is fully 
>> initialized return this incorrectly computed/cached value.
>>
>> This appears to be something the IntelliJ team might have to handle 
>> better in their debug view/rendering, I guess. I see this as neither 
>> specific to BigDecimal nor as a bug in this implementation. I believe 
>> any similar class will run into similar problems for cases like these 
>> where the instance isn't yet fully initialized to be presented in the 
>> debug view.
>>
>> -Jaikiran
>>
>>


From thomas.stuefe at gmail.com  Wed Jun 20 13:04:36 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jun 2018 15:04:36 +0200
Subject: IntelliJ for jdk dev - question about idea.sh
Message-ID: <CAA-vtUxL_AEcuBb+zV5Rd+YB-Pwbfsd1CCfKYSVkqftz70nMAw@mail.gmail.com>

Hi all,

I am checking out IntelliJ as an alternative for jdk development.

A possibly stupid question, does the /bin/idea.sh project-build script
assume that we run configure from within the source directory?

In my workflow I always place the output directories outside the
source tree, and I would to keep it that way. I would even prefer the
.idea folder to live outside the source tree as well. Is that
possible?

Thank you,

Thomas

From Roger.Riggs at Oracle.com  Wed Jun 20 16:02:12 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 20 Jun 2018 12:02:12 -0400
Subject: CFV: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <6f7898cd-2f43-f7d6-286c-4d85dd734ae9@Oracle.com>

Vote: Yes

On 6/13/2018 12:40 PM, Volker Simonis wrote:
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.

From vicente.romero at oracle.com  Wed Jun 20 17:40:53 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 20 Jun 2018 13:40:53 -0400
Subject: CFV: New JDK Committer: Bernard Blaser
Message-ID: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>

I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.

Bernard is an international freelance software engineer. He was awarded
the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
JDK9. He has
contributed 13 changes within the last two years, mostly related to the 
backend area of javac.
A full list of his contributions can be found at [3].

Votes are due by 19:00 EDT July 4, 2018.

Only current JDK Committers [1] 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 [2].

Thank you and best regards,
Vicente

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote
[3] 
http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()

8202372: Diagnostic with incorrect line info generated when compiling 
lambda expression
8201440: javac should create unique DynamicMethodSymbols at LambdaToMethod
8196074: Remove uses of loose type equality tests
8063054: Incorrect raw type warning for method reference
8187978: javac can show overload error messages that include non-valid 
candidates
8173798: Tests for printing modules
8148100: Convert lambda most specific positive tests to check runtime 
behavior
8147527: Wrong code generated for postfix unary operators
8203338: Unboxing in return from lambda miscompiled to throw 
ClassCastExceptiondefault tip
8203813: javac accepts an illegal name as a receiver parameter name
8189335: javac exception when referencing private inner class with same 
name as normal class with dollar_1
8203398: Test 
test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
writes into the source directory
8202141: Unique symbols for .class

From vicente.romero at oracle.com  Wed Jun 20 17:42:33 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 20 Jun 2018 13:42:33 -0400
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <55060e91-b3d5-0564-6b5e-5ce0f2c3bae6@oracle.com>

vote: yes

Vicente

On 06/20/2018 01:40 PM, Vicente Romero wrote:
> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>
> Bernard is an international freelance software engineer. He was awarded
> the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
> JDK9. He has
> contributed 13 changes within the last two years, mostly related to 
> the backend area of javac.
> A full list of his contributions can be found at [3].
>
> Votes are due by 19:00 EDT July 4, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Vicente
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()
>
> 8202372: Diagnostic with incorrect line info generated when compiling 
> lambda expression
> 8201440: javac should create unique DynamicMethodSymbols at 
> LambdaToMethod
> 8196074: Remove uses of loose type equality tests
> 8063054: Incorrect raw type warning for method reference
> 8187978: javac can show overload error messages that include non-valid 
> candidates
> 8173798: Tests for printing modules
> 8148100: Convert lambda most specific positive tests to check runtime 
> behavior
> 8147527: Wrong code generated for postfix unary operators
> 8203338: Unboxing in return from lambda miscompiled to throw 
> ClassCastExceptiondefault tip
> 8203813: javac accepts an illegal name as a receiver parameter name
> 8189335: javac exception when referencing private inner class with 
> same name as normal class with dollar_1
> 8203398: Test 
> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
> writes into the source directory
> 8202141: Unique symbols for .class


From eric.caspole at oracle.com  Wed Jun 20 17:47:49 2018
From: eric.caspole at oracle.com (Eric Caspole)
Date: Wed, 20 Jun 2018 13:47:49 -0400
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <55060e91-b3d5-0564-6b5e-5ce0f2c3bae6@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
 <55060e91-b3d5-0564-6b5e-5ce0f2c3bae6@oracle.com>
Message-ID: <f48ff6f4-5cf3-86f4-c96c-78d0422aa3e3@oracle.com>

Vote: yes
Regards,
Eric

On 06/20/2018 01:42 PM, Vicente Romero wrote:
> vote: yes
> 
> Vicente
> 
> On 06/20/2018 01:40 PM, Vicente Romero wrote:
>> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>>
>> Bernard is an international freelance software engineer. He was awarded
>> the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
>> JDK9. He has
>> contributed 13 changes within the last two years, mostly related to 
>> the backend area of javac.
>> A full list of his contributions can be found at [3].
>>
>> Votes are due by 19:00 EDT July 4, 2018.
>>
>> Only current JDK Committers [1] 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 [2].
>>
>> Thank you and best regards,
>> Vicente
>>
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>> [3] 
>> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge() 
>>
>>
>> 8202372: Diagnostic with incorrect line info generated when compiling 
>> lambda expression
>> 8201440: javac should create unique DynamicMethodSymbols at 
>> LambdaToMethod
>> 8196074: Remove uses of loose type equality tests
>> 8063054: Incorrect raw type warning for method reference
>> 8187978: javac can show overload error messages that include non-valid 
>> candidates
>> 8173798: Tests for printing modules
>> 8148100: Convert lambda most specific positive tests to check runtime 
>> behavior
>> 8147527: Wrong code generated for postfix unary operators
>> 8203338: Unboxing in return from lambda miscompiled to throw 
>> ClassCastExceptiondefault tip
>> 8203813: javac accepts an illegal name as a receiver parameter name
>> 8189335: javac exception when referencing private inner class with 
>> same name as normal class with dollar_1
>> 8203398: Test 
>> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
>> writes into the source directory
>> 8202141: Unique symbols for .class
> 

From jan.lahoda at oracle.com  Wed Jun 20 18:23:54 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 20 Jun 2018 20:23:54 +0200
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <5B2A9BBA.9020608@oracle.com>

vote: yes

Jan

On 20.6.2018 19:40, Vicente Romero wrote:
> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>
> Bernard is an international freelance software engineer. He was awarded
> the Swiss Engineering Award 2005 and has been an OpenJDK Author since
> JDK9. He has
> contributed 13 changes within the last two years, mostly related to the
> backend area of javac.
> A full list of his contributions can be found at [3].
>
> Votes are due by 19:00 EDT July 4, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Vicente
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()
>
>
> 8202372: Diagnostic with incorrect line info generated when compiling
> lambda expression
> 8201440: javac should create unique DynamicMethodSymbols at LambdaToMethod
> 8196074: Remove uses of loose type equality tests
> 8063054: Incorrect raw type warning for method reference
> 8187978: javac can show overload error messages that include non-valid
> candidates
> 8173798: Tests for printing modules
> 8148100: Convert lambda most specific positive tests to check runtime
> behavior
> 8147527: Wrong code generated for postfix unary operators
> 8203338: Unboxing in return from lambda miscompiled to throw
> ClassCastExceptiondefault tip
> 8203813: javac accepts an illegal name as a receiver parameter name
> 8189335: javac exception when referencing private inner class with same
> name as normal class with dollar_1
> 8203398: Test
> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java
> writes into the source directory
> 8202141: Unique symbols for .class

From maurizio.cimadamore at oracle.com  Wed Jun 20 20:08:43 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 20 Jun 2018 21:08:43 +0100
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <b1288f49-4333-f572-d7dd-32a136a49502@oracle.com>

Vote: yes!

Maurizio


On 20/06/18 18:40, Vicente Romero wrote:
> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>
> Bernard is an international freelance software engineer. He was awarded
> the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
> JDK9. He has
> contributed 13 changes within the last two years, mostly related to 
> the backend area of javac.
> A full list of his contributions can be found at [3].
>
> Votes are due by 19:00 EDT July 4, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Vicente
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()
>
> 8202372: Diagnostic with incorrect line info generated when compiling 
> lambda expression
> 8201440: javac should create unique DynamicMethodSymbols at 
> LambdaToMethod
> 8196074: Remove uses of loose type equality tests
> 8063054: Incorrect raw type warning for method reference
> 8187978: javac can show overload error messages that include non-valid 
> candidates
> 8173798: Tests for printing modules
> 8148100: Convert lambda most specific positive tests to check runtime 
> behavior
> 8147527: Wrong code generated for postfix unary operators
> 8203338: Unboxing in return from lambda miscompiled to throw 
> ClassCastExceptiondefault tip
> 8203813: javac accepts an illegal name as a receiver parameter name
> 8189335: javac exception when referencing private inner class with 
> same name as normal class with dollar_1
> 8203398: Test 
> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
> writes into the source directory
> 8202141: Unique symbols for .class


From jonathan.gibbons at oracle.com  Wed Jun 20 21:07:59 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 20 Jun 2018 14:07:59 -0700
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <ed90edb1-e7f0-9887-7889-5144e7569221@oracle.com>

Vote: yes


On 6/20/18 10:40 AM, Vicente Romero wrote:
> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>
> Bernard is an international freelance software engineer. He was awarded
> the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
> JDK9. He has
> contributed 13 changes within the last two years, mostly related to 
> the backend area of javac.
> A full list of his contributions can be found at [3].
>
> Votes are due by 19:00 EDT July 4, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Vicente
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()
>
> 8202372: Diagnostic with incorrect line info generated when compiling 
> lambda expression
> 8201440: javac should create unique DynamicMethodSymbols at 
> LambdaToMethod
> 8196074: Remove uses of loose type equality tests
> 8063054: Incorrect raw type warning for method reference
> 8187978: javac can show overload error messages that include non-valid 
> candidates
> 8173798: Tests for printing modules
> 8148100: Convert lambda most specific positive tests to check runtime 
> behavior
> 8147527: Wrong code generated for postfix unary operators
> 8203338: Unboxing in return from lambda miscompiled to throw 
> ClassCastExceptiondefault tip
> 8203813: javac accepts an illegal name as a receiver parameter name
> 8189335: javac exception when referencing private inner class with 
> same name as normal class with dollar_1
> 8203398: Test 
> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
> writes into the source directory
> 8202141: Unique symbols for .class


From vyom.tewari at oracle.com  Thu Jun 21 02:45:57 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 21 Jun 2018 08:15:57 +0530
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <61a78ba2-7f35-4516-76c3-6ead631d30fd@oracle.com>

vote: yes


On Wednesday 20 June 2018 11:10 PM, Vicente Romero wrote:
> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>
> Bernard is an international freelance software engineer. He was awarded
> the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
> JDK9. He has
> contributed 13 changes within the last two years, mostly related to 
> the backend area of javac.
> A full list of his contributions can be found at [3].
>
> Votes are due by 19:00 EDT July 4, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Vicente
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()
>
> 8202372: Diagnostic with incorrect line info generated when compiling 
> lambda expression
> 8201440: javac should create unique DynamicMethodSymbols at 
> LambdaToMethod
> 8196074: Remove uses of loose type equality tests
> 8063054: Incorrect raw type warning for method reference
> 8187978: javac can show overload error messages that include non-valid 
> candidates
> 8173798: Tests for printing modules
> 8148100: Convert lambda most specific positive tests to check runtime 
> behavior
> 8147527: Wrong code generated for postfix unary operators
> 8203338: Unboxing in return from lambda miscompiled to throw 
> ClassCastExceptiondefault tip
> 8203813: javac accepts an illegal name as a receiver parameter name
> 8189335: javac exception when referencing private inner class with 
> same name as normal class with dollar_1
> 8203398: Test 
> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
> writes into the source directory
> 8202141: Unique symbols for .class


From maurizio.cimadamore at oracle.com  Thu Jun 21 10:18:19 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Jun 2018 11:18:19 +0100
Subject: IntelliJ for jdk dev - question about idea.sh
In-Reply-To: <CAA-vtUxL_AEcuBb+zV5Rd+YB-Pwbfsd1CCfKYSVkqftz70nMAw@mail.gmail.com>
References: <CAA-vtUxL_AEcuBb+zV5Rd+YB-Pwbfsd1CCfKYSVkqftz70nMAw@mail.gmail.com>
Message-ID: <dbacbb0f-47b2-1a7b-cd27-e418fec08d46@oracle.com>



On 20/06/18 14:04, Thomas St?fe wrote:
> Hi all,
>
> I am checking out IntelliJ as an alternative for jdk development.
>
> A possibly stupid question, does the /bin/idea.sh project-build script
> assume that we run configure from within the source directory?
Right now yes, it does assume that.
>
> In my workflow I always place the output directories outside the
> source tree, and I would to keep it that way. I would even prefer the
> .idea folder to live outside the source tree as well. Is that
> possible?
It is a very reasonable request. I think we are talking about three 
variables:

* path to JDK root (this is needed to find the sources)

* path to .idea output

* path to build output (needed for spec.gmk and also for generated sources)

Maurizio
>
> Thank you,
>
> Thomas


From bhanu.prakash.gopularam at oracle.com  Thu Jun 21 10:29:01 2018
From: bhanu.prakash.gopularam at oracle.com (bhanu.prakash.gopularam at oracle.com)
Date: Thu, 21 Jun 2018 15:59:01 +0530
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <ebc57fb8-b679-bbe7-f7af-135f58d51bd3@oracle.com>

vote: yes

Bhanu Prakash

On 06/20/2018 11:10 PM, Vicente Romero wrote:
> I hereby nominate Bernard Blaser (bsrbnd) to JDK Committer.
>
> Bernard is an international freelance software engineer. He was awarded
> the Swiss Engineering Award 2005 and has been an OpenJDK Author since 
> JDK9. He has
> contributed 13 changes within the last two years, mostly related to 
> the backend area of javac.
> A full list of his contributions can be found at [3].
>
> Votes are due by 19:00 EDT July 4, 2018.
>
> Only current JDK Committers [1] 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 [2].
>
> Thank you and best regards,
> Vicente
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(bsrbnd)+or+desc(%22bsrbnd at gmail.com%22))+and+not+merge()
>
> 8202372: Diagnostic with incorrect line info generated when compiling 
> lambda expression
> 8201440: javac should create unique DynamicMethodSymbols at 
> LambdaToMethod
> 8196074: Remove uses of loose type equality tests
> 8063054: Incorrect raw type warning for method reference
> 8187978: javac can show overload error messages that include non-valid 
> candidates
> 8173798: Tests for printing modules
> 8148100: Convert lambda most specific positive tests to check runtime 
> behavior
> 8147527: Wrong code generated for postfix unary operators
> 8203338: Unboxing in return from lambda miscompiled to throw 
> ClassCastExceptiondefault tip
> 8203813: javac accepts an illegal name as a receiver parameter name
> 8189335: javac exception when referencing private inner class with 
> same name as normal class with dollar_1
> 8203398: Test 
> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java 
> writes into the source directory
> 8202141: Unique symbols for .class


From dalibor.topic at oracle.com  Thu Jun 21 10:43:11 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 21 Jun 2018 12:43:11 +0200
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <41f8b2c7-bb46-896b-68a8-a2082a39b86e@oracle.com>

Vote: Yes.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+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

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From thomas.stuefe at gmail.com  Thu Jun 21 10:56:43 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 21 Jun 2018 12:56:43 +0200
Subject: IntelliJ for jdk dev - question about idea.sh
In-Reply-To: <dbacbb0f-47b2-1a7b-cd27-e418fec08d46@oracle.com>
References: <CAA-vtUxL_AEcuBb+zV5Rd+YB-Pwbfsd1CCfKYSVkqftz70nMAw@mail.gmail.com>
 <dbacbb0f-47b2-1a7b-cd27-e418fec08d46@oracle.com>
Message-ID: <CAA-vtUz4cZ+Fa7igaJ3oZ3HHg9139o74acvZCBEweYQgXAPE0g@mail.gmail.com>

Hi Maurizio,

On Thu, Jun 21, 2018 at 12:18 PM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> On 20/06/18 14:04, Thomas St?fe wrote:
>>
>> Hi all,
>>
>> I am checking out IntelliJ as an alternative for jdk development.
>>
>> A possibly stupid question, does the /bin/idea.sh project-build script
>> assume that we run configure from within the source directory?
>
> Right now yes, it does assume that.
>>
>>
>> In my workflow I always place the output directories outside the
>> source tree, and I would to keep it that way. I would even prefer the
>> .idea folder to live outside the source tree as well. Is that
>> possible?
>
> It is a very reasonable request. I think we are talking about three
> variables:
>
> * path to JDK root (this is needed to find the sources)
>
> * path to .idea output
>
> * path to build output (needed for spec.gmk and also for generated sources)
>

Yes. But I think I could even live with the .idea folder living inside
the source root and just adding it to .hgignore - if cutting down
configuration variants helps to reduce the complexity.

But allowing for separate output folders would be very helpful, since
this setup is deeply ingrained in me. It is also quite common with me
and my coworkers.

Thank you!

...Thomas

> Maurizio

>>
>>
>> Thank you,
>>
>> Thomas
>
>

From mark.reinhold at oracle.com  Thu Jun 21 15:10:59 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 21 Jun 2018 08:10:59 -0700
Subject: Process JEP proposed for review: 3: JDK Release Process
Message-ID: <20180621081059.261252153@eggemoggin.niobe.net>

Thanks to those who sent comments on the draft version of this JEP.
I?ve moved it along to the Candidate state:

  3: JDK Release Process
     http://openjdk.java.net/jeps/3

Further comment is invited.  If no objections are raised by 16:00 UTC
next Thursday, 28 June, or if they're raised and then satisfactorily
answered, then per the JEP 2.0 process proposal [1] I'll mark this
process JEP as active, and this is the process that we?ll use for
JDK 11 and beyond.

(JBS does not (yet) implement the "process" 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 mark.reinhold at oracle.com  Thu Jun 21 23:06:56 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 21 Jun 2018 16:06:56 -0700
Subject: JEP proposed to target JDK 11: 332: Transport Layer Security
 (TLS) 1.3
In-Reply-To: <20180614220109.74F231DD1B1@eggemoggin.niobe.net>
References: <20180614220109.74F231DD1B1@eggemoggin.niobe.net>
Message-ID: <20180621160656.704475248@eggemoggin.niobe.net>

2018/6/14 15:01:09 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   332: Transport Layer Security (TLS) 1.3
>        http://openjdk.java.net/jeps/332
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 21 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark

From bradford.wetmore at oracle.com  Thu Jun 21 23:20:10 2018
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 21 Jun 2018 16:20:10 -0700
Subject: Result: New jdk-dev Reviewer: Rajan Halade
Message-ID: <5c82da7e-caee-ce6e-c417-60b94aa89133@oracle.com>

Voting for Rajan Halade [1] is now closed.

Yes: 24
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is
sufficient to approve the nomination.

Brad Wetmore
(filling in for Sean Mullan, the original nominator)

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001311.html


From mark.reinhold at oracle.com  Fri Jun 22 16:42:11 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 22 Jun 2018 09:42:11 -0700 (PDT)
Subject: JDK 11 enters Rampdown Phase One next week
Message-ID: <20180622164211.175291DE18E@eggemoggin.niobe.net>

JDK 11 enters Rampdown Phase One next week, on Thursday, 28 June.
Changes intended for JDK 11 should be in the main-line repository
(http://hg.openjdk.java.net/jdk/jdk) or the client repository
(jdk/client), by 15:00 UTC on that day [1].

At that time we?ll fork jdk/jdk to the JDK 11 stabilization repository,
jdk/jdk11, and promote next week?s build (jdk-11+20) and all remaining
JDK 11 builds from there.

We'll semi-automatically merge changes pushed to jdk/jdk11 into the
main-line jdk/jdk repository, as we did for the transitions from 9
to 10 and 10 to 11.  This means that:

  - If you make a change in JDK 11 then you needn't do any extra
    work to get it into the main line, though if a merge conflict
    arises then you might be asked to help resolve it.

  - If you need to make a change in both JDK 11 and the main line
    then just push it to JDK 11, and wait for the automatic merge
    to complete.

Changes pushed into the jdk/jdk or jdk/client repositories after 15:00
UTC next Thursday will be destined for JDK 12 unless they're back-ported.

The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
We?ll set up a jdk/submit11 repo for jdk/jdk11 work.

The Rampdown Phase One process will be similar to that of JDK 10,
as proposed in JEP 3 [2].

- Mark


[1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Rampdown+Phase+One&iso=20180628T15
[2] http://openjdk.java.net/jeps/3

From joe.darcy at oracle.com  Fri Jun 22 17:03:57 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 22 Jun 2018 10:03:57 -0700
Subject: Reminder: avoid hard-coding release values in regression tests
Message-ID: <c4761ffb-8e6e-9e66-6ba3-410e6d7a5759@oracle.com>

Hello,

With the JDK 11 and JDK 12 split coming soon [1], work has begun on 
preparing the JDK 12 b01 changes to increment the version number, add 12 
as an option to javac's -source and -target options, etc.

This effort has revealed a number of regression tests which hard-code 
release values in various ways.

Please avoid this technique except when strictly necessary as it 
increases the maintenance cost of starting a new JDK release. Prefer to 
query the current release programmatically and dynamically construct 
earlier and later release values as needed.

Cheers,

-Joe

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html


From jini at zeus.net.au  Sat Jun 23 01:51:08 2018
From: jini at zeus.net.au (Peter)
Date: Sat, 23 Jun 2018 11:51:08 +1000
Subject: JDK-8161256
Message-ID: <5B2DA78C.2090100@zeus.net.au>

Will a JEP be created for general data in constant pools?

CONSTANT_Bytes - tag byte 2
CONSTANT_Group - tag byte 13

The attraction of allowing general data in constant pools, is that it 
may stabilise the constant pool, there have been a number of additions 
to the constant pool since Java 8 and this feature, while adding two 
more constants, reduces future need or motivation for growing the 
constant pool.

It's my understanding that Java 11 will be a long term support release, 
like Java 8.   Will this be added in Java 12?

Thanks,

Peter.

From serguei.spitsyn at oracle.com  Sun Jun 24 06:58:49 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Sat, 23 Jun 2018 23:58:49 -0700
Subject: CFV: New JDK Committer: Bernard Blaser
In-Reply-To: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
References: <23a6c6b0-355f-1c09-1c5c-058709f5cadf@oracle.com>
Message-ID: <7b918d60-5633-eb83-80ce-1d2426869baf@oracle.com>

Vote: yes

From martijnverburg at gmail.com  Mon Jun 25 10:49:23 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 25 Jun 2018 11:49:23 +0100
Subject: JDK-8161256
In-Reply-To: <5B2DA78C.2090100@zeus.net.au>
References: <5B2DA78C.2090100@zeus.net.au>
Message-ID: <CAP7YuATDOwxBQVosa0ps5PQqpvf4HxEHCo4GW=yhsiP8iZDzpA@mail.gmail.com>

Hi Peter,

I think this idea / discussion is probably better suited to the
valhalla-dev mailing list.  It might be worth fleshing our your proposal a
bit as well before bringing it there.

Cheers,
Martijn


On Sat, 23 Jun 2018 at 02:51, Peter <jini at zeus.net.au> wrote:

> Will a JEP be created for general data in constant pools?
>
> CONSTANT_Bytes - tag byte 2
> CONSTANT_Group - tag byte 13
>
> The attraction of allowing general data in constant pools, is that it
> may stabilise the constant pool, there have been a number of additions
> to the constant pool since Java 8 and this feature, while adding two
> more constants, reduces future need or motivation for growing the
> constant pool.
>
> It's my understanding that Java 11 will be a long term support release,
> like Java 8.   Will this be added in Java 12?
>
> Thanks,
>
> Peter.
>

From daniel_megert at ch.ibm.com  Mon Jun 25 15:54:48 2018
From: daniel_megert at ch.ibm.com (Daniel Megert)
Date: Mon, 25 Jun 2018 17:54:48 +0200
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <OF6EDDF924.D785F334-ONC12582AD.0025A0D7-C12582AD.0025AE01@LocalDomain>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
 <OF6EDDF924.D785F334-ONC12582AD.0025A0D7-C12582AD.0025AE01@LocalDomain>
Message-ID: <OF98CD575C.796ECEE4-ONC12582B7.0057068F-C12582B7.00576A5B@notes.na.collabserv.com>

Sorry, didn't see your reply.

> Is Eclipse willing to sign up to maintain this technology?

If someone steps up to do so, yes. I think Peter has interest to do so. 
The question is: is it legally allowed to implement and ship a deprecated 
specification?

Dani



From:   Daniel Megert/Zurich/IBM
To:     mark.reinhold at oracle.com
Date:   15.06.2018 08:51
Subject:        Re: JEP proposed to target JDK 11: 336: Deprecate the 
Pack200 Tools and API


Hi Mark

Can you please comment on 
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001382.html.

Dani




From:   mark.reinhold at oracle.com
To:     jdk-dev at openjdk.java.net
Date:   15.06.2018 01:07
Subject:        Re: JEP proposed to target JDK 11: 336: Deprecate the 
Pack200 Tools and API
Sent by:        "jdk-dev" <jdk-dev-bounces at openjdk.java.net>



2018/6/7 15:35:15 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   336: Deprecate the Pack200 Tools and API
>        
http://openjdk.java.net/jeps/336

> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 14 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

- Mark







From lenborje at gmail.com  Tue Jun 26 07:02:16 2018
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Tue, 26 Jun 2018 09:02:16 +0200
Subject: OpenJDK installers for Win/Mac?
Message-ID: <C98E4298-F645-40AE-80D0-94818A5B7F2D@gmail.com>

The early-access page for jdk 11 (http://jdk.java.net/11/ <http://jdk.java.net/11/>) links to installers for Mac and Windows for the Oracle JDK build, but the OpenJDK builds are plain archives only.

The installers provide additional platform-specific integration (e.g. the /usr/lib_exec/java_home utility on Mac, and various other integration tools on both platforms).

The OpenJDK build would surely benefit from this additional integration, too.

Is this a temporary oversight or intentional? Will OpenJDK get installers?

/Lennart

From forax at univ-mlv.fr  Tue Jun 26 07:16:28 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 26 Jun 2018 09:16:28 +0200 (CEST)
Subject: OpenJDK installers for Win/Mac?
In-Reply-To: <C98E4298-F645-40AE-80D0-94818A5B7F2D@gmail.com>
References: <C98E4298-F645-40AE-80D0-94818A5B7F2D@gmail.com>
Message-ID: <626287428.455997.1529997388095.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Lennart B?rjeson" <lenborje at gmail.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Mardi 26 Juin 2018 09:02:16
> Objet: OpenJDK installers for Win/Mac?

> The early-access page for jdk 11 (http://jdk.java.net/11/
> <http://jdk.java.net/11/>) links to installers for Mac and Windows for the
> Oracle JDK build, but the OpenJDK builds are plain archives only.
> 
> The installers provide additional platform-specific integration (e.g. the
> /usr/lib_exec/java_home utility on Mac, and various other integration tools on
> both platforms).
> 
> The OpenJDK build would surely benefit from this additional integration, too.

i hope not, it will make CI configurations, image building scripts, etc less regular, so more complex than they should be.

> 
> Is this a temporary oversight or intentional? Will OpenJDK get installers?
> 
> /Lennart

Remi

From sven.reimers at gmail.com  Tue Jun 26 10:51:48 2018
From: sven.reimers at gmail.com (Sven Reimers)
Date: Tue, 26 Jun 2018 12:51:48 +0200
Subject: OpenJDK installers for Win/Mac?
In-Reply-To: <626287428.455997.1529997388095.JavaMail.zimbra@u-pem.fr>
References: <C98E4298-F645-40AE-80D0-94818A5B7F2D@gmail.com>
 <626287428.455997.1529997388095.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAP+Jvx6zJf4Op_2GJqiP-+2WMXyYeVELqZTuB2wCeeoTtgMFAA@mail.gmail.com>

Hi,

I remembered asking that question a while back on twitter... read the
answer from @DonaldOJDK

https://twitter.com/DonaldOJDK/status/976581576497614849?s=09

-Sven



Remi Forax <forax at univ-mlv.fr> schrieb am Di., 26. Juni 2018, 10:47:

> ----- Mail original -----
> > De: "Lennart B?rjeson" <lenborje at gmail.com>
> > ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> > Envoy?: Mardi 26 Juin 2018 09:02:16
> > Objet: OpenJDK installers for Win/Mac?
>
> > The early-access page for jdk 11 (http://jdk.java.net/11/
> > <http://jdk.java.net/11/>) links to installers for Mac and Windows for
> the
> > Oracle JDK build, but the OpenJDK builds are plain archives only.
> >
> > The installers provide additional platform-specific integration (e.g. the
> > /usr/lib_exec/java_home utility on Mac, and various other integration
> tools on
> > both platforms).
> >
> > The OpenJDK build would surely benefit from this additional integration,
> too.
>
> i hope not, it will make CI configurations, image building scripts, etc
> less regular, so more complex than they should be.
>
> >
> > Is this a temporary oversight or intentional? Will OpenJDK get
> installers?
> >
> > /Lennart
>
> Remi
>

From dalibor.topic at oracle.com  Tue Jun 26 11:51:21 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Tue, 26 Jun 2018 13:51:21 +0200
Subject: OpenJDK installers for Win/Mac?
In-Reply-To: <C98E4298-F645-40AE-80D0-94818A5B7F2D@gmail.com>
References: <C98E4298-F645-40AE-80D0-94818A5B7F2D@gmail.com>
Message-ID: <f6d3b4bd-ccdf-027e-a07d-64cff59b2278@oracle.com>



On 26.06.2018 09:02, Lennart B?rjeson wrote:
> The early-access page for jdk 11 (http://jdk.java.net/11/ <http://jdk.java.net/11/>) links to installers for Mac and Windows for the Oracle JDK build, but the OpenJDK builds are plain archives only.
> 
> The installers provide additional platform-specific integration (e.g. the /usr/lib_exec/java_home utility on Mac, and various other integration tools on both platforms).
> 
> The OpenJDK build would surely benefit from this additional integration, too.
> 
> Is this a temporary oversight or intentional? Will OpenJDK get installers?

It's intentional - the source code for the installers hasn't been made 
open source yet. First things first. ;)

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+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

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From ksrinifmt at gmail.com  Tue Jun 26 13:50:35 2018
From: ksrinifmt at gmail.com (Kumar Srinivasan)
Date: Tue, 26 Jun 2018 06:50:35 -0700
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <5B20EF57.4070704@zeus.net.au>
References: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
 <5B20EF57.4070704@zeus.net.au>
Message-ID: <CAEXt0tQ5-FwyD8cAhS5VMb5+Pv4GcAid4GkVu9MkMKs4=-0e9g@mail.gmail.com>

Hi Peter,

There are two parts to Pack200 (maybe three), what you looked at is
unpack200(.exe), a C++
native decoder or the unpacker, this is primarily used by the JDK
installers to break the
bootstrap, ie. the  chicken/egg problem.

FWIW, the complete coder and decoder implementations in Java  are available
at:
http://hg.openjdk.java.net/jdk/jdk/file/2f2af62dfac7/src/java.base/share/classes/com/sun/java/util/jar/pack

Hope this helps.

Regards
Kumar Srinivasan


On Wed, Jun 13, 2018 at 9:12 AM Peter Firmstone <peter.firmstone at zeus.net.au>
wrote:

> Hi Daniel,
>
> I had a look at the pack200 code in openjdk, it's written in c++, and
> looks a little painful to maintain.  I also had a look at Apache
> Harmony's implementation, written in Java, it uses the ASM byte code
> library and it's also already an OSGi Bundle.  It's still only at
> bytecode version 1.6, but it's going to be a lot easier to maintain in
> the long term.
>
> https://github.com/pfirmstone/pack200
>
> Cheers,
>
> Peter.
>
> On 13/06/2018 6:50 AM, Daniel Megert wrote:
> > pack200 is used by the Eclipse update manager a.k.a. p2. The JARed
> > plug-ins are compressed with pack200 and put into a p2 repository.
> > Removing pack200 will make the download (and hence install) of plug-ins
> > much slower. Eclipse would therefore like to keep this technology. If
> > that's not an option, then we would like that the removal does not happen
> > before Java 13.
> >
> > Dani
> > Eclipse PMC
> >
>
>

From mark.reinhold at oracle.com  Tue Jun 26 18:04:17 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 26 Jun 2018 11:04:17 -0700
Subject: New candidate JEP: 336: Deprecate the Pack200 Tools and API
In-Reply-To: <5B29948E.5060400@zeus.net.au>
References: <OF543C3950.0C996683-ONC12582AA.00719066-C12582AA.00727FA2@notes.na.collabserv.com>
 <20180615072517.55245716@eggemoggin.niobe.net> <5B29948E.5060400@zeus.net.au>
Message-ID: <20180626110417.157160738@eggemoggin.niobe.net>

2018/6/19 16:41:02 -0700, Peter <jini at zeus.net.au>:
> Mark,
> 
> Can Oracle deprecate the implementation but allow the development of the 
> specification to continue?
> 
> ...
> 
> If Java can retain the api and specification (and support the 
> specification) while deprecating the current implmentation, then the 
> community can use the existing provider mechanism to load any 
> implementation.

In general, I don?t think it makes a lot of sense for the platform to
include a complex specification with no implementation.  (Yes, there are
historical exceptions such as JDBC, but those were created in a very
different time.)

An API in the platform that requires an external component in order to
work is little more than a tease to developers who just want to get the
job done.  It makes for a weaker compatibility story, since the JCK
can?t test an external implementation.  Finally, it requires even more
effort on the part of those who sign up to do the maintenance work,
since now the specification and the implementation are in different
places.

- Mark

From mark.reinhold at oracle.com  Tue Jun 26 18:05:14 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 26 Jun 2018 11:05:14 -0700
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <OF98CD575C.796ECEE4-ONC12582B7.0057068F-C12582B7.00576A5B@notes.na.collabserv.com>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
 <OF6EDDF924.D785F334-ONC12582AD.0025A0D7-C12582AD.0025AE01@LocalDomain>
 <OF98CD575C.796ECEE4-ONC12582B7.0057068F-C12582B7.00576A5B@notes.na.collabserv.com>
Message-ID: <20180626110514.937844064@eggemoggin.niobe.net>

2018/6/25 8:54:48 -0700, daniel_megert at ch.ibm.com:
> Sorry, didn't see your reply.
> 
>> Is Eclipse willing to sign up to maintain this technology?
> 
> If someone steps up to do so, yes. I think Peter has interest to do so. 
> The question is: is it legally allowed to implement and ship a deprecated 
> specification?

That?s a legal question, which I?m not qualified to answer.

- Mark

From mark.reinhold at oracle.com  Tue Jun 26 23:02:52 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 26 Jun 2018 16:02:52 -0700
Subject: JEP proposed to target JDK 11: 335: Deprecate the Nashorn
 JavaScript Engine
In-Reply-To: <20180619210632.A1D801DDAB6@eggemoggin.niobe.net>
References: <20180619210632.A1D801DDAB6@eggemoggin.niobe.net>
Message-ID: <20180626160252.850665809@eggemoggin.niobe.net>

2018/6/19 14:06:32 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   335: Deprecate the Nashorn JavaScript Engine
>        http://openjdk.java.net/jeps/335
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Tuesday,
> 26 June, 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.

Hearing no objections, I?ve targeted this JEP to JDK 11.

As I noted in a previous message [1], there?s still plenty of time for
others to step up to take on the maintenance of Nashorn after JDK 11.
This JEP will only deprecate Nashorn -- it won?t remove it.

- Mark


[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001381.html

From daniel_megert at ch.ibm.com  Wed Jun 27 13:24:17 2018
From: daniel_megert at ch.ibm.com (Daniel Megert)
Date: Wed, 27 Jun 2018 15:24:17 +0200
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <20180626110514.937844064@eggemoggin.niobe.net>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
 <OF6EDDF924.D785F334-ONC12582AD.0025A0D7-C12582AD.0025AE01@LocalDomain>
 <OF98CD575C.796ECEE4-ONC12582B7.0057068F-C12582B7.00576A5B@notes.na.collabserv.com>
 <20180626110514.937844064@eggemoggin.niobe.net>
Message-ID: <OF5C5B7627.49C53BE4-ONC12582B9.0048584C-C12582B9.0049A2D5@notes.na.collabserv.com>

Understood.

I tend to agree with your other comment about keeping the spec without 
shipping an implementation and JCK tests.

Dani



From:   mark.reinhold at oracle.com
To:     Daniel Megert <daniel_megert at ch.ibm.com>
Cc:     jdk-dev at openjdk.java.net
Date:   26.06.2018 20:05
Subject:        Re: JEP proposed to target JDK 11: 336: Deprecate the 
Pack200 Tools and API



2018/6/25 8:54:48 -0700, daniel_megert at ch.ibm.com:
> Sorry, didn't see your reply.
> 
>> Is Eclipse willing to sign up to maintain this technology?
> 
> If someone steps up to do so, yes. I think Peter has interest to do so. 
> The question is: is it legally allowed to implement and ship a 
deprecated 
> specification?

That?s a legal question, which I?m not qualified to answer.

- Mark






From gnu.andrew at redhat.com  Wed Jun 27 15:05:20 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Jun 2018 16:05:20 +0100
Subject: CFV: New OpenJDK Committer: Martin Balao
Message-ID: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>

I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.

Martin has already produced a number of valuable contributions to
OpenJDK [0], particularly in the security area, and has more pending review.
In an area that seems low on OpenJDK developers, I think we should
do our best to support such work.

Votes are due by 17h00 UTC on the 11th of July, 2018.

Only current OpenJDK Committers [1] 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 [2].

[0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
[1] http://openjdk.java.net/census#jdk
[2] http://openjdk.java.net/projects/#committer-vote
-- 
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 adinn at redhat.com  Wed Jun 27 15:19:10 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 27 Jun 2018 16:19:10 +0100
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <8b5dbd15-a074-daaf-cfa6-c008f3a64ca9@redhat.com>

Vote: yes

On 27/06/18 16:05, Andrew Hughes wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
> 
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
> 
> Votes are due by 17h00 UTC on the 11th of July, 2018.
> 
> Only current OpenJDK Committers [1] 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 [2].
> 
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote
> 

-- 
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From zgu at redhat.com  Wed Jun 27 15:22:32 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 27 Jun 2018 11:22:32 -0400
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <7eb238b5-293a-5dff-1b48-13c33f1137e2@redhat.com>

Vote: yes

-Zhengyu

On 06/27/2018 11:05 AM, Andrew Hughes wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
> 
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
> 
> Votes are due by 17h00 UTC on the 11th of July, 2018.
> 
> Only current OpenJDK Committers [1] 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 [2].
> 
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote
> 

From neugens at redhat.com  Wed Jun 27 15:26:08 2018
From: neugens at redhat.com (Mario Torre)
Date: Wed, 27 Jun 2018 17:26:08 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <CAJwKKmZw8_5vmY76ArCJOwtVNSoQcRLF=nyqZM0SMFuz7KW26A@mail.gmail.com>

Vote: Yes,

Cheers,
Mario

On Wed, Jun 27, 2018 at 5:05 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
>
> Votes are due by 17h00 UTC on the 11th of July, 2018.
>
> Only current OpenJDK Committers [1] 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 [2].
>
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From ivan.gerasimov at oracle.com  Wed Jun 27 15:59:03 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 27 Jun 2018 08:59:03 -0700
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <22194150-8eb6-6617-e7ff-a7dc47b2ea8c@oracle.com>

Vote: Yes


On 6/27/18 8:05 AM, Andrew Hughes wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
>
> Votes are due by 17h00 UTC on the 11th of July, 2018.
>
> Only current OpenJDK Committers [1] 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 [2].
>
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote

-- 
With kind regards,
Ivan Gerasimov


From vyom.tewari at oracle.com  Wed Jun 27 16:36:05 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Wed, 27 Jun 2018 22:06:05 +0530
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <849852cc-02ab-326b-cf4b-5d37e063cac3@oracle.com>

Vote: Yes


On Wednesday 27 June 2018 08:35 PM, Andrew Hughes wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
>
> Votes are due by 17h00 UTC on the 11th of July, 2018.
>
> Only current OpenJDK Committers [1] 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 [2].
>
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote


From gnu.andrew at redhat.com  Wed Jun 27 17:12:27 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Jun 2018 18:12:27 +0100
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <CABi63P6wY7Odd18E4zNgC1WDsKEgDew7mWsvj4W=o2hSj-xL+Q@mail.gmail.com>

On 27 June 2018 at 16:05, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
>
> Votes are due by 17h00 UTC on the 11th of July, 2018.
>
> Only current OpenJDK Committers [1] 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 [2].
>
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> 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

Vote: Yes
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From volker.simonis at gmail.com  Thu Jun 28 06:42:43 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 Jun 2018 08:42:43 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>

Hi Andrew,

I totally agree that we need more OpenJDK developers in the security
area and I'm sure Martin is a perfect fit for this role.

But the process document [1] clearly states that a "Contributor should
make at least eight significant contributions to that Project before
being nominated". From the references you've provided I can only see
five changes contributed by Martin. I'd therefore like to kindly ask
you to withdraw this CFV and postpone it until Martin has reached at
least the required minimum number of contributions.

Sorry for nit-picking, but I think we should all play by the same rules.

Best regards,
Volker

[1] http://openjdk.java.net/projects/#project-committer


On Wed, Jun 27, 2018 at 5:05 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
>
> Votes are due by 17h00 UTC on the 11th of July, 2018.
>
> Only current OpenJDK Committers [1] 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 [2].
>
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From volker.simonis at gmail.com  Thu Jun 28 07:39:29 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 Jun 2018 09:39:29 +0200
Subject: Result: New JDK Committer: Gustavo Romero
Message-ID: <CA+3eh12Tb6t=7hOqeqPCdgFJjhiSS8yD_iXxr-rkfkG4v1THEQ@mail.gmail.com>

Voting for Gustavo Romero [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Volker Simonis

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001387.html

From goetz.lindenmaier at sap.com  Thu Jun 28 08:27:24 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 28 Jun 2018 08:27:24 +0000
Subject: New JDK Committer: Gustavo Romero
In-Reply-To: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
References: <CA+3eh106cp6v0mw9KjcL807tTK6M+GsY02rg0oPQv9HoSShoLQ@mail.gmail.com>
Message-ID: <47a425eecddf4b8bb274278b4b315e3e@sap.com>

vote: yes

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of
> Volker Simonis
> Sent: Mittwoch, 13. Juni 2018 18:41
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Gustavo Romero
> 
> I hereby nominate Gustavo Romero (gromero) to JDK Committer.
> 
> Gustavo works for the Linux on Power team at IBM and has contributed
> 16 changes within the last two years, mostly related to supporting
> hardware transactional memory and NUMA support on ppc64. A full list
> of his contributions can be found at [3].
> 
> Votes are due by 19:00 CET June 27, 2018.
> 
> Only current JDK Committers [1] 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 [2].
> 
> Thank you and best regards,
> Volker
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(gromer
> o)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge()
> 
> 8164987: RTM jtreg tests failing due to unnamed module unable to
> access class jdk.internal.misc.Unsafe
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to
> non-optimized compilation
> 8171236: RTM/HTM jtreg tests regression after transition to the new
> GNU-style options
> 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
> 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA is used
> 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated
> bootstrap.url
> 8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
> 8201218: PPC64: Avoid use of yield instruction on spinlock
> 8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9
> 8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM
> detection for enabling RTM on Linux / POWER9"
> 8204136: jtreg: Fix failing RTM test RTMSpinLoopCount
> 8204134: jtreg: Fix RTM abort provoker for various tests after
> "8149159: Clean up Unsafe"
> 8150353: PPC64LE: Support RTM on linux
> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of
> illegal instructions
> 8154156: PPC64: improve array copy stubs by using vector instructions
> 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical
> section

From adinn at redhat.com  Thu Jun 28 08:44:58 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 28 Jun 2018 09:44:58 +0100
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
Message-ID: <ab5c4fbe-3c73-75da-d43b-6bd04638d03f@redhat.com>

On 28/06/18 07:42, Volker Simonis wrote:
> I totally agree that we need more OpenJDK developers in the security
> area and I'm sure Martin is a perfect fit for this role.
> 
> But the process document [1] clearly states that a "Contributor should
> make at least eight significant contributions to that Project before
> being nominated". From the references you've provided I can only see
> five changes contributed by Martin. I'd therefore like to kindly ask
> you to withdraw this CFV and postpone it until Martin has reached at
> least the required minimum number of contributions.
> 
> Sorry for nit-picking, but I think we should all play by the same rules.
Hmm, I don't believe that nit was picked quite thoroughly enough. The
process document clearly states a little more than what is cited above:

  As a rough guide, a Contributor should make at least eight significant
contributions to that Project before being nominated.

The leading phrase which you omitted is critical. This is guidance, not law.

You yourself admit that Martin is "a perfect fit for this role". It
seems to me a foolish waste of project time to force him to have to
obtain sponsors for his upcoming commits (as Andrew noted there are some
in the pipeline) when he is clearly ready to be able to commit changes
himself.

Perhaps you might withdraw your objection?

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 steve.hruda at gmail.com  Thu Jun 28 09:43:18 2018
From: steve.hruda at gmail.com (Steve Hruda)
Date: Thu, 28 Jun 2018 11:43:18 +0200
Subject: JDK-8204934 - OpenJDK - Windows - Digital Signatures
Message-ID: <CAHJxpfS6gPc5eiNC+_-eE2=2cUKsVYz7-AXK7G=5pdNMUHk4nw@mail.gmail.com>

Hi,
two weeks ago I opened a issue at Oracle's bug database which was confirmed
and available at bugs.java.com & bugs.openjdk.java.net.

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204934
https://bugs.openjdk.java.net/browse/JDK-8204934

Now it seems that the issue was deleted without any feedback.

My questions was related to the digital signatures of the official OpenJDK
zip.

All OracleJDK's *.exe and *.dll files have a valid Digital Signature but
the same files of the OpenJDK doesn't have one.

*e.g.: *java.dll & java.exe

Is that on purpose or is that an open issue which will be solved at the
final OpenJDK 11 build?

I asking because some end-users will be protected by Microsoft's AppLocker
which provides the possibility to define a whitelist of digital signatures.
Which means that *.dll's & *.exe files without an signature would be
blocked.

Best Regards,
Steve

From dalibor.topic at oracle.com  Thu Jun 28 09:59:23 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 28 Jun 2018 11:59:23 +0200
Subject: JDK-8204934 - OpenJDK - Windows - Digital Signatures
In-Reply-To: <CAHJxpfS6gPc5eiNC+_-eE2=2cUKsVYz7-AXK7G=5pdNMUHk4nw@mail.gmail.com>
References: <CAHJxpfS6gPc5eiNC+_-eE2=2cUKsVYz7-AXK7G=5pdNMUHk4nw@mail.gmail.com>
Message-ID: <f5250573-f9dd-e2f9-e380-92fe8dfca8e1@oracle.com>

On 28.06.2018 11:43, Steve Hruda wrote:
> Hi,
> two weeks ago I opened a issue at Oracle's bug database which was confirmed
> and available at bugs.java.com & bugs.openjdk.java.net.
> 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204934
> https://bugs.openjdk.java.net/browse/JDK-8204934
> 
> Now it seems that the issue was deleted without any feedback.

Ah, it only seems that way. It was marked as confidential at some point. 
I'll poke around to see what went wrong. Thanks for the ping.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+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

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From steve.hruda at gmail.com  Thu Jun 28 10:09:55 2018
From: steve.hruda at gmail.com (Steve Hruda)
Date: Thu, 28 Jun 2018 12:09:55 +0200
Subject: JDK-8204934 - OpenJDK - Windows - Digital Signatures
In-Reply-To: <f5250573-f9dd-e2f9-e380-92fe8dfca8e1@oracle.com>
References: <CAHJxpfS6gPc5eiNC+_-eE2=2cUKsVYz7-AXK7G=5pdNMUHk4nw@mail.gmail.com>
 <f5250573-f9dd-e2f9-e380-92fe8dfca8e1@oracle.com>
Message-ID: <CAHJxpfSNaGnyV5C1U9Zz0uWJ0pP2Jx-ROXXkafEp8rM2Jeejdw@mail.gmail.com>

Thanks Dalibor!

Am Do., 28. Juni 2018 um 11:59 Uhr schrieb dalibor topic <
dalibor.topic at oracle.com>:

> On 28.06.2018 11:43, Steve Hruda wrote:
> > Hi,
> > two weeks ago I opened a issue at Oracle's bug database which was
> confirmed
> > and available at bugs.java.com & bugs.openjdk.java.net.
> >
> > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204934
> > https://bugs.openjdk.java.net/browse/JDK-8204934
> >
> > Now it seems that the issue was deleted without any feedback.
>
> Ah, it only seems that way. It was marked as confidential at some point.
> I'll poke around to see what went wrong. Thanks for the ping.
>
> cheers,
> dalibor topic
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+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
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>


-- 
Mit freundlichen Gr??en
Steve Hruda

From thomas.stuefe at gmail.com  Thu Jun 28 12:07:03 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 28 Jun 2018 14:07:03 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <ab5c4fbe-3c73-75da-d43b-6bd04638d03f@redhat.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <ab5c4fbe-3c73-75da-d43b-6bd04638d03f@redhat.com>
Message-ID: <CAA-vtUyP=3G3T-L1nn3w3QB3T2Uf_Qaah4U6pqTsH+fCvKHefw@mail.gmail.com>

Hi Andrew,

I can see Volkers side.

To get the the short term benefit of quickly adding a developer and
saving some sponsoring work we risk long term erosion of a well
established voting process.

Needless to say, in no way has this to do with Martins value as a developer.

Kind Regards, Thomas

On Thu, Jun 28, 2018 at 10:44 AM, Andrew Dinn <adinn at redhat.com> wrote:
> On 28/06/18 07:42, Volker Simonis wrote:
>> I totally agree that we need more OpenJDK developers in the security
>> area and I'm sure Martin is a perfect fit for this role.
>>
>> But the process document [1] clearly states that a "Contributor should
>> make at least eight significant contributions to that Project before
>> being nominated". From the references you've provided I can only see
>> five changes contributed by Martin. I'd therefore like to kindly ask
>> you to withdraw this CFV and postpone it until Martin has reached at
>> least the required minimum number of contributions.
>>
>> Sorry for nit-picking, but I think we should all play by the same rules.
> Hmm, I don't believe that nit was picked quite thoroughly enough. The
> process document clearly states a little more than what is cited above:
>
>   As a rough guide, a Contributor should make at least eight significant
> contributions to that Project before being nominated.
>
> The leading phrase which you omitted is critical. This is guidance, not law.
>
> You yourself admit that Martin is "a perfect fit for this role". It
> seems to me a foolish waste of project time to force him to have to
> obtain sponsors for his upcoming commits (as Andrew noted there are some
> in the pipeline) when he is clearly ready to be able to commit changes
> himself.
>
> Perhaps you might withdraw your objection?
>
> 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 volker.simonis at gmail.com  Thu Jun 28 12:11:02 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 Jun 2018 14:11:02 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <ab5c4fbe-3c73-75da-d43b-6bd04638d03f@redhat.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <ab5c4fbe-3c73-75da-d43b-6bd04638d03f@redhat.com>
Message-ID: <CA+3eh12bXudo9=6y2hCws=jAoE1mP3ZrtW-ntpdbxOaiYsQ7=g@mail.gmail.com>

On Thu, Jun 28, 2018 at 10:44 AM, Andrew Dinn <adinn at redhat.com> wrote:
> On 28/06/18 07:42, Volker Simonis wrote:
>> I totally agree that we need more OpenJDK developers in the security
>> area and I'm sure Martin is a perfect fit for this role.
>>
>> But the process document [1] clearly states that a "Contributor should
>> make at least eight significant contributions to that Project before
>> being nominated". From the references you've provided I can only see
>> five changes contributed by Martin. I'd therefore like to kindly ask
>> you to withdraw this CFV and postpone it until Martin has reached at
>> least the required minimum number of contributions.
>>
>> Sorry for nit-picking, but I think we should all play by the same rules.
> Hmm, I don't believe that nit was picked quite thoroughly enough. The
> process document clearly states a little more than what is cited above:
>
>   As a rough guide, a Contributor should make at least eight significant
> contributions to that Project before being nominated.
>
> The leading phrase which you omitted is critical. This is guidance, not law.
>

Yes, you're right. But I always understood this sentence in the way
that "eight significant contributions" is an absolute minimum for
becoming a Committer.

> You yourself admit that Martin is "a perfect fit for this role". It
> seems to me a foolish waste of project time to force him to have to
> obtain sponsors for his upcoming commits (as Andrew noted there are some
> in the pipeline) when he is clearly ready to be able to commit changes
> himself.
>

Until now we (i.e. me and my colleagues from the SAP JVM team) always
accepted this overhead in order to conform with what we thought are
the general rules of the project. But maybe that was unnecessary and
naive?

> Perhaps you might withdraw your objection?
>

I "kindly asked" and specially did not vote with "Veto". So if you and
all the other voters think this vote is OK, I won't further object.

Thank you and best regards,
Volker

> 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 erik.osterlund at oracle.com  Thu Jun 28 12:24:40 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 28 Jun 2018 14:24:40 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <0AEE2F93-CF40-4B2B-BDF7-FAB29F3EE783@oracle.com>

Vote: yes

/Erik

> On 27 Jun 2018, at 17:05, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
> 
> Martin has already produced a number of valuable contributions to
> OpenJDK [0], particularly in the security area, and has more pending review.
> In an area that seems low on OpenJDK developers, I think we should
> do our best to support such work.
> 
> Votes are due by 17h00 UTC on the 11th of July, 2018.
> 
> Only current OpenJDK Committers [1] 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 [2].
> 
> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census#jdk
> [2] http://openjdk.java.net/projects/#committer-vote
> -- 
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From neugens.limasoftware at gmail.com  Thu Jun 28 12:30:59 2018
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 28 Jun 2018 14:30:59 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
Message-ID: <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>

Hi Volker,

I see your point, but I think this needs to be taken as a general
guidance and decided on a case by case basis, as it has been discussed
over and over. We should be looking instead at the quality of the
current contributions and what they mean to the general development of
the project rather than counting numbers. Or we can keep pushing
patches for Martin if you prefer, he's going to hit the 8 mark in 3
patches, then we can propose the nomination gain and the process will
be happy for the sake of being a process... We all agree here that
Martin is not only qualified, but he is a contributor that is doing
significant work in the area of security and cryptography for OpenJDK,
don't we want that?

Then again, if you prefer we can wait a few months and see what
happens... And no, I'm not saying this because he's a colleague at Red
Hat, a similar issue was raised a few months ago for an Oracle
developer, similar in all respect, including concerns, but then common
sense prevailed.

This entrance barrier is a necessary training, but if someone shows
commitment and value in the work they do it doesn't have to be
strictly at the eight contribution mark. It can be five or ten too.
Generally you want to respect an higher number of contributions when
you are uncertain of the quality and steadiness of the developer, but
doesn't make a lot of sense in this case for me.

Cheers,
Mario

Il giorno gio 28 giu 2018 alle ore 08:43 Volker Simonis
<volker.simonis at gmail.com> ha scritto:
>
> Hi Andrew,
>
> I totally agree that we need more OpenJDK developers in the security
> area and I'm sure Martin is a perfect fit for this role.
>
> But the process document [1] clearly states that a "Contributor should
> make at least eight significant contributions to that Project before
> being nominated". From the references you've provided I can only see
> five changes contributed by Martin. I'd therefore like to kindly ask
> you to withdraw this CFV and postpone it until Martin has reached at
> least the required minimum number of contributions.
>
> Sorry for nit-picking, but I think we should all play by the same rules.
>
> Best regards,
> Volker
>
> [1] http://openjdk.java.net/projects/#project-committer
>
>
> On Wed, Jun 27, 2018 at 5:05 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> > I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
> >
> > Martin has already produced a number of valuable contributions to
> > OpenJDK [0], particularly in the security area, and has more pending review.
> > In an area that seems low on OpenJDK developers, I think we should
> > do our best to support such work.
> >
> > Votes are due by 17h00 UTC on the 11th of July, 2018.
> >
> > Only current OpenJDK Committers [1] 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 [2].
> >
> > [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
> > [1] http://openjdk.java.net/census#jdk
> > [2] http://openjdk.java.net/projects/#committer-vote
> > --
> > 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



-- 
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 sgehwolf at redhat.com  Thu Jun 28 12:36:00 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 28 Jun 2018 14:36:00 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <0485dfa98b7d5d318851f04f14c885153005cd8c.camel@redhat.com>

On Wed, 2018-06-27 at 16:05 +0100, Andrew Hughes wrote:
> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.

Vote: yes.

From jesper.wilhelmsson at oracle.com  Thu Jun 28 13:54:23 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 28 Jun 2018 15:54:23 +0200
Subject: JDK 11 enters Rampdown Phase One next week
In-Reply-To: <20180622164211.175291DE18E@eggemoggin.niobe.net>
References: <20180622164211.175291DE18E@eggemoggin.niobe.net>
Message-ID: <9C8B4E8D-86B4-46BE-A6C3-41CD1E9E4E6D@oracle.com>

Just a reminder that this happens in just over one hour from now.

We will pick a build just after the deadline and run a series of tests on it (tiers 1-3) before adding the tag jdk12+0. Once that is done the JDK 11 stabilization repo will be created. Running the tests will take a few hours so have patience and please do not push any changes intended for JDK 12 until the tag has been pushed. I will keep you updated of our progress.

Thanks,
/Jesper

> On 22 Jun 2018, at 18:42, mark.reinhold at oracle.com wrote:
> 
> JDK 11 enters Rampdown Phase One next week, on Thursday, 28 June.
> Changes intended for JDK 11 should be in the main-line repository
> (http://hg.openjdk.java.net/jdk/jdk) or the client repository
> (jdk/client), by 15:00 UTC on that day [1].
> 
> At that time we?ll fork jdk/jdk to the JDK 11 stabilization repository,
> jdk/jdk11, and promote next week?s build (jdk-11+20) and all remaining
> JDK 11 builds from there.
> 
> We'll semi-automatically merge changes pushed to jdk/jdk11 into the
> main-line jdk/jdk repository, as we did for the transitions from 9
> to 10 and 10 to 11.  This means that:
> 
>  - If you make a change in JDK 11 then you needn't do any extra
>    work to get it into the main line, though if a merge conflict
>    arises then you might be asked to help resolve it.
> 
>  - If you need to make a change in both JDK 11 and the main line
>    then just push it to JDK 11, and wait for the automatic merge
>    to complete.
> 
> Changes pushed into the jdk/jdk or jdk/client repositories after 15:00
> UTC next Thursday will be destined for JDK 12 unless they're back-ported.
> 
> The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
> We?ll set up a jdk/submit11 repo for jdk/jdk11 work.
> 
> The Rampdown Phase One process will be similar to that of JDK 10,
> as proposed in JEP 3 [2].
> 
> - Mark
> 
> 
> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Rampdown+Phase+One&iso=20180628T15
> [2] http://openjdk.java.net/jeps/3


From volker.simonis at gmail.com  Thu Jun 28 14:50:43 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 Jun 2018 16:50:43 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
Message-ID: <CA+3eh13tagxs-p1pcpNpNjSsQ+bU3+2ELJT8hFC2Ha=WVNS0NQ@mail.gmail.com>

Hi Mario,

as I wrote before - if I'm the only one who has misinterpreted the
rules I apologize and won't complain any more.

Regards,
Volker


On Thu, Jun 28, 2018 at 2:30 PM, Mario Torre
<neugens.limasoftware at gmail.com> wrote:
> Hi Volker,
>
> I see your point, but I think this needs to be taken as a general
> guidance and decided on a case by case basis, as it has been discussed
> over and over. We should be looking instead at the quality of the
> current contributions and what they mean to the general development of
> the project rather than counting numbers. Or we can keep pushing
> patches for Martin if you prefer, he's going to hit the 8 mark in 3
> patches, then we can propose the nomination gain and the process will
> be happy for the sake of being a process... We all agree here that
> Martin is not only qualified, but he is a contributor that is doing
> significant work in the area of security and cryptography for OpenJDK,
> don't we want that?
>
> Then again, if you prefer we can wait a few months and see what
> happens... And no, I'm not saying this because he's a colleague at Red
> Hat, a similar issue was raised a few months ago for an Oracle
> developer, similar in all respect, including concerns, but then common
> sense prevailed.
>
> This entrance barrier is a necessary training, but if someone shows
> commitment and value in the work they do it doesn't have to be
> strictly at the eight contribution mark. It can be five or ten too.
> Generally you want to respect an higher number of contributions when
> you are uncertain of the quality and steadiness of the developer, but
> doesn't make a lot of sense in this case for me.
>
> Cheers,
> Mario
>
> Il giorno gio 28 giu 2018 alle ore 08:43 Volker Simonis
> <volker.simonis at gmail.com> ha scritto:
>>
>> Hi Andrew,
>>
>> I totally agree that we need more OpenJDK developers in the security
>> area and I'm sure Martin is a perfect fit for this role.
>>
>> But the process document [1] clearly states that a "Contributor should
>> make at least eight significant contributions to that Project before
>> being nominated". From the references you've provided I can only see
>> five changes contributed by Martin. I'd therefore like to kindly ask
>> you to withdraw this CFV and postpone it until Martin has reached at
>> least the required minimum number of contributions.
>>
>> Sorry for nit-picking, but I think we should all play by the same rules.
>>
>> Best regards,
>> Volker
>>
>> [1] http://openjdk.java.net/projects/#project-committer
>>
>>
>> On Wed, Jun 27, 2018 at 5:05 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>> > I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>> >
>> > Martin has already produced a number of valuable contributions to
>> > OpenJDK [0], particularly in the security area, and has more pending review.
>> > In an area that seems low on OpenJDK developers, I think we should
>> > do our best to support such work.
>> >
>> > Votes are due by 17h00 UTC on the 11th of July, 2018.
>> >
>> > Only current OpenJDK Committers [1] 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 [2].
>> >
>> > [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
>> > [1] http://openjdk.java.net/census#jdk
>> > [2] http://openjdk.java.net/projects/#committer-vote
>> > --
>> > 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
>
>
>
> --
> 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 daniel.daugherty at oracle.com  Thu Jun 28 15:18:33 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 28 Jun 2018 11:18:33 -0400
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CA+3eh13tagxs-p1pcpNpNjSsQ+bU3+2ELJT8hFC2Ha=WVNS0NQ@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
 <CA+3eh13tagxs-p1pcpNpNjSsQ+bU3+2ELJT8hFC2Ha=WVNS0NQ@mail.gmail.com>
Message-ID: <776384db-23b3-9b7d-d585-c1c99f34d290@oracle.com>

Volker,

You are not the only one that interprets the rules as 8 or more
contributions so I don't think you need to apologize.

Dan

On 6/28/18 10:50 AM, Volker Simonis wrote:
> Hi Mario,
>
> as I wrote before - if I'm the only one who has misinterpreted the
> rules I apologize and won't complain any more.
>
> Regards,
> Volker
>
>
> On Thu, Jun 28, 2018 at 2:30 PM, Mario Torre
> <neugens.limasoftware at gmail.com> wrote:
>> Hi Volker,
>>
>> I see your point, but I think this needs to be taken as a general
>> guidance and decided on a case by case basis, as it has been discussed
>> over and over. We should be looking instead at the quality of the
>> current contributions and what they mean to the general development of
>> the project rather than counting numbers. Or we can keep pushing
>> patches for Martin if you prefer, he's going to hit the 8 mark in 3
>> patches, then we can propose the nomination gain and the process will
>> be happy for the sake of being a process... We all agree here that
>> Martin is not only qualified, but he is a contributor that is doing
>> significant work in the area of security and cryptography for OpenJDK,
>> don't we want that?
>>
>> Then again, if you prefer we can wait a few months and see what
>> happens... And no, I'm not saying this because he's a colleague at Red
>> Hat, a similar issue was raised a few months ago for an Oracle
>> developer, similar in all respect, including concerns, but then common
>> sense prevailed.
>>
>> This entrance barrier is a necessary training, but if someone shows
>> commitment and value in the work they do it doesn't have to be
>> strictly at the eight contribution mark. It can be five or ten too.
>> Generally you want to respect an higher number of contributions when
>> you are uncertain of the quality and steadiness of the developer, but
>> doesn't make a lot of sense in this case for me.
>>
>> Cheers,
>> Mario
>>
>> Il giorno gio 28 giu 2018 alle ore 08:43 Volker Simonis
>> <volker.simonis at gmail.com> ha scritto:
>>> Hi Andrew,
>>>
>>> I totally agree that we need more OpenJDK developers in the security
>>> area and I'm sure Martin is a perfect fit for this role.
>>>
>>> But the process document [1] clearly states that a "Contributor should
>>> make at least eight significant contributions to that Project before
>>> being nominated". From the references you've provided I can only see
>>> five changes contributed by Martin. I'd therefore like to kindly ask
>>> you to withdraw this CFV and postpone it until Martin has reached at
>>> least the required minimum number of contributions.
>>>
>>> Sorry for nit-picking, but I think we should all play by the same rules.
>>>
>>> Best regards,
>>> Volker
>>>
>>> [1] http://openjdk.java.net/projects/#project-committer
>>>
>>>
>>> On Wed, Jun 27, 2018 at 5:05 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>>>>
>>>> Martin has already produced a number of valuable contributions to
>>>> OpenJDK [0], particularly in the security area, and has more pending review.
>>>> In an area that seems low on OpenJDK developers, I think we should
>>>> do our best to support such work.
>>>>
>>>> Votes are due by 17h00 UTC on the 11th of July, 2018.
>>>>
>>>> Only current OpenJDK Committers [1] 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 [2].
>>>>
>>>> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
>>>> [1] http://openjdk.java.net/census#jdk
>>>> [2] http://openjdk.java.net/projects/#committer-vote
>>>> --
>>>> 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
>>
>>
>> --
>> 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 jesper.wilhelmsson at oracle.com  Thu Jun 28 15:23:27 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 28 Jun 2018 17:23:27 +0200
Subject: JDK 11 enters Rampdown Phase One next week
In-Reply-To: <9C8B4E8D-86B4-46BE-A6C3-41CD1E9E4E6D@oracle.com>
References: <20180622164211.175291DE18E@eggemoggin.niobe.net>
 <9C8B4E8D-86B4-46BE-A6C3-41CD1E9E4E6D@oracle.com>
Message-ID: <98F4CF10-FB84-4E52-8CDC-E2474E4AAF07@oracle.com>

Testing has been started.
The last changes that made it in before JDK 11 FC was JDK-8137164, JDK-8206004, JDK-8205956.

No new builds will be produced from jdk/jdk until after the jdk-12+0 tag and corresponding version string changes etc has been put in place.

Thanks,
/Jesper

> On 28 Jun 2018, at 15:54, jesper.wilhelmsson at oracle.com wrote:
> 
> Just a reminder that this happens in just over one hour from now.
> 
> We will pick a build just after the deadline and run a series of tests on it (tiers 1-3) before adding the tag jdk12+0. Once that is done the JDK 11 stabilization repo will be created. Running the tests will take a few hours so have patience and please do not push any changes intended for JDK 12 until the tag has been pushed. I will keep you updated of our progress.
> 
> Thanks,
> /Jesper
> 
>> On 22 Jun 2018, at 18:42, mark.reinhold at oracle.com wrote:
>> 
>> JDK 11 enters Rampdown Phase One next week, on Thursday, 28 June.
>> Changes intended for JDK 11 should be in the main-line repository
>> (http://hg.openjdk.java.net/jdk/jdk) or the client repository
>> (jdk/client), by 15:00 UTC on that day [1].
>> 
>> At that time we?ll fork jdk/jdk to the JDK 11 stabilization repository,
>> jdk/jdk11, and promote next week?s build (jdk-11+20) and all remaining
>> JDK 11 builds from there.
>> 
>> We'll semi-automatically merge changes pushed to jdk/jdk11 into the
>> main-line jdk/jdk repository, as we did for the transitions from 9
>> to 10 and 10 to 11.  This means that:
>> 
>> - If you make a change in JDK 11 then you needn't do any extra
>>   work to get it into the main line, though if a merge conflict
>>   arises then you might be asked to help resolve it.
>> 
>> - If you need to make a change in both JDK 11 and the main line
>>   then just push it to JDK 11, and wait for the automatic merge
>>   to complete.
>> 
>> Changes pushed into the jdk/jdk or jdk/client repositories after 15:00
>> UTC next Thursday will be destined for JDK 12 unless they're back-ported.
>> 
>> The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
>> We?ll set up a jdk/submit11 repo for jdk/jdk11 work.
>> 
>> The Rampdown Phase One process will be similar to that of JDK 10,
>> as proposed in JEP 3 [2].
>> 
>> - Mark
>> 
>> 
>> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Rampdown+Phase+One&iso=20180628T15
>> [2] http://openjdk.java.net/jeps/3
> 


From neugens at redhat.com  Thu Jun 28 15:52:26 2018
From: neugens at redhat.com (Mario Torre)
Date: Thu, 28 Jun 2018 17:52:26 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <776384db-23b3-9b7d-d585-c1c99f34d290@oracle.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
 <CA+3eh13tagxs-p1pcpNpNjSsQ+bU3+2ELJT8hFC2Ha=WVNS0NQ@mail.gmail.com>
 <776384db-23b3-9b7d-d585-c1c99f34d290@oracle.com>
Message-ID: <CAJwKKma6_esKLWjr9Cp7OxsOav_SbANHJtdNAgpQZVv+JOB6tQ@mail.gmail.com>

I don't think Volker should apologise, his rationale is valid to a
certain degree, however the interpretation of the guidelines has been
clarified multiple times by the Governing Board itself, so I don't
think we should be challenging them again.

For the case in question, those are the additional patches under
review/uncommited:

 * SunPKCS11 memory leak fix (under review)
  * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.09/

 * SunPKCS11 + TLS 1.2 (under review)
  * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03/

 * Fix in SunPKCS11 Secmod
  * http://cr.openjdk.java.net/~akasko/mbalao/8195607_nss_sqlite/8195607.webrev.01/

 * TLS Channel Bindings (on hold because of TLS 1.3)
  * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.03/

 * Trusted CA Indication extension + Certificate Authorities (on hold
because of TLS 1.3)
  * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/

There are also a number of other contributions in the pipeline, as you
see at least 3 of them will likely be pushed shortly, reaching the
magic number necessary [1].

Andrew could have waited a couple of weeks perhaps, but honestly I
don't think there's a compelling reason to pause this nomination.

Cheers,
Mario

[1] Btw, why we choose "eight" and not some way nicer prime number instead?

On Thu, Jun 28, 2018 at 5:18 PM, Daniel D. Daugherty
<daniel.daugherty at oracle.com> wrote:
> Volker,
>
> You are not the only one that interprets the rules as 8 or more
> contributions so I don't think you need to apologize.
>
> Dan
>
>
> On 6/28/18 10:50 AM, Volker Simonis wrote:
>>
>> Hi Mario,
>>
>> as I wrote before - if I'm the only one who has misinterpreted the
>> rules I apologize and won't complain any more.
>>
>> Regards,
>> Volker
>>
>>
>> On Thu, Jun 28, 2018 at 2:30 PM, Mario Torre
>> <neugens.limasoftware at gmail.com> wrote:
>>>
>>> Hi Volker,
>>>
>>> I see your point, but I think this needs to be taken as a general
>>> guidance and decided on a case by case basis, as it has been discussed
>>> over and over. We should be looking instead at the quality of the
>>> current contributions and what they mean to the general development of
>>> the project rather than counting numbers. Or we can keep pushing
>>> patches for Martin if you prefer, he's going to hit the 8 mark in 3
>>> patches, then we can propose the nomination gain and the process will
>>> be happy for the sake of being a process... We all agree here that
>>> Martin is not only qualified, but he is a contributor that is doing
>>> significant work in the area of security and cryptography for OpenJDK,
>>> don't we want that?
>>>
>>> Then again, if you prefer we can wait a few months and see what
>>> happens... And no, I'm not saying this because he's a colleague at Red
>>> Hat, a similar issue was raised a few months ago for an Oracle
>>> developer, similar in all respect, including concerns, but then common
>>> sense prevailed.
>>>
>>> This entrance barrier is a necessary training, but if someone shows
>>> commitment and value in the work they do it doesn't have to be
>>> strictly at the eight contribution mark. It can be five or ten too.
>>> Generally you want to respect an higher number of contributions when
>>> you are uncertain of the quality and steadiness of the developer, but
>>> doesn't make a lot of sense in this case for me.
>>>
>>> Cheers,
>>> Mario
>>>
>>> Il giorno gio 28 giu 2018 alle ore 08:43 Volker Simonis
>>> <volker.simonis at gmail.com> ha scritto:
>>>>
>>>> Hi Andrew,
>>>>
>>>> I totally agree that we need more OpenJDK developers in the security
>>>> area and I'm sure Martin is a perfect fit for this role.
>>>>
>>>> But the process document [1] clearly states that a "Contributor should
>>>> make at least eight significant contributions to that Project before
>>>> being nominated". From the references you've provided I can only see
>>>> five changes contributed by Martin. I'd therefore like to kindly ask
>>>> you to withdraw this CFV and postpone it until Martin has reached at
>>>> least the required minimum number of contributions.
>>>>
>>>> Sorry for nit-picking, but I think we should all play by the same rules.
>>>>
>>>> Best regards,
>>>> Volker
>>>>
>>>> [1] http://openjdk.java.net/projects/#project-committer
>>>>
>>>>
>>>> On Wed, Jun 27, 2018 at 5:05 PM, Andrew Hughes <gnu.andrew at redhat.com>
>>>> wrote:
>>>>>
>>>>> I hereby nominate Martin Balao (mbalao) to OpenJDK Committer.
>>>>>
>>>>> Martin has already produced a number of valuable contributions to
>>>>> OpenJDK [0], particularly in the security area, and has more pending
>>>>> review.
>>>>> In an area that seems low on OpenJDK developers, I think we should
>>>>> do our best to support such work.
>>>>>
>>>>> Votes are due by 17h00 UTC on the 11th of July, 2018.
>>>>>
>>>>> Only current OpenJDK Committers [1] 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 [2].
>>>>>
>>>>> [0]
>>>>> http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge()
>>>>> [1] http://openjdk.java.net/census#jdk
>>>>> [2] http://openjdk.java.net/projects/#committer-vote
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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/
>
>



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From gnu.andrew at redhat.com  Thu Jun 28 16:28:46 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 28 Jun 2018 17:28:46 +0100
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
Message-ID: <CABi63P5SoUTYcDe_t++_a39eqRODek2TM8zZBr7uS6+988HaRw@mail.gmail.com>

On 28 June 2018 at 07:42, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi Andrew,
>
> I totally agree that we need more OpenJDK developers in the security
> area and I'm sure Martin is a perfect fit for this role.
>
> But the process document [1] clearly states that a "Contributor should
> make at least eight significant contributions to that Project before
> being nominated". From the references you've provided I can only see
> five changes contributed by Martin. I'd therefore like to kindly ask
> you to withdraw this CFV and postpone it until Martin has reached at
> least the required minimum number of contributions.
>
> Sorry for nit-picking, but I think we should all play by the same rules.
>
> Best regards,
> Volker
>
> [1] http://openjdk.java.net/projects/#project-committer
>

Hi Volker,

Thanks for bringing this up. I don't think it's nit-picking; we should all
try and be on the same page when it comes to such things.

I wasn't aware of the document you refer to. My only reference
when writing the original e-mail, and others in the past, has been
the bylaws [0], which have no such prescription. I tend to concur
with what Mario and Andrew Dinn have already said so well, in that
this is intended as guidance, rather than a strict rule.

It is hard to interpret it as such without also defining "significant" in
some absolute way. Generally, what is regard a significant patch
by one person may not be by another. I can also easily see how
someone could easily produce more than eight patches of low
complexity in the time it may take them to produce one of a higher
complexity.

Moreover, I do not see the need for such strong barriers on making
someone a committer. If we were considering the post of reviewer,
I may be more stringent, but all we are offering is the ability to push
approved patches to the repositories. Unless we believe Martin
to be a rogue agent, I don't see a value in this. We are not suggesting
that he should be able to freely push patches without approval.
All delaying his approval as committer achieves is creating more
tedious work for others, as they then have to repeat his work of applying
and building the patch before pushing it on his behalf. I do think we
need to keep practicality and accessibility in mind, as well as strict
conformance to the rules.

What prompted me to post this yesterday is I also opened a similar
vote for Severin on 8u [1]. There, we have the even more bizarre situation
that someone who can push to OpenJDK 9 and later can not push to
OpenJDK 8, because, while such permissions are automatically carried
to new versions of the JDK project, they are not applied retrospectively
to older versions. This brought Martin to mind, and, to be fair to him, for
his part, he rather modestly thought it was too soon to be proposed.
Being aware of the work he has done, and is in the process of doing,
I thought otherwise.

It may well be that, by the time the two week voting period has expired,
eight patches have been committed. My experience is that this has more
to do with the availability of reviewers in the security space than anything
else. If however, you still disagree and wish to veto, I bear you no hard
feelings on the matter.

[0] http://openjdk.java.net/bylaws#committer
[1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007588.html

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From jesper.wilhelmsson at oracle.com  Thu Jun 28 16:54:32 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 28 Jun 2018 18:54:32 +0200
Subject: JDK 11 enters Rampdown Phase One next week
In-Reply-To: <98F4CF10-FB84-4E52-8CDC-E2474E4AAF07@oracle.com>
References: <20180622164211.175291DE18E@eggemoggin.niobe.net>
 <9C8B4E8D-86B4-46BE-A6C3-41CD1E9E4E6D@oracle.com>
 <98F4CF10-FB84-4E52-8CDC-E2474E4AAF07@oracle.com>
Message-ID: <7C70411D-7685-4BF2-A8CC-66D3DA117F91@oracle.com>

My earlier wording was a little too strict. jdk/jdk is always open and changes can be pushed even now before the tag is in there. Please note however that changes pushed to jdk/jdk now will be pushed to JDK 12. They will not go into JDK 11 unless manually backported. Please update the fix version in JBS before pushing.

There will also not be any automatic testing done on these changes until after the tag has been pushed, so personally I think it would be nice not having a large number of new changes in the first JDK 12 build.

Current status is that tier 1 passed with no failures. In tier 2 there is a build failure on windows-x64-slowdebug. This will need a fix.

Thanks,
/Jesper

> On 28 Jun 2018, at 17:23, jesper.wilhelmsson at oracle.com wrote:
> 
> Testing has been started.
> The last changes that made it in before JDK 11 FC was JDK-8137164, JDK-8206004, JDK-8205956.
> 
> No new builds will be produced from jdk/jdk until after the jdk-12+0 tag and corresponding version string changes etc has been put in place.
> 
> Thanks,
> /Jesper
> 
>> On 28 Jun 2018, at 15:54, jesper.wilhelmsson at oracle.com wrote:
>> 
>> Just a reminder that this happens in just over one hour from now.
>> 
>> We will pick a build just after the deadline and run a series of tests on it (tiers 1-3) before adding the tag jdk12+0. Once that is done the JDK 11 stabilization repo will be created. Running the tests will take a few hours so have patience and please do not push any changes intended for JDK 12 until the tag has been pushed. I will keep you updated of our progress.
>> 
>> Thanks,
>> /Jesper
>> 
>>> On 22 Jun 2018, at 18:42, mark.reinhold at oracle.com wrote:
>>> 
>>> JDK 11 enters Rampdown Phase One next week, on Thursday, 28 June.
>>> Changes intended for JDK 11 should be in the main-line repository
>>> (http://hg.openjdk.java.net/jdk/jdk) or the client repository
>>> (jdk/client), by 15:00 UTC on that day [1].
>>> 
>>> At that time we?ll fork jdk/jdk to the JDK 11 stabilization repository,
>>> jdk/jdk11, and promote next week?s build (jdk-11+20) and all remaining
>>> JDK 11 builds from there.
>>> 
>>> We'll semi-automatically merge changes pushed to jdk/jdk11 into the
>>> main-line jdk/jdk repository, as we did for the transitions from 9
>>> to 10 and 10 to 11.  This means that:
>>> 
>>> - If you make a change in JDK 11 then you needn't do any extra
>>>  work to get it into the main line, though if a merge conflict
>>>  arises then you might be asked to help resolve it.
>>> 
>>> - If you need to make a change in both JDK 11 and the main line
>>>  then just push it to JDK 11, and wait for the automatic merge
>>>  to complete.
>>> 
>>> Changes pushed into the jdk/jdk or jdk/client repositories after 15:00
>>> UTC next Thursday will be destined for JDK 12 unless they're back-ported.
>>> 
>>> The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
>>> We?ll set up a jdk/submit11 repo for jdk/jdk11 work.
>>> 
>>> The Rampdown Phase One process will be similar to that of JDK 10,
>>> as proposed in JEP 3 [2].
>>> 
>>> - Mark
>>> 
>>> 
>>> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Rampdown+Phase+One&iso=20180628T15
>>> [2] http://openjdk.java.net/jeps/3
>> 
> 


From daniel.daugherty at oracle.com  Thu Jun 28 17:37:04 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 28 Jun 2018 13:37:04 -0400
Subject: JDK 11 enters Rampdown Phase One next week
In-Reply-To: <7C70411D-7685-4BF2-A8CC-66D3DA117F91@oracle.com>
References: <20180622164211.175291DE18E@eggemoggin.niobe.net>
 <9C8B4E8D-86B4-46BE-A6C3-41CD1E9E4E6D@oracle.com>
 <98F4CF10-FB84-4E52-8CDC-E2474E4AAF07@oracle.com>
 <7C70411D-7685-4BF2-A8CC-66D3DA117F91@oracle.com>
Message-ID: <3cbbe38f-4c0e-fd03-31d8-b222e7f02d21@oracle.com>

 > Please update the fix version in JBS before pushing.

If folks do that then, the hgupdater will auto create a
JDK11 backport until the updater is switched to JDK12.
It is better to manually update the 'fix version' for
these pushes from '11' to '12'. Then we don't have to
deal with errant/premature JDK11 backports...

Dan


On 6/28/18 12:54 PM, jesper.wilhelmsson at oracle.com wrote:
> My earlier wording was a little too strict. jdk/jdk is always open and changes can be pushed even now before the tag is in there. Please note however that changes pushed to jdk/jdk now will be pushed to JDK 12. They will not go into JDK 11 unless manually backported. Please update the fix version in JBS before pushing.
>
> There will also not be any automatic testing done on these changes until after the tag has been pushed, so personally I think it would be nice not having a large number of new changes in the first JDK 12 build.
>
> Current status is that tier 1 passed with no failures. In tier 2 there is a build failure on windows-x64-slowdebug. This will need a fix.
>
> Thanks,
> /Jesper
>
>> On 28 Jun 2018, at 17:23, jesper.wilhelmsson at oracle.com wrote:
>>
>> Testing has been started.
>> The last changes that made it in before JDK 11 FC was JDK-8137164, JDK-8206004, JDK-8205956.
>>
>> No new builds will be produced from jdk/jdk until after the jdk-12+0 tag and corresponding version string changes etc has been put in place.
>>
>> Thanks,
>> /Jesper
>>
>>> On 28 Jun 2018, at 15:54, jesper.wilhelmsson at oracle.com wrote:
>>>
>>> Just a reminder that this happens in just over one hour from now.
>>>
>>> We will pick a build just after the deadline and run a series of tests on it (tiers 1-3) before adding the tag jdk12+0. Once that is done the JDK 11 stabilization repo will be created. Running the tests will take a few hours so have patience and please do not push any changes intended for JDK 12 until the tag has been pushed. I will keep you updated of our progress.
>>>
>>> Thanks,
>>> /Jesper
>>>
>>>> On 22 Jun 2018, at 18:42, mark.reinhold at oracle.com wrote:
>>>>
>>>> JDK 11 enters Rampdown Phase One next week, on Thursday, 28 June.
>>>> Changes intended for JDK 11 should be in the main-line repository
>>>> (http://hg.openjdk.java.net/jdk/jdk) or the client repository
>>>> (jdk/client), by 15:00 UTC on that day [1].
>>>>
>>>> At that time we?ll fork jdk/jdk to the JDK 11 stabilization repository,
>>>> jdk/jdk11, and promote next week?s build (jdk-11+20) and all remaining
>>>> JDK 11 builds from there.
>>>>
>>>> We'll semi-automatically merge changes pushed to jdk/jdk11 into the
>>>> main-line jdk/jdk repository, as we did for the transitions from 9
>>>> to 10 and 10 to 11.  This means that:
>>>>
>>>> - If you make a change in JDK 11 then you needn't do any extra
>>>>   work to get it into the main line, though if a merge conflict
>>>>   arises then you might be asked to help resolve it.
>>>>
>>>> - If you need to make a change in both JDK 11 and the main line
>>>>   then just push it to JDK 11, and wait for the automatic merge
>>>>   to complete.
>>>>
>>>> Changes pushed into the jdk/jdk or jdk/client repositories after 15:00
>>>> UTC next Thursday will be destined for JDK 12 unless they're back-ported.
>>>>
>>>> The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
>>>> We?ll set up a jdk/submit11 repo for jdk/jdk11 work.
>>>>
>>>> The Rampdown Phase One process will be similar to that of JDK 10,
>>>> as proposed in JEP 3 [2].
>>>>
>>>> - Mark
>>>>
>>>>
>>>> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Rampdown+Phase+One&iso=20180628T15
>>>> [2] http://openjdk.java.net/jeps/3


From philip.race at oracle.com  Thu Jun 28 18:23:47 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Jun 2018 11:23:47 -0700
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P5SoUTYcDe_t++_a39eqRODek2TM8zZBr7uS6+988HaRw@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CABi63P5SoUTYcDe_t++_a39eqRODek2TM8zZBr7uS6+988HaRw@mail.gmail.com>
Message-ID: <b562f4af-dd42-01a5-3748-2f9ccb9831ad@oracle.com>

It might be time to update the process document to say something about this
to avoid these debates.

I (personal view) think the intent of a number like 8 is to ensure that 
a committer is,
well, .. committed ... as well as capable.
They've been around for a while, made contributions in that time and 
expect to
stick around, and you should take into account the time period, 
technical difficulty and
significance of their contributions rather than focusing on an absolute 
number.
8 is therefore a guideline based on some estimation of typical size + 
complexity of
fixes in the project to show a sufficient body of work.

-phil.

On 06/28/2018 09:28 AM, Andrew Hughes wrote:
> On 28 June 2018 at 07:42, Volker Simonis <volker.simonis at gmail.com> wrote:
>> Hi Andrew,
>>
>> I totally agree that we need more OpenJDK developers in the security
>> area and I'm sure Martin is a perfect fit for this role.
>>
>> But the process document [1] clearly states that a "Contributor should
>> make at least eight significant contributions to that Project before
>> being nominated". From the references you've provided I can only see
>> five changes contributed by Martin. I'd therefore like to kindly ask
>> you to withdraw this CFV and postpone it until Martin has reached at
>> least the required minimum number of contributions.
>>
>> Sorry for nit-picking, but I think we should all play by the same rules.
>>
>> Best regards,
>> Volker
>>
>> [1] http://openjdk.java.net/projects/#project-committer
>>
> Hi Volker,
>
> Thanks for bringing this up. I don't think it's nit-picking; we should all
> try and be on the same page when it comes to such things.
>
> I wasn't aware of the document you refer to. My only reference
> when writing the original e-mail, and others in the past, has been
> the bylaws [0], which have no such prescription. I tend to concur
> with what Mario and Andrew Dinn have already said so well, in that
> this is intended as guidance, rather than a strict rule.
>
> It is hard to interpret it as such without also defining "significant" in
> some absolute way. Generally, what is regard a significant patch
> by one person may not be by another. I can also easily see how
> someone could easily produce more than eight patches of low
> complexity in the time it may take them to produce one of a higher
> complexity.
>
> Moreover, I do not see the need for such strong barriers on making
> someone a committer. If we were considering the post of reviewer,
> I may be more stringent, but all we are offering is the ability to push
> approved patches to the repositories. Unless we believe Martin
> to be a rogue agent, I don't see a value in this. We are not suggesting
> that he should be able to freely push patches without approval.
> All delaying his approval as committer achieves is creating more
> tedious work for others, as they then have to repeat his work of applying
> and building the patch before pushing it on his behalf. I do think we
> need to keep practicality and accessibility in mind, as well as strict
> conformance to the rules.
>
> What prompted me to post this yesterday is I also opened a similar
> vote for Severin on 8u [1]. There, we have the even more bizarre situation
> that someone who can push to OpenJDK 9 and later can not push to
> OpenJDK 8, because, while such permissions are automatically carried
> to new versions of the JDK project, they are not applied retrospectively
> to older versions. This brought Martin to mind, and, to be fair to him, for
> his part, he rather modestly thought it was too soon to be proposed.
> Being aware of the work he has done, and is in the process of doing,
> I thought otherwise.
>
> It may well be that, by the time the two week voting period has expired,
> eight patches have been committed. My experience is that this has more
> to do with the availability of reviewers in the security space than anything
> else. If however, you still disagree and wish to veto, I bear you no hard
> feelings on the matter.
>
> [0] http://openjdk.java.net/bylaws#committer
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007588.html
>
> Thanks,


From mark.reinhold at oracle.com  Thu Jun 28 18:37:13 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Jun 2018 11:37:13 -0700
Subject: Process JEP proposed for review: 3: JDK Release Process
In-Reply-To: <20180621081059.261252153@eggemoggin.niobe.net>
References: <20180621081059.261252153@eggemoggin.niobe.net>
Message-ID: <20180628113713.338266408@eggemoggin.niobe.net>

2018/6/21 8:10:59 -0700, mark.reinhold at oracle.com:
> Thanks to those who sent comments on the draft version of this JEP.
> I?ve moved it along to the Candidate state:
> 
>   3: JDK Release Process
>      http://openjdk.java.net/jeps/3
> 
> Further comment is invited.  If no objections are raised by 16:00 UTC
> next Thursday, 28 June, or if they're raised and then satisfactorily
> answered, then per the JEP 2.0 process proposal [1] I'll mark this
> process JEP as active, and this is the process that we?ll use for
> JDK 11 and beyond.

Hearing no objections, I?ve moved this process JEP to ?Active? (which
appears as ?Completed? in JBS, for now).

- Mark

From jesper.wilhelmsson at oracle.com  Thu Jun 28 18:53:00 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 28 Jun 2018 20:53:00 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <b562f4af-dd42-01a5-3748-2f9ccb9831ad@oracle.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CABi63P5SoUTYcDe_t++_a39eqRODek2TM8zZBr7uS6+988HaRw@mail.gmail.com>
 <b562f4af-dd42-01a5-3748-2f9ccb9831ad@oracle.com>
Message-ID: <DCB9F3A1-5EB1-4535-B677-E23F5FA37C4C@oracle.com>

The last time this was up for debate I suggested to change the description on the OpenJDK page, http://openjdk.java.net/projects/#project-committer, to something like:

"A Contributor who is trusted to use their push access in a responsible fashion and who has shown through previous work in the Project to understand the workflow and infrastructure required to work in the Project can be nominated."

I think we should try to make this happen.
/Jesper

> On 28 Jun 2018, at 20:23, Phil Race <philip.race at oracle.com> wrote:
> 
> It might be time to update the process document to say something about this
> to avoid these debates.
> 
> I (personal view) think the intent of a number like 8 is to ensure that a committer is,
> well, .. committed ... as well as capable.
> They've been around for a while, made contributions in that time and expect to
> stick around, and you should take into account the time period, technical difficulty and
> significance of their contributions rather than focusing on an absolute number.
> 8 is therefore a guideline based on some estimation of typical size + complexity of
> fixes in the project to show a sufficient body of work.
> 
> -phil.
> 
> On 06/28/2018 09:28 AM, Andrew Hughes wrote:
>> On 28 June 2018 at 07:42, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> Hi Andrew,
>>> 
>>> I totally agree that we need more OpenJDK developers in the security
>>> area and I'm sure Martin is a perfect fit for this role.
>>> 
>>> But the process document [1] clearly states that a "Contributor should
>>> make at least eight significant contributions to that Project before
>>> being nominated". From the references you've provided I can only see
>>> five changes contributed by Martin. I'd therefore like to kindly ask
>>> you to withdraw this CFV and postpone it until Martin has reached at
>>> least the required minimum number of contributions.
>>> 
>>> Sorry for nit-picking, but I think we should all play by the same rules.
>>> 
>>> Best regards,
>>> Volker
>>> 
>>> [1] http://openjdk.java.net/projects/#project-committer
>>> 
>> Hi Volker,
>> 
>> Thanks for bringing this up. I don't think it's nit-picking; we should all
>> try and be on the same page when it comes to such things.
>> 
>> I wasn't aware of the document you refer to. My only reference
>> when writing the original e-mail, and others in the past, has been
>> the bylaws [0], which have no such prescription. I tend to concur
>> with what Mario and Andrew Dinn have already said so well, in that
>> this is intended as guidance, rather than a strict rule.
>> 
>> It is hard to interpret it as such without also defining "significant" in
>> some absolute way. Generally, what is regard a significant patch
>> by one person may not be by another. I can also easily see how
>> someone could easily produce more than eight patches of low
>> complexity in the time it may take them to produce one of a higher
>> complexity.
>> 
>> Moreover, I do not see the need for such strong barriers on making
>> someone a committer. If we were considering the post of reviewer,
>> I may be more stringent, but all we are offering is the ability to push
>> approved patches to the repositories. Unless we believe Martin
>> to be a rogue agent, I don't see a value in this. We are not suggesting
>> that he should be able to freely push patches without approval.
>> All delaying his approval as committer achieves is creating more
>> tedious work for others, as they then have to repeat his work of applying
>> and building the patch before pushing it on his behalf. I do think we
>> need to keep practicality and accessibility in mind, as well as strict
>> conformance to the rules.
>> 
>> What prompted me to post this yesterday is I also opened a similar
>> vote for Severin on 8u [1]. There, we have the even more bizarre situation
>> that someone who can push to OpenJDK 9 and later can not push to
>> OpenJDK 8, because, while such permissions are automatically carried
>> to new versions of the JDK project, they are not applied retrospectively
>> to older versions. This brought Martin to mind, and, to be fair to him, for
>> his part, he rather modestly thought it was too soon to be proposed.
>> Being aware of the work he has done, and is in the process of doing,
>> I thought otherwise.
>> 
>> It may well be that, by the time the two week voting period has expired,
>> eight patches have been committed. My experience is that this has more
>> to do with the availability of reviewers in the security space than anything
>> else. If however, you still disagree and wish to veto, I bear you no hard
>> feelings on the matter.
>> 
>> [0] http://openjdk.java.net/bylaws#committer
>> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007588.html
>> 
>> Thanks,
> 


From mark.reinhold at oracle.com  Thu Jun 28 19:32:24 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Jun 2018 12:32:24 -0700
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
Message-ID: <20180628123224.776208292@eggemoggin.niobe.net>

2018/6/28 5:30:59 -0700, Mario Torre <neugens.limasoftware at gmail.com>:
> I see your point, but I think this needs to be taken as a general
> guidance and decided on a case by case basis, as it has been discussed
> over and over. We should be looking instead at the quality of the
> current contributions and what they mean to the general development of
> the project rather than counting numbers. ...

I agree.

As one of the original authors of the guidance on the general Projects
page [1], I can affirm that the intent from the start was only to offer
guidance, not hard-and-fast rules.  The thresholds of eight for a new
Committer and 32 for a new Reviewer are just advice, not hard-and-fast
rules.  That?s why these numbers are qualified as ?a rough guide,? and
why they appear on the informal Projects page rather than in the formal
Bylaws.

When I evaluate a potential new Committer or Reviewer I look at their
entire track record, not just their changeset count, including any
earlier work outside of the OpenJDK Community.  If a very experienced
and trustworthy developer shows up and makes five contributions then at
that point I don?t think it?s premature to nominate them to Committer
status.

Let?s leave some room for judgement here.

- Mark

From jesper.wilhelmsson at oracle.com  Thu Jun 28 21:23:03 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 28 Jun 2018 23:23:03 +0200
Subject: JDK 11 enters Rampdown Phase One next week
In-Reply-To: <7C70411D-7685-4BF2-A8CC-66D3DA117F91@oracle.com>
References: <20180622164211.175291DE18E@eggemoggin.niobe.net>
 <9C8B4E8D-86B4-46BE-A6C3-41CD1E9E4E6D@oracle.com>
 <98F4CF10-FB84-4E52-8CDC-E2474E4AAF07@oracle.com>
 <7C70411D-7685-4BF2-A8CC-66D3DA117F91@oracle.com>
Message-ID: <1A26DC78-2E56-400E-A7F6-77BD00F4DE02@oracle.com>

The fork is done.
jdk/jdk is open for JDK 12 changes.
jdk/jdk11 is ready for JDK 11 changes.

Thanks,
/Jesper

> On 28 Jun 2018, at 18:54, jesper.wilhelmsson at oracle.com wrote:
> 
> My earlier wording was a little too strict. jdk/jdk is always open and changes can be pushed even now before the tag is in there. Please note however that changes pushed to jdk/jdk now will be pushed to JDK 12. They will not go into JDK 11 unless manually backported. Please update the fix version in JBS before pushing.
> 
> There will also not be any automatic testing done on these changes until after the tag has been pushed, so personally I think it would be nice not having a large number of new changes in the first JDK 12 build.
> 
> Current status is that tier 1 passed with no failures. In tier 2 there is a build failure on windows-x64-slowdebug. This will need a fix.
> 
> Thanks,
> /Jesper
> 
>> On 28 Jun 2018, at 17:23, jesper.wilhelmsson at oracle.com wrote:
>> 
>> Testing has been started.
>> The last changes that made it in before JDK 11 FC was JDK-8137164, JDK-8206004, JDK-8205956.
>> 
>> No new builds will be produced from jdk/jdk until after the jdk-12+0 tag and corresponding version string changes etc has been put in place.
>> 
>> Thanks,
>> /Jesper
>> 
>>> On 28 Jun 2018, at 15:54, jesper.wilhelmsson at oracle.com wrote:
>>> 
>>> Just a reminder that this happens in just over one hour from now.
>>> 
>>> We will pick a build just after the deadline and run a series of tests on it (tiers 1-3) before adding the tag jdk12+0. Once that is done the JDK 11 stabilization repo will be created. Running the tests will take a few hours so have patience and please do not push any changes intended for JDK 12 until the tag has been pushed. I will keep you updated of our progress.
>>> 
>>> Thanks,
>>> /Jesper
>>> 
>>>> On 22 Jun 2018, at 18:42, mark.reinhold at oracle.com wrote:
>>>> 
>>>> JDK 11 enters Rampdown Phase One next week, on Thursday, 28 June.
>>>> Changes intended for JDK 11 should be in the main-line repository
>>>> (http://hg.openjdk.java.net/jdk/jdk) or the client repository
>>>> (jdk/client), by 15:00 UTC on that day [1].
>>>> 
>>>> At that time we?ll fork jdk/jdk to the JDK 11 stabilization repository,
>>>> jdk/jdk11, and promote next week?s build (jdk-11+20) and all remaining
>>>> JDK 11 builds from there.
>>>> 
>>>> We'll semi-automatically merge changes pushed to jdk/jdk11 into the
>>>> main-line jdk/jdk repository, as we did for the transitions from 9
>>>> to 10 and 10 to 11.  This means that:
>>>> 
>>>> - If you make a change in JDK 11 then you needn't do any extra
>>>> work to get it into the main line, though if a merge conflict
>>>> arises then you might be asked to help resolve it.
>>>> 
>>>> - If you need to make a change in both JDK 11 and the main line
>>>> then just push it to JDK 11, and wait for the automatic merge
>>>> to complete.
>>>> 
>>>> Changes pushed into the jdk/jdk or jdk/client repositories after 15:00
>>>> UTC next Thursday will be destined for JDK 12 unless they're back-ported.
>>>> 
>>>> The jdk/submit repo will continue to be for main-line (jdk/jdk) work.
>>>> We?ll set up a jdk/submit11 repo for jdk/jdk11 work.
>>>> 
>>>> The Rampdown Phase One process will be similar to that of JDK 10,
>>>> as proposed in JEP 3 [2].
>>>> 
>>>> - Mark
>>>> 
>>>> 
>>>> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Rampdown+Phase+One&iso=20180628T15
>>>> [2] http://openjdk.java.net/jeps/3
>>> 
>> 
> 


From mark.reinhold at oracle.com  Thu Jun 28 21:29:22 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Jun 2018 14:29:22 -0700 (PDT)
Subject: JDK 11 is now in Rampdown Phase One
Message-ID: <20180628212922.8266C1DFB9B@eggemoggin.niobe.net>

Per the JDK 11 schedule [1], we are now in Rampdown Phase One.

The overall feature set is frozen.  No further JEPs will be targeted to
this release.

We?ve forked the main-line source repository, jdk/jdk, to the jdk/jdk11
stabilization repository.  Any changes pushed to jdk/jdk or jdk/client
are now bound for JDK 12, as noted previously [2].

The stabilization repository is open for select bug fixes and, with
approval, late enhancements per JEP 3, the JDK Release Process [3].
If you?re responsible for any of the bugs on the RDP 1 candidate-bug
list [3] then please see JEP 3 for guidance on how to handle them.

- Mark


[1] http://openjdk.java.net/projects/jdk/11/#Schedule
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html
[3] http://openjdk.java.net/jeps/3
[4] http://j.mp/jdk-rdp-1

From jini at zeus.net.au  Fri Jun 29 07:27:07 2018
From: jini at zeus.net.au (Peter)
Date: Fri, 29 Jun 2018 17:27:07 +1000
Subject: JEP proposed to target JDK 11: 336: Deprecate the Pack200 Tools
 and API
In-Reply-To: <20180626110514.937844064@eggemoggin.niobe.net>
References: <20180607223515.C8A861DC639@eggemoggin.niobe.net>
 <20180614160623.855585027@eggemoggin.niobe.net>
 <OF6EDDF924.D785F334-ONC12582AD.0025A0D7-C12582AD.0025AE01@LocalDomain>
 <OF98CD575C.796ECEE4-ONC12582B7.0057068F-C12582B7.00576A5B@notes.na.collabserv.com>
 <20180626110514.937844064@eggemoggin.niobe.net>
Message-ID: <5B35DF4B.10900@zeus.net.au>

We've been discussing this on the Eclipse p2 dev list.

The following has been proposed:

   1. Deprecate and remove the C++ Pack200 implementation and command
      line tools.
   2. Maintain the Pack200 standard and Pack200 implementation written
      in java, including adding support for Java 9 and 11 new pool
      constants and attributes.
   3. Don't deprecate the Pack200 standard or the Java library api or
      the java implementation.

I'll sign up to maintain the java implementation.

Regards,

Peter Firmstone.

On 27/06/2018 4:05 AM, mark.reinhold at oracle.com wrote:
> 2018/6/25 8:54:48 -0700, daniel_megert at ch.ibm.com:
>> Sorry, didn't see your reply.
>>
>>> Is Eclipse willing to sign up to maintain this technology?
>> If someone steps up to do so, yes. I think Peter has interest to do so.
>> The question is: is it legally allowed to implement and ship a deprecated
>> specification?
> That?s a legal question, which I?m not qualified to answer.
>
> - Mark


From volker.simonis at gmail.com  Fri Jun 29 09:29:49 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 29 Jun 2018 11:29:49 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <20180628123224.776208292@eggemoggin.niobe.net>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
 <20180628123224.776208292@eggemoggin.niobe.net>
Message-ID: <CA+3eh13z0cs8D-HTurz=cwDnJ0OCG_BZqbuhz0BJvnpFzLM+vg@mail.gmail.com>

On Thu, Jun 28, 2018 at 9:32 PM,  <mark.reinhold at oracle.com> wrote:
> 2018/6/28 5:30:59 -0700, Mario Torre <neugens.limasoftware at gmail.com>:
>> I see your point, but I think this needs to be taken as a general
>> guidance and decided on a case by case basis, as it has been discussed
>> over and over. We should be looking instead at the quality of the
>> current contributions and what they mean to the general development of
>> the project rather than counting numbers. ...
>
> I agree.
>
> As one of the original authors of the guidance on the general Projects
> page [1], I can affirm that the intent from the start was only to offer
> guidance, not hard-and-fast rules.  The thresholds of eight for a new
> Committer and 32 for a new Reviewer are just advice, not hard-and-fast
> rules.  That?s why these numbers are qualified as ?a rough guide,? and
> why they appear on the informal Projects page rather than in the formal
> Bylaws.
>
> When I evaluate a potential new Committer or Reviewer I look at their
> entire track record, not just their changeset count, including any
> earlier work outside of the OpenJDK Community.  If a very experienced
> and trustworthy developer shows up and makes five contributions then at
> that point I don?t think it?s premature to nominate them to Committer
> status.
>
> Let?s leave some room for judgement here.
>

If that's the general opinion, I'd strongly support Jesper's proposal
to update the Projects page accordingly.

Regards,
Volker

> - Mark

From neugens at redhat.com  Fri Jun 29 10:02:16 2018
From: neugens at redhat.com (Mario Torre)
Date: Fri, 29 Jun 2018 12:02:16 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CA+3eh13z0cs8D-HTurz=cwDnJ0OCG_BZqbuhz0BJvnpFzLM+vg@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CAGUMyaQLfRmp4z_mCKMBTDWJ0mzB=kKcX03afHE6j-dJFjB_zA@mail.gmail.com>
 <20180628123224.776208292@eggemoggin.niobe.net>
 <CA+3eh13z0cs8D-HTurz=cwDnJ0OCG_BZqbuhz0BJvnpFzLM+vg@mail.gmail.com>
Message-ID: <CAJwKKmYmaap18K+iKvVUq11OfArhMptH=Z-mK=apMhPHH-oCDA@mail.gmail.com>

On Fri, Jun 29, 2018 at 11:29 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
>> Let?s leave some room for judgement here.
>>
>
> If that's the general opinion, I'd strongly support Jesper's proposal
> to update the Projects page accordingly.

It makes sense to have something like that to clarify the position, I agree.

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From dalibor.topic at oracle.com  Fri Jun 29 10:58:39 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 29 Jun 2018 12:58:39 +0200
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
Message-ID: <e65bd0a5-612d-f369-e7b3-3832f3fe26fc@oracle.com>

Vote: Yes.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+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

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From gnu.andrew at redhat.com  Fri Jun 29 17:01:32 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 29 Jun 2018 18:01:32 +0100
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <DCB9F3A1-5EB1-4535-B677-E23F5FA37C4C@oracle.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CABi63P5SoUTYcDe_t++_a39eqRODek2TM8zZBr7uS6+988HaRw@mail.gmail.com>
 <b562f4af-dd42-01a5-3748-2f9ccb9831ad@oracle.com>
 <DCB9F3A1-5EB1-4535-B677-E23F5FA37C4C@oracle.com>
Message-ID: <CABi63P7jV6KhYmYyipGOBVKF1UqwP6wF=aticiqM7foxAynHfw@mail.gmail.com>

On 28 June 2018 at 19:53,  <jesper.wilhelmsson at oracle.com> wrote:
> The last time this was up for debate I suggested to change the description on the OpenJDK page, http://openjdk.java.net/projects/#project-committer, to something like:
>
> "A Contributor who is trusted to use their push access in a responsible fashion and who has shown through previous work in the Project to understand the workflow and infrastructure required to work in the Project can be nominated."
>
> I think we should try to make this happen.
> /Jesper
>

+1.
-- 
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 Xuelei.Fan at Oracle.Com  Fri Jun 29 17:07:27 2018
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Fri, 29 Jun 2018 10:07:27 -0700
Subject: CFV: New OpenJDK Committer: Martin Balao
In-Reply-To: <CABi63P7jV6KhYmYyipGOBVKF1UqwP6wF=aticiqM7foxAynHfw@mail.gmail.com>
References: <CABi63P6iURNxhq-HnD4wnirMg3JDbTKDD3D8B3NZnLvNXN0o5g@mail.gmail.com>
 <CA+3eh11GwXdj0uvSaL4Z9ON9bX-M_JgzgYwUjeVBiMvAVLVAcQ@mail.gmail.com>
 <CABi63P5SoUTYcDe_t++_a39eqRODek2TM8zZBr7uS6+988HaRw@mail.gmail.com>
 <b562f4af-dd42-01a5-3748-2f9ccb9831ad@oracle.com>
 <DCB9F3A1-5EB1-4535-B677-E23F5FA37C4C@oracle.com>
 <CABi63P7jV6KhYmYyipGOBVKF1UqwP6wF=aticiqM7foxAynHfw@mail.gmail.com>
Message-ID: <8FA62198-15C9-47C3-8B7D-766BADFCFDB9@Oracle.Com>

Vote: Yes.

Xuelei

> On Jun 29, 2018, at 10:01 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 
>> On 28 June 2018 at 19:53,  <jesper.wilhelmsson at oracle.com> wrote:
>> The last time this was up for debate I suggested to change the description on the OpenJDK page, http://openjdk.java.net/projects/#project-committer, to something like:
>> 
>> "A Contributor who is trusted to use their push access in a responsible fashion and who has shown through previous work in the Project to understand the workflow and infrastructure required to work in the Project can be nominated."
>> 
>> I think we should try to make this happen.
>> /Jesper
>> 
> 
> +1.
> -- 
> 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