From jai.forums2013 at gmail.com  Mon Mar  4 09:56:28 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 4 Mar 2019 15:26:28 +0530
Subject: Lambda expression using a final field in object initialization block
Message-ID: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>

Please consider this trivial code:


import java.util.Map;
import java.util.HashMap;
import java.util.function.Supplier;

public class LambdaTest {
??? private final String name;

??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();

??? {
??? ??? this.suppliers.put("a", () -> name);
??? }

??? private LambdaTest(final String name) {
??? ??? this.name = name;
??? }

??? public static void main(final String[] args) throws Exception {
??? ??? final LambdaTest self = new LambdaTest("hello");
??? }
}

When I compile this with Java 8 (javac 1.8.0_172) and even Java 11
(javac 11.0.1), I get a compilation error, in the object initialization
block where I am using a lambda expression to populate the "suppliers"
Map and am referring to a final field (called "name") of the class. The
compilation error is:

LambdaTest.java:12: error: variable name might not have been initialized
?? ??? ?this.suppliers.put("a", () -> name);
?? ??? ?????????????????????????????? ^
1 error

Now, if I replace that piece of code with:


import java.util.Map;
import java.util.HashMap;
import java.util.function.Supplier;

public class LambdaTest {
??? private final String name;

??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();

??? {
??? ??? this.suppliers.put("a", new Supplier<String>() {
??????????? @Override
??????????? public String get() {
??????????????? return name;
??????????? }
??????? });
??? }

??? private LambdaTest(final String name) {
??? ??? this.name = name;
??? }

??? public static void main(final String[] args) throws Exception {
??? ??? final LambdaTest self = new LambdaTest("hello");
??? }
}

The only change in this is the object initialization block, where I no
longer use a lambda and instead use an anonymous class. This passes
compilation successfully.

Why is it an error to use such a final field in a lambda expression? The
(basic) documentation[1] of Lambda expressions doesn't seem to mention
this construct as invalid.


[1]
https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html

-Jaikiran



From forax at univ-mlv.fr  Mon Mar  4 12:37:53 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 4 Mar 2019 13:37:53 +0100 (CET)
Subject: Lambda expression using a final field in object initialization
 block
In-Reply-To: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>
References: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>
Message-ID: <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>

Hi Jaikiran,
the initialisation block is called before the constructor so at that point name is not initialised, that why your first code fails.
For the second one, 
  this.suppliers.put("a", new Supplier<String>() {
             @Override
             public String get() {
                 return name;
             }
  });

  "return name" here is equivalent to return LambdaTest.this.name, with LambdaTest.this being the same reference as this inside the initialization block,
  at that point the compiler doesn't track if name is initialized or not anymore, that's why it compiles. 

so you can fool the compiler the same way with a lambda by introducing a local variable, i.e the example below should compile
    {
        var that = this;
        this.suppliers.put("a", () -> that.name);
    } 

Note, this mailing list is a list to discuss how to implement the JDK not how to use it.
This kind of question will be answered better and faster on stackoverflow.com.

regards,
R?mi

----- Mail original -----
> De: "Jaikiran Pai" <jai.forums2013 at gmail.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Lundi 4 Mars 2019 10:56:28
> Objet: Lambda expression using a final field in object initialization block

> Please consider this trivial code:
> 
> 
> import java.util.Map;
> import java.util.HashMap;
> import java.util.function.Supplier;
> 
> public class LambdaTest {
>??? private final String name;
> 
>??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
> 
>??? {
>??? ??? this.suppliers.put("a", () -> name);
>??? }
> 
>??? private LambdaTest(final String name) {
>??? ??? this.name = name;
>??? }
> 
>??? public static void main(final String[] args) throws Exception {
>??? ??? final LambdaTest self = new LambdaTest("hello");
>??? }
> }
> 
> When I compile this with Java 8 (javac 1.8.0_172) and even Java 11
> (javac 11.0.1), I get a compilation error, in the object initialization
> block where I am using a lambda expression to populate the "suppliers"
> Map and am referring to a final field (called "name") of the class. The
> compilation error is:
> 
> LambdaTest.java:12: error: variable name might not have been initialized
>?? ??? ?this.suppliers.put("a", () -> name);
>?? ??? ?????????????????????????????? ^
> 1 error
> 
> Now, if I replace that piece of code with:
> 
> 
> import java.util.Map;
> import java.util.HashMap;
> import java.util.function.Supplier;
> 
> public class LambdaTest {
>??? private final String name;
> 
>??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
> 
>??? {
>??? ??? this.suppliers.put("a", new Supplier<String>() {
>??????????? @Override
>??????????? public String get() {
>??????????????? return name;
>??????????? }
>??????? });
>??? }
> 
>??? private LambdaTest(final String name) {
>??? ??? this.name = name;
>??? }
> 
>??? public static void main(final String[] args) throws Exception {
>??? ??? final LambdaTest self = new LambdaTest("hello");
>??? }
> }
> 
> The only change in this is the object initialization block, where I no
> longer use a lambda and instead use an anonymous class. This passes
> compilation successfully.
> 
> Why is it an error to use such a final field in a lambda expression? The
> (basic) documentation[1] of Lambda expressions doesn't seem to mention
> this construct as invalid.
> 
> 
> [1]
> https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html
> 
> -Jaikiran

From adinn at redhat.com  Tue Mar  5 09:29:15 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 5 Mar 2019 09:29:15 +0000
Subject: Lambda expression using a final field in object initialization
 block
In-Reply-To: <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>
References: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>
 <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>
Message-ID: <881e0fb6-c36a-2e51-e0a5-bc30869e776c@redhat.com>

On 04/03/2019 12:37, Remi Forax wrote:
> Note, this mailing list is a list to discuss how to implement the JDK not how to use it.
> This kind of question will be answered better and faster on stackoverflow.com.
I'm not sure I agree with either of those conclusions even though the
premise is sound ;-)

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 orionllmain at gmail.com  Tue Mar  5 11:19:11 2019
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Tue, 5 Mar 2019 18:19:11 +0700
Subject: Apple Notarization
In-Reply-To: <CAMYkHE8Rnm72ZA5zofBo3O1oaUq27NchfLpbMZjHybePCE6i9g@mail.gmail.com>
References: <CAMYkHE8Rnm72ZA5zofBo3O1oaUq27NchfLpbMZjHybePCE6i9g@mail.gmail.com>
Message-ID: <CAF2POUdS_-HCEgacrdfHOdd6OGTqY6X7UPzAn6F-9iBczGpKQg@mail.gmail.com>

Hello Jessica. We also deliver our software with a bundled Java. In the
last couple of months, I was trying to overcome Apple notarization. I
finally managed to do it, however, after signing of Java executables and
dynamic libraries it doesn't work anymore.

Here I'll describe the steps I did:

1. Downloaded JRE 10.0.2 for macOS from Oracle (I could use JDK 11 as well,
JR).

2. Ungzipped it with `tar -zxf`.

3. Signed all executables and dynamic libraries with `codesign --force
--verify --deep --verbose --sign <identity> --timestamp -o runtime
--entitlements test.entitlements`
`-o runtime` enabled hardened runtime (which is required for successful
notarization)
test.entitlements is a file with entitlements. Its contents are:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "
http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>

4. Zipped the JRE and submitted it for notarization: `xcrun altool
--notarize-app --primary-bundle-id "<id here>" --username <user name>
--file <jre zip file name>

The archive successfully passed the notarization. However, JRE is not
executable anymore. When I run `java -version`, it reports an error:
Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

And I'm stuck here. I have no ideas on how to resolve this. I was trying to
read the JVM source code but with no luck (it requires deep knowledge of
the JVM internals).

Can anyone help with this? I would really appreciate if someone helped me
to understand this error message.

Thanks.


??, 19 ???. 2018 ?. ? 03:51, Jessica Leigh <jessica at geneious.com>:

> I'm investigating the process of getting an application "notarized" for Mac
> OS. This is a process that Apple has introduced with Mac OS 10.14 Mojave,
> and they've indicated that it will be required for developer-signed
> applications in the near future. The process differs from code signing
> (applications are uploaded to Apple, where they're scanned and either
> notarized or rejected). More information is available from Apple:
>
> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
>
> Our software is bundled with Java 11, and my attempts to find information
> on notarizing Java applications led me to some Stack Overflow questions
> that suggest there may be problems with JAR files, e.g.,
>
> https://stackoverflow.com/questions/53439639/notarize-java-app-for-distribution-on-mac-app-store
> , where dynamic libraries inside JARs aren't signed, which causes
> notarization to fail.
>
> Has any thought been put into preparing/signing Java for the purpose of
> notarization? It seems like Java might not be ready for this yet.
>
>
>
> *Dr. Jessica Leigh*Software Developer
> GENEIOUS
>

From jonathan.gibbons at oracle.com  Wed Mar  6 01:04:38 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 5 Mar 2019 17:04:38 -0800
Subject: Accessibility of JDK API documentation: headings
Message-ID: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>

In our ongoing endeavors to improve the accessibility of the Java SE
and JDK API documentation, we need to pay attention to headings.
In this context, "heading" refers to the use of HTML tags <h1> ... <h6>
in the generated documentation.

There are 3 problem areas; all need to be fixed to address the goal
of being able to generate accessible Java SE and JDK API documentation.

  1. The standard doclet was inconsistent about its use of headings,
     using <h1> for the main heading on some pages, and <h2> for the
     main heading on other pages. This has now been fixed, and the 	
     main heading is now <h1> on all pages.
 ?2. The standard doclet provides little-to-no guidance as to the use of
     headings in documentation comments. This will be fixed.
     To summarize, headings in documentation comments for modules, packages
     and types should start at <h2>; headings in documentation comments
     for members of a type (field, constructor, method, etc) should start
     at <h4>.
 ?3. Many headings in documentation comments do not follow the best
     practices for headings in accessible documents. For example, many
     classes in java.lang.invoke use <h1> repeatedly within the
     documentation comments.

The best practices are all to facilitate navigating and reading the page
with a screen reader, and can be summarized as follows:

   * The main heading for a page should be <h1>
   * There should be just one <h1> per page
   * Headings should be hierarchical, and without ascending gaps, so <h1>
     should be followed by <h2>, <h2> should be followed by <h3> or
     another <h2>, etc.? It is OK to have "missing" headings when
     starting a new higher level section, so that <h4> may be followed by
     <h2>, for example; in that case, the <h2> would implicitly end the
     preceding section at the <h4> level and the one at the <h3> level.

Now that javadoc has been fixed to generate consistent headings, we need
to address the headings in JDK API comments. The good news is that headings
in comments are relatively rare (about 600 overall) and of those, only about
174 need to be fixed, in 126 files in 49 packages in 12 modules.

Now that we have identified the headings that need to be fixed, I'll be
filing bugs against the various areas.  The issues fall into two categories:

* Missing headings: these have generally been caused by changing javadoc
   to start headings at <h1> instead of <h2>.
   There are 105 instances of this issue.

* Low headings: these are generally because of bad use of headings in
   documentation comments, such as the inappropriate use of <h1> or <h2> within
   a comment.
   There are 69 instances of this issue.

-- Jon


From Sergey.Bylokhov at oracle.com  Wed Mar  6 01:08:51 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Mar 2019 17:08:51 -0800
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
Message-ID: <942f37e2-e2b7-75d6-481e-c6fe483bf943@oracle.com>

Hi, Jonathan.

Is it possible to catch such issues using doclint?

On 05/03/2019 17:04, Jonathan Gibbons wrote:
> In our ongoing endeavors to improve the accessibility of the Java SE
> and JDK API documentation, we need to pay attention to headings.
> In this context, "heading" refers to the use of HTML tags <h1> ... <h6>
> in the generated documentation.
> 
> There are 3 problem areas; all need to be fixed to address the goal
> of being able to generate accessible Java SE and JDK API documentation.
> 
>  ?1. The standard doclet was inconsistent about its use of headings,
>  ??? using <h1> for the main heading on some pages, and <h2> for the
>  ??? main heading on other pages. This has now been fixed, and the
>  ??? main heading is now <h1> on all pages.
>  ?2. The standard doclet provides little-to-no guidance as to the use of
>  ??? headings in documentation comments. This will be fixed.
>  ??? To summarize, headings in documentation comments for modules, packages
>  ??? and types should start at <h2>; headings in documentation comments
>  ??? for members of a type (field, constructor, method, etc) should start
>  ??? at <h4>.
>  ?3. Many headings in documentation comments do not follow the best
>  ??? practices for headings in accessible documents. For example, many
>  ??? classes in java.lang.invoke use <h1> repeatedly within the
>  ??? documentation comments.
> 
> The best practices are all to facilitate navigating and reading the page
> with a screen reader, and can be summarized as follows:
> 
>  ? * The main heading for a page should be <h1>
>  ? * There should be just one <h1> per page
>  ? * Headings should be hierarchical, and without ascending gaps, so <h1>
>  ??? should be followed by <h2>, <h2> should be followed by <h3> or
>  ??? another <h2>, etc.? It is OK to have "missing" headings when
>  ??? starting a new higher level section, so that <h4> may be followed by
>  ??? <h2>, for example; in that case, the <h2> would implicitly end the
>  ??? preceding section at the <h4> level and the one at the <h3> level.
> 
> Now that javadoc has been fixed to generate consistent headings, we need
> to address the headings in JDK API comments. The good news is that headings
> in comments are relatively rare (about 600 overall) and of those, only about
> 174 need to be fixed, in 126 files in 49 packages in 12 modules.
> 
> Now that we have identified the headings that need to be fixed, I'll be
> filing bugs against the various areas.? The issues fall into two categories:
> 
> * Missing headings: these have generally been caused by changing javadoc
>  ? to start headings at <h1> instead of <h2>.
>  ? There are 105 instances of this issue.
> 
> * Low headings: these are generally because of bad use of headings in
>  ? documentation comments, such as the inappropriate use of <h1> or <h2> within
>  ? a comment.
>  ? There are 69 instances of this issue.
> 
> -- Jon
> 


-- 
Best regards, Sergey.

From jai.forums2013 at gmail.com  Wed Mar  6 06:38:24 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 6 Mar 2019 12:08:24 +0530
Subject: Lambda expression using a final field in object initialization
 block
In-Reply-To: <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>
References: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>
 <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>
Message-ID: <619bba7a-f08a-99fd-b8e8-a48fe7636abf@gmail.com>

Hello Remi,

Thank you for responding :) The reason why I asked this in the jdk-dev
mailing list was a combination of 2 things:

1. I didn't understand why the compiler would want the value to be
initialized at all at that place in the lambda usage and the docs around
this wasn't clear either. I still don't understand why it needs that
field to be initialized whereas its equivalent anonymous class
counterpart doesn't need it to be initialized. With my limited
understanding of lambdas I was under the impression that the members
used in the lambda expression will only be evaluated when the lambda is
invoked, by which time, in this specific case the field will be
initialized since it's a final member of the instance.

2. The mailing list index[1] mentioned this as the place for "Technical
discussion related to the JDK Project".

Having said that, I do respect and understand what you mean by this
being a user/usage question and I'll pursue this further in a different
forum.

[1] https://mail.openjdk.java.net/mailman/listinfo

-Jaikiran

On 04/03/19 6:07 PM, Remi Forax wrote:
> Hi Jaikiran,
> the initialisation block is called before the constructor so at that point name is not initialised, that why your first code fails.
> For the second one, 
>   this.suppliers.put("a", new Supplier<String>() {
>              @Override
>              public String get() {
>                  return name;
>              }
>   });
>
>   "return name" here is equivalent to return LambdaTest.this.name, with LambdaTest.this being the same reference as this inside the initialization block,
>   at that point the compiler doesn't track if name is initialized or not anymore, that's why it compiles. 
>
> so you can fool the compiler the same way with a lambda by introducing a local variable, i.e the example below should compile
>     {
>         var that = this;
>         this.suppliers.put("a", () -> that.name);
>     } 
>
> Note, this mailing list is a list to discuss how to implement the JDK not how to use it.
> This kind of question will be answered better and faster on stackoverflow.com.
>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "Jaikiran Pai" <jai.forums2013 at gmail.com>
>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>> Envoy?: Lundi 4 Mars 2019 10:56:28
>> Objet: Lambda expression using a final field in object initialization block
>> Please consider this trivial code:
>>
>>
>> import java.util.Map;
>> import java.util.HashMap;
>> import java.util.function.Supplier;
>>
>> public class LambdaTest {
>> ??? private final String name;
>>
>> ??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
>>
>> ??? {
>> ??? ??? this.suppliers.put("a", () -> name);
>> ??? }
>>
>> ??? private LambdaTest(final String name) {
>> ??? ??? this.name = name;
>> ??? }
>>
>> ??? public static void main(final String[] args) throws Exception {
>> ??? ??? final LambdaTest self = new LambdaTest("hello");
>> ??? }
>> }
>>
>> When I compile this with Java 8 (javac 1.8.0_172) and even Java 11
>> (javac 11.0.1), I get a compilation error, in the object initialization
>> block where I am using a lambda expression to populate the "suppliers"
>> Map and am referring to a final field (called "name") of the class. The
>> compilation error is:
>>
>> LambdaTest.java:12: error: variable name might not have been initialized
>> ?? ??? ?this.suppliers.put("a", () -> name);
>> ?? ??? ?????????????????????????????? ^
>> 1 error
>>
>> Now, if I replace that piece of code with:
>>
>>
>> import java.util.Map;
>> import java.util.HashMap;
>> import java.util.function.Supplier;
>>
>> public class LambdaTest {
>> ??? private final String name;
>>
>> ??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
>>
>> ??? {
>> ??? ??? this.suppliers.put("a", new Supplier<String>() {
>> ??????????? @Override
>> ??????????? public String get() {
>> ??????????????? return name;
>> ??????????? }
>> ??????? });
>> ??? }
>>
>> ??? private LambdaTest(final String name) {
>> ??? ??? this.name = name;
>> ??? }
>>
>> ??? public static void main(final String[] args) throws Exception {
>> ??? ??? final LambdaTest self = new LambdaTest("hello");
>> ??? }
>> }
>>
>> The only change in this is the object initialization block, where I no
>> longer use a lambda and instead use an anonymous class. This passes
>> compilation successfully.
>>
>> Why is it an error to use such a final field in a lambda expression? The
>> (basic) documentation[1] of Lambda expressions doesn't seem to mention
>> this construct as invalid.
>>
>>
>> [1]
>> https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html
>>
>> -Jaikiran


From forax at univ-mlv.fr  Wed Mar  6 12:31:25 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 6 Mar 2019 13:31:25 +0100 (CET)
Subject: Lambda expression using a final field in object initialization
 block
In-Reply-To: <619bba7a-f08a-99fd-b8e8-a48fe7636abf@gmail.com>
References: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>
 <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>
 <619bba7a-f08a-99fd-b8e8-a48fe7636abf@gmail.com>
Message-ID: <1226251956.526928.1551875485492.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jaikiran Pai" <jai.forums2013 at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Mercredi 6 Mars 2019 07:38:24
> Objet: Re: Lambda expression using a final field in object initialization block

> Hello Remi,
> 
> Thank you for responding :) The reason why I asked this in the jdk-dev
> mailing list was a combination of 2 things:
> 
> 1. I didn't understand why the compiler would want the value to be
> initialized at all at that place in the lambda usage and the docs around
> this wasn't clear either. I still don't understand why it needs that
> field to be initialized whereas its equivalent anonymous class
> counterpart doesn't need it to be initialized. With my limited
> understanding of lambdas I was under the impression that the members
> used in the lambda expression will only be evaluated when the lambda is
> invoked, by which time, in this specific case the field will be
> initialized since it's a final member of the instance.

ok, first, you have to understand that the uninitialised fields detection in constructors is here to avoid users to routinely shoot themselves into the foot, it's like a fence near a cliff.
It relies on the fact that the compiler can see if the code use a field before the field being initialized but obviously we know that for some codes the compiler has no way to see if the field is really initialized or not.
Now, there are two kinds of lambdas, lambdas that are delayed computations and lambdas that abstract a block of code (as a function abstract a block of code), the former are executed at some point in time, the later are executed directly. In some languages you have two different syntax, block and Proc in Ruby, in Kotlin, you tag the function that receive a lambda with inline if you want the lambda to act like a block of code. In Java, there is no way to tell the difference but we want to stay open to make a difference between the two use cases in the future.

So given that detecting uninitialised fields is a user protection mechanism and that in the future, we may make a difference between the two kind of lambdas, the lambda expert group has decided that the compiler will consider the worst case, i.e. that lambdas can be executed just after being created.

Here is an example of lambdas used as block of code executed directly
  class Foo {
    final String name;
 
    Foo(List<String> list) {
      list.removeIf(s -> s.equals(name));
      name = ...
    }
  }  


> 
> 2. The mailing list index[1] mentioned this as the place for "Technical
> discussion related to the JDK Project".
> 
> Having said that, I do respect and understand what you mean by this
> being a user/usage question and I'll pursue this further in a different
> forum.
> 
> [1] https://mail.openjdk.java.net/mailman/listinfo
> 
> -Jaikiran

R?mi

> 
> On 04/03/19 6:07 PM, Remi Forax wrote:
>> Hi Jaikiran,
>> the initialisation block is called before the constructor so at that point name
>> is not initialised, that why your first code fails.
>> For the second one,
>>   this.suppliers.put("a", new Supplier<String>() {
>>              @Override
>>              public String get() {
>>                  return name;
>>              }
>>   });
>>
>>   "return name" here is equivalent to return LambdaTest.this.name, with
>>   LambdaTest.this being the same reference as this inside the initialization
>>   block,
>>   at that point the compiler doesn't track if name is initialized or not anymore,
>>   that's why it compiles.
>>
>> so you can fool the compiler the same way with a lambda by introducing a local
>> variable, i.e the example below should compile
>>     {
>>         var that = this;
>>         this.suppliers.put("a", () -> that.name);
>>     }
>>
>> Note, this mailing list is a list to discuss how to implement the JDK not how to
>> use it.
>> This kind of question will be answered better and faster on stackoverflow.com.
>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Jaikiran Pai" <jai.forums2013 at gmail.com>
>>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>>> Envoy?: Lundi 4 Mars 2019 10:56:28
>>> Objet: Lambda expression using a final field in object initialization block
>>> Please consider this trivial code:
>>>
>>>
>>> import java.util.Map;
>>> import java.util.HashMap;
>>> import java.util.function.Supplier;
>>>
>>> public class LambdaTest {
>>> ??? private final String name;
>>>
>>> ??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
>>>
>>> ??? {
>>> ??? ??? this.suppliers.put("a", () -> name);
>>> ??? }
>>>
>>> ??? private LambdaTest(final String name) {
>>> ??? ??? this.name = name;
>>> ??? }
>>>
>>> ??? public static void main(final String[] args) throws Exception {
>>> ??? ??? final LambdaTest self = new LambdaTest("hello");
>>> ??? }
>>> }
>>>
>>> When I compile this with Java 8 (javac 1.8.0_172) and even Java 11
>>> (javac 11.0.1), I get a compilation error, in the object initialization
>>> block where I am using a lambda expression to populate the "suppliers"
>>> Map and am referring to a final field (called "name") of the class. The
>>> compilation error is:
>>>
>>> LambdaTest.java:12: error: variable name might not have been initialized
>>> ?? ??? ?this.suppliers.put("a", () -> name);
>>> ?? ??? ?????????????????????????????? ^
>>> 1 error
>>>
>>> Now, if I replace that piece of code with:
>>>
>>>
>>> import java.util.Map;
>>> import java.util.HashMap;
>>> import java.util.function.Supplier;
>>>
>>> public class LambdaTest {
>>> ??? private final String name;
>>>
>>> ??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
>>>
>>> ??? {
>>> ??? ??? this.suppliers.put("a", new Supplier<String>() {
>>> ??????????? @Override
>>> ??????????? public String get() {
>>> ??????????????? return name;
>>> ??????????? }
>>> ??????? });
>>> ??? }
>>>
>>> ??? private LambdaTest(final String name) {
>>> ??? ??? this.name = name;
>>> ??? }
>>>
>>> ??? public static void main(final String[] args) throws Exception {
>>> ??? ??? final LambdaTest self = new LambdaTest("hello");
>>> ??? }
>>> }
>>>
>>> The only change in this is the object initialization block, where I no
>>> longer use a lambda and instead use an anonymous class. This passes
>>> compilation successfully.
>>>
>>> Why is it an error to use such a final field in a lambda expression? The
>>> (basic) documentation[1] of Lambda expressions doesn't seem to mention
>>> this construct as invalid.
>>>
>>>
>>> [1]
>>> https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html
>>>
> >> -Jaikiran

From jonathan.gibbons at oracle.com  Wed Mar  6 21:06:43 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 6 Mar 2019 13:06:43 -0800
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <942f37e2-e2b7-75d6-481e-c6fe483bf943@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
 <942f37e2-e2b7-75d6-481e-c6fe483bf943@oracle.com>
Message-ID: <d9c92a38-f5d5-51f4-557d-7497bd52b4c8@oracle.com>

Sergey,

> Is it possible to catch such issues using doclint? 

In principle, yes; in practice, today: no.

I can and will update doclint to detect these issues, which reduces the 
problem to actually running doclint.

Right now, I'm using a custom annotation processor to detect and report 
problems. The line-numbers currently point to the declaration to which 
the doc comment applies; I hope to increase the resolution to the line 
number within the comment, and will include the reports in any bugs that 
get filed.

-- Jon


On 03/05/2019 05:08 PM, Sergey Bylokhov wrote:
> Hi, Jonathan.
>
> Is it possible to catch such issues using doclint?
>
> On 05/03/2019 17:04, Jonathan Gibbons wrote:
>> In our ongoing endeavors to improve the accessibility of the Java SE
>> and JDK API documentation, we need to pay attention to headings.
>> In this context, "heading" refers to the use of HTML tags <h1> ... <h6>
>> in the generated documentation.
>>
>> There are 3 problem areas; all need to be fixed to address the goal
>> of being able to generate accessible Java SE and JDK API documentation.
>>
>> ??1. The standard doclet was inconsistent about its use of headings,
>> ???? using <h1> for the main heading on some pages, and <h2> for the
>> ???? main heading on other pages. This has now been fixed, and the
>> ???? main heading is now <h1> on all pages.
>> ??2. The standard doclet provides little-to-no guidance as to the use of
>> ???? headings in documentation comments. This will be fixed.
>> ???? To summarize, headings in documentation comments for modules, 
>> packages
>> ???? and types should start at <h2>; headings in documentation comments
>> ???? for members of a type (field, constructor, method, etc) should 
>> start
>> ???? at <h4>.
>> ??3. Many headings in documentation comments do not follow the best
>> ???? practices for headings in accessible documents. For example, many
>> ???? classes in java.lang.invoke use <h1> repeatedly within the
>> ???? documentation comments.
>>
>> The best practices are all to facilitate navigating and reading the page
>> with a screen reader, and can be summarized as follows:
>>
>> ?? * The main heading for a page should be <h1>
>> ?? * There should be just one <h1> per page
>> ?? * Headings should be hierarchical, and without ascending gaps, so 
>> <h1>
>> ???? should be followed by <h2>, <h2> should be followed by <h3> or
>> ???? another <h2>, etc.? It is OK to have "missing" headings when
>> ???? starting a new higher level section, so that <h4> may be 
>> followed by
>> ???? <h2>, for example; in that case, the <h2> would implicitly end the
>> ???? preceding section at the <h4> level and the one at the <h3> level.
>>
>> Now that javadoc has been fixed to generate consistent headings, we need
>> to address the headings in JDK API comments. The good news is that 
>> headings
>> in comments are relatively rare (about 600 overall) and of those, 
>> only about
>> 174 need to be fixed, in 126 files in 49 packages in 12 modules.
>>
>> Now that we have identified the headings that need to be fixed, I'll be
>> filing bugs against the various areas.? The issues fall into two 
>> categories:
>>
>> * Missing headings: these have generally been caused by changing javadoc
>> ?? to start headings at <h1> instead of <h2>.
>> ?? There are 105 instances of this issue.
>>
>> * Low headings: these are generally because of bad use of headings in
>> ?? documentation comments, such as the inappropriate use of <h1> or 
>> <h2> within
>> ?? a comment.
>> ?? There are 69 instances of this issue.
>>
>> -- Jon
>>
>
>


From nati.zelig at overopshq.com  Thu Mar  7 10:19:36 2019
From: nati.zelig at overopshq.com (Nati Zelig)
Date: Thu, 7 Mar 2019 12:19:36 +0200
Subject: [Java 10 - 11 - 12 ] JDK-8210457 : JVM crash in
 ResolvedMethodTable::add_method(Handle)
Message-ID: <CAGp8WZWBFQKgNdCKeRXr0mUM__SFp_3LNSuLK9Fm3Qb5Y2ohdA@mail.gmail.com>

Hello all,
The company I work for is developing a solution for JVM's, as a native
agent which performing redefinition of some of the classes loaded.
Since JDK 10 (Tested up to 11), the JVM is crashing as noted in OpenJDK bug
list:
https://bugs.openjdk.java.net/browse/JDK-8210457.
This issue is affecting our ability to support those versions.
1. What are the changes cause this crash to appear? (maybe link to a
commit).
2. Is this crash will be fixed for version 10, 11 and 12? (I saw the fix
intended for JDK 13).
Thanks,
Netanel.

From rfscholte at apache.org  Thu Mar  7 18:52:35 2019
From: rfscholte at apache.org (Robert Scholte)
Date: Thu, 07 Mar 2019 19:52:35 +0100
Subject: [RFE] Control Relative Path Resolution
In-Reply-To: <op.zw2790s6kdkhrr@desktop-2khsk44>
References: <op.zw2790s6kdkhrr@desktop-2khsk44>
Message-ID: <op.zyapdxfkkdkhrr@desktop-2khsk44.dynamic.ziggo.nl>

In conclusion: System properties is not an option.
However, the original request stays: being able to control relative path  
resolution.

In search for another solution I had a look at an approach mentioned by  
Alan: the FileSystem.
It was possible to make it work for java.nio.file.Path, but not for  
java.io.File.[1]
But even for Path I had to wrap several classes, which is not my preferred  
solution, since the wrapped instance will never be able to call a  
reimplemented method like toAbsolutePath().
Controlling the root of a FileSystem seems the missing feature here.

I'm open for any proper solution, but it seems this can be fixed within  
the JVM, ideally for both File and Path to keep all those Java projects  
working with paths relative to the pom's directory.

thanks,
Robert

[1] https://github.com/apache/maven-studies/tree/maven-basedir-filesystem

On Tue, 12 Feb 2019 08:26:14 +0100, Robert Scholte <rfscholte at apache.org>  
wrote:

> Recently an interesting change has been applied to the codebase of the  
> JDK: Several predefined System properties are now read-only. This makes  
> the runtime more robust, so we consider this as a great improvement.
>
> However, this introduces a new challenge, in this case regarding the  
> system property 'user.dir', since it has different purposes. Some Maven  
> plugins change this value in some cases as it is the only way to control  
> the resolution of relative paths. Being able to change the "working  
> directory" gives several interesting benefits, which should not impact  
> other usages of user.dir.
>
> TLDR: As a Java User
>        I want a *standard* way to control the resolution of a File with  
> a relative path
>        So that I'm not forced to start a new JVM
>
> Backgrounds:
>
> # How java.io.File works (from JavaDoc):
>
> ...
>
> A pathname, whether abstract or in string form, may be either absolute  
> or relative. An absolute pathname is complete in that no other  
> information is required in order to locate the file that it denotes. A  
> relative pathname, in contrast, must be interpreted in terms of  
> information taken from some other pathname. By default the classes in  
> the java.io package always resolve relative pathnames against the  
> current user directory. This directory is named by the system property  
> user.dir, and is typically the directory in which the Java virtual  
> machine was invoked.
>
> ...
>
> # How Apache Maven works:
>
> root
>   - pom.xml
>   \- M1
>   |   - pom.xml
>   \- M2
>       - pom.xml|
>       \- M3
>           -pom.xml
>
> (when talking about a Maven module, this is a directory with a pom.xml  
> containing instructions, in general to compile sources of one of the  
> subfolders and to package it into a jar)
>
> Maven has the concept of a multi-module project, which is a tree of  
> directories containing several pom.xml files. There are in this picture  
> 2 kinds om poms: aggregator-poms to trigger other poms and project-poms  
> to compile,test and package the content of that folder. It is possible  
> to start anywhere in this tree. In fact it is even possible to start  
> outside this tree and run maven like 'mvn -f /path/to/any/pom.xml'. This  
> should clearly explain there's no relation between the starting  
> directory (user.dir) and the working directory.
>
> In Maven the best practice is to use relative paths when working with  
> files. This is always relative to the folder containing the pom.xml of  
> that Maven module. This way we can ensure that files are always  
> calculated correctly no matter where and how you start Maven. For  
> instance, IDE's follow the same concept.
>
> # In practice
>
> What we also see is that people are having problems understanding  
> inputstreams. The following codefragments we see quite often:
>
> File f = new File( "src/test/resources/README.md" );
> FileReader is = new FileReader( f );
>
> Knowing that files under src/test/resources end up on the classpath,  
> this is the preferred solution:
> InputStream is = MyClass.class.getResourceAsStream("/README.md");
>
> However, others feel more comfortable with URLs and Files, resulting in:
> URL url = MyClass.class.getResource("/README.md");
> File f = url.getFile();
> FileReader is = new FileReader( f );
>
> (this works as long as the compiled classfiles are in a directory and  
> not in a jar)
> Depending on the knowledge, unexperienced developers tend to fall back  
> to Files when possible. However, they do understand the difference  
> between relative and absolute paths.
>
> # Evaluation
>
> This topic has been discussed with several OpenJDK developers from  
> Oracle and committers of the Apache Maven team at FOSDEM 2019 and we  
> came to the following conclusions:
>
> Consider: File f = new File( "a/b/c" );
>
> Available solutions:
> * Use the classpath as much as possible
>    - not always possible, in some cases you are forces to work with  
> files.
>
> * Start a new JVM from the expected directory
>    Consequences are:
>    - longer execution time (even though the JVM startup time has  
> improved over the years)
>    - more memory consumption
>    (we recently received an email from somebody having a Maven  
> Multimodule project of ~1600 modules, getting close to its limits. For a  
> project like this, being forced to fork has a negative impact)
>
> * File f = new File( System.property( "file.basedir", ""), "a/b/c" );
>    Consequences are:
>    - Developers must rewrite their code, including every time the *same*  
> statement when relative paths are used
>    - The execution framework should provide this 'magic' property and  
> might pick their own name. E.g. in cases of unittests it would be best  
> to have the same name used by Surefire(Maven) and all IDEs, since they  
> all have their own test execution framework.
>
> # Proposal
>
> All the options above would not require any changes to the JDK. However,  
> after rethinking these solutions with the Maven committers we would like  
> to see a small change in the JDK itself.
>
> The Java community would benefit if the JDK would specify 1 *mutable*  
> System property to control the basedir of a File. This property would  
> default to the value of 'user.dir' to keep the current behavior. With  
> this there is exactly 1 way for all to adjust the resolution of relative  
> paths.
> This would make it possible to remain the original behavior (users don't  
> have to change their code) and to make the JDK more robust by keeping  
> user.dir read-only.
>
> With regards,
> Robert Scholte

From christoph.langer at sap.com  Fri Mar  8 08:10:22 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 8 Mar 2019 08:10:22 +0000
Subject: [Java 10 - 11 - 12 ] JDK-8210457 : JVM crash in
 ResolvedMethodTable::add_method(Handle)
In-Reply-To: <CAGp8WZWBFQKgNdCKeRXr0mUM__SFp_3LNSuLK9Fm3Qb5Y2ohdA@mail.gmail.com>
References: <CAGp8WZWBFQKgNdCKeRXr0mUM__SFp_3LNSuLK9Fm3Qb5Y2ohdA@mail.gmail.com>
Message-ID: <HE1PR0201MB2266982D2630D53A1F1D48A98A4D0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Nethanel,

> Since JDK 10 (Tested up to 11), the JVM is crashing as noted in OpenJDK bug
> list:
> https://bugs.openjdk.java.net/browse/JDK-8210457.
> This issue is affecting our ability to support those versions.
> 1. What are the changes cause this crash to appear? (maybe link to a
> commit).
> 2. Is this crash will be fixed for version 10, 11 and 12? (I saw the fix
> intended for JDK 13).

I can see that the fix for this issue is quite young. It just went in to the jdk/jdk codebase (OpenJDK 13) a few days ago. You should probably ask your questions on the serviceability-dev and/or hotspot-runtime-dev mailing lists since the fix was discussed there.

At the end, I think the fix could be backported to upcoming update releases of JDK11 and JDK12 (JDK10 is out of maintenance). But as it seems it's not a small and trivial fix (It does not even apply straight on the jdk12u codebase), you'll have to ask on the mentioned mailing lists for a sponsors of these backports who will do the work of integrating and testing.

Best regards
Christoph


From jai.forums2013 at gmail.com  Sat Mar  9 13:29:14 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 9 Mar 2019 18:59:14 +0530
Subject: Lambda expression using a final field in object initialization
 block
In-Reply-To: <1226251956.526928.1551875485492.JavaMail.zimbra@u-pem.fr>
References: <5a1fd1b4-0cea-956f-9c35-f0b458ba613b@gmail.com>
 <463600466.90277.1551703073579.JavaMail.zimbra@u-pem.fr>
 <619bba7a-f08a-99fd-b8e8-a48fe7636abf@gmail.com>
 <1226251956.526928.1551875485492.JavaMail.zimbra@u-pem.fr>
Message-ID: <b779c6d5-aa29-12e0-81c6-6eab57d90dd8@gmail.com>

Hello Remi,

Thank you for that detailed explanation. That was helpful!

-Jaikiran

On 06/03/19 6:01 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Jaikiran Pai" <jai.forums2013 at gmail.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
>> Envoy?: Mercredi 6 Mars 2019 07:38:24
>> Objet: Re: Lambda expression using a final field in object initialization block
>> Hello Remi,
>>
>> Thank you for responding :) The reason why I asked this in the jdk-dev
>> mailing list was a combination of 2 things:
>>
>> 1. I didn't understand why the compiler would want the value to be
>> initialized at all at that place in the lambda usage and the docs around
>> this wasn't clear either. I still don't understand why it needs that
>> field to be initialized whereas its equivalent anonymous class
>> counterpart doesn't need it to be initialized. With my limited
>> understanding of lambdas I was under the impression that the members
>> used in the lambda expression will only be evaluated when the lambda is
>> invoked, by which time, in this specific case the field will be
>> initialized since it's a final member of the instance.
> ok, first, you have to understand that the uninitialised fields detection in constructors is here to avoid users to routinely shoot themselves into the foot, it's like a fence near a cliff.
> It relies on the fact that the compiler can see if the code use a field before the field being initialized but obviously we know that for some codes the compiler has no way to see if the field is really initialized or not.
> Now, there are two kinds of lambdas, lambdas that are delayed computations and lambdas that abstract a block of code (as a function abstract a block of code), the former are executed at some point in time, the later are executed directly. In some languages you have two different syntax, block and Proc in Ruby, in Kotlin, you tag the function that receive a lambda with inline if you want the lambda to act like a block of code. In Java, there is no way to tell the difference but we want to stay open to make a difference between the two use cases in the future.
>
> So given that detecting uninitialised fields is a user protection mechanism and that in the future, we may make a difference between the two kind of lambdas, the lambda expert group has decided that the compiler will consider the worst case, i.e. that lambdas can be executed just after being created.
>
> Here is an example of lambdas used as block of code executed directly
>   class Foo {
>     final String name;
>  
>     Foo(List<String> list) {
>       list.removeIf(s -> s.equals(name));
>       name = ...
>     }
>   }  
>
>
>> 2. The mailing list index[1] mentioned this as the place for "Technical
>> discussion related to the JDK Project".
>>
>> Having said that, I do respect and understand what you mean by this
>> being a user/usage question and I'll pursue this further in a different
>> forum.
>>
>> [1] https://mail.openjdk.java.net/mailman/listinfo
>>
>> -Jaikiran
> R?mi
>
>> On 04/03/19 6:07 PM, Remi Forax wrote:
>>> Hi Jaikiran,
>>> the initialisation block is called before the constructor so at that point name
>>> is not initialised, that why your first code fails.
>>> For the second one,
>>>   this.suppliers.put("a", new Supplier<String>() {
>>>              @Override
>>>              public String get() {
>>>                  return name;
>>>              }
>>>   });
>>>
>>>   "return name" here is equivalent to return LambdaTest.this.name, with
>>>   LambdaTest.this being the same reference as this inside the initialization
>>>   block,
>>>   at that point the compiler doesn't track if name is initialized or not anymore,
>>>   that's why it compiles.
>>>
>>> so you can fool the compiler the same way with a lambda by introducing a local
>>> variable, i.e the example below should compile
>>>     {
>>>         var that = this;
>>>         this.suppliers.put("a", () -> that.name);
>>>     }
>>>
>>> Note, this mailing list is a list to discuss how to implement the JDK not how to
>>> use it.
>>> This kind of question will be answered better and faster on stackoverflow.com.
>>>
>>> regards,
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Jaikiran Pai" <jai.forums2013 at gmail.com>
>>>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>>>> Envoy?: Lundi 4 Mars 2019 10:56:28
>>>> Objet: Lambda expression using a final field in object initialization block
>>>> Please consider this trivial code:
>>>>
>>>>
>>>> import java.util.Map;
>>>> import java.util.HashMap;
>>>> import java.util.function.Supplier;
>>>>
>>>> public class LambdaTest {
>>>> ??? private final String name;
>>>>
>>>> ??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
>>>>
>>>> ??? {
>>>> ??? ??? this.suppliers.put("a", () -> name);
>>>> ??? }
>>>>
>>>> ??? private LambdaTest(final String name) {
>>>> ??? ??? this.name = name;
>>>> ??? }
>>>>
>>>> ??? public static void main(final String[] args) throws Exception {
>>>> ??? ??? final LambdaTest self = new LambdaTest("hello");
>>>> ??? }
>>>> }
>>>>
>>>> When I compile this with Java 8 (javac 1.8.0_172) and even Java 11
>>>> (javac 11.0.1), I get a compilation error, in the object initialization
>>>> block where I am using a lambda expression to populate the "suppliers"
>>>> Map and am referring to a final field (called "name") of the class. The
>>>> compilation error is:
>>>>
>>>> LambdaTest.java:12: error: variable name might not have been initialized
>>>> ?? ??? ?this.suppliers.put("a", () -> name);
>>>> ?? ??? ?????????????????????????????? ^
>>>> 1 error
>>>>
>>>> Now, if I replace that piece of code with:
>>>>
>>>>
>>>> import java.util.Map;
>>>> import java.util.HashMap;
>>>> import java.util.function.Supplier;
>>>>
>>>> public class LambdaTest {
>>>> ??? private final String name;
>>>>
>>>> ??? private final Map<String, Supplier<String>> suppliers = new HashMap<>();
>>>>
>>>> ??? {
>>>> ??? ??? this.suppliers.put("a", new Supplier<String>() {
>>>> ??????????? @Override
>>>> ??????????? public String get() {
>>>> ??????????????? return name;
>>>> ??????????? }
>>>> ??????? });
>>>> ??? }
>>>>
>>>> ??? private LambdaTest(final String name) {
>>>> ??? ??? this.name = name;
>>>> ??? }
>>>>
>>>> ??? public static void main(final String[] args) throws Exception {
>>>> ??? ??? final LambdaTest self = new LambdaTest("hello");
>>>> ??? }
>>>> }
>>>>
>>>> The only change in this is the object initialization block, where I no
>>>> longer use a lambda and instead use an anonymous class. This passes
>>>> compilation successfully.
>>>>
>>>> Why is it an error to use such a final field in a lambda expression? The
>>>> (basic) documentation[1] of Lambda expressions doesn't seem to mention
>>>> this construct as invalid.
>>>>
>>>>
>>>> [1]
>>>> https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html
>>>>
>>>> -Jaikiran

From david.holmes at oracle.com  Mon Mar 11 02:32:03 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Mar 2019 12:32:03 +1000
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
Message-ID: <94641a07-d1a1-bbcd-e473-3edff2205ef9@oracle.com>

Hi Jon,

On 6/03/2019 11:04 am, Jonathan Gibbons wrote:
> In our ongoing endeavors to improve the accessibility of the Java SE
> and JDK API documentation, we need to pay attention to headings.
> In this context, "heading" refers to the use of HTML tags <h1> ... <h6>
> in the generated documentation.
> 
> There are 3 problem areas; all need to be fixed to address the goal
> of being able to generate accessible Java SE and JDK API documentation.
> 
>  ?1. The standard doclet was inconsistent about its use of headings,
>  ??? using <h1> for the main heading on some pages, and <h2> for the
>  ??? main heading on other pages. This has now been fixed, and the
>  ??? main heading is now <h1> on all pages.

Is this:

<h2 title="Interface ExecutorService" class="title">Interface 
ExecutorService</h2>

one of the h2's that will now be a h1?

If so, if the page heading is a h1 for a given class or interface, then 
I would have expected the field/method/constructor sections to 
implicitly act like h2 (as they are the structural entities of the 
class/interface), and so within that text h3 would be the logical 
heading to use - ref: JDK-8220248. Using h2 in such contexts just seems 
wrong to me.

>  ?2. The standard doclet provides little-to-no guidance as to the use of
>  ??? headings in documentation comments. This will be fixed.
>  ??? To summarize, headings in documentation comments for modules, packages
>  ??? and types should start at <h2>; headings in documentation comments
>  ??? for members of a type (field, constructor, method, etc) should start
>  ??? at <h4>.

?? What happened to h3? And how does this relate back to "the main 
heading is now h1"?

>  ?3. Many headings in documentation comments do not follow the best
>  ??? practices for headings in accessible documents. For example, many
>  ??? classes in java.lang.invoke use <h1> repeatedly within the
>  ??? documentation comments.
> 
> The best practices are all to facilitate navigating and reading the page
> with a screen reader, and can be summarized as follows:
> 
>  ? * The main heading for a page should be <h1>
>  ? * There should be just one <h1> per page
>  ? * Headings should be hierarchical, and without ascending gaps, so <h1>
>  ??? should be followed by <h2>, <h2> should be followed by <h3> or
>  ??? another <h2>, etc.? It is OK to have "missing" headings when
>  ??? starting a new higher level section, so that <h4> may be followed by
>  ??? <h2>, for example; in that case, the <h2> would implicitly end the
>  ??? preceding section at the <h4> level and the one at the <h3> level.

Well that makes perfect sense if you are writing a book chapter, or some 
normal multi-part text document. But the API pages are not like that, 
they are more like advanced tables, and the use of any heading tag 
within table cells is highly questionable to begin with. So I'm not 
seeing how these rules really apply to our API docs.

Thanks,
David
-----

> Now that javadoc has been fixed to generate consistent headings, we need
> to address the headings in JDK API comments. The good news is that headings
> in comments are relatively rare (about 600 overall) and of those, only 
> about
> 174 need to be fixed, in 126 files in 49 packages in 12 modules.
> 
> Now that we have identified the headings that need to be fixed, I'll be
> filing bugs against the various areas.? The issues fall into two 
> categories:
> 
> * Missing headings: these have generally been caused by changing javadoc
>  ? to start headings at <h1> instead of <h2>.
>  ? There are 105 instances of this issue.
> 
> * Low headings: these are generally because of bad use of headings in
>  ? documentation comments, such as the inappropriate use of <h1> or <h2> 
> within
>  ? a comment.
>  ? There are 69 instances of this issue.
> 
> -- Jon
> 

From jonathan.gibbons at oracle.com  Mon Mar 11 03:42:02 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 10 Mar 2019 20:42:02 -0700
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <94641a07-d1a1-bbcd-e473-3edff2205ef9@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
 <94641a07-d1a1-bbcd-e473-3edff2205ef9@oracle.com>
Message-ID: <6059aaa3-eb25-0c71-e1fb-af8b804e012c@oracle.com>


On 3/10/19 7:32 PM, David Holmes wrote:
> But the API pages are not like that, they are more like advanced 
> tables, and the use of any heading tag within table cells is highly 
> questionable to begin with. So I'm not seeing how these rules really 
> apply to our API docs. 


The "summary" section of the page for a type declaration (class, 
interface, enum etc) is indeed rendered as a table, and only the first 
sentence of each doc comment for a member appears in the table.

The "details" section of the page for a type declaration is rendered as 
a list, not a table, although we have identified some bugs in the 
presentation of that list that we are working to address.

You might still reasonably say that? heading tags are inadvisable within 
the doc comment for a member, and I wouldn't entirely disagree, but the 
fact remains that there are headings in doc comments, and this work is 
about doing the best we can to rationalize the structure of those 
headings, into the structure of the page generated by javadoc.

-- Jon


From david.holmes at oracle.com  Mon Mar 11 06:32:49 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Mar 2019 16:32:49 +1000
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <6059aaa3-eb25-0c71-e1fb-af8b804e012c@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
 <94641a07-d1a1-bbcd-e473-3edff2205ef9@oracle.com>
 <6059aaa3-eb25-0c71-e1fb-af8b804e012c@oracle.com>
Message-ID: <b3d0f8bc-75b2-92d4-ceb4-dc9297c3c3e6@oracle.com>

On 11/03/2019 1:42 pm, Jonathan Gibbons wrote:
> 
> On 3/10/19 7:32 PM, David Holmes wrote:
>> But the API pages are not like that, they are more like advanced 
>> tables, and the use of any heading tag within table cells is highly 
>> questionable to begin with. So I'm not seeing how these rules really 
>> apply to our API docs. 
> 
> 
> The "summary" section of the page for a type declaration (class, 
> interface, enum etc) is indeed rendered as a table, and only the first 
> sentence of each doc comment for a member appears in the table.
> 
> The "details" section of the page for a type declaration is rendered as 
> a list, not a table, although we have identified some bugs in the 
> presentation of that list that we are working to address.

It may be rendered as a list but the whole thing has the look of a 
complex table. Regardless, the "headings" within those entries do not 
relate to any overall heading structure for the entire page.

> 
> You might still reasonably say that? heading tags are inadvisable within 
> the doc comment for a member, and I wouldn't entirely disagree, but the 
> fact remains that there are headings in doc comments, and this work is 
> about doing the best we can to rationalize the structure of those 
> headings, into the structure of the page generated by javadoc.

Sorry but I can't see how changing h3 to h2 within a 
field/method/constructor improves anything. Those h3 don't relate to the 
existing h1 except in the loosest possible way. They don't define 
subsections of the original h1 (which is what an h2 would be doing).

You'd be better off replacing them with non-header tags IMHO.

David
-----

> -- Jon
> 

From david.holmes at oracle.com  Mon Mar 11 06:46:54 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Mar 2019 16:46:54 +1000
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <b3d0f8bc-75b2-92d4-ceb4-dc9297c3c3e6@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
 <94641a07-d1a1-bbcd-e473-3edff2205ef9@oracle.com>
 <6059aaa3-eb25-0c71-e1fb-af8b804e012c@oracle.com>
 <b3d0f8bc-75b2-92d4-ceb4-dc9297c3c3e6@oracle.com>
Message-ID: <4e58122e-0b5a-68bb-3bd8-bcd2bdc560e8@oracle.com>

On 11/03/2019 4:32 pm, David Holmes wrote:
> On 11/03/2019 1:42 pm, Jonathan Gibbons wrote:
>>
>> On 3/10/19 7:32 PM, David Holmes wrote:
>>> But the API pages are not like that, they are more like advanced 
>>> tables, and the use of any heading tag within table cells is highly 
>>> questionable to begin with. So I'm not seeing how these rules really 
>>> apply to our API docs. 
>>
>>
>> The "summary" section of the page for a type declaration (class, 
>> interface, enum etc) is indeed rendered as a table, and only the first 
>> sentence of each doc comment for a member appears in the table.
>>
>> The "details" section of the page for a type declaration is rendered 
>> as a list, not a table, although we have identified some bugs in the 
>> presentation of that list that we are working to address.
> 
> It may be rendered as a list but the whole thing has the look of a 
> complex table. Regardless, the "headings" within those entries do not 
> relate to any overall heading structure for the entire page.
> 
>>
>> You might still reasonably say that? heading tags are inadvisable 
>> within the doc comment for a member, and I wouldn't entirely disagree, 
>> but the fact remains that there are headings in doc comments, and this 
>> work is about doing the best we can to rationalize the structure of 
>> those headings, into the structure of the page generated by javadoc.
> 
> Sorry but I can't see how changing h3 to h2 within a 
> field/method/constructor improves anything. Those h3 don't relate to the 
> existing h1 except in the loosest possible way. They don't define 
> subsections of the original h1 (which is what an h2 would be doing).

Sorry I misread the examples in the bug report - they are not in the 
field/method/constructor entries but the top-level class/interface docs. 
Use of h2 in that context is less problematic. The way we lay things out 
makes it very hard to see where actual "headings are. For example, given:


Module java.base
Package java.util.concurrent.locks
Interface Lock

     All Known Implementing Classes:
         ReentrantLock, ReentrantReadWriteLock.ReadLock, 
ReentrantReadWriteLock.WriteLock

     public interface Lock

where is the h1? I could argue it should be "Interface Lock", with 
"public interface Lock" then arguably a h2, and then the headings in the 
main javadoc would be correctly left as h3.

But if "public interface Lock" is the h1 then the headings would 
correctly be changed to h2.

David
-----

> You'd be better off replacing them with non-header tags IMHO.
> 
> David
> -----
> 
>> -- Jon
>>

From lance.andersen at oracle.com  Mon Mar 11 11:41:32 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 11 Mar 2019 07:41:32 -0400
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <d9c92a38-f5d5-51f4-557d-7497bd52b4c8@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
 <942f37e2-e2b7-75d6-481e-c6fe483bf943@oracle.com>
 <d9c92a38-f5d5-51f4-557d-7497bd52b4c8@oracle.com>
Message-ID: <C0AC4E1C-1DE0-4B52-959B-DB5A37BFB649@oracle.com>

Hi Jon,

Once we fix (or believe we have), is there a way to validate that we addressed the issue? 

Best
Lance
> On Mar 6, 2019, at 4:06 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Sergey,
> 
>> Is it possible to catch such issues using doclint? 
> 
> In principle, yes; in practice, today: no.
> 
> I can and will update doclint to detect these issues, which reduces the problem to actually running doclint.
> 
> Right now, I'm using a custom annotation processor to detect and report problems. The line-numbers currently point to the declaration to which the doc comment applies; I hope to increase the resolution to the line number within the comment, and will include the reports in any bugs that get filed.
> 
> -- Jon
> 
> 
> On 03/05/2019 05:08 PM, Sergey Bylokhov wrote:
>> Hi, Jonathan.
>> 
>> Is it possible to catch such issues using doclint?
>> 
>> On 05/03/2019 17:04, Jonathan Gibbons wrote:
>>> In our ongoing endeavors to improve the accessibility of the Java SE
>>> and JDK API documentation, we need to pay attention to headings.
>>> In this context, "heading" refers to the use of HTML tags <h1> ... <h6>
>>> in the generated documentation.
>>> 
>>> There are 3 problem areas; all need to be fixed to address the goal
>>> of being able to generate accessible Java SE and JDK API documentation.
>>> 
>>>   1. The standard doclet was inconsistent about its use of headings,
>>>      using <h1> for the main heading on some pages, and <h2> for the
>>>      main heading on other pages. This has now been fixed, and the
>>>      main heading is now <h1> on all pages.
>>>   2. The standard doclet provides little-to-no guidance as to the use of
>>>      headings in documentation comments. This will be fixed.
>>>      To summarize, headings in documentation comments for modules, packages
>>>      and types should start at <h2>; headings in documentation comments
>>>      for members of a type (field, constructor, method, etc) should start
>>>      at <h4>.
>>>   3. Many headings in documentation comments do not follow the best
>>>      practices for headings in accessible documents. For example, many
>>>      classes in java.lang.invoke use <h1> repeatedly within the
>>>      documentation comments.
>>> 
>>> The best practices are all to facilitate navigating and reading the page
>>> with a screen reader, and can be summarized as follows:
>>> 
>>>    * The main heading for a page should be <h1>
>>>    * There should be just one <h1> per page
>>>    * Headings should be hierarchical, and without ascending gaps, so <h1>
>>>      should be followed by <h2>, <h2> should be followed by <h3> or
>>>      another <h2>, etc.  It is OK to have "missing" headings when
>>>      starting a new higher level section, so that <h4> may be followed by
>>>      <h2>, for example; in that case, the <h2> would implicitly end the
>>>      preceding section at the <h4> level and the one at the <h3> level.
>>> 
>>> Now that javadoc has been fixed to generate consistent headings, we need
>>> to address the headings in JDK API comments. The good news is that headings
>>> in comments are relatively rare (about 600 overall) and of those, only about
>>> 174 need to be fixed, in 126 files in 49 packages in 12 modules.
>>> 
>>> Now that we have identified the headings that need to be fixed, I'll be
>>> filing bugs against the various areas.  The issues fall into two categories:
>>> 
>>> * Missing headings: these have generally been caused by changing javadoc
>>>    to start headings at <h1> instead of <h2>.
>>>    There are 105 instances of this issue.
>>> 
>>> * Low headings: these are generally because of bad use of headings in
>>>    documentation comments, such as the inappropriate use of <h1> or <h2> within
>>>    a comment.
>>>    There are 69 instances of this issue.
>>> 
>>> -- Jon
>>> 
>> 
>> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From jonathan.gibbons at oracle.com  Mon Mar 11 14:41:11 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Mar 2019 07:41:11 -0700
Subject: Accessibility of JDK API documentation: headings
In-Reply-To: <C0AC4E1C-1DE0-4B52-959B-DB5A37BFB649@oracle.com>
References: <2eb0837a-2066-77ff-5ee2-5bb6bbfaba09@oracle.com>
 <942f37e2-e2b7-75d6-481e-c6fe483bf943@oracle.com>
 <d9c92a38-f5d5-51f4-557d-7497bd52b4c8@oracle.com>
 <C0AC4E1C-1DE0-4B52-959B-DB5A37BFB649@oracle.com>
Message-ID: <fab2f8fa-07d1-8cf9-90a3-f1a696fc5f6e@oracle.com>

Hi Lance,

I'm working to update doclint with improve validation of headings.? I 
hope to post the review for that work today.

-- Jon

On 3/11/19 4:41 AM, Lance Andersen wrote:
> Hi Jon,
>
> Once we fix (or believe we have), is there a way to validate that we 
> addressed the issue?
>
> Best
> Lance
>> On Mar 6, 2019, at 4:06 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>> Sergey,
>>
>>> Is it possible to catch such issues using doclint?
>>
>> In principle, yes; in practice, today: no.
>>
>> I can and will update doclint to detect these issues, which reduces 
>> the problem to actually running doclint.
>>
>> Right now, I'm using a custom annotation processor to detect and 
>> report problems. The line-numbers currently point to the declaration 
>> to which the doc comment applies; I hope to increase the resolution 
>> to the line number within the comment, and will include the reports 
>> in any bugs that get filed.
>>
>> -- Jon
>>
>>
>> On 03/05/2019 05:08 PM, Sergey Bylokhov wrote:
>>> Hi, Jonathan.
>>>
>>> Is it possible to catch such issues using doclint?
>>>
>>> On 05/03/2019 17:04, Jonathan Gibbons wrote:
>>>> In our ongoing endeavors to improve the accessibility of the Java SE
>>>> and JDK API documentation, we need to pay attention to headings.
>>>> In this context, "heading" refers to the use of HTML tags <h1> ... <h6>
>>>> in the generated documentation.
>>>>
>>>> There are 3 problem areas; all need to be fixed to address the goal
>>>> of being able to generate accessible Java SE and JDK API documentation.
>>>>
>>>> ??1. The standard doclet was inconsistent about its use of headings,
>>>> ???? using <h1> for the main heading on some pages, and <h2> for the
>>>> ???? main heading on other pages. This has now been fixed, and the
>>>> ???? main heading is now <h1> on all pages.
>>>> ??2. The standard doclet provides little-to-no guidance as to the 
>>>> use of
>>>> ???? headings in documentation comments. This will be fixed.
>>>> ???? To summarize, headings in documentation comments for modules, 
>>>> packages
>>>> ???? and types should start at <h2>; headings in documentation comments
>>>> ???? for members of a type (field, constructor, method, etc) should 
>>>> start
>>>> ???? at <h4>.
>>>> ??3. Many headings in documentation comments do not follow the best
>>>> ???? practices for headings in accessible documents. For example, many
>>>> ???? classes in java.lang.invoke use <h1> repeatedly within the
>>>> ???? documentation comments.
>>>>
>>>> The best practices are all to facilitate navigating and reading the 
>>>> page
>>>> with a screen reader, and can be summarized as follows:
>>>>
>>>> ?? * The main heading for a page should be <h1>
>>>> ?? * There should be just one <h1> per page
>>>> ?? * Headings should be hierarchical, and without ascending gaps, 
>>>> so <h1>
>>>> ???? should be followed by <h2>, <h2> should be followed by <h3> or
>>>> ???? another <h2>, etc.? It is OK to have "missing" headings when
>>>> ???? starting a new higher level section, so that <h4> may be 
>>>> followed by
>>>> ???? <h2>, for example; in that case, the <h2> would implicitly end the
>>>> ???? preceding section at the <h4> level and the one at the <h3> level.
>>>>
>>>> Now that javadoc has been fixed to generate consistent headings, we 
>>>> need
>>>> to address the headings in JDK API comments. The good news is that 
>>>> headings
>>>> in comments are relatively rare (about 600 overall) and of those, 
>>>> only about
>>>> 174 need to be fixed, in 126 files in 49 packages in 12 modules.
>>>>
>>>> Now that we have identified the headings that need to be fixed, I'll be
>>>> filing bugs against the various areas.? The issues fall into two 
>>>> categories:
>>>>
>>>> * Missing headings: these have generally been caused by changing 
>>>> javadoc
>>>> ?? to start headings at <h1> instead of <h2>.
>>>> ?? There are 105 instances of this issue.
>>>>
>>>> * Low headings: these are generally because of bad use of headings in
>>>> ?? documentation comments, such as the inappropriate use of <h1> or 
>>>> <h2> within
>>>> ?? a comment.
>>>> ?? There are 69 instances of this issue.
>>>>
>>>> -- Jon
>>>>
>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From jianglizhou at google.com  Tue Mar 12 23:15:25 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 12 Mar 2019 16:15:25 -0700
Subject: CFV: New JDK Committer: Man Cao
Message-ID: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>

I hereby nominate Man Cao (manc) to JDK committer.

Man works in the Java team at Google and has contributed 11 changesets [3].
His contributions focus on runtime performance improvement, garbage
collection, and bug fixes.

Votes are due by Tuesday March 26, 2019.

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].

Thanks,
Jiangli Zhou

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

Contributed-by:
8193386: CompressedClassSize too large with MaxMetaspace
8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
8210724: Change the verbosity threshold of logging for [oopstorage,ref]
Authored:
8210716: Detailed GC logging request misses some
8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
8213829: Remove circular dependency between g1CollectedHeap and
g1ConcurrentMark
8213224: Move code related to GC threads calculation out of
AdaptiveSizePolicy
8215043: Remove declaration of parallel_worker_threads
8215114: Fix indent and dead code in GCPolicyCounters
8218192: Remove copy constructor for MemRegion
8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
overhead

From jianglizhou at google.com  Tue Mar 12 23:24:43 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 12 Mar 2019 16:24:43 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <CALrW1jyemGfbKUs+8SxNscn-_+TGd-5mu4UgvEjoR7L7Vn0FAA@mail.gmail.com>

Vote: yes

Thanks,

Jiangli


On Tue, Mar 12, 2019 at 4:15 PM Jiangli Zhou <jianglizhou at google.com> wrote:

> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets
> [3]. His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
>

From david.holmes at oracle.com  Wed Mar 13 01:41:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Mar 2019 11:41:50 +1000
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <44928cf8-4898-097b-848f-bfcf1ce084d6@oracle.com>

Vote: yes

David

On 13/03/2019 9:15 am, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
> 

From jcbeyler at google.com  Wed Mar 13 02:13:38 2019
From: jcbeyler at google.com (Jean Christophe Beyler)
Date: Tue, 12 Mar 2019 19:13:38 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <CAF9BGBzvfhVwzkBoTYNy5=kWp8-ZPFb7BY0rv7q20aDFDb2PPQ@mail.gmail.com>

Vote: yes

On Tue, Mar 12, 2019 at 4:27 PM Jiangli Zhou <jianglizhou at google.com> wrote:

> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
>
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
>


-- 

Thanks,
Jc

From serguei.spitsyn at oracle.com  Wed Mar 13 02:18:15 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 12 Mar 2019 19:18:15 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <33e1b852-31eb-7c84-0337-573da0444c42@oracle.com>

Vote: yes

From christoph.langer at sap.com  Wed Mar 13 08:03:11 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Mar 2019 08:03:11 +0000
Subject: CFV: New JDK Committer: Man Cao
Message-ID: <HE1PR0201MB22669C30B3C00036601DF9EF8A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Vote: Yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Jiangli
> Zhou
> Sent: Mittwoch, 13. M?rz 2019 00:15
> To: jdk-dev at openjdk.java.net
> Subject: CFV: New JDK Committer: Man Cao
> 
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)
> +or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead

From thomas.schatzl at oracle.com  Wed Mar 13 08:20:20 2019
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 13 Mar 2019 09:20:20 +0100
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <dc7798f11e67ef9e662e721c9ad0aea86c61b8c3.camel@oracle.com>

Vote: yes



From shade at redhat.com  Wed Mar 13 08:22:26 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 13 Mar 2019 09:22:26 +0100
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <7e1201a0-26fe-503b-4aa5-6e8ebcc310be@redhat.com>

Vote: yes

On 3/13/19 12:15 AM, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.




From sgehwolf at redhat.com  Wed Mar 13 09:09:28 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 13 Mar 2019 10:09:28 +0100
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <dd5a162eeb167db2bbe76a4a26a8e84d9aa691e3.camel@redhat.com>

Vote: yes

On Tue, 2019-03-12 at 16:15 -0700, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead


From adinn at redhat.com  Wed Mar 13 09:19:34 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 13 Mar 2019 09:19:34 +0000
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <228ce995-63e5-efdb-1d4d-b63b64b1216a@redhat.com>

Vote: yes

On 12/03/2019 23:15, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
> 

-- 
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 stefan.karlsson at oracle.com  Wed Mar 13 09:21:10 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 13 Mar 2019 10:21:10 +0100
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <f052bad7-0260-2c0a-046c-2b4e3089942f@oracle.com>

Vote: yes

StefanK

On 2019-03-13 00:15, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
> 

From zgu at redhat.com  Wed Mar 13 11:36:26 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 13 Mar 2019 07:36:26 -0400
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CAF9BGBzvfhVwzkBoTYNy5=kWp8-ZPFb7BY0rv7q20aDFDb2PPQ@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
 <CAF9BGBzvfhVwzkBoTYNy5=kWp8-ZPFb7BY0rv7q20aDFDb2PPQ@mail.gmail.com>
Message-ID: <093957b5-3d07-e710-034c-3fe0e607e3f4@redhat.com>

Vote: yes

-Zhengyu

> 
>> I hereby nominate Man Cao (manc) to JDK committer.
>>
>> Man works in the Java team at Google and has contributed 11 changesets [3].
>> His contributions focus on runtime performance improvement, garbage
>> collection, and bug fixes.
>>
>> Votes are due by Tuesday March 26, 2019.
>>
>> 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].
>>
>> Thanks,
>> Jiangli Zhou
>>
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>> [3]
>>
>> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>>
>> Contributed-by:
>> 8193386: CompressedClassSize too large with MaxMetaspace
>> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
>> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
>> Authored:
>> 8210716: Detailed GC logging request misses some
>> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
>> 8213829: Remove circular dependency between g1CollectedHeap and
>> g1ConcurrentMark
>> 8213224: Move code related to GC threads calculation out of
>> AdaptiveSizePolicy
>> 8215043: Remove declaration of parallel_worker_threads
>> 8215114: Fix indent and dead code in GCPolicyCounters
>> 8218192: Remove copy constructor for MemRegion
>> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
>> overhead
>>
> 
> 

From eric.caspole at oracle.com  Wed Mar 13 13:25:53 2019
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Wed, 13 Mar 2019 09:25:53 -0400
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <d9608edd-9868-225f-fe18-1d4b7369c6a1@oracle.com>

Vote: yes

-Eric


On 3/12/19 7:15 PM, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead


From bhanu.prakash.gopularam at oracle.com  Wed Mar 13 13:30:45 2019
From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam)
Date: Wed, 13 Mar 2019 19:00:45 +0530
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <6E4126CC-F165-4FD5-B8C2-4CEC0CD59151@oracle.com>

Vote: Yes

Regards,
Bhanu

> On 13-Mar-2019, at 4:45 AM, Jiangli Zhou <jianglizhou at google.com> wrote:
> 
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead


From Roger.Riggs at oracle.com  Wed Mar 13 13:45:07 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 13 Mar 2019 09:45:07 -0400
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <3801583e-db6e-3608-b5e0-61bcecfb97b7@oracle.com>

Vote: Yes

On 03/12/2019 07:15 PM, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.


From daniel.fuchs at oracle.com  Wed Mar 13 13:59:56 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 13:59:56 +0000
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <33bcba0f-d3fd-70ee-67c7-60a274035eef@oracle.com>

Vote: yes

best regards,

-- daniel

On 12/03/2019 23:15, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.


From rasbold at google.com  Wed Mar 13 14:46:17 2019
From: rasbold at google.com (Chuck Rasbold)
Date: Wed, 13 Mar 2019 07:46:17 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <CALFb4KuD=2UmDbKfgz-B75phEQRmu3wXYSOpvpfOkVrzdyqC+Q@mail.gmail.com>

Vote: yes

On Tue, Mar 12, 2019 at 4:27 PM Jiangli Zhou <jianglizhou at google.com> wrote:

> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
>
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
>

From mikhailo.seledtsov at oracle.com  Wed Mar 13 15:15:34 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Wed, 13 Mar 2019 08:15:34 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <62930b61-c737-e516-e573-1077feb6c025@oracle.com>

Vote: Yes


On 3/12/19 4:15 PM, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead


From cushon at google.com  Wed Mar 13 15:18:50 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 08:18:50 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <CAL4QsgsXc_bOL_aR1C06hneg9V0f9i2yuT=1Zjyc4P93bsbc-A@mail.gmail.com>

Vote: yes

On Tue, Mar 12, 2019 at 4:27 PM Jiangli Zhou <jianglizhou at google.com> wrote:

> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
>
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
>

From kim.barrett at oracle.com  Wed Mar 13 23:41:11 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 13 Mar 2019 19:41:11 -0400
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <EE6AE981-972C-4C46-8971-5E41C0E006DD@oracle.com>

vote: yes

> On Mar 12, 2019, at 7:15 PM, Jiangli Zhou <jianglizhou at google.com> wrote:
> 
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead



From martinrb at google.com  Thu Mar 14 00:18:45 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 17:18:45 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <44928cf8-4898-097b-848f-bfcf1ce084d6@oracle.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
 <44928cf8-4898-097b-848f-bfcf1ce084d6@oracle.com>
Message-ID: <CA+kOe08UkveauPk9J6y=LomvFJ7AVecYimb8vvD9-0FC5BpSxQ@mail.gmail.com>

Vote: yes

From per.liden at oracle.com  Thu Mar 14 01:04:32 2019
From: per.liden at oracle.com (Per Liden)
Date: Thu, 14 Mar 2019 02:04:32 +0100
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <ff9d1799-242d-c0dd-da5f-e22838449a21@oracle.com>

Vote: yes

/Per

On 2019-03-13 00:15, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
> 
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
> 
> Votes are due by Tuesday March 26, 2019.
> 
> 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].
> 
> Thanks,
> Jiangli Zhou
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
> 
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead
> 

From hohensee at amazon.com  Thu Mar 14 19:05:22 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 14 Mar 2019 19:05:22 +0000
Subject: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <3BC8646D-CB2D-4FD1-B6DF-146FA9E225BB@amazon.com>

Vote: yes

?On 3/12/19, 4:17 PM, "jdk-dev on behalf of Jiangli Zhou" <jdk-dev-bounces at openjdk.java.net on behalf of jianglizhou at google.com> wrote:

    I hereby nominate Man Cao (manc) to JDK committer.
    
    Man works in the Java team at Google and has contributed 11 changesets [3].
    His contributions focus on runtime performance improvement, garbage
    collection, and bug fixes.
    
    Votes are due by Tuesday March 26, 2019.
    
    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].
    
    Thanks,
    Jiangli Zhou
    
    [1] http://openjdk.java.net/census
    [2] http://openjdk.java.net/projects/#committer-vote
    [3]
    https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
    
    Contributed-by:
    8193386: CompressedClassSize too large with MaxMetaspace
    8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
    8210724: Change the verbosity threshold of logging for [oopstorage,ref]
    Authored:
    8210716: Detailed GC logging request misses some
    8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
    8213829: Remove circular dependency between g1CollectedHeap and
    g1ConcurrentMark
    8213224: Move code related to GC threads calculation out of
    AdaptiveSizePolicy
    8215043: Remove declaration of parallel_worker_threads
    8215114: Fix indent and dead code in GCPolicyCounters
    8218192: Remove copy constructor for MemRegion
    8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
    overhead
    


From sangheon.kim at oracle.com  Thu Mar 14 20:21:47 2019
From: sangheon.kim at oracle.com (sangheon.kim at oracle.com)
Date: Thu, 14 Mar 2019 13:21:47 -0700
Subject: CFV: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
References: <CALrW1jw4Os_3zMO7JRPn7G2S3h911pmF_Lj0mWdhj13aPjwUQA@mail.gmail.com>
Message-ID: <3007e466-c3c0-f862-89be-bc4d948f3705@oracle.com>

Vote: yes

Thanks,
Sangheon


On 3/12/19 4:15 PM, Jiangli Zhou wrote:
> I hereby nominate Man Cao (manc) to JDK committer.
>
> Man works in the Java team at Google and has contributed 11 changesets [3].
> His contributions focus on runtime performance improvement, garbage
> collection, and bug fixes.
>
> Votes are due by Tuesday March 26, 2019.
>
> 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].
>
> Thanks,
> Jiangli Zhou
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(manc)+or+desc(%22manc at google.com%22))+and+not+merge()
>
> Contributed-by:
> 8193386: CompressedClassSize too large with MaxMetaspace
> 8210192: Hsperf counter ParNew::CMS should be ParNew:CMS
> 8210724: Change the verbosity threshold of logging for [oopstorage,ref]
> Authored:
> 8210716: Detailed GC logging request misses some
> 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
> 8213829: Remove circular dependency between g1CollectedHeap and
> g1ConcurrentMark
> 8213224: Move code related to GC threads calculation out of
> AdaptiveSizePolicy
> 8215043: Remove declaration of parallel_worker_threads
> 8215114: Fix indent and dead code in GCPolicyCounters
> 8218192: Remove copy constructor for MemRegion
> 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC
> overhead


From jesper.wilhelmsson at oracle.com  Sat Mar 16 00:43:13 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Sat, 16 Mar 2019 01:43:13 +0100
Subject: RFR(xxs): JDK-8220745 - Fix problemlist entry to refer to 8220613
Message-ID: <5920AE95-01B0-4C8A-B9AA-A3F3DF79AC68@oracle.com>

Hi,

Please review this tiny fix to make the problemlist entry for TimSortStackSize2.java refer to JDK-8220613, which is the issue that is investigating the problem. The old value, JDK-8220005, became the issue used to problemlist the test.

Bug: https://bugs.openjdk.java.net/browse/JDK-8220745 <https://bugs.openjdk.java.net/browse/JDK-8220745>
Diff:

diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -840,7 +840,7 @@

 # jdk_util

-java/util/Arrays/TimSortStackSize2.java                         8220005 generic-all
+java/util/Arrays/TimSortStackSize2.java                         8220613 generic-all

 ############################################################################


Thanks,
/Jesper


From daniel.daugherty at oracle.com  Sat Mar 16 00:48:36 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 15 Mar 2019 20:48:36 -0400
Subject: RFR(xxs): JDK-8220745 - Fix problemlist entry to refer to 8220613
In-Reply-To: <5920AE95-01B0-4C8A-B9AA-A3F3DF79AC68@oracle.com>
References: <5920AE95-01B0-4C8A-B9AA-A3F3DF79AC68@oracle.com>
Message-ID: <ced3faeb-9450-0594-d77d-165ac32432d8@oracle.com>

Thumbs up.

Dan


On 3/15/19 8:43 PM, jesper.wilhelmsson at oracle.com wrote:
> Hi,
>
> Please review this tiny fix to make the problemlist entry for TimSortStackSize2.java refer to JDK-8220613, which is the issue that is investigating the problem. The old value, JDK-8220005, became the issue used to problemlist the test.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220745 <https://bugs.openjdk.java.net/browse/JDK-8220745>
> Diff:
>
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -840,7 +840,7 @@
>
>   # jdk_util
>
> -java/util/Arrays/TimSortStackSize2.java                         8220005 generic-all
> +java/util/Arrays/TimSortStackSize2.java                         8220613 generic-all
>
>   ############################################################################
>
>
> Thanks,
> /Jesper
>


From jesper.wilhelmsson at oracle.com  Sat Mar 16 01:06:59 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Sat, 16 Mar 2019 02:06:59 +0100
Subject: RFR(xxs): JDK-8220745 - Fix problemlist entry to refer to 8220613
In-Reply-To: <ced3faeb-9450-0594-d77d-165ac32432d8@oracle.com>
References: <5920AE95-01B0-4C8A-B9AA-A3F3DF79AC68@oracle.com>
 <ced3faeb-9450-0594-d77d-165ac32432d8@oracle.com>
Message-ID: <69462827-9E70-4ECE-B40E-3C5B5386D86F@oracle.com>

Thanks Dan!
/Jesper

> On 16 Mar 2019, at 01:48, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
> Thumbs up.
> 
> Dan
> 
> 
> On 3/15/19 8:43 PM, jesper.wilhelmsson at oracle.com wrote:
>> Hi,
>> 
>> Please review this tiny fix to make the problemlist entry for TimSortStackSize2.java refer to JDK-8220613, which is the issue that is investigating the problem. The old value, JDK-8220005, became the issue used to problemlist the test.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220745 <https://bugs.openjdk.java.net/browse/JDK-8220745>
>> Diff:
>> 
>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -840,7 +840,7 @@
>> 
>>  # jdk_util
>> 
>> -java/util/Arrays/TimSortStackSize2.java                         8220005 generic-all
>> +java/util/Arrays/TimSortStackSize2.java                         8220613 generic-all
>> 
>>  ############################################################################
>> 
>> 
>> Thanks,
>> /Jesper
>> 
> 


From wasiuddin.qazi at gmail.com  Sat Mar 16 07:27:17 2019
From: wasiuddin.qazi at gmail.com (Wasiuddin Qazi)
Date: Sat, 16 Mar 2019 12:57:17 +0530
Subject: Welcome to the "jdk-dev" mailing list
In-Reply-To: <mailman.112.1552031959.20664.jdk-dev@openjdk.java.net>
References: <mailman.112.1552031959.20664.jdk-dev@openjdk.java.net>
Message-ID: <CADOcG-JbE73bYzpA7WJ2Y5KWc-an1eGt6eNdPheyBdbKLaUh0g@mail.gmail.com>

Acknowledgment

On Fri, 8 Mar 2019 at 1:29 PM <jdk-dev-request at openjdk.java.net> wrote:

> Welcome to the jdk-dev at openjdk.java.net mailing list!
>
> To post to this list, send your email to:
>
>   jdk-dev at openjdk.java.net
>
> General information about the mailing list is at:
>
>   https://mail.openjdk.java.net/mailman/listinfo/jdk-dev
>
> If you ever want to unsubscribe or change your options (eg, switch to
> or from digest mode, change your password, etc.), visit your
> subscription page at:
>
>
> https://mail.openjdk.java.net/mailman/options/jdk-dev/wasiuddin.qazi%40gmail.com
>
>
> You can also make such adjustments via email by sending a message to:
>
>   jdk-dev-request at openjdk.java.net
>
> with the word `help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions.
>
> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe.  It is:
>
>   asd-2020
>
> Normally, Mailman will remind you of your openjdk.java.net mailing
> list passwords once every month, although you can disable this if you
> prefer.  This reminder will also include instructions on how to
> unsubscribe or change your account options.  There is also a button on
> your options page that will email your current password to you.
>
-- 
Sent from my iPhone

From zhaixiang at loongson.cn  Sun Mar 17 09:30:39 2019
From: zhaixiang at loongson.cn (Leslie Zhai)
Date: Sun, 17 Mar 2019 17:30:39 +0800
Subject: Request for Comments: Potential leak of memory pointed to by 'name'
 about jvmciCodeInstaller
Message-ID: <a321af54-3683-aa66-b129-0953ef66cd6c@loongson.cn>

Hi,

Bug reported[1] by the clang static analyzer.

Description: Potential leak of memory pointed to by 'name'
File: /home/zhaixiang/jdk/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
Line: 653

652? char* name = strdup(java_lang_String::as_utf8_string(stubName));

 ???? 5 ? Memory is allocated? ?

653? cb = RuntimeStub::new_runtime_stub(name,

 ???? 6 ? Potential leak of memory pointed to by 'name'

I checked `install` function in 
src/hotspot/share/jvmci/jvmciCodeInstaller.cpp and `installCode` 
C2V_VMENTRY in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp carefully.? 
There is no `free` to release the allocated memory, so I argue that it 
is a Memory leak issue, not a False positive[2]. May I file a bug if it 
is real potential leak of memory issue?

Because I think webrev is related to BUGID[3], so I just paste my patch 
here:


----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
diff -r 1a18b8d56d73 src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
--- a/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp    Sat Mar 16 15:05:21 2019 -0700
+++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp    Sun Mar 17 17:06:50 2019 +0800
@@ -623,7 +623,7 @@
  #endif // INCLUDE_AOT
  
  // constructor used to create a method
-JVMCIEnv::CodeInstallResult CodeInstaller::install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, Handle installed_code, Handle speculation_log, TRAPS) {
+JVMCIEnv::CodeInstallResult CodeInstaller::install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, char*& cb_name, Handle installed_code, Handle speculation_log, TRAPS) {
    CodeBuffer buffer("JVMCI Compiler CodeBuffer");
    jobject compiled_code_obj = JNIHandles::make_local(compiled_code());
    OopRecorder* recorder = new OopRecorder(&_arena, true);
@@ -649,8 +649,8 @@
      if (stubName == NULL) {
        JVMCI_ERROR_OK("stub should have a name");
      }
-    char* name = strdup(java_lang_String::as_utf8_string(stubName));
-    cb = RuntimeStub::new_runtime_stub(name,
+    cb_name = strdup(java_lang_String::as_utf8_string(stubName));
+    cb = RuntimeStub::new_runtime_stub(cb_name,
                                         &buffer,
                                         CodeOffsets::frame_never_safe,
                                         stack_slots,
diff -r 1a18b8d56d73 src/hotspot/share/jvmci/jvmciCodeInstaller.hpp
--- a/src/hotspot/share/jvmci/jvmciCodeInstaller.hpp    Sat Mar 16 15:05:21 2019 -0700
+++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.hpp    Sun Mar 17 17:06:50 2019 +0800
@@ -207,7 +207,7 @@
  #if INCLUDE_AOT
    JVMCIEnv::CodeInstallResult gather_metadata(Handle target, Handle compiled_code, CodeMetadata& metadata, TRAPS);
  #endif
-  JVMCIEnv::CodeInstallResult install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, Handle installed_code, Handle speculation_log, TRAPS);
+  JVMCIEnv::CodeInstallResult install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, char*& cb_name, Handle installed_code, Handle speculation_log, TRAPS);
  
    static address runtime_call_target_address(oop runtime_call);
    static VMReg get_hotspot_reg(jint jvmciRegisterNumber, TRAPS);
diff -r 1a18b8d56d73 src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
--- a/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp     Sat Mar 16 15:05:21 2019 -0700
+++ b/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp     Sun Mar 17 17:06:50 2019 +0800
@@ -677,6 +677,7 @@
    Handle target_handle(THREAD, JNIHandles::resolve(target));
    Handle compiled_code_handle(THREAD, JNIHandles::resolve(compiled_code));
    CodeBlob* cb = NULL;
+  char* cb_name = NULL;
    Handle installed_code_handle(THREAD, JNIHandles::resolve(installed_code));
    Handle speculation_log_handle(THREAD, JNIHandles::resolve(speculation_log));
  
@@ -685,7 +686,7 @@
    TraceTime install_time("installCode", JVMCICompiler::codeInstallTimer());
    bool is_immutable_PIC = HotSpotCompiledCode::isImmutablePIC(compiled_code_handle) > 0;
    CodeInstaller installer(is_immutable_PIC);
-  JVMCIEnv::CodeInstallResult result = installer.install(compiler, target_handle, compiled_code_handle, cb, installed_code_handle, speculation_log_handle, CHECK_0);
+  JVMCIEnv::CodeInstallResult result = installer.install(compiler, target_handle, compiled_code_handle, cb, cb_name, installed_code_handle, speculation_log_handle, CHECK_0);
  
    if (PrintCodeCacheOnCompilation) {
      stringStream s;
@@ -722,6 +723,7 @@
        }
      }
    }
+  if (cb_name) free(cb_name);
    return result;
  C2V_END
  

----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---


I ran clang static analyzer again, and it is not reproducible owing to I 
fixed the issue, not False negative :)

hotspot:tier1 linux-x86_64-server-fastdebug 2 fail:

* compiler/c2/Test8062950.java: it is also reproducible for mips64el 
without the patch
* runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java: Test 
empty bootstrap_methods table within BootstrapMethods attribute


Please point out my any fault!

Thanks,

Leslie Zhai

[1] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/jvmciCodeInstaller.cpp.png

[2] https://bugs.llvm.org/show_bug.cgi?id=40913

[3] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007855.html



From doug.simon at oracle.com  Sun Mar 17 21:55:39 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Sun, 17 Mar 2019 22:55:39 +0100
Subject: Request for Comments: Potential leak of memory pointed to by
 'name' about jvmciCodeInstaller
In-Reply-To: <a321af54-3683-aa66-b129-0953ef66cd6c@loongson.cn>
References: <a321af54-3683-aa66-b129-0953ef66cd6c@loongson.cn>
Message-ID: <B27E0EAA-3613-4599-9646-A1C434D01A69@oracle.com>

Hi Leslie,

As a point of process, I think hotspot-compiler-dev at openjdk.java.net is probably a better list for JVMCI bugs.

In any case, thanks for the investigation. However, I don?t think this is a bug as RuntimeStub simply passes along the name argument which is eventually stored to CodeBlob::_name without any further copying. If we subsequently freed that argument, the CodeBlob::_name would become invalid.

-Doug

> On 17 Mar 2019, at 10:30, Leslie Zhai <zhaixiang at loongson.cn> wrote:
> 
> Hi,
> 
> Bug reported[1] by the clang static analyzer.
> 
> Description: Potential leak of memory pointed to by 'name'
> File: /home/zhaixiang/jdk/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
> Line: 653
> 
> 652  char* name = strdup(java_lang_String::as_utf8_string(stubName));
> 
>      5 ? Memory is allocated  ?
> 
> 653  cb = RuntimeStub::new_runtime_stub(name,
> 
>      6 ? Potential leak of memory pointed to by 'name'
> 
> I checked `install` function in src/hotspot/share/jvmci/jvmciCodeInstaller.cpp and `installCode` C2V_VMENTRY in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp carefully.  There is no `free` to release the allocated memory, so I argue that it is a Memory leak issue, not a False positive[2]. May I file a bug if it is real potential leak of memory issue?
> 
> Because I think webrev is related to BUGID[3], so I just paste my patch here:
> 
> 
> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
> diff -r 1a18b8d56d73 src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
> --- a/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp    Sat Mar 16 15:05:21 2019 -0700
> +++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp    Sun Mar 17 17:06:50 2019 +0800
> @@ -623,7 +623,7 @@
> #endif // INCLUDE_AOT
>  // constructor used to create a method
> -JVMCIEnv::CodeInstallResult CodeInstaller::install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, Handle installed_code, Handle speculation_log, TRAPS) {
> +JVMCIEnv::CodeInstallResult CodeInstaller::install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, char*& cb_name, Handle installed_code, Handle speculation_log, TRAPS) {
>   CodeBuffer buffer("JVMCI Compiler CodeBuffer");
>   jobject compiled_code_obj = JNIHandles::make_local(compiled_code());
>   OopRecorder* recorder = new OopRecorder(&_arena, true);
> @@ -649,8 +649,8 @@
>     if (stubName == NULL) {
>       JVMCI_ERROR_OK("stub should have a name");
>     }
> -    char* name = strdup(java_lang_String::as_utf8_string(stubName));
> -    cb = RuntimeStub::new_runtime_stub(name,
> +    cb_name = strdup(java_lang_String::as_utf8_string(stubName));
> +    cb = RuntimeStub::new_runtime_stub(cb_name,
>                                        &buffer,
>                                        CodeOffsets::frame_never_safe,
>                                        stack_slots,
> diff -r 1a18b8d56d73 src/hotspot/share/jvmci/jvmciCodeInstaller.hpp
> --- a/src/hotspot/share/jvmci/jvmciCodeInstaller.hpp    Sat Mar 16 15:05:21 2019 -0700
> +++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.hpp    Sun Mar 17 17:06:50 2019 +0800
> @@ -207,7 +207,7 @@
> #if INCLUDE_AOT
>   JVMCIEnv::CodeInstallResult gather_metadata(Handle target, Handle compiled_code, CodeMetadata& metadata, TRAPS);
> #endif
> -  JVMCIEnv::CodeInstallResult install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, Handle installed_code, Handle speculation_log, TRAPS);
> +  JVMCIEnv::CodeInstallResult install(JVMCICompiler* compiler, Handle target, Handle compiled_code, CodeBlob*& cb, char*& cb_name, Handle installed_code, Handle speculation_log, TRAPS);
>    static address runtime_call_target_address(oop runtime_call);
>   static VMReg get_hotspot_reg(jint jvmciRegisterNumber, TRAPS);
> diff -r 1a18b8d56d73 src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
> --- a/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp     Sat Mar 16 15:05:21 2019 -0700
> +++ b/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp     Sun Mar 17 17:06:50 2019 +0800
> @@ -677,6 +677,7 @@
>   Handle target_handle(THREAD, JNIHandles::resolve(target));
>   Handle compiled_code_handle(THREAD, JNIHandles::resolve(compiled_code));
>   CodeBlob* cb = NULL;
> +  char* cb_name = NULL;
>   Handle installed_code_handle(THREAD, JNIHandles::resolve(installed_code));
>   Handle speculation_log_handle(THREAD, JNIHandles::resolve(speculation_log));
> @@ -685,7 +686,7 @@
>   TraceTime install_time("installCode", JVMCICompiler::codeInstallTimer());
>   bool is_immutable_PIC = HotSpotCompiledCode::isImmutablePIC(compiled_code_handle) > 0;
>   CodeInstaller installer(is_immutable_PIC);
> -  JVMCIEnv::CodeInstallResult result = installer.install(compiler, target_handle, compiled_code_handle, cb, installed_code_handle, speculation_log_handle, CHECK_0);
> +  JVMCIEnv::CodeInstallResult result = installer.install(compiler, target_handle, compiled_code_handle, cb, cb_name, installed_code_handle, speculation_log_handle, CHECK_0);
>    if (PrintCodeCacheOnCompilation) {
>     stringStream s;
> @@ -722,6 +723,7 @@
>       }
>     }
>   }
> +  if (cb_name) free(cb_name);
>   return result;
> C2V_END
> 
> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
> 
> 
> I ran clang static analyzer again, and it is not reproducible owing to I fixed the issue, not False negative :)
> 
> hotspot:tier1 linux-x86_64-server-fastdebug 2 fail:
> 
> * compiler/c2/Test8062950.java: it is also reproducible for mips64el without the patch
> * runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java: Test empty bootstrap_methods table within BootstrapMethods attribute
> 
> 
> Please point out my any fault!
> 
> Thanks,
> 
> Leslie Zhai
> 
> [1] https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/jvmciCodeInstaller.cpp.png
> 
> [2] https://bugs.llvm.org/show_bug.cgi?id=40913
> 
> [3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007855.html
> 
> 


From mark.reinhold at oracle.com  Mon Mar 18 21:20:41 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 18 Mar 2019 14:20:41 -0700 (PDT)
Subject: Proposed schedule for JDK 13
Message-ID: <20190318212041.EE17E26CB55@eggemoggin.niobe.net>

With JDK 12 nearly finished, here?s a proposed schedule for JDK 13:

  2019/06/13  Rampdown Phase One
  2019/07/18  Rampdown Phase Two
  2019/08/08  Initial Release Candidate
  2019/08/22  Final Release Candidate
  2019/09/17  General Availability

The phases are defined in JEP 3 [1].

Comments on this proposal from JDK Committers and Reviewers [2] are
welcome, as are reasoned objections.  If no such objections are raised by
23:00 UTC next Monday, 25 March, or if they?re raised and satisfactorily
answered, then per the JEP 2.0 process proposal [3] this will be the
schedule for JDK 13.

- Mark


[1] https://openjdk.java.net/jeps/3
[2] https://openjdk.java.net/census#jdk
[3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From jai.forums2013 at gmail.com  Tue Mar 19 09:44:24 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 19 Mar 2019 15:14:24 +0530
Subject: Release notes for each version of Java 11?
Message-ID: <ff1700ef-9338-433a-4b18-59d7afbb7bf2@gmail.com>

Right now the Java 11 release notes page[1] shows the release notes for
the latest update release of Java 11. Is there a place where the release
notes of previous releases of Java 11 can be found at? I looked at the
archive page[2] but that just has links to binaries and checksums but
not release notes. Maybe this archive page should include a link for
release notes of each released version?


[1] https://jdk.java.net/11/release-notes

[2] https://jdk.java.net/archive/

-Jaikiran


From mark.reinhold at oracle.com  Tue Mar 19 16:55:06 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 19 Mar 2019 09:55:06 -0700 (PDT)
Subject: Java 12 / JDK 12: General Availability
Message-ID: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>

JDK 12, the reference implementation of Java 12, is now Generally
Available.  We?ve identified no P1 bugs since we promoted build 33 over
three weeks ago so that?s the official GA release, ready for production
use.

GPL-licensed OpenJDK builds from Oracle are available here:

  https://jdk.java.net/12

Builds from other implementors will no doubt be available soon.

This release includes eight features [3]:

  189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
  230: Microbenchmark Suite
  325: Switch Expressions (Preview)
  334: JVM Constants API
  340: One AArch64 Port, Not Two
  341: Default CDS Archives
  344: Abortable Mixed Collections for G1
  346: Promptly Return Unused Committed Memory from G1

along with, as usual, hundreds of smaller enhancements and thousands of
bug fixes.

Thanks to everyone who contributed JDK 12, whether by creating features
or enhancements, fixing bugs, or downloading and testing the early-access
builds.

Coming up next ... lucky 13!

- Mark


[1] https://mreinhold.org/blog/forward-faster
[2] https://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3] https://openjdk.java.net/projects/jdk/12

From goetz.lindenmaier at sap.com  Wed Mar 20 08:11:31 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Mar 2019 08:11:31 +0000
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
Message-ID: <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi,

we are missing the -ga tag in the OpenJDK repository:
http://hg.openjdk.java.net/jdk/jdk12/

We had expected a tag similar to jdk-11.0.2-ga:
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/0a8cde5d5ceb

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> mark.reinhold at oracle.com
> Sent: Dienstag, 19. M?rz 2019 17:55
> To: announce at openjdk.java.net
> Cc: jdk-dev at openjdk.java.net
> Subject: Java 12 / JDK 12: General Availability
> 
> JDK 12, the reference implementation of Java 12, is now Generally
> Available.  We?ve identified no P1 bugs since we promoted build 33 over
> three weeks ago so that?s the official GA release, ready for production
> use.
> 
> GPL-licensed OpenJDK builds from Oracle are available here:
> 
>   https://jdk.java.net/12
> 
> Builds from other implementors will no doubt be available soon.
> 
> This release includes eight features [3]:
> 
>   189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
>   230: Microbenchmark Suite
>   325: Switch Expressions (Preview)
>   334: JVM Constants API
>   340: One AArch64 Port, Not Two
>   341: Default CDS Archives
>   344: Abortable Mixed Collections for G1
>   346: Promptly Return Unused Committed Memory from G1
> 
> along with, as usual, hundreds of smaller enhancements and thousands of
> bug fixes.
> 
> Thanks to everyone who contributed JDK 12, whether by creating features
> or enhancements, fixing bugs, or downloading and testing the early-access
> builds.
> 
> Coming up next ... lucky 13!
> 
> - Mark
> 
> 
> [1] https://mreinhold.org/blog/forward-faster
> [2] https://mail.openjdk.java.net/pipermail/discuss/2017-
> September/004281.html
> [3] https://openjdk.java.net/projects/jdk/12

From christoph.langer at sap.com  Wed Mar 20 08:37:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 08:37:34 +0000
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

FWIW: The GA tagging is tracked by this bug: https://bugs.openjdk.java.net/browse/JDK-8217255

The bug links to the mailing list discussions. In that discussion, Se?n said that he'd ask the project leads to use the ga tags. So it would really be appreciated if ga tags could be used by OpenJDK major releases, too.

Thanks
Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> Lindenmaier, Goetz
> Sent: Mittwoch, 20. M?rz 2019 09:12
> To: mark.reinhold at oracle.com; announce at openjdk.java.net
> Cc: jdk-dev at openjdk.java.net
> Subject: [CAUTION] RE: Java 12 / JDK 12: General Availability
> 
> Hi,
> 
> we are missing the -ga tag in the OpenJDK repository:
> http://hg.openjdk.java.net/jdk/jdk12/
> 
> We had expected a tag similar to jdk-11.0.2-ga:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/0a8cde5d5ceb
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> > mark.reinhold at oracle.com
> > Sent: Dienstag, 19. M?rz 2019 17:55
> > To: announce at openjdk.java.net
> > Cc: jdk-dev at openjdk.java.net
> > Subject: Java 12 / JDK 12: General Availability
> >
> > JDK 12, the reference implementation of Java 12, is now Generally
> > Available.  We?ve identified no P1 bugs since we promoted build 33 over
> > three weeks ago so that?s the official GA release, ready for production
> > use.
> >
> > GPL-licensed OpenJDK builds from Oracle are available here:
> >
> >   https://jdk.java.net/12
> >
> > Builds from other implementors will no doubt be available soon.
> >
> > This release includes eight features [3]:
> >
> >   189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
> >   230: Microbenchmark Suite
> >   325: Switch Expressions (Preview)
> >   334: JVM Constants API
> >   340: One AArch64 Port, Not Two
> >   341: Default CDS Archives
> >   344: Abortable Mixed Collections for G1
> >   346: Promptly Return Unused Committed Memory from G1
> >
> > along with, as usual, hundreds of smaller enhancements and thousands of
> > bug fixes.
> >
> > Thanks to everyone who contributed JDK 12, whether by creating features
> > or enhancements, fixing bugs, or downloading and testing the early-access
> > builds.
> >
> > Coming up next ... lucky 13!
> >
> > - Mark
> >
> >
> > [1] https://mreinhold.org/blog/forward-faster
> > [2] https://mail.openjdk.java.net/pipermail/discuss/2017-
> > September/004281.html
> > [3] https://openjdk.java.net/projects/jdk/12

From jesper.wilhelmsson at oracle.com  Wed Mar 20 14:10:12 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 20 Mar 2019 15:10:12 +0100
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>

Hi,

I didn't see any actual decision on this. Is it enough that there is a bug filed in JBS and a mail thread with five or so people that thinks it is a good idea? Given that this is enough for most code changes that potentially could have a much larger impact on the OpenJDK maybe it's fine. I don't have an opinion here, I'm just curious as to how we make decisions in the OpenJDK.

If there was a decision made, please inform those who actually make the tagging happen - or will there be infrastructure that make this tagging happen automatically?

Thanks,
/Jesper


> On 20 Mar 2019, at 09:37, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
> 
> FWIW: The GA tagging is tracked by this bug: https://bugs.openjdk.java.net/browse/JDK-8217255
> 
> The bug links to the mailing list discussions. In that discussion, Se?n said that he'd ask the project leads to use the ga tags. So it would really be appreciated if ga tags could be used by OpenJDK major releases, too.
> 
> Thanks
> Christoph
> 
>> -----Original Message-----
>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
>> Lindenmaier, Goetz
>> Sent: Mittwoch, 20. M?rz 2019 09:12
>> To: mark.reinhold at oracle.com; announce at openjdk.java.net
>> Cc: jdk-dev at openjdk.java.net
>> Subject: [CAUTION] RE: Java 12 / JDK 12: General Availability
>> 
>> Hi,
>> 
>> we are missing the -ga tag in the OpenJDK repository:
>> http://hg.openjdk.java.net/jdk/jdk12/
>> 
>> We had expected a tag similar to jdk-11.0.2-ga:
>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/0a8cde5d5ceb
>> 
>> Best regards,
>>  Goetz.
>> 
>>> -----Original Message-----
>>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
>>> mark.reinhold at oracle.com
>>> Sent: Dienstag, 19. M?rz 2019 17:55
>>> To: announce at openjdk.java.net
>>> Cc: jdk-dev at openjdk.java.net
>>> Subject: Java 12 / JDK 12: General Availability
>>> 
>>> JDK 12, the reference implementation of Java 12, is now Generally
>>> Available.  We?ve identified no P1 bugs since we promoted build 33 over
>>> three weeks ago so that?s the official GA release, ready for production
>>> use.
>>> 
>>> GPL-licensed OpenJDK builds from Oracle are available here:
>>> 
>>>  https://jdk.java.net/12
>>> 
>>> Builds from other implementors will no doubt be available soon.
>>> 
>>> This release includes eight features [3]:
>>> 
>>>  189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
>>>  230: Microbenchmark Suite
>>>  325: Switch Expressions (Preview)
>>>  334: JVM Constants API
>>>  340: One AArch64 Port, Not Two
>>>  341: Default CDS Archives
>>>  344: Abortable Mixed Collections for G1
>>>  346: Promptly Return Unused Committed Memory from G1
>>> 
>>> along with, as usual, hundreds of smaller enhancements and thousands of
>>> bug fixes.
>>> 
>>> Thanks to everyone who contributed JDK 12, whether by creating features
>>> or enhancements, fixing bugs, or downloading and testing the early-access
>>> builds.
>>> 
>>> Coming up next ... lucky 13!
>>> 
>>> - Mark
>>> 
>>> 
>>> [1] https://mreinhold.org/blog/forward-faster
>>> [2] https://mail.openjdk.java.net/pipermail/discuss/2017-
>>> September/004281.html
>>> [3] https://openjdk.java.net/projects/jdk/12


From sean.coffey at oracle.com  Wed Mar 20 14:16:17 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 20 Mar 2019 14:16:17 +0000
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
Message-ID: <4a6a2318-59cf-042a-e030-7494fd902237@oracle.com>

Jesper,

this was discussed with all impacted Project teams last October [1]. It 
was very much welcomed also.

Adding the jdk12-ga tag should be straightforward I hope. We just need 
to remember to capture it in process.

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

Regards,
Sean.

On 20/03/19 14:10, jesper.wilhelmsson at oracle.com wrote:
> Hi,
>
> I didn't see any actual decision on this. Is it enough that there is a bug filed in JBS and a mail thread with five or so people that thinks it is a good idea? Given that this is enough for most code changes that potentially could have a much larger impact on the OpenJDK maybe it's fine. I don't have an opinion here, I'm just curious as to how we make decisions in the OpenJDK.
>
> If there was a decision made, please inform those who actually make the tagging happen - or will there be infrastructure that make this tagging happen automatically?
>
> Thanks,
> /Jesper
>
>
>> On 20 Mar 2019, at 09:37, Langer, Christoph <christoph.langer at sap.com> wrote:
>>
>> Hi,
>>
>> FWIW: The GA tagging is tracked by this bug: https://bugs.openjdk.java.net/browse/JDK-8217255
>>
>> The bug links to the mailing list discussions. In that discussion, Se?n said that he'd ask the project leads to use the ga tags. So it would really be appreciated if ga tags could be used by OpenJDK major releases, too.
>>
>> Thanks
>> Christoph
>>
>>> -----Original Message-----
>>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
>>> Lindenmaier, Goetz
>>> Sent: Mittwoch, 20. M?rz 2019 09:12
>>> To: mark.reinhold at oracle.com; announce at openjdk.java.net
>>> Cc: jdk-dev at openjdk.java.net
>>> Subject: [CAUTION] RE: Java 12 / JDK 12: General Availability
>>>
>>> Hi,
>>>
>>> we are missing the -ga tag in the OpenJDK repository:
>>> http://hg.openjdk.java.net/jdk/jdk12/
>>>
>>> We had expected a tag similar to jdk-11.0.2-ga:
>>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/0a8cde5d5ceb
>>>
>>> Best regards,
>>>   Goetz.
>>>
>>>> -----Original Message-----
>>>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
>>>> mark.reinhold at oracle.com
>>>> Sent: Dienstag, 19. M?rz 2019 17:55
>>>> To: announce at openjdk.java.net
>>>> Cc: jdk-dev at openjdk.java.net
>>>> Subject: Java 12 / JDK 12: General Availability
>>>>
>>>> JDK 12, the reference implementation of Java 12, is now Generally
>>>> Available.  We?ve identified no P1 bugs since we promoted build 33 over
>>>> three weeks ago so that?s the official GA release, ready for production
>>>> use.
>>>>
>>>> GPL-licensed OpenJDK builds from Oracle are available here:
>>>>
>>>>   https://jdk.java.net/12
>>>>
>>>> Builds from other implementors will no doubt be available soon.
>>>>
>>>> This release includes eight features [3]:
>>>>
>>>>   189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
>>>>   230: Microbenchmark Suite
>>>>   325: Switch Expressions (Preview)
>>>>   334: JVM Constants API
>>>>   340: One AArch64 Port, Not Two
>>>>   341: Default CDS Archives
>>>>   344: Abortable Mixed Collections for G1
>>>>   346: Promptly Return Unused Committed Memory from G1
>>>>
>>>> along with, as usual, hundreds of smaller enhancements and thousands of
>>>> bug fixes.
>>>>
>>>> Thanks to everyone who contributed JDK 12, whether by creating features
>>>> or enhancements, fixing bugs, or downloading and testing the early-access
>>>> builds.
>>>>
>>>> Coming up next ... lucky 13!
>>>>
>>>> - Mark
>>>>
>>>>
>>>> [1] https://mreinhold.org/blog/forward-faster
>>>> [2] https://mail.openjdk.java.net/pipermail/discuss/2017-
>>>> September/004281.html
>>>> [3] https://openjdk.java.net/projects/jdk/12


From goetz.lindenmaier at sap.com  Wed Mar 20 14:38:29 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 20 Mar 2019 14:38:29 +0000
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
Message-ID: <VI1PR02MB5183D73B96A82D55E3AF17CFEC410@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi,

As jdk-11.0.2 was tagged -ga I assumed there is an established process now in 
Oracle.  I don't know all the processes you are running, I'm observing and
trying to understand ... 
At least it is strange if the original release is not tagged, but the updates
are...

Best regards,
  Goetz.


> -----Original Message-----
> From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com>
> Sent: Mittwoch, 20. M?rz 2019 15:10
> To: Se?n Coffey <sean.coffey at oracle.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; mark.reinhold at oracle.com;
> announce at openjdk.java.net; jdk-dev at openjdk.java.net
> Subject: Re: Java 12 / JDK 12: General Availability
> 
> Hi,
> 
> I didn't see any actual decision on this. Is it enough that there is a bug filed in
> JBS and a mail thread with five or so people that thinks it is a good idea? Given
> that this is enough for most code changes that potentially could have a much
> larger impact on the OpenJDK maybe it's fine. I don't have an opinion here, I'm
> just curious as to how we make decisions in the OpenJDK.
> 
> If there was a decision made, please inform those who actually make the
> tagging happen - or will there be infrastructure that make this tagging happen
> automatically?
> 
> Thanks,
> /Jesper
> 
> 
> > On 20 Mar 2019, at 09:37, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> >
> > Hi,
> >
> > FWIW: The GA tagging is tracked by this bug:
> https://bugs.openjdk.java.net/browse/JDK-8217255
> >
> > The bug links to the mailing list discussions. In that discussion, Se?n said that
> he'd ask the project leads to use the ga tags. So it would really be appreciated
> if ga tags could be used by OpenJDK major releases, too.
> >
> > Thanks
> > Christoph
> >
> >> -----Original Message-----
> >> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> >> Lindenmaier, Goetz
> >> Sent: Mittwoch, 20. M?rz 2019 09:12
> >> To: mark.reinhold at oracle.com; announce at openjdk.java.net
> >> Cc: jdk-dev at openjdk.java.net
> >> Subject: [CAUTION] RE: Java 12 / JDK 12: General Availability
> >>
> >> Hi,
> >>
> >> we are missing the -ga tag in the OpenJDK repository:
> >> http://hg.openjdk.java.net/jdk/jdk12/
> >>
> >> We had expected a tag similar to jdk-11.0.2-ga:
> >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/0a8cde5d5ceb
> >>
> >> Best regards,
> >>  Goetz.
> >>
> >>> -----Original Message-----
> >>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> >>> mark.reinhold at oracle.com
> >>> Sent: Dienstag, 19. M?rz 2019 17:55
> >>> To: announce at openjdk.java.net
> >>> Cc: jdk-dev at openjdk.java.net
> >>> Subject: Java 12 / JDK 12: General Availability
> >>>
> >>> JDK 12, the reference implementation of Java 12, is now Generally
> >>> Available.  We?ve identified no P1 bugs since we promoted build 33 over
> >>> three weeks ago so that?s the official GA release, ready for production
> >>> use.
> >>>
> >>> GPL-licensed OpenJDK builds from Oracle are available here:
> >>>
> >>>  https://jdk.java.net/12
> >>>
> >>> Builds from other implementors will no doubt be available soon.
> >>>
> >>> This release includes eight features [3]:
> >>>
> >>>  189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
> >>>  230: Microbenchmark Suite
> >>>  325: Switch Expressions (Preview)
> >>>  334: JVM Constants API
> >>>  340: One AArch64 Port, Not Two
> >>>  341: Default CDS Archives
> >>>  344: Abortable Mixed Collections for G1
> >>>  346: Promptly Return Unused Committed Memory from G1
> >>>
> >>> along with, as usual, hundreds of smaller enhancements and thousands of
> >>> bug fixes.
> >>>
> >>> Thanks to everyone who contributed JDK 12, whether by creating features
> >>> or enhancements, fixing bugs, or downloading and testing the early-access
> >>> builds.
> >>>
> >>> Coming up next ... lucky 13!
> >>>
> >>> - Mark
> >>>
> >>>
> >>> [1] https://mreinhold.org/blog/forward-faster
> >>> [2] https://mail.openjdk.java.net/pipermail/discuss/2017-
> >>> September/004281.html
> >>> [3] https://openjdk.java.net/projects/jdk/12


From barbara.oconnor at oracle.com  Wed Mar 20 14:44:32 2019
From: barbara.oconnor at oracle.com (Barbara O'connor)
Date: Wed, 20 Mar 2019 10:44:32 -0400
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <4a6a2318-59cf-042a-e030-7494fd902237@oracle.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
 <4a6a2318-59cf-042a-e030-7494fd902237@oracle.com>
Message-ID: <caf1c1d4-a7ae-1db3-85b8-86b29bc5bee7@oracle.com>

Thanks - I've added this to our release checklist for feature releases 
going forward.

-b


On 3/20/2019 10:16 AM, Se?n Coffey wrote:
> Jesper,
>
> this was discussed with all impacted Project teams last October [1]. 
> It was very much welcomed also.
>
> Adding the jdk12-ga tag should be straightforward I hope. We just need 
> to remember to capture it in process.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-October/002004.html
>
> Regards,
> Sean.
>
> On 20/03/19 14:10, jesper.wilhelmsson at oracle.com wrote:
>> Hi,
>>
>> I didn't see any actual decision on this. Is it enough that there is 
>> a bug filed in JBS and a mail thread with five or so people that 
>> thinks it is a good idea? Given that this is enough for most code 
>> changes that potentially could have a much larger impact on the 
>> OpenJDK maybe it's fine. I don't have an opinion here, I'm just 
>> curious as to how we make decisions in the OpenJDK.
>>
>> If there was a decision made, please inform those who actually make 
>> the tagging happen - or will there be infrastructure that make this 
>> tagging happen automatically?
>>
>> Thanks,
>> /Jesper
>>
>>
>>> On 20 Mar 2019, at 09:37, Langer, Christoph 
>>> <christoph.langer at sap.com> wrote:
>>>
>>> Hi,
>>>
>>> FWIW: The GA tagging is tracked by this bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-8217255
>>>
>>> The bug links to the mailing list discussions. In that discussion, 
>>> Se?n said that he'd ask the project leads to use the ga tags. So it 
>>> would really be appreciated if ga tags could be used by OpenJDK 
>>> major releases, too.
>>>
>>> Thanks
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
>>>> Lindenmaier, Goetz
>>>> Sent: Mittwoch, 20. M?rz 2019 09:12
>>>> To: mark.reinhold at oracle.com; announce at openjdk.java.net
>>>> Cc: jdk-dev at openjdk.java.net
>>>> Subject: [CAUTION] RE: Java 12 / JDK 12: General Availability
>>>>
>>>> Hi,
>>>>
>>>> we are missing the -ga tag in the OpenJDK repository:
>>>> http://hg.openjdk.java.net/jdk/jdk12/
>>>>
>>>> We had expected a tag similar to jdk-11.0.2-ga:
>>>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/0a8cde5d5ceb
>>>>
>>>> Best regards,
>>>> ? Goetz.
>>>>
>>>>> -----Original Message-----
>>>>> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
>>>>> mark.reinhold at oracle.com
>>>>> Sent: Dienstag, 19. M?rz 2019 17:55
>>>>> To: announce at openjdk.java.net
>>>>> Cc: jdk-dev at openjdk.java.net
>>>>> Subject: Java 12 / JDK 12: General Availability
>>>>>
>>>>> JDK 12, the reference implementation of Java 12, is now Generally
>>>>> Available.? We?ve identified no P1 bugs since we promoted build 33 
>>>>> over
>>>>> three weeks ago so that?s the official GA release, ready for 
>>>>> production
>>>>> use.
>>>>>
>>>>> GPL-licensed OpenJDK builds from Oracle are available here:
>>>>>
>>>>> ? https://jdk.java.net/12
>>>>>
>>>>> Builds from other implementors will no doubt be available soon.
>>>>>
>>>>> This release includes eight features [3]:
>>>>>
>>>>> ? 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
>>>>> ? 230: Microbenchmark Suite
>>>>> ? 325: Switch Expressions (Preview)
>>>>> ? 334: JVM Constants API
>>>>> ? 340: One AArch64 Port, Not Two
>>>>> ? 341: Default CDS Archives
>>>>> ? 344: Abortable Mixed Collections for G1
>>>>> ? 346: Promptly Return Unused Committed Memory from G1
>>>>>
>>>>> along with, as usual, hundreds of smaller enhancements and 
>>>>> thousands of
>>>>> bug fixes.
>>>>>
>>>>> Thanks to everyone who contributed JDK 12, whether by creating 
>>>>> features
>>>>> or enhancements, fixing bugs, or downloading and testing the 
>>>>> early-access
>>>>> builds.
>>>>>
>>>>> Coming up next ... lucky 13!
>>>>>
>>>>> - Mark
>>>>>
>>>>>
>>>>> [1] https://mreinhold.org/blog/forward-faster
>>>>> [2] https://mail.openjdk.java.net/pipermail/discuss/2017-
>>>>> September/004281.html
>>>>> [3] https://openjdk.java.net/projects/jdk/12
>

From mark.reinhold at oracle.com  Wed Mar 20 15:49:19 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 20 Mar 2019 08:49:19 -0700
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
Message-ID: <20190320084919.353484575@eggemoggin.niobe.net>

// Dropping announce at ojn, since no one else?s e-mail client appears
// intelligent enough to do so

2019/3/20 7:10:12 -0700, jesper.wilhelmsson at oracle.com:
> I didn't see any actual decision on this. Is it enough that there is a
> bug filed in JBS and a mail thread with five or so people that thinks
> it is a good idea? Given that this is enough for most code changes
> that potentially could have a much larger impact on the OpenJDK maybe
> it's fine. I don't have an opinion here, I'm just curious as to how we
> make decisions in the OpenJDK.

In the OpenJDK Community we generally make decisions by rough consensus,
except for situations explicitly identified in the Bylaws as requiring
formal votes.

In any case, as the Lead of the JDK Project I endorse Se?n?s original
proposal [1].

Jesper -- since you handle promotion tagging for the main-line repo,
could you please also create the jdk-12-ga tag in that repo?  Thanks.

- Mark


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

From jesper.wilhelmsson at oracle.com  Wed Mar 20 16:47:02 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 20 Mar 2019 17:47:02 +0100
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <20190320084919.353484575@eggemoggin.niobe.net>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
 <20190320084919.353484575@eggemoggin.niobe.net>
Message-ID: <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>

> On 20 Mar 2019, at 16:49, mark.reinhold at oracle.com wrote:
> 
> // Dropping announce at ojn, since no one else?s e-mail client appears
> // intelligent enough to do so
> 
> 2019/3/20 7:10:12 -0700, jesper.wilhelmsson at oracle.com:
>> I didn't see any actual decision on this. Is it enough that there is a
>> bug filed in JBS and a mail thread with five or so people that thinks
>> it is a good idea? Given that this is enough for most code changes
>> that potentially could have a much larger impact on the OpenJDK maybe
>> it's fine. I don't have an opinion here, I'm just curious as to how we
>> make decisions in the OpenJDK.
> 
> In the OpenJDK Community we generally make decisions by rough consensus,
> except for situations explicitly identified in the Bylaws as requiring
> formal votes.
> 
> In any case, as the Lead of the JDK Project I endorse Se?n?s original
> proposal [1].
> 
> Jesper -- since you handle promotion tagging for the main-line repo,
> could you please also create the jdk-12-ga tag in that repo?  Thanks.

Done.

Will the tag propagate to jdk-updates/jdk12u or should I add it there as well?

Thanks,
/Jesper

> - Mark
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-October/002004.html


From mark.reinhold at oracle.com  Wed Mar 20 21:10:30 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 20 Mar 2019 14:10:30 -0700
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
 <20190320084919.353484575@eggemoggin.niobe.net>
 <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>
Message-ID: <20190320141030.888908173@eggemoggin.niobe.net>

2019/3/20 9:47:02 -0700, jesper.wilhelmsson at oracle.com:
>> On 20 Mar 2019, at 16:49, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> Jesper -- since you handle promotion tagging for the main-line repo,
>> could you please also create the jdk-12-ga tag in that repo?  Thanks.
> 
> Done.

Thanks!

> Will the tag propagate to jdk-updates/jdk12u or should I add it there as well?

Not automatically, so please add it there too.

- Mark

From daniel.smith at oracle.com  Thu Mar 21 00:18:10 2019
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 20 Mar 2019 18:18:10 -0600
Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve
 documentation
Message-ID: <3852C1F4-F890-4B76-903D-7525C4A5D7F9@oracle.com>

http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ <http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/>

Please review this update to java.lang.invoke.LambdaMetafactory. Adds some argument validation with tests; improves documentation; renames some variables.

JBS: https://bugs.openjdk.java.net/browse/JDK-8174222 <https://bugs.openjdk.java.net/browse/JDK-8174222>

?Dan


From daniel.smith at oracle.com  Thu Mar 21 04:01:50 2019
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 20 Mar 2019 22:01:50 -0600
Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve
 documentation
In-Reply-To: <3852C1F4-F890-4B76-903D-7525C4A5D7F9@oracle.com>
References: <3852C1F4-F890-4B76-903D-7525C4A5D7F9@oracle.com>
Message-ID: <45D7D772-7A13-44BB-A9CD-7F03CEE0C18D@oracle.com>

Sorry, intended for core-libs-dev. Please disregard.

> On Mar 20, 2019, at 6:18 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ <http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/>
> 
> Please review this update to java.lang.invoke.LambdaMetafactory. Adds some argument validation with tests; improves documentation; renames some variables.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8174222 <https://bugs.openjdk.java.net/browse/JDK-8174222>
> 
> ?Dan
> 


From goetz.lindenmaier at sap.com  Thu Mar 21 10:21:54 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 21 Mar 2019 10:21:54 +0000
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
 <20190320084919.353484575@eggemoggin.niobe.net>
 <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>
Message-ID: <VI1PR02MB51838C43921D0EF44CC6A153EC420@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi Jesper, 

thanks a lot!  This will help us automatizing our release builds.

Best regards,
  Goetz

> -----Original Message-----
> From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com>
> Sent: Mittwoch, 20. M?rz 2019 17:47
> To: mark.reinhold at oracle.com
> Cc: sean.coffey at oracle.com; Langer, Christoph <christoph.langer at sap.com>;
> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-dev at openjdk.java.net
> Subject: Re: Java 12 / JDK 12: General Availability
> 
> > On 20 Mar 2019, at 16:49, mark.reinhold at oracle.com wrote:
> >
> > // Dropping announce at ojn, since no one else?s e-mail client appears
> > // intelligent enough to do so
> >
> > 2019/3/20 7:10:12 -0700, jesper.wilhelmsson at oracle.com:
> >> I didn't see any actual decision on this. Is it enough that there is a
> >> bug filed in JBS and a mail thread with five or so people that thinks
> >> it is a good idea? Given that this is enough for most code changes
> >> that potentially could have a much larger impact on the OpenJDK maybe
> >> it's fine. I don't have an opinion here, I'm just curious as to how we
> >> make decisions in the OpenJDK.
> >
> > In the OpenJDK Community we generally make decisions by rough
> consensus,
> > except for situations explicitly identified in the Bylaws as requiring
> > formal votes.
> >
> > In any case, as the Lead of the JDK Project I endorse Se?n?s original
> > proposal [1].
> >
> > Jesper -- since you handle promotion tagging for the main-line repo,
> > could you please also create the jdk-12-ga tag in that repo?  Thanks.
> 
> Done.
> 
> Will the tag propagate to jdk-updates/jdk12u or should I add it there as well?
> 
> Thanks,
> /Jesper
> 
> > - Mark
> >
> >
> > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-
> October/002004.html


From rob.mckenna at oracle.com  Thu Mar 21 17:23:31 2019
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 21 Mar 2019 17:23:31 +0000
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <20190320141030.888908173@eggemoggin.niobe.net>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
 <20190320084919.353484575@eggemoggin.niobe.net>
 <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>
 <20190320141030.888908173@eggemoggin.niobe.net>
Message-ID: <20190321172331.GB4067@vimes>

I'll take care of that with the regular sync to jdk12u. (the final one
has yet to happen) Thanks,

    -Rob

On 20/03/19 14:10, mark.reinhold at oracle.com wrote:
> 2019/3/20 9:47:02 -0700, jesper.wilhelmsson at oracle.com:
> >> On 20 Mar 2019, at 16:49, mark.reinhold at oracle.com wrote:
> >> ...
> >> 
> >> Jesper -- since you handle promotion tagging for the main-line repo,
> >> could you please also create the jdk-12-ga tag in that repo?  Thanks.
> > 
> > Done.
> 
> Thanks!
> 
> > Will the tag propagate to jdk-updates/jdk12u or should I add it there as well?
> 
> Not automatically, so please add it there too.
> 
> - Mark

From jesper.wilhelmsson at oracle.com  Thu Mar 21 18:04:26 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 21 Mar 2019 19:04:26 +0100
Subject: Java 12 / JDK 12: General Availability
In-Reply-To: <20190321172331.GB4067@vimes>
References: <20190319165506.A3E2026CD1F@eggemoggin.niobe.net>
 <VI1PR02MB51839314333F87276E29A814EC410@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266B5AABA950E842CD551898A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <31B81D4C-49B7-429F-8DC0-67FD1789D43F@oracle.com>
 <20190320084919.353484575@eggemoggin.niobe.net>
 <842B8B5A-B1D1-4AE2-8087-B0F1E3B47A10@oracle.com>
 <20190320141030.888908173@eggemoggin.niobe.net> <20190321172331.GB4067@vimes>
Message-ID: <3E84B002-27DE-42F6-BECE-EFA99EC2836F@oracle.com>

I did that already yesterday so I guess the final sync has happened now :-)   There were no other changes than the tag to bring over.
/Jesper


> On 21 Mar 2019, at 18:23, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> I'll take care of that with the regular sync to jdk12u. (the final one
> has yet to happen) Thanks,
> 
>    -Rob
> 
> On 20/03/19 14:10, mark.reinhold at oracle.com wrote:
>> 2019/3/20 9:47:02 -0700, jesper.wilhelmsson at oracle.com:
>>>> On 20 Mar 2019, at 16:49, mark.reinhold at oracle.com wrote:
>>>> ...
>>>> 
>>>> Jesper -- since you handle promotion tagging for the main-line repo,
>>>> could you please also create the jdk-12-ga tag in that repo?  Thanks.
>>> 
>>> Done.
>> 
>> Thanks!
>> 
>>> Will the tag propagate to jdk-updates/jdk12u or should I add it there as well?
>> 
>> Not automatically, so please add it there too.
>> 
>> - Mark


From gromero at linux.vnet.ibm.com  Tue Mar 26 01:35:40 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 25 Mar 2019 22:35:40 -0300
Subject: Is jdk/submit repo working fine?
Message-ID: <5c8a94ed-1d82-ff1e-4625-55d0596130d5@linux.vnet.ibm.com>

Hello,

Is jdk/submit repo working correctly?

I submitted a change for testing:

http://hg.openjdk.java.net/jdk/submit/rev/7d39e6aad505

and it's passed ~3 hours without a reply/result.

Any clue on that?

Thanks a lot.

Regards,
Gustavo


From christian.tornqvist at oracle.com  Tue Mar 26 01:59:55 2019
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 25 Mar 2019 18:59:55 -0700
Subject: Is jdk/submit repo working fine?
In-Reply-To: <5c8a94ed-1d82-ff1e-4625-55d0596130d5@linux.vnet.ibm.com>
References: <5c8a94ed-1d82-ff1e-4625-55d0596130d5@linux.vnet.ibm.com>
Message-ID: <601422B0-A665-4490-B322-A1A7476F7D9C@oracle.com>

Hi Gustavo,

The job failed to submit to our test system, most likely because your branch is not up-to-date, see if pulling the latest changes from the default branch helps.

Thanks,
Christian

> On Mar 25, 2019, at 6:35 PM, Gustavo Romero <gromero at linux.vnet.ibm.com> wrote:
> 
> Hello,
> 
> Is jdk/submit repo working correctly?
> 
> I submitted a change for testing:
> 
> http://hg.openjdk.java.net/jdk/submit/rev/7d39e6aad505
> 
> and it's passed ~3 hours without a reply/result.
> 
> Any clue on that?
> 
> Thanks a lot.
> 
> Regards,
> Gustavo
> 


From gromero at linux.vnet.ibm.com  Tue Mar 26 14:30:02 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 26 Mar 2019 11:30:02 -0300
Subject: Is jdk/submit repo working fine?
In-Reply-To: <601422B0-A665-4490-B322-A1A7476F7D9C@oracle.com>
References: <5c8a94ed-1d82-ff1e-4625-55d0596130d5@linux.vnet.ibm.com>
 <601422B0-A665-4490-B322-A1A7476F7D9C@oracle.com>
Message-ID: <1ead5a7a-835e-792d-c3cb-e0857bd567da@linux.vnet.ibm.com>

Hi Christian,

On 03/25/2019 10:59 PM, Christian Tornqvist wrote:
> Hi Gustavo,
> 
> The job failed to submit to our test system, most likely because your branch is not up-to-date, see if pulling the latest changes from the default branch helps.

Thanks for checking it!

I'm sure I did a `hg pull` in the default branch and made sure it was updated
with 'hg update`, then I created a branch as usual, with
'hg branch "JDK-<bug_id>"' and committed the change there.

But one thing was odd in fact: sitting on my branch "JDK-<bud_id>" 'hg outgoing'
showed lots of changes instead of only the one I committed in my branch. So I
pushed using --branch specifying explicitly my branch, trying to
avoid anything else besides my change to be pushed/submitted.

Anyway, won't that be good to have at least an automatic message telling us it
failed to be submitted?

Regards,
Gustavo

> Thanks,
> Christian
> 
>> On Mar 25, 2019, at 6:35 PM, Gustavo Romero <gromero at linux.vnet.ibm.com> wrote:
>>
>> Hello,
>>
>> Is jdk/submit repo working correctly?
>>
>> I submitted a change for testing:
>>
>> http://hg.openjdk.java.net/jdk/submit/rev/7d39e6aad505
>>
>> and it's passed ~3 hours without a reply/result.
>>
>> Any clue on that?
>>
>> Thanks a lot.
>>
>> Regards,
>> Gustavo
>>
> 


From mark.reinhold at oracle.com  Tue Mar 26 18:56:58 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 26 Mar 2019 11:56:58 -0700
Subject: Proposed schedule for JDK 13
In-Reply-To: <20190318212041.EE17E26CB55@eggemoggin.niobe.net>
References: <20190318212041.EE17E26CB55@eggemoggin.niobe.net>
Message-ID: <20190326115658.118568924@eggemoggin.niobe.net>

2019/3/18 14:20:41 -0700, mark.reinhold at oracle.com:
> With JDK 12 nearly finished, here?s a proposed schedule for JDK 13:
> 
>   2019/06/13  Rampdown Phase One
>   2019/07/18  Rampdown Phase Two
>   2019/08/08  Initial Release Candidate
>   2019/08/22  Final Release Candidate
>   2019/09/17  General Availability
> 
> The phases are defined in JEP 3 [1].
> 
> Comments on this proposal from JDK Committers and Reviewers [2] are
> welcome, as are reasoned objections.  If no such objections are raised by
> 23:00 UTC next Monday, 25 March, or if they?re raised and satisfactorily
> answered, then per the JEP 2.0 process proposal [3] this will be the
> schedule for JDK 13.

Hearing no objections, this is now the schedule for JDK 13.

- Mark

From stanislav.smirnov at oracle.com  Wed Mar 27 18:48:28 2019
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Wed, 27 Mar 2019 14:48:28 -0400
Subject: Is jdk/submit repo working fine?
In-Reply-To: <1ead5a7a-835e-792d-c3cb-e0857bd567da@linux.vnet.ibm.com>
References: <5c8a94ed-1d82-ff1e-4625-55d0596130d5@linux.vnet.ibm.com>
 <601422B0-A665-4490-B322-A1A7476F7D9C@oracle.com>
 <1ead5a7a-835e-792d-c3cb-e0857bd567da@linux.vnet.ibm.com>
Message-ID: <308139AD-C0FD-4A7C-882A-C0A4805451A7@oracle.com>

Hi Gustavo,

yes, we are planning to enhance the jdk-submit notifications

Best regards,
Stanislav Smirnov





> On Mar 26, 2019, at 10:30 AM, Gustavo Romero <gromero at linux.vnet.ibm.com> wrote:
> 
> Anyway, won't that be good to have at least an automatic message telling us it
> failed to be submitted?


From jianglizhou at google.com  Thu Mar 28 01:31:28 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Wed, 27 Mar 2019 18:31:28 -0700
Subject: Result: New JDK Committer: Man Cao
Message-ID: <CALrW1jzGHmOj56jBHUoSqaLv14-dHLWec_TUVErMFrmx5LE+Eg@mail.gmail.com>

Voting for Man Cao (manc) [1] is now closed.

Yes: 23
Veto: 0
Abstain: 0

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

Thanks and regards,
Jiangli

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002686.html

From mark.reinhold at oracle.com  Thu Mar 28 15:15:16 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Mar 2019 08:15:16 -0700
Subject: Result: New JDK Committer: Man Cao
In-Reply-To: <CALrW1jzGHmOj56jBHUoSqaLv14-dHLWec_TUVErMFrmx5LE+Eg@mail.gmail.com>
References: <CALrW1jzGHmOj56jBHUoSqaLv14-dHLWec_TUVErMFrmx5LE+Eg@mail.gmail.com>
Message-ID: <20190328081516.11785001@eggemoggin.niobe.net>

2019/3/27 18:31:28 -0700, jianglizhou at google.com:
> Voting for Man Cao (manc) [1] is now closed.
> 
> Yes: 23
> Veto: 0
> Abstain: 0
> 
> According to the Bylaws definition of Lazy Consensus, this is
> sufficient to approve the nomination.

So recorded.

- Mark

From gromero at linux.vnet.ibm.com  Fri Mar 29 16:36:58 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Fri, 29 Mar 2019 13:36:58 -0300
Subject: Is jdk/submit repo working fine?
In-Reply-To: <308139AD-C0FD-4A7C-882A-C0A4805451A7@oracle.com>
References: <5c8a94ed-1d82-ff1e-4625-55d0596130d5@linux.vnet.ibm.com>
 <601422B0-A665-4490-B322-A1A7476F7D9C@oracle.com>
 <1ead5a7a-835e-792d-c3cb-e0857bd567da@linux.vnet.ibm.com>
 <308139AD-C0FD-4A7C-882A-C0A4805451A7@oracle.com>
Message-ID: <1c471d4c-d0a9-ac6a-c2e6-b3db14a9c3fe@linux.vnet.ibm.com>

On 03/27/2019 03:48 PM, Stanislav Smirnov wrote:
> yes, we are planning to enhance the jdk-submit notifications

Thanks for letting me know, Stanislav. Nice.

Best regards,
Gustavo



From alex.buckley at oracle.com  Sat Mar 30 00:19:19 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 29 Mar 2019 17:19:19 -0700
Subject: Call for feedback -- switch expressions in JDK 12
Message-ID: <5C9EB607.9020508@oracle.com>

Hi everyone,

People often ask how they can contribute to the Java development 
process. One of the easiest ways is to try out new features _on real 
code_ and share your experiences. We would love to hear how you're using 
the new language feature available on a preview basis in JDK 12 -- 
switch expressions.

Switch expressions make it easy to express multi-way conditionals in a 
compact, readable manner. Unlike switch statements, switch expressions 
don't fall through from one case to the next. Also, switch expressions 
on enums don't require a default if the cases are exhaustive. Also, 
multiple labels per case. See http://openjdk.java.net/jeps/325 for more.

To try switch expressions in your favorite environment:
- IntelliJ IDEA 2019.1: 
https://blog.jetbrains.com/idea/2019/02/java-12-and-intellij-idea/
- Eclipse 4.11: https://www.eclipse.org/eclipse/news/4.11/jdt.php#Java12
- Apache NetBeans 11.0: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091452
- jshell in JDK 12: pass `--enable-preview`
- javac in JDK 12: pass `--release 12 --enable-preview`

What works? What doesn't work? What was surprising? (Asking about use of 
the language feature, not setup of the IDE.)

Please respond here, or on the amber-dev list. Thank you in advance!

Alex