From jjg at openjdk.java.net  Mon Aug  2 15:37:35 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Aug 2021 15:37:35 GMT
Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint
 flags
In-Reply-To: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
References: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
Message-ID: <a-zyYLVjSHf8BP0DfbQj0vRGKCW76l2WX7zHEs3OvAo=.431072a6-1262-4e7f-8a6b-ecd9412eb386@github.com>

On Mon, 28 Jun 2021 13:33:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.
> 
> This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.
> 
> Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.
> 
> Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094
> 
> The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose

I suggest using a text block in the test, unless there is a compelling reason why you can't.

test/langtools/tools/javac/launcher/SourceLauncherTest.java line 624:

> 622:             "      if (o instanceof String s) {\n" +
> 623:             "          System.out.println(s);\n" +
> 624:             "      }\n" +

Is there a reason you're not using a text block here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4613

From darcy at openjdk.java.net  Tue Aug  3 00:48:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 Aug 2021 00:48:47 GMT
Subject: RFR: 8225488: Examine ExecutableType.getReceiverType behavior when
 source receiver parameter is absent
Message-ID: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>

A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior:

   Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value.

rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too.

BasicAnnoTests.java is updated for revised offsets.

All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18.

Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703

-------------

Commit messages:
 - Appease jcheck.
 - 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent

Changes: https://git.openjdk.java.net/jdk/pull/4965/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4965&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225488
  Stats: 32 lines in 4 files changed: 18 ins; 1 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4965.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4965/head:pull/4965

PR: https://git.openjdk.java.net/jdk/pull/4965

From cushon at openjdk.java.net  Tue Aug  3 04:21:51 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 3 Aug 2021 04:21:51 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that
 don't use it
Message-ID: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>

This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

-------------

Commit messages:
 - 8271623: Omit enclosing instance fields from inner classes that don't use it

Changes: https://git.openjdk.java.net/jdk/pull/4966/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271623
  Stats: 261 lines in 14 files changed: 216 ins; 15 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4966/head:pull/4966

PR: https://git.openjdk.java.net/jdk/pull/4966

From github.com+7806504+liach at openjdk.java.net  Tue Aug  3 07:02:32 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Tue, 3 Aug 2021 07:02:32 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <5Spxx3wzen48ZPfwjbOlwlM9992rcTi42Vk7RHnGc1M=.71f542fc-ebfd-4cfe-ae80-754f1ec38ec7@github.com>

On Tue, 3 Aug 2021 03:19:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

I hope we have a test case that ensures the field is not erroneously removed when this nested class doesn't use the field, but another nested class within this nested class does. An example:


public class Second {

  int t = 3;

  public static void main(String... a) {
    var q = new Second();
    var p = q.new Third().new Fourth();
    q.t = 6;
    p.print();
  }
  
  public class Third {
    public class Fourth {
      public void print() {
        System.out.println(Second.this.t);
      }
    }
  }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Tue Aug  3 18:48:04 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 3 Aug 2021 18:48:04 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <5Spxx3wzen48ZPfwjbOlwlM9992rcTi42Vk7RHnGc1M=.71f542fc-ebfd-4cfe-ae80-754f1ec38ec7@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <5Spxx3wzen48ZPfwjbOlwlM9992rcTi42Vk7RHnGc1M=.71f542fc-ebfd-4cfe-ae80-754f1ec38ec7@github.com>
Message-ID: <aOtz7BQ6O3a3hW2TCqEKUv8EpGpKpwZCpWEB_5bZCZc=.9b9858a7-bc7c-4bbc-99b7-642475f7a54a@github.com>

On Tue, 3 Aug 2021 06:59:36 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> I hope we have a test case that ensures the field is not erroneously removed when this nested class doesn't use the field, but another nested class within this nested class does. An example:
> 
> 
> public class Second {
> 
>   int t = 3;
> 
>   public static void main(String... a) {
>     var q = new Second();
>     var p = q.new Third().new Fourth();
>     q.t = 6;
>     p.print();
>   }
>   
>   public class Third {
>     public class Fourth {
>       public void print() {
>         System.out.println(Second.this.t);
>       }
>     }
>   }
> }

@liach thanks, I added another test case with nested inner classes.

The current implementation handles that correctly, because the nested classes are lowered first, so any uses of the enclosing instance's `this$` field will be recorded before it is finished being lowered.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Tue Aug  3 18:48:00 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 3 Aug 2021 18:48:00 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v2]
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <xv7z_CMdWdMNWNlpXWRYrCK5mPXnYXnYC_48zaZJgaQ=.93a0d3d4-3adb-4aa1-9e52-ae28fa56f4a6@github.com>

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add a test case with nested inner classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4966/files
  - new: https://git.openjdk.java.net/jdk/pull/4966/files/0ff3a3b9..3db4488c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=00-01

  Stats: 31 lines in 1 file changed: 23 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4966/head:pull/4966

PR: https://git.openjdk.java.net/jdk/pull/4966

From rafael.wth at gmail.com  Tue Aug  3 19:56:23 2021
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 3 Aug 2021 21:56:23 +0200
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
Message-ID: <CA+DM0Ak3J1v7MRz-C+SzFRdGC2t_7LvkfOHB-8PCimeW-x4wMA@mail.gmail.com>

Hi,

I remember remotely that this has been a discussion several times before,
this would especially be useful if it was also applied to anonymous inner
classes. The argument against, if I recall correctly, is that adding a
field access can create unexpected behavioral change, for example by
introducing memory leaks where there has not been one before only as the
result of an inline access change. With consistent handling, at least the
outcome is consistent and errors are not first introduced after minor
changes. I could however not find the threads on it, and I do personally
agree that there is potential for improvement.

I do however think that you must retain the constructor to accept the outer
instance, no matter if it is stored in a field or not. Otherwise, a public
inner class might change its constructor and introduce a binary
incompatible change if a field access of the outer class is removed or
added and this class is recompiled independently. If the constructor only
stores the field depending on the need to use it or not, the same effect is
achieved without risking such API breakage.

Without this, API developers would need to be very careful to include a
field access also if it is no longer required, after changing a class. For
instance,

class Outer {
  class Inner { }
}

would compile to bytecode for instantiation of Inner similar to:

new Outer.Inner();

after adding a field access from outer to inner, the bytecode would change
to:

new Outer.Inner(new Outer());

That's why the desugared code should look like this I think:

class Outer {
  class Inner {
    Inner(Outer this$) { }
  }
}

where the field is only added if required.

Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210803/d2f38a6c/attachment.htm>

From darcy at openjdk.java.net  Tue Aug  3 21:42:31 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 Aug 2021 21:42:31 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v2]
In-Reply-To: <xv7z_CMdWdMNWNlpXWRYrCK5mPXnYXnYC_48zaZJgaQ=.93a0d3d4-3adb-4aa1-9e52-ae28fa56f4a6@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <xv7z_CMdWdMNWNlpXWRYrCK5mPXnYXnYC_48zaZJgaQ=.93a0d3d4-3adb-4aa1-9e52-ae28fa56f4a6@github.com>
Message-ID: <LZjA4IC8mSineKFvkcdjqH4vrM5SnXeDeLWBnzbn7O8=.116c178d-d6ca-4152-b9cf-5554c9cf9146@github.com>

On Tue, 3 Aug 2021 18:48:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test case with nested inner classes

For the CSR review of this change, I'll request a corpus run be initiated.

Depending on the results of that run, the use of the new code generation idiom here may be triggered on -source/--release level. In other words, always use this$ in -source/--release 17 and earlier and omit it (when possible) on 18 and later.

If you have not done so already, please also run the core reflection regression tests with this change.

While the code generation idioms of javac are not a supported contract, applications can come to reply on them and change this idiom for earlier source levels may by too large of a behavioral compatibility change in that use-case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From alex.buckley at oracle.com  Tue Aug  3 23:34:10 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 3 Aug 2021 16:34:10 -0700
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <CA+DM0Ak3J1v7MRz-C+SzFRdGC2t_7LvkfOHB-8PCimeW-x4wMA@mail.gmail.com>
References: <CA+DM0Ak3J1v7MRz-C+SzFRdGC2t_7LvkfOHB-8PCimeW-x4wMA@mail.gmail.com>
Message-ID: <0420dc9f-4371-f73d-448c-e7a2a64f75bb@oracle.com>

On 8/3/2021 12:56 PM, Rafael Winterhalter wrote:
> I do however think that you must retain the constructor to accept the 
> outer instance, no matter if it is stored in a field or not. Otherwise, 
> a public inner class might change its constructor and introduce a binary 
> incompatible change if a field access of the outer class is removed or 
> added and this class is recompiled independently. ...

The JLS mandates a constructor parameter for the outer instance -- 
https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.8.1-200 
-- and nothing in the patch appears to do away with that parameter. 
There's even a comment in Lower.java that "If the variable is never 
accessed, we skip creating an outer instance field and saving the 
constructor parameter to it." -- implying the parameter still exists.

It would be good for the CSR (JDK-8271717) to clarify that the 
T-accepting constructor in class T$I is still present after the change, 
and merely invokes a super constructor.

Alex

From john.r.rose at oracle.com  Tue Aug  3 23:47:52 2021
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 3 Aug 2021 23:47:52 +0000
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <CA+DM0Ak3J1v7MRz-C+SzFRdGC2t_7LvkfOHB-8PCimeW-x4wMA@mail.gmail.com>
References: <CA+DM0Ak3J1v7MRz-C+SzFRdGC2t_7LvkfOHB-8PCimeW-x4wMA@mail.gmail.com>
Message-ID: <EC39D288-70B2-49D5-9ED0-B6274E133547@oracle.com>

On Aug 3, 2021, at 12:56 PM, Rafael Winterhalter <rafael.wth at gmail.com<mailto:rafael.wth at gmail.com>> wrote:

I do however think that you must retain the constructor to accept the outer instance, no matter if it is stored in a field or not. Otherwise, a public inner class might change its constructor and introduce a binary incompatible change if a field access of the outer class is removed or added and this class is recompiled independently. If the constructor only stores the field depending on the need to use it or not, the same effect is achieved without risking such API breakage.

Good point.  The named inner classes are supposed
to have a predictable shape at the VM level, to make
use of reflection and debuggers a little easier.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210803/4066a530/attachment.htm>

From graeme.rocher at oracle.com  Wed Aug  4 07:48:41 2021
From: graeme.rocher at oracle.com (Graeme Keith Rocher)
Date: Wed, 4 Aug 2021 07:48:41 +0000
Subject: Scanning for resources on the user classpath from an annotation
 processor
Message-ID: <BY5PR10MB4210103B375BEA49FC1282D395F19@BY5PR10MB4210.namprd10.prod.outlook.com>

Hi all,

Apologies in advance if I am sending this to the wrong place.

We have a requirement in the upcoming CDI lite specification to find ?beans.xml? files in the user classpath from an annotation processor (Micronaut).

The issue is that as far as I am aware there is no way to do this from an annotation processor since the ?JavaFileManager? interface is inaccessible which provides this functionality via the ?getClassLoader? method that accepts a location that can be the user classpath:

https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location)

We have an experimental and not officially supported hack in the Micronaut annotation processor to attempt to work around this which retrieves the ?JavaFileManager? via reflection:

https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142

However clearly this violates the JDKs direction in terms of closing more of the internals.

I would like to request the addition of an officially supported way to do this via the APT API and am happy to contribute a proposal / JEP + PR if it means it can be taken forward since without this functionality it would mean that users will have to unnecessarily pollute the annotation processor classpath with JARs that aren?t required on that classpath.

Thanks in advance for any feedback.

Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210804/48502f47/attachment.htm>

From tomas.langer at oracle.com  Wed Aug  4 12:15:04 2021
From: tomas.langer at oracle.com (Tomas Langer)
Date: Wed, 4 Aug 2021 12:15:04 +0000
Subject: Scanning for resources on the user classpath from an annotation
 processor
Message-ID: <B7069239-5492-49A2-B615-47FFD3B106A0@oracle.com>

Hello,

 I have also tried to do this and failed. I have tried the workaround - it works fine with Java 11, but fails with Java 17:

java.lang.IllegalAccessException: class MyAnnotationProcessor cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @78a0dabb
        at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
        at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
        at java.base/java.lang.reflect.Method.invoke(Method.java:560)
        at MyAnnotationProcessor.fileManager(MyAnnotationProcessor.java:644)


Thanks,

Tomas


> Hi all,
>
> Apologies in advance if I am sending this to the wrong place.
>
> We have a requirement in the upcoming CDI lite specification to find ?beans.xml? files in the user classpath from an annotation processor (Micronaut).
>
> The issue is that as far as I am aware there is no way to do this from an annotation processor since the ?JavaFileManager? interface is inaccessible which provides this functionality via the ?getClassLoader? method that accepts a location that can be the user classpath:
>
> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location)
>
> We have an experimental and not officially supported hack in the Micronaut annotation processor to attempt to work around this which retrieves the ?JavaFileManager? via reflection:
>
> https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142<https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142>
>
> However clearly this violates the JDKs direction in terms of closing more of the internals.
>
> I would like to request the addition of an officially supported way to do this via the APT API and am happy to contribute a proposal / JEP + PR if it means it can be taken  forward since without this functionality it would mean that users will have to unnecessarily pollute the annotation processor classpath with JARs that aren?t required on  that classpath.
>
> Thanks in advance for any feedback.
>
> Graeme


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210804/d44ef6b8/attachment.htm>

From darcy at openjdk.java.net  Wed Aug  4 22:51:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 4 Aug 2021 22:51:46 GMT
Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model utility
 class
Message-ID: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>

Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903.

-------------

Commit messages:
 - Appease jcheck.
 - Now with tests and javac Elements implementation.
 - Merge branch 'master' into JDK-8140442
 - Merge branch 'master' into JDK-8140442
 - Initial version pre-tests.

Changes: https://git.openjdk.java.net/jdk/pull/5007/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8140442
  Stats: 322 lines in 6 files changed: 268 ins; 53 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5007/head:pull/5007

PR: https://git.openjdk.java.net/jdk/pull/5007

From asotona at openjdk.java.net  Thu Aug  5 09:02:30 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 5 Aug 2021 09:02:30 GMT
Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint
 flags
In-Reply-To: <a-zyYLVjSHf8BP0DfbQj0vRGKCW76l2WX7zHEs3OvAo=.431072a6-1262-4e7f-8a6b-ecd9412eb386@github.com>
References: <qjY5eulWucRl0uOLn3SUAN5kNfssM9FIzu3Dd9wudsE=.87757a9c-b29a-4797-8fcf-a6fa2260f7b9@github.com>
 <a-zyYLVjSHf8BP0DfbQj0vRGKCW76l2WX7zHEs3OvAo=.431072a6-1262-4e7f-8a6b-ecd9412eb386@github.com>
Message-ID: <tz_Ro4t1vkHETowY8qVMe4jGDbtWIHx9Wp8hqxagdEM=.253ef83f-89ec-442e-8c7b-65572281b549@github.com>

On Mon, 2 Aug 2021 15:33:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.
>> 
>> This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.
>> 
>> Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.
>> 
>> Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094
>> 
>> The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose
>
> test/langtools/tools/javac/launcher/SourceLauncherTest.java line 624:
> 
>> 622:             "      if (o instanceof String s) {\n" +
>> 623:             "          System.out.println(s);\n" +
>> 624:             "      }\n" +
> 
> Is there a reason you're not using a text block here?

Using text block will prevent potential "clean" backports of this issue. However if you think this patch won't be subject of backport, I can turn it into text block.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4613

From jlahoda at openjdk.java.net  Thu Aug  5 11:37:45 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Aug 2021 11:37:45 GMT
Subject: RFR: 8271928: ErroneousTree with start position -1
Message-ID: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>

For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set.

-------------

Commit messages:
 - 8271928: ErroneousTree with start position -1

Changes: https://git.openjdk.java.net/jdk/pull/5018/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5018&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271928
  Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5018.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5018/head:pull/5018

PR: https://git.openjdk.java.net/jdk/pull/5018

From jlaskey at openjdk.java.net  Thu Aug  5 11:49:32 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 5 Aug 2021 11:49:32 GMT
Subject: RFR: 8271928: ErroneousTree with start position -1
In-Reply-To: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>
References: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>
Message-ID: <uM1JpJRVOOaSCwa5PhW9DQJF0fUH0GTssIE-rdgalHQ=.6f0d7133-1e53-44d1-b5a7-d9c2faf1fa08@github.com>

On Thu, 5 Aug 2021 11:30:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5018

From vromero at openjdk.java.net  Thu Aug  5 17:04:30 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 Aug 2021 17:04:30 GMT
Subject: RFR: 8271928: ErroneousTree with start position -1
In-Reply-To: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>
References: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>
Message-ID: <b_hXQ7kbApE1poaPMfkrjU8Uxb3tJJKSKVtZJOx2f8c=.b9726cc4-dca1-4ed4-8a32-78a80df34622@github.com>

On Thu, 5 Aug 2021 11:30:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set.

Marked as reviewed by vromero (Reviewer).

looks good

-------------

PR: https://git.openjdk.java.net/jdk/pull/5018Marked as reviewed by vromero (Reviewer).

From jjg at openjdk.java.net  Thu Aug  5 19:26:50 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 19:26:50 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
Message-ID: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>

Please review a semi-automatic update of the nroff man pages from the upstream files.

-------------

Commit messages:
 - JDK-8270872: Final nroff manpage update for JDK 17

Changes: https://git.openjdk.java.net/jdk17/pull/303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270872
  Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/303/head:pull/303

PR: https://git.openjdk.java.net/jdk17/pull/303

From darcy at openjdk.java.net  Thu Aug  5 19:44:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 Aug 2021 19:44:37 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <aWsXaUX5hmJ55kEcFzOXW7NqpE9NgjKXkZrDuNOHFJo=.2e213a1d-9d49-41ac-92d7-166ef9c08c67@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 20:01:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 20:01:37 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:

> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.

This seems not correct?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From mr at openjdk.java.net  Thu Aug  5 20:13:39 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 Aug 2021 20:13:39 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <jv6rEFb4aLBK1e6FBH186cyOqbPFVYLvomqdfzafljA=.95892c77-ab88-422f-91fc-343dfe6f99c6@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by mr (Lead).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From iris at openjdk.java.net  Thu Aug  5 20:40:40 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 5 Aug 2021 20:40:40 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <liAhrSHq9y4NbW5DufoiKCG95FcISducefm4wUe8ocE=.57c889b5-b016-4678-9980-e62769b62f8d@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From jjg at openjdk.java.net  Thu Aug  5 21:39:38 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 21:39:38 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
Message-ID: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>

On Thu, 5 Aug 2021 19:57:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review a semi-automatic update of the nroff man pages from the upstream files.
>
> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:
> 
>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> This seems not correct?

According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.

I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.

This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.

I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 21:44:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 21:44:35 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <aq2UDjtBswQl63RvqgMXPgYZu5Eo9b34GJqGM0YzOpE=.185c7174-d0dd-4b52-9815-f7909a45187a@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 21:44:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 21:44:36 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
 <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
Message-ID: <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>

On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:
>> 
>>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>> 
>> This seems not correct?
>
> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.
> 
> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.
> 
> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.
> 
> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.

Thanks for the explanation, Jon. Fine by me.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From mr at openjdk.java.net  Thu Aug  5 21:44:36 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 Aug 2021 21:44:36 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
 <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
 <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>
Message-ID: <k4aobJsxKwpdOZQqr1GFaBhAGbMh16e4EUxpDAql-Us=.5d7d0799-8d1c-42a0-91a2-44b0912ed475@github.com>

On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.
>> 
>> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.
>> 
>> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.
>> 
>> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.
>
> Thanks for the explanation, Jon. Fine by me.

I agree that fixing this date is not necessary at this time.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From jjg at openjdk.java.net  Thu Aug  5 22:15:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 22:15:29 GMT
Subject: [jdk17] Integrated: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <k3Bqh5GeG3FgEBh_9rbFrDjJrTd6VSoO2S-KYSPIY_s=.50ab8e33-39b0-4ca9-9931-61cb55ec5c0d@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

This pull request has now been integrated.

Changeset: dfacda48
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/dfacda488bfbe2e11e8d607a6d08527710286982
Stats:     289 lines in 27 files changed: 117 ins; 31 del; 141 mod

8270872: Final nroff manpage update for JDK 17

Reviewed-by: darcy, mr, iris, naoto

-------------

PR: https://git.openjdk.java.net/jdk17/pull/303

From jwilhelm at openjdk.java.net  Thu Aug  5 23:57:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 5 Aug 2021 23:57:59 GMT
Subject: RFR: Merge jdk17
Message-ID: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8270872: Final nroff manpage update for JDK 17
 - 8271588: JFR Recorder Thread crashed with SIGSEGV in write_klass
 - 8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/5026/files
  Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026

PR: https://git.openjdk.java.net/jdk/pull/5026

From jwilhelm at openjdk.java.net  Fri Aug  6 01:27:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 01:27:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
References: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
Message-ID: <lfK3BfjviJuRKG0C--gFo3MRja2_KrGtQjN4gEp4OsU=.9c421dfd-08de-40d5-8fb5-f88dcad215bb@github.com>

On Thu, 5 Aug 2021 23:49:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 14692d5e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/14692d5ed0652b867fcf28baafa498a9441683ac
Stats:     307 lines in 32 files changed: 129 ins; 33 del; 145 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/5026

From jwilhelm at openjdk.java.net  Fri Aug  6 01:27:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 01:27:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
References: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
Message-ID: <1oUovSIU_RoljyN5VHPljZLMI5NpHqK3ys9BDhsuLI8=.15d53c62-802e-4982-9415-527c302b8ab4@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 440 commits:

 - Merge
 - 8271293: Monitor class should use ThreadBlockInVMPreprocess
   
   Reviewed-by: dholmes, dcubed
 - 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS
   
   Reviewed-by: psadhukhan, aivanov
 - 8271905: mark hotspot runtime/Metaspace tests which ignore external VM flags
   
   Reviewed-by: stuefe
 - 8271308: (fc) FileChannel.transferTo() transfers no more than Integer.MAX_VALUE bytes in one call
   
   Reviewed-by: alanb, vtewari
 - 8271953: fix mis-merge in JDK-8271878
   
   Reviewed-by: jwilhelm, ctornqvi
 - 8267840: Improve URLStreamHandler.parseURL()
   
   Reviewed-by: dfuchs, redestad
 - 8271840: Add simple Integer.toString microbenchmarks
   
   Reviewed-by: shade
 - 8271121: ZGC: stack overflow (segv) when -Xlog:gc+start=debug
   
   Reviewed-by: ayang, eosterlund
 - 8270903: sun.net.httpserver.HttpConnection: Improve toString
   
   Reviewed-by: chegar, vtewari
 - ... and 430 more: https://git.openjdk.java.net/jdk/compare/dfacda48...7e069880

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=01
  Stats: 97370 lines in 1522 files changed: 61891 ins; 27834 del; 7645 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026

PR: https://git.openjdk.java.net/jdk/pull/5026

From prappo at openjdk.java.net  Fri Aug  6 12:24:06 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 6 Aug 2021 12:24:06 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Pass through FIXMEs and TODOs
  
  Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/0a47e9c2..22d1e07d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=05-06

  Stats: 11 lines in 5 files changed: 3 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From darcy at openjdk.java.net  Fri Aug  6 21:21:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 6 Aug 2021 21:21:51 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s)
Message-ID: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>

Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

-------------

Commit messages:
 - 8224922: Access JavaFileObject from Element(s)

Changes: https://git.openjdk.java.net/jdk/pull/5038/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8224922
  Stats: 74 lines in 2 files changed: 74 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From graeme.rocher at oracle.com  Mon Aug  9 08:03:54 2021
From: graeme.rocher at oracle.com (Graeme Keith Rocher)
Date: Mon, 9 Aug 2021 08:03:54 +0000
Subject: Scanning for resources on the user classpath from an annotation
 processor
In-Reply-To: <BY5PR10MB4210103B375BEA49FC1282D395F19@BY5PR10MB4210.namprd10.prod.outlook.com>
References: <BY5PR10MB4210103B375BEA49FC1282D395F19@BY5PR10MB4210.namprd10.prod.outlook.com>
Message-ID: <BY5PR10MB4210BFD994E0BEA455CA701E95F69@BY5PR10MB4210.namprd10.prod.outlook.com>

Having thought about this some more, this request can be ignored as it would be better to implement the required functionality at the build tooling layer whereby the build tooling collects the beans.xml resources needed by the processor and specifies them as inputs (annotation processor arguments) in order for incremental compilation to work.

Apologies for the noise.

Graeme

From: Graeme Keith Rocher <graeme.rocher at oracle.com>
Date: Wednesday, 4 August 2021 at 09:48
To: compiler-dev at openjdk.java.net <compiler-dev at openjdk.java.net>
Subject: Scanning for resources on the user classpath from an annotation processor
Hi all,

Apologies in advance if I am sending this to the wrong place.

We have a requirement in the upcoming CDI lite specification to find ?beans.xml? files in the user classpath from an annotation processor (Micronaut).

The issue is that as far as I am aware there is no way to do this from an annotation processor since the ?JavaFileManager? interface is inaccessible which provides this functionality via the ?getClassLoader? method that accepts a location that can be the user classpath:

https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location)

We have an experimental and not officially supported hack in the Micronaut annotation processor to attempt to work around this which retrieves the ?JavaFileManager? via reflection:

https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142

However clearly this violates the JDKs direction in terms of closing more of the internals.

I would like to request the addition of an officially supported way to do this via the APT API and am happy to contribute a proposal / JEP + PR if it means it can be taken forward since without this functionality it would mean that users will have to unnecessarily pollute the annotation processor classpath with JARs that aren?t required on that classpath.

Thanks in advance for any feedback.

Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210809/4ed918ab/attachment.htm>

From forax at univ-mlv.fr  Mon Aug  9 09:28:56 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 9 Aug 2021 11:28:56 +0200 (CEST)
Subject: Scanning for resources on the user classpath from an annotation
 processor
In-Reply-To: <BY5PR10MB4210BFD994E0BEA455CA701E95F69@BY5PR10MB4210.namprd10.prod.outlook.com>
References: <BY5PR10MB4210103B375BEA49FC1282D395F19@BY5PR10MB4210.namprd10.prod.outlook.com>
 <BY5PR10MB4210BFD994E0BEA455CA701E95F69@BY5PR10MB4210.namprd10.prod.outlook.com>
Message-ID: <1021925133.103217.1628501336757.JavaMail.zimbra@u-pem.fr>

> From: "Graeme Keith Rocher" <graeme.rocher at oracle.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Monday, August 9, 2021 10:03:54 AM
> Subject: Re: Scanning for resources on the user classpath from an annotation
> processor

> Having thought about this some more, this request can be ignored as it would be
> better to implement the required functionality at the build tooling layer
> whereby the build tooling collects the beans.xml resources needed by the
> processor and specifies them as inputs (annotation processor arguments) in
> order for incremental compilation to work.

yes, it seems a better design :) 

> Apologies for the noise.

> Graeme

R?mi 

> From: Graeme Keith Rocher <graeme.rocher at oracle.com>
> Date: Wednesday, 4 August 2021 at 09:48
> To: compiler-dev at openjdk.java.net <compiler-dev at openjdk.java.net>
> Subject: Scanning for resources on the user classpath from an annotation
> processor

> Hi all,

> Apologies in advance if I am sending this to the wrong place.

> We have a requirement in the upcoming CDI lite specification to find ?beans.xml?
> files in the user classpath from an annotation processor (Micronaut).

> The issue is that as far as I am aware there is no way to do this from an
> annotation processor since the ?JavaFileManager? interface is inaccessible
> which provides this functionality via the ?getClassLoader? method that accepts
> a location that can be the user classpath:

> [
> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader%28javax.tools.JavaFileManager.Location%29
> |
> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location)
> ]

> We have an experimental and not officially supported hack in the Micronaut
> annotation processor to attempt to work around this which retrieves the
> ?JavaFileManager? via reflection:

> [
> https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142
> |
> https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142
> ]

> However clearly this violates the JDKs direction in terms of closing more of the
> internals.

> I would like to request the addition of an officially supported way to do this
> via the APT API and am happy to contribute a proposal / JEP + PR if it means it
> can be taken forward since without this functionality it would mean that users
> will have to unnecessarily pollute the annotation processor classpath with JARs
> that aren?t required on that classpath.

> Thanks in advance for any feedback.

> Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210809/97a8470f/attachment-0001.htm>

From jjg at openjdk.java.net  Mon Aug  9 18:00:38 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 9 Aug 2021 18:00:38 GMT
Subject: RFR: 8225488: Examine ExecutableType.getReceiverType behavior
 when source receiver parameter is absent
In-Reply-To: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>
References: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>
Message-ID: <UMNW7a_GkIiIf2vQnwk4Nxcu8k_WBAvHIMXCzdFEI7k=.821c0905-257c-42f3-8257-45a02ad71c66@github.com>

On Tue, 3 Aug 2021 00:06:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior:
> 
>    Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value.
> 
> rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too.
> 
> BasicAnnoTests.java is updated for revised offsets.
> 
> All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18.
> 
> Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4965

From darcy at openjdk.java.net  Mon Aug  9 18:10:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 Aug 2021 18:10:12 GMT
Subject: RFR: 8225488: Examine ExecutableType.getReceiverType behavior
 when source receiver parameter is absent [v2]
In-Reply-To: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>
References: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>
Message-ID: <_uz2pKdslmqy2W5rofgUOt-DDGzWv1GC-UVKJX2ww10=.f0b8850e-3a57-4e3a-b764-35ed64aeae63@github.com>

> A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior:
> 
>    Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value.
> 
> rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too.
> 
> BasicAnnoTests.java is updated for revised offsets.
> 
> All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18.
> 
> Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge and update copyrights.
 - Merge branch 'master' into 8225488
 - Appease jcheck.
 - 8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4965/files
  - new: https://git.openjdk.java.net/jdk/pull/4965/files/ed3bed58..c9df1003

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4965&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4965&range=00-01

  Stats: 11405 lines in 361 files changed: 9000 ins; 1427 del; 978 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4965.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4965/head:pull/4965

PR: https://git.openjdk.java.net/jdk/pull/4965

From darcy at openjdk.java.net  Mon Aug  9 18:36:36 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 Aug 2021 18:36:36 GMT
Subject: Integrated: 8225488: Examine ExecutableType.getReceiverType behavior
 when source receiver parameter is absent
In-Reply-To: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>
References: <heAh3BA7Um7aaEE7bFYXbDVLZJAz8KxD1ASUwQ9ELg8=.09f59494-06db-477b-adb1-4d44d48beebd@github.com>
Message-ID: <iCvLMmVlJnEkG9ZEQqLnPCbkkh0cej_e0oOUzamcy0s=.cdc45e9d-f7d1-42e2-a345-65cae16cf606@github.com>

On Tue, 3 Aug 2021 00:06:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A belated companion fix to JDK-8222369, this change updates ExecutableType.getReceiverType to have its specified behavior:
> 
>    Returns the return type of this executable. Returns a NoType with kind VOID if this executable is not a method, or is a method that does not return a value.
> 
> rather than returning null, as the implementation did before. The ExecutableElement implementation in Symbol is updated accordingly to take advantage of the change in Type, along with augmenting the test from JDK-8222369 to cover the receiver type from the ExecutableType too.
> 
> BasicAnnoTests.java is updated for revised offsets.
> 
> All langtools tests pass with these changes and TestExecutableReceiverType.java fails with an unmodified javac in JDK 18.
> 
> Please also review the companion CSR JDK-8271703, https://bugs.openjdk.java.net/browse/JDK-8271703

This pull request has now been integrated.

Changeset: 7fc99cf9
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7fc99cf9b69f99fc78709e57b92cd88e09577d0f
Stats:     34 lines in 4 files changed: 18 ins; 1 del; 15 mod

8225488: Examine ExecutableType.getReceiverType behavior when source receiver parameter is absent

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/4965

From thartmann at openjdk.java.net  Tue Aug 10 07:02:29 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 10 Aug 2021 07:02:29 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v3]
In-Reply-To: <sX1BXdvV5XuyHbk9R1qjSFglgNmpKEKZXCT2nQeyi6k=.df711317-dbc7-4295-ad17-a3f0d0a8bfca@github.com>
References: <IHKVdDTKJq7jzIc_gl3gJVC-qvHa_WTn6SYdVL1tgWs=.d575e257-f611-4333-86ad-d939dc430c95@github.com>
 <sX1BXdvV5XuyHbk9R1qjSFglgNmpKEKZXCT2nQeyi6k=.df711317-dbc7-4295-ad17-a3f0d0a8bfca@github.com>
Message-ID: <1yrVMHVq7Q4cI9GvLEvITL_tSGYX96ntJDzCiz-x8NE=.0242dbb2-23f2-4a3d-befd-a4271dac63ca@github.com>

On Mon, 26 Jul 2021 07:43:39 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
>> 
>> ----
>> 
>> The attached test generates the following bytecode:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: iload_1
>>          3: bipush        100
>>          5: if_icmpge     29
>>          8: iinc          1, 1
>>         11: goto          2
>>         14: astore_2
>>         15: iload_1
>>         16: bipush        100
>>         18: if_icmpge     27
>>         21: iinc          1, 1
>>         24: goto          15
>>         27: aload_2
>>         28: athrow
>>         29: return
>> 
>> 
>> 
>> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
>> 
>> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: nop
>>          3: iload_1
>>          4: bipush        100
>>          6: if_icmpge     30
>>          9: iinc          1, 1
>>         12: goto          3
>>         15: astore_2
>>         16: iload_1
>>         17: bipush        100
>>         19: if_icmpge     28
>>         22: iinc          1, 1
>>         25: goto          16
>>         28: aload_2
>>         29: athrow
>>         30: return
>>       Exception table:
>>          from    to  target type
>>              2     3    15   any
>> 
>> 
>> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove usenewcode

HotSpot and javac should be fixed independently, please file a new bug for javac.

Regarding the change to `GenerateOopMap::do_exception_edge`, is that sufficient to fix the bug even without the change to javac? Because HotSpot should also handle bytecode not generated by javac.

The fix looks reasonable to me but someone from runtime who knows that code better should have a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Tue Aug 10 07:46:31 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 10 Aug 2021 07:46:31 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v3]
In-Reply-To: <1yrVMHVq7Q4cI9GvLEvITL_tSGYX96ntJDzCiz-x8NE=.0242dbb2-23f2-4a3d-befd-a4271dac63ca@github.com>
References: <IHKVdDTKJq7jzIc_gl3gJVC-qvHa_WTn6SYdVL1tgWs=.d575e257-f611-4333-86ad-d939dc430c95@github.com>
 <sX1BXdvV5XuyHbk9R1qjSFglgNmpKEKZXCT2nQeyi6k=.df711317-dbc7-4295-ad17-a3f0d0a8bfca@github.com>
 <1yrVMHVq7Q4cI9GvLEvITL_tSGYX96ntJDzCiz-x8NE=.0242dbb2-23f2-4a3d-befd-a4271dac63ca@github.com>
Message-ID: <5WUlshFIZfiqx73HIQ9vPSihWC0XfeGQSZ8aCJ8ECD8=.af0e4262-4fd1-4d61-8504-4795d588fa7c@github.com>

On Tue, 10 Aug 2021 06:59:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> HotSpot and javac should be fixed independently, please file a new bug for javac.
> 
> Regarding the change to `GenerateOopMap::do_exception_edge`, is that sufficient to fix the bug even without the change to javac? Because HotSpot should also handle bytecode not generated by javac.
> 
> The fix looks reasonable to me but someone from runtime who knows that code better should have a look.

Hi Tobias,

It's not sufficient to fix this bug without javac changes. But it reveals [another crash](https://github.com/openjdk/jdk/pull/4902#issuecomment-886774027) that I posted above. Maybe I should file a new issue for that and fix it? Later when javac bug is solved, this bug can also be set to resolve.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4902

From thartmann at openjdk.java.net  Tue Aug 10 08:17:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 10 Aug 2021 08:17:40 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v3]
In-Reply-To: <sX1BXdvV5XuyHbk9R1qjSFglgNmpKEKZXCT2nQeyi6k=.df711317-dbc7-4295-ad17-a3f0d0a8bfca@github.com>
References: <IHKVdDTKJq7jzIc_gl3gJVC-qvHa_WTn6SYdVL1tgWs=.d575e257-f611-4333-86ad-d939dc430c95@github.com>
 <sX1BXdvV5XuyHbk9R1qjSFglgNmpKEKZXCT2nQeyi6k=.df711317-dbc7-4295-ad17-a3f0d0a8bfca@github.com>
Message-ID: <Pju2ZkDpruSXcYUoMb-Wp8lBoEa7WPnANJ7E5VNt4ds=.1d44fae3-d633-4ed0-a86a-ea064fb58c1f@github.com>

On Mon, 26 Jul 2021 07:43:39 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
>> 
>> ----
>> 
>> The attached test generates the following bytecode:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: iload_1
>>          3: bipush        100
>>          5: if_icmpge     29
>>          8: iinc          1, 1
>>         11: goto          2
>>         14: astore_2
>>         15: iload_1
>>         16: bipush        100
>>         18: if_icmpge     27
>>         21: iinc          1, 1
>>         24: goto          15
>>         27: aload_2
>>         28: athrow
>>         29: return
>> 
>> 
>> 
>> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
>> 
>> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: nop
>>          3: iload_1
>>          4: bipush        100
>>          6: if_icmpge     30
>>          9: iinc          1, 1
>>         12: goto          3
>>         15: astore_2
>>         16: iload_1
>>         17: bipush        100
>>         19: if_icmpge     28
>>         22: iinc          1, 1
>>         25: goto          16
>>         28: aload_2
>>         29: athrow
>>         30: return
>>       Exception table:
>>          from    to  target type
>>              2     3    15   any
>> 
>> 
>> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove usenewcode

Okay but then the fix is incomplete because the VM also needs to handle bytecode not generated by javac. Other compilers or hand written bytecode might still miss these traps.Of course, if the bytecode violates the Spec, the verifier should catch this but otherwise the VM should not crash or assert.

> Maybe I should file a new issue for that and fix it?

I think it's just a different failure mode and should be fixed with this bug.

> Later when javac bug is solved, this bug can also be set to resolve.

No, as explained above, other compilers could still generate this bytecode shape. We need to handle it properly in the VM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Tue Aug 10 08:32:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 10 Aug 2021 08:32:30 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v3]
In-Reply-To: <Pju2ZkDpruSXcYUoMb-Wp8lBoEa7WPnANJ7E5VNt4ds=.1d44fae3-d633-4ed0-a86a-ea064fb58c1f@github.com>
References: <IHKVdDTKJq7jzIc_gl3gJVC-qvHa_WTn6SYdVL1tgWs=.d575e257-f611-4333-86ad-d939dc430c95@github.com>
 <sX1BXdvV5XuyHbk9R1qjSFglgNmpKEKZXCT2nQeyi6k=.df711317-dbc7-4295-ad17-a3f0d0a8bfca@github.com>
 <Pju2ZkDpruSXcYUoMb-Wp8lBoEa7WPnANJ7E5VNt4ds=.1d44fae3-d633-4ed0-a86a-ea064fb58c1f@github.com>
Message-ID: <o8Hjeb_e0ximsroleszFDKR8bJtUZ1QUuuxvfEDT4NY=.6af992c5-c83c-4d35-a039-f7aba2d8e703@github.com>

On Tue, 10 Aug 2021 08:14:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Okay but then the fix is incomplete because the VM also needs to handle bytecode not generated by javac. Other compilers or hand written bytecode might still miss these traps.Of course, if the bytecode violates the Spec, the verifier should catch this but otherwise the VM should not crash or assert.
> 
> > Maybe I should file a new issue for that and fix it?
> 
> I think it's just a different failure mode and should be fixed with this bug.
> 
> > Later when javac bug is solved, this bug can also be set to resolve.
> 
> No, as explained above, other compilers could still generate this bytecode shape. We need to handle it properly in the VM.

Make sense! I will prepare a more proper fix to solve this even without javac change. (But it may take a while since I'm busy on other stuffs now...)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4902

From jlahoda at openjdk.java.net  Tue Aug 10 13:00:30 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 Aug 2021 13:00:30 GMT
Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model
 utility class
In-Reply-To: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
References: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
Message-ID: <v-841tA0b9IZtNqrZGtBMe5-EdB1Oc8l17H2t0x5tQc=.591f78cf-f362-4968-966e-c4aa7d43c831@github.com>

On Wed, 4 Aug 2021 22:41:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903.

To me, looks good, with some nits inlined.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 581:

> 579:             // for misbehaving element implementations.
> 580:             while (true) {
> 581:                 // Conceptual instanceof TypeElment check. If the

Nit:
Suggestion:

                // Conceptual instanceof TypeElement check. If the

test/langtools/tools/javac/processing/model/util/elements/TestOutermostTypeElement.java line 78:

> 76:         @Override
> 77:         public Void scan(Element e, Elements elts) {
> 78:             // System.out.println(e.getSimpleName() + " " + e.getKind());

Nit:
Suggestion:

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5007

From darcy at openjdk.java.net  Tue Aug 10 16:35:38 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 Aug 2021 16:35:38 GMT
Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model
 utility class [v2]
In-Reply-To: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
References: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
Message-ID: <dDkgj54mMMJCggUnSRWNyfuFdRIguUXH76wm83Tx8M8=.8216f25d-b1b1-4b68-a3b9-8c2b70d1f266@github.com>

> Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback and update copyright.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5007/files
  - new: https://git.openjdk.java.net/jdk/pull/5007/files/bc1de3f0..3ac05554

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5007/head:pull/5007

PR: https://git.openjdk.java.net/jdk/pull/5007

From darcy at openjdk.java.net  Tue Aug 10 16:42:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 Aug 2021 16:42:39 GMT
Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model
 utility class [v3]
In-Reply-To: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
References: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
Message-ID: <TQr4Vi8n4QOwrdHylX2Tv23ycNj_i_Q0Qx7kdxtKGSY=.1fe7e331-c4d4-49b2-88af-8463fd84fe69@github.com>

> Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8140442
 - Respond to review feedback and update copyright.
 - Appease jcheck.
 - Now with tests and javac Elements implementation.
 - Merge branch 'master' into JDK-8140442
 - Merge branch 'master' into JDK-8140442
 - Initial version pre-tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5007/files
  - new: https://git.openjdk.java.net/jdk/pull/5007/files/3ac05554..7f58ab5b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5007&range=01-02

  Stats: 6854 lines in 191 files changed: 5916 ins; 432 del; 506 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5007/head:pull/5007

PR: https://git.openjdk.java.net/jdk/pull/5007

From darcy at openjdk.java.net  Tue Aug 10 16:46:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 Aug 2021 16:46:00 GMT
Subject: RFR: 8140442: Add getOutermostTypeElement to javax.lang.model
 utility class [v3]
In-Reply-To: <v-841tA0b9IZtNqrZGtBMe5-EdB1Oc8l17H2t0x5tQc=.591f78cf-f362-4968-966e-c4aa7d43c831@github.com>
References: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
 <v-841tA0b9IZtNqrZGtBMe5-EdB1Oc8l17H2t0x5tQc=.591f78cf-f362-4968-966e-c4aa7d43c831@github.com>
Message-ID: <GL5YplfFvW0j6lUBuVj0w7pgolw-reSbUkT_CAr-qF4=.224e2b88-27d7-4be6-a692-ed90638286e6@github.com>

On Tue, 10 Aug 2021 12:55:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8140442
>>  - Respond to review feedback and update copyright.
>>  - Appease jcheck.
>>  - Now with tests and javac Elements implementation.
>>  - Merge branch 'master' into JDK-8140442
>>  - Merge branch 'master' into JDK-8140442
>>  - Initial version pre-tests.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 581:
> 
>> 579:             // for misbehaving element implementations.
>> 580:             while (true) {
>> 581:                 // Conceptual instanceof TypeElment check. If the
> 
> Nit:
> Suggestion:
> 
>                 // Conceptual instanceof TypeElement check. If the

Nits fixed; thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5007

From darcy at openjdk.java.net  Tue Aug 10 16:52:59 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 Aug 2021 16:52:59 GMT
Subject: Integrated: 8140442: Add getOutermostTypeElement to javax.lang.model
 utility class
In-Reply-To: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
References: <rpXbaU7P9bqZOnAMKczAnm6l4lhU44xDeCT1_1UXbWQ=.f501a6d7-b141-4dc6-856a-89f06ce87ff6@github.com>
Message-ID: <C4aZa480Mik32UDsVl_87H63VInIHB_RFfR7Yb9y2-s=.bf45912f-5c76-4e12-a358-0f74d6ae5210@github.com>

On Wed, 4 Aug 2021 22:41:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this change to add a getOutermostTypeElement method to javax.lang.model.Elements along with the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8271903.

This pull request has now been integrated.

Changeset: 57ae9fbe
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57ae9fbe779e63f9606077047137b00220c6b3a2
Stats:     322 lines in 6 files changed: 267 ins; 53 del; 2 mod

8140442: Add getOutermostTypeElement to javax.lang.model utility class

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/5007

From darcy at openjdk.java.net  Tue Aug 10 20:06:56 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 Aug 2021 20:06:56 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v2]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <X1WoLyswl8wVFNy7eFdQoj6IGD3Lfd0wEa4iwzRdnbg=.6279753d-846f-4672-abb5-2810a4288119@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8224922
 - 8224922: Access JavaFileObject from Element(s)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/70547512..e2acf39d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=00-01

  Stats: 8572 lines in 241 files changed: 6930 ins; 813 del; 829 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From jlahoda at openjdk.java.net  Tue Aug 10 20:51:40 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 Aug 2021 20:51:40 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v2]
In-Reply-To: <X1WoLyswl8wVFNy7eFdQoj6IGD3Lfd0wEa4iwzRdnbg=.6279753d-846f-4672-abb5-2810a4288119@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
 <X1WoLyswl8wVFNy7eFdQoj6IGD3Lfd0wEa4iwzRdnbg=.6279753d-846f-4672-abb5-2810a4288119@github.com>
Message-ID: <lkWzNq_uid07VNa37b2seB6O2bqwmI9ch40pDqpt-mg=.faba44f3-cdf6-45ce-94e1-5130e43f2807@github.com>

On Tue, 10 Aug 2021 20:06:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8224922
>  - 8224922: Access JavaFileObject from Element(s)

Seems useful to me. A possible conversion from Element to FileObject is needed elsewhere as well, I've tried to write it here:
https://github.com/openjdk/jdk/blob/aa61e594b96acba1bcb7e5ea57b1631d917cf545/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java#L526

-------------

PR: https://git.openjdk.java.net/jdk/pull/5038

From jlahoda at openjdk.java.net  Tue Aug 10 20:54:45 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 Aug 2021 20:54:45 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to JavaFileManager
Message-ID: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>

This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files.

Any feedback on this prototype would be welcome.

-------------

Commit messages:
 - Improving testing
 - Updating @since
 - Merge branch 'master' into ap-keep-originating-elements
 - Another attempt to fix the test.
 - More attempts to fix the test.
 - Attempting to fix test.
 - Adding @since
 - Improving the patch and API.
 - Merge branch 'master' into ap-keep-originating-elements
 - Fixing the TestClientCodeWrapper.java test,
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/a86ac0d1...aa61e594

Changes: https://git.openjdk.java.net/jdk/pull/5076/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272234
  Stats: 575 lines in 8 files changed: 564 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076

PR: https://git.openjdk.java.net/jdk/pull/5076

From jlahoda at openjdk.java.net  Wed Aug 11 08:57:31 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 11 Aug 2021 08:57:31 GMT
Subject: Integrated: 8271928: ErroneousTree with start position -1
In-Reply-To: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>
References: <bleJIvTbX4pE3Es1iom2HVgctfqFsa_UVynuZyNmo0g=.825f596d-230c-4434-98d5-489367163479@github.com>
Message-ID: <BcbXVh5KUuKu650zj8nPV2ZoJbQOyl_Ihx9sCa26eIY=.fca7b2c5-b61f-48b3-b89d-499d778ddfc5@github.com>

On Thu, 5 Aug 2021 11:30:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For some (very) erroneous code, the javac's parser may create an `ErroneousTree`, which contains an empty `ModifiersTree`. The empty `ModifiersTree` will not have the position, set but the `ModifiersTree`'s position will be used as the start position of the `ErroneousTree`, leading to start position `-1`. The proposal is to fall back on the the `ErroneousTree`'s `pos` when the nested tree does not have any position set.

This pull request has now been integrated.

Changeset: 3215dbc8
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3215dbc8b8e5f2c1454741dc7f94b0232c5d911f
Stats:     33 lines in 2 files changed: 30 ins; 0 del; 3 mod

8271928: ErroneousTree with start position -1

Reviewed-by: jlaskey, vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/5018

From jjg at openjdk.java.net  Wed Aug 11 17:45:48 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 11 Aug 2021 17:45:48 GMT
Subject: RFR: JDK-8271159: [REDO] JDK-8249634 doclint should report implicit
 constructor as missing javadoc comments
Message-ID: <BrDVfsxpUN7yzPoRZHrCh3hjpwM3U95dQBI2LZdr0sc=.f2f64440-180c-4bb8-a788-b64b7cc55f43@github.com>

Please review a do-over of JDK-8249634, to report a missing doc comment when an implicit/default constructor is used.

The `src` code is the same as before.   The previous version had missing test files (now added), and had a test fail because an interaction with another changeset that was pushed while the previous version was in review. The solution for that is the use of `-Xdoclint:all,-missing` in `TestDocTreeDiags.java`.

-------------

Commit messages:
 - JDK-8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments

Changes: https://git.openjdk.java.net/jdk/pull/5088/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5088&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271159
  Stats: 240 lines in 77 files changed: 125 ins; 4 del; 111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5088/head:pull/5088

PR: https://git.openjdk.java.net/jdk/pull/5088

From darcy at openjdk.java.net  Wed Aug 11 18:03:25 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 11 Aug 2021 18:03:25 GMT
Subject: RFR: JDK-8271159: [REDO] JDK-8249634 doclint should report
 implicit constructor as missing javadoc comments
In-Reply-To: <BrDVfsxpUN7yzPoRZHrCh3hjpwM3U95dQBI2LZdr0sc=.f2f64440-180c-4bb8-a788-b64b7cc55f43@github.com>
References: <BrDVfsxpUN7yzPoRZHrCh3hjpwM3U95dQBI2LZdr0sc=.f2f64440-180c-4bb8-a788-b64b7cc55f43@github.com>
Message-ID: <8-v6822Vfm_SfsnPuuWA6hb5cRcDykIrPuT1XQRZUUc=.7aa297aa-8deb-49de-bb7c-e53cc2a02bf6@github.com>

On Wed, 11 Aug 2021 17:38:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a do-over of JDK-8249634, to report a missing doc comment when an implicit/default constructor is used.
> 
> The `src` code is the same as before.   The previous version had missing test files (now added), and had a test fail because an interaction with another changeset that was pushed while the previous version was in review. The solution for that is the use of `-Xdoclint:all,-missing` in `TestDocTreeDiags.java`.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5088

From jjg at openjdk.java.net  Wed Aug 11 18:06:30 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 11 Aug 2021 18:06:30 GMT
Subject: Integrated: JDK-8271159: [REDO] JDK-8249634 doclint should report
 implicit constructor as missing javadoc comments
In-Reply-To: <BrDVfsxpUN7yzPoRZHrCh3hjpwM3U95dQBI2LZdr0sc=.f2f64440-180c-4bb8-a788-b64b7cc55f43@github.com>
References: <BrDVfsxpUN7yzPoRZHrCh3hjpwM3U95dQBI2LZdr0sc=.f2f64440-180c-4bb8-a788-b64b7cc55f43@github.com>
Message-ID: <nDjTr52bvwtew7cJ7XEsAmopnktZg2Q3FRZdthOhxLA=.1987c7e9-c71e-4226-a30c-5389806edf5e@github.com>

On Wed, 11 Aug 2021 17:38:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a do-over of JDK-8249634, to report a missing doc comment when an implicit/default constructor is used.
> 
> The `src` code is the same as before.   The previous version had missing test files (now added), and had a test fail because an interaction with another changeset that was pushed while the previous version was in review. The solution for that is the use of `-Xdoclint:all,-missing` in `TestDocTreeDiags.java`.

This pull request has now been integrated.

Changeset: ec8d3bad
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec8d3badc869be7898b5a49fa5f9ba447bbbcf8d
Stats:     240 lines in 77 files changed: 125 ins; 4 del; 111 mod

8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/5088

From jlahoda at openjdk.java.net  Thu Aug 12 08:31:39 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 12 Aug 2021 08:31:39 GMT
Subject: RFR: 8259039: Passing different version to --release flag than javac
 version output warning
Message-ID: <z2rJBSptf2E3VUduC_2UCZvtduZOiNTeCsUu5W53x8c=.41ebb396-a5be-40cc-a149-e78ed0ff5d8e@github.com>

For code like:

com.sun.nio.file.ExtendedOpenOption o;


certain combination of command line options produce a proprietary warnings:

$ javac --release 11 T.java 
T.java:2: warning: ExtendedOpenOption is internal proprietary API and may be removed in a future release
    com.sun.nio.file.ExtendedOpenOption o;
                    ^
1 warning


But some do not:

$ javac -source 8 T.java 
warning: [options] bootstrap class path not set in conjunction with -source 8
1 warning


The reason is that the `ct.properties` files does not mark `com.sun.nio.file` as proprietary. The proposed fix has two parts:
-adds `proprietary` to the `com.sun.nio.file` package in `ct.properties`
-limits the `ct.properties` so that it is only used for `-source 8`. The `ct.properties` contains 3 types of information: it hides some packages, it marks some packages as "proprietary" (so that they produce the warning), and assigns packages to compact profiles. For `-source 9+`, most of these is not needed - packages are hidden using the module system, the only packages that need a warning are from the `jdk.unsupported` module, and there are no compact profiles. So for `-source 9+`, we don't need to use the `ct.properties`. (Note none of this applies to `--release` - it uses a different database.)

-------------

Commit messages:
 - Removing trailing whitespace.
 - 8259039: Passing different version to --release flag than javac version output warning

Changes: https://git.openjdk.java.net/jdk/pull/5053/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5053&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259039
  Stats: 162 lines in 4 files changed: 152 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5053.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5053/head:pull/5053

PR: https://git.openjdk.java.net/jdk/pull/5053

From serb at openjdk.java.net  Thu Aug 12 19:54:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 19:54:33 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other locales
 than the US
Message-ID: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>

As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

-------------

Commit messages:
 - Initial fix of JDK-8272358

Changes: https://git.openjdk.java.net/jdk/pull/5098/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5098&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272358
  Stats: 9 lines in 4 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5098.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5098/head:pull/5098

PR: https://git.openjdk.java.net/jdk/pull/5098

From jjg at openjdk.java.net  Fri Aug 13 03:59:49 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 13 Aug 2021 03:59:49 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
Message-ID: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>

Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.

It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.

There are three cases to consider:

* The comment itself is missing: this was already checked and reported as "missing comment".
* The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
* The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 

No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.

Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)

Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.

A new test is added, focussing on the different forms of empty/missing descriptions, as described above.

-------------

Commit messages:
 - JDK-8272374: doclint should report missing "body" comments

Changes: https://git.openjdk.java.net/jdk/pull/5106/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272374
  Stats: 281 lines in 37 files changed: 152 ins; 10 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106

PR: https://git.openjdk.java.net/jdk/pull/5106

From kcr at openjdk.java.net  Fri Aug 13 15:46:27 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Aug 2021 15:46:27 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
In-Reply-To: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
Message-ID: <WwN_qGlfgMwTevBmVoMK-DMKpS3tSjre37lUOjfYAEI=.b206ebfc-5eda-4a48-93d4-877d3165a01f@github.com>

On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.
> 
> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.
> 
> There are three cases to consider:
> 
> * The comment itself is missing: this was already checked and reported as "missing comment".
> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 
> 
> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.
> 
> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)
> 
> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.
> 
> A new test is added, focussing on the different forms of empty/missing descriptions, as described above.

I tested this by using it to generate the JavaFX docs. We have 62 new warnings for methods with empty descriptions that we otherwise would not have easily found.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/5106

From duke at openjdk.java.net  Sat Aug 14 12:28:30 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 14 Aug 2021 12:28:30 GMT
Subject: Withdrawn: 8263926: JavacFileManager.hasExplicitLocation fails with
 NPE while compiling
In-Reply-To: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
Message-ID: <GajkiKc6JliOsni1dqEi_Gwx042o8HRH8fm7FSjW5wI=.48d537c1-57d4-41a5-821a-757fac526afe@github.com>

On Thu, 17 Jun 2021 15:41:46 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926).
> 
> Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`.
> 
> 
> -            if (fileManager.contains(msym.sourceLocation, fo)) 
> +            if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) 
> 
> 
> But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test.
> 
> Recently, I deeply researched the relationship of the source code provided by the user 
> and construct a minimal test case to verify the patch. 
> The minimal test was attached to the JBS just now.
> The attached test reproduces the bug by using the shell script instead of maven.
> And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. 
> The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above.
> 
> Given that the bug is hard to be reproduced, I give some comments here.
> 
> 1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module.
>     First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`.
>     Then  I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`.
>     Commands are like: 
>     `javac test/TestUnnamedModule.java` and 
>     `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java`
> 
> 2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. 
>     Because the compiler implicitly choose the last modified file if both source files and class files are present.
>     We need the compiler the choose the `*.java` files to reproduce the bug.
>     So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files.
>     Command is like: `touch test/TestUnnamedModule.java`.
> 
> 3. We need to use the class of the `test.jar` in a named module.
>     I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`.
>     You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`.
> 
> 4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`.
> 
> 5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not  the argument of the `-sourcepath` and `--module-path`.
>     Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java`
> 
> We can see that these five requirements are difficult to meet.
> - Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly .
> - And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files.
> - Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`.
> Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`).
> 
> It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), 
> the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive).
> 
> Anyway, we actually meet it now which is provided by the user.
> Hope you are not confused by these descriptions.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4523

From hannesw at openjdk.java.net  Mon Aug 16 11:45:25 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 16 Aug 2021 11:45:25 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
In-Reply-To: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
Message-ID: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com>

On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.
> 
> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.
> 
> There are three cases to consider:
> 
> * The comment itself is missing: this was already checked and reported as "missing comment".
> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 
> 
> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.
> 
> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)
> 
> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.
> 
> A new test is added, focussing on the different forms of empty/missing descriptions, as described above.

Looks good. One thing I wonder about is why you only look for `@deprecated` in the first block tag. I guess it is just a convention to add this tag at the first position?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203:

> 201:                     // Don't report an empty description if the comment begins with @deprecated,
> 202:                     // because javadoc will use the content of that tag in summary tables.
> 203:                     if (firstTag.getKind() != DocTree.Kind.DEPRECATED) {

Why do we only check the first block tag here?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 204:

> 202:                     // because javadoc will use the content of that tag in summary tables.
> 203:                     if (firstTag.getKind() != DocTree.Kind.DEPRECATED) {
> 204:                         env.messages.report(MISSING, Kind.WARNING, tree, "dc.empty.description");

Is there a reason to not use `reportMissing` here?

-------------

Marked as reviewed by hannesw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5106

From jjg at openjdk.java.net  Mon Aug 16 17:11:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 17:11:29 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
In-Reply-To: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
 <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com>
Message-ID: <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com>

On Fri, 13 Aug 2021 09:20:19 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.
>> 
>> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.
>> 
>> There are three cases to consider:
>> 
>> * The comment itself is missing: this was already checked and reported as "missing comment".
>> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
>> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 
>> 
>> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.
>> 
>> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)
>> 
>> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.
>> 
>> A new test is added, focussing on the different forms of empty/missing descriptions, as described above.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203:
> 
>> 201:                     // Don't report an empty description if the comment begins with @deprecated,
>> 202:                     // because javadoc will use the content of that tag in summary tables.
>> 203:                     if (firstTag.getKind() != DocTree.Kind.DEPRECATED) {
> 
> Why do we only check the first block tag here?

Various reasons, 
1. It seems the convention is to simply prefix an existing comment with `@deprecated` or to replace the existing body description with `@deprecated reason-why-deprecated`
2. This is only for the case when there is no body description; it seems hard to imagine that someone would start a comment with `@see` `@param` `@return` etc and then have the `@deprecated` tag.

That being said, it would be easy enough to change the code to check for any instance of `@deprecated`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5106

From jjg at openjdk.java.net  Mon Aug 16 17:18:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 17:18:29 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
In-Reply-To: <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
 <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com>
Message-ID: <zSgCk1XSolAY6wI1fBxC3WAynvajj___3TTetRl33R0=.e183b36b-11db-403c-a2a1-c0f3085bfb40@github.com>

On Fri, 13 Aug 2021 09:21:40 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.
>> 
>> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.
>> 
>> There are three cases to consider:
>> 
>> * The comment itself is missing: this was already checked and reported as "missing comment".
>> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
>> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 
>> 
>> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.
>> 
>> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)
>> 
>> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.
>> 
>> A new test is added, focussing on the different forms of empty/missing descriptions, as described above.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 204:
> 
>> 202:                     // because javadoc will use the content of that tag in summary tables.
>> 203:                     if (firstTag.getKind() != DocTree.Kind.DEPRECATED) {
>> 204:                         env.messages.report(MISSING, Kind.WARNING, tree, "dc.empty.description");
> 
> Is there a reason to not use `reportMissing` here?

It doesn't have the right signature. `reportMissing` reports a missing comment on an element; here, we're reporting a missing description within a `DocTree`.  There's a similar occurrence at line 1214.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5106

From jjg at openjdk.java.net  Mon Aug 16 17:22:31 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 17:22:31 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
In-Reply-To: <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
 <-8oey_QHb7omZMiWEFbMUkK37CdVDjxTBxEqCuZyumo=.130eca61-0ac3-4176-99ee-7426eb13048a@github.com>
 <8_n_Wcn6QF4nXLkgtIgrlTSKESOi5HmTpC_a4pcUKMM=.c9499fce-31b5-40ee-a806-2e92d5894bd6@github.com>
Message-ID: <2nzruNweIsajakC9eWy6UFJVrR6m5T4TDQuSvxP5PaY=.ec56f7db-f398-4d74-aa9f-f8c0b47a690b@github.com>

On Mon, 16 Aug 2021 17:08:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 203:
>> 
>>> 201:                     // Don't report an empty description if the comment begins with @deprecated,
>>> 202:                     // because javadoc will use the content of that tag in summary tables.
>>> 203:                     if (firstTag.getKind() != DocTree.Kind.DEPRECATED) {
>> 
>> Why do we only check the first block tag here?
>
> Various reasons, 
> 1. It seems the convention is to simply prefix an existing comment with `@deprecated` or to replace the existing body description with `@deprecated reason-why-deprecated`
> 2. This is only for the case when there is no body description; it seems hard to imagine that someone would start a comment with `@see` `@param` `@return` etc and then have the `@deprecated` tag.
> 
> That being said, it would be easy enough to change the code to check for any instance of `@deprecated`.

Given that the downstream code does not impose any ordering restrictions on the tags, it is probably with doing the same here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5106

From jjg at openjdk.java.net  Mon Aug 16 17:38:05 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 17:38:05 GMT
Subject: RFR: JDK-8272374: doclint should report missing "body" comments
 [v2]
In-Reply-To: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
Message-ID: <yCUKX3UFlHzs7WalGdtNHtXaU6NPIt8h9227KKUBPsQ=.f2afbe37-98eb-4708-a97c-fa37f8fac786@github.com>

> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.
> 
> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.
> 
> There are three cases to consider:
> 
> * The comment itself is missing: this was already checked and reported as "missing comment".
> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 
> 
> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.
> 
> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)
> 
> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.
> 
> A new test is added, focussing on the different forms of empty/missing descriptions, as described above.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5106/files
  - new: https://git.openjdk.java.net/jdk/pull/5106/files/60c6f569..6c875688

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106

PR: https://git.openjdk.java.net/jdk/pull/5106

From jjg at openjdk.java.net  Mon Aug 16 20:51:32 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 20:51:32 GMT
Subject: Integrated: JDK-8272374: doclint should report missing "body" comments
In-Reply-To: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
References: <VR0LawdnoOHmZl_244sRHbULLBONAzfe8OYchIP6ErA=.aa8d7634-2a1b-4f8c-89f0-09b996d6c2f2@github.com>
Message-ID: <o5oW72ZtT8p2p9Yp8TDFbMvu-xZB9eLW2Nyp6xda0zQ=.c3be5680-d99e-41f2-91f0-4196820f4092@github.com>

On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags.
> 
> It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc.
> 
> There are three cases to consider:
> 
> * The comment itself is missing: this was already checked and reported as "missing comment".
> * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment".
> * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". 
> 
> No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation.
> 
> Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`.  This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`.  To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module.  To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary)
> 
> Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well.
> 
> A new test is added, focussing on the different forms of empty/missing descriptions, as described above.

This pull request has now been integrated.

Changeset: ae45592d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ae45592d3304f50aa9e8e114416a41e7899fe37b
Stats:     280 lines in 37 files changed: 151 ins; 10 del; 119 mod

8272374: doclint should report missing "body" comments

Reviewed-by: kcr, hannesw

-------------

PR: https://git.openjdk.java.net/jdk/pull/5106

From jjg at openjdk.java.net  Mon Aug 16 22:45:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 22:45:41 GMT
Subject: RFR: JDK-8271227: Missing `{@code }` in com.sun.source.*
Message-ID: <QrLj2xNu_uWyrD_IF0oFEUMS9PX8dtimLEwLhY1xm40=.15691434-2c42-4d20-aa8a-862ac2795e48@github.com>

Please review a simple `noreg-doc` update to files in the `com.sun.source.*` API, to enclose type names in the descriptions in doc comments with `{@code }`. 

Apart from fixing one typo, the changes are all formatting changes, with no changes to the content of the spec, so no CSR.

-------------

Commit messages:
 - JDK-8271227: Missing `{@code }` in com.sun.source.*

Changes: https://git.openjdk.java.net/jdk/pull/5133/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5133&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271227
  Stats: 133 lines in 3 files changed: 0 ins; 0 del; 133 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5133.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5133/head:pull/5133

PR: https://git.openjdk.java.net/jdk/pull/5133

From iris at openjdk.java.net  Mon Aug 16 22:55:30 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 16 Aug 2021 22:55:30 GMT
Subject: RFR: JDK-8271227: Missing `{@code }` in com.sun.source.*
In-Reply-To: <QrLj2xNu_uWyrD_IF0oFEUMS9PX8dtimLEwLhY1xm40=.15691434-2c42-4d20-aa8a-862ac2795e48@github.com>
References: <QrLj2xNu_uWyrD_IF0oFEUMS9PX8dtimLEwLhY1xm40=.15691434-2c42-4d20-aa8a-862ac2795e48@github.com>
Message-ID: <Jb_bKnRSw3kiZjs2ZI_GRTUX6KGqNu5lEHfwSOv9_ZY=.9926d3a4-8b9c-4500-9010-8d1c4def0349@github.com>

On Mon, 16 Aug 2021 22:37:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple `noreg-doc` update to files in the `com.sun.source.*` API, to enclose type names in the descriptions in doc comments with `{@code }`. 
> 
> Apart from fixing one typo, the changes are all formatting changes, with no changes to the content of the spec, so no CSR.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5133

From jjg at openjdk.java.net  Mon Aug 16 22:58:31 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 Aug 2021 22:58:31 GMT
Subject: Integrated: JDK-8271227: Missing `{@code }` in com.sun.source.*
In-Reply-To: <QrLj2xNu_uWyrD_IF0oFEUMS9PX8dtimLEwLhY1xm40=.15691434-2c42-4d20-aa8a-862ac2795e48@github.com>
References: <QrLj2xNu_uWyrD_IF0oFEUMS9PX8dtimLEwLhY1xm40=.15691434-2c42-4d20-aa8a-862ac2795e48@github.com>
Message-ID: <DwbCnCQQOOBzmC5mn3CTJR6DneH5exiVFEH_fXchd_E=.ca18aa3e-51c6-4f05-a9e1-f7020149e0ec@github.com>

On Mon, 16 Aug 2021 22:37:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple `noreg-doc` update to files in the `com.sun.source.*` API, to enclose type names in the descriptions in doc comments with `{@code }`. 
> 
> Apart from fixing one typo, the changes are all formatting changes, with no changes to the content of the spec, so no CSR.

This pull request has now been integrated.

Changeset: 3fb19279
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3fb19279da240ecabee04148ba8907f036450575
Stats:     133 lines in 3 files changed: 0 ins; 0 del; 133 mod

8271227: Missing `{@code }` in com.sun.source.*

Reviewed-by: iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/5133

From vromero at openjdk.java.net  Tue Aug 17 17:05:43 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 17 Aug 2021 17:05:43 GMT
Subject: RFR: 8270835: regression after JDK-8261006
Message-ID: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>

This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec:


According to: 8.1.3 Inner Classes and Enclosing Instances:

A construct (statement, local variable declaration statement, local class declaration,
local interface declaration, or expression) occurs in a static context if the innermost:
...
    ? explicit constructor invocation statement

which encloses the construct is one of the following:
    ? an explicit constructor invocation statement (?8.8.7.1)
...
...
The purpose of a static context is to demarcate code that must not refer explicitly or
implicitly to the current instance of the class whose declaration lexically encloses the static
context. Consequently, code that occurs in a static context is restricted in the following
ways:
    ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1).

also from: 15.13 Method Reference Expressions:

If a method reference expression has the form super :: [TypeArguments] Identifier
or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
the expression occurs in a static context (?8.1.3).

Meaning that code like:

this(Feature.super::getString); or
this(Feature.super.getString());

should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't:

    class A extends B {
        A(int i) {}

        class C extends B {
            class D extends S {
                D(float f) {
                    C.super.ref.super(); // ok
                }
            }
        }
    }

    class B {
        B ref;
        class S {}
    }

so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not.

TIA

-------------

Commit messages:
 - 8270835: regression after JDK-8261006

Changes: https://git.openjdk.java.net/jdk/pull/5149/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5149&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270835
  Stats: 52 lines in 4 files changed: 51 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5149/head:pull/5149

PR: https://git.openjdk.java.net/jdk/pull/5149

From jlahoda at openjdk.java.net  Tue Aug 17 20:41:22 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 17 Aug 2021 20:41:22 GMT
Subject: RFR: 8270835: regression after JDK-8261006
In-Reply-To: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>
References: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>
Message-ID: <LYYXlp_V_iGHF83k7FbxPbk6PAQRpE8vu7n7WIzYwjo=.981efa7f-8dcb-4f4f-8d96-0f5705e8cdb2@github.com>

On Tue, 17 Aug 2021 16:57:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec:
> 
> 
> According to: 8.1.3 Inner Classes and Enclosing Instances:
> 
> A construct (statement, local variable declaration statement, local class declaration,
> local interface declaration, or expression) occurs in a static context if the innermost:
> ...
>     ? explicit constructor invocation statement
> 
> which encloses the construct is one of the following:
>     ? an explicit constructor invocation statement (?8.8.7.1)
> ...
> ...
> The purpose of a static context is to demarcate code that must not refer explicitly or
> implicitly to the current instance of the class whose declaration lexically encloses the static
> context. Consequently, code that occurs in a static context is restricted in the following
> ways:
>     ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1).
> 
> also from: 15.13 Method Reference Expressions:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> Meaning that code like:
> 
> this(Feature.super::getString); or
> this(Feature.super.getString());
> 
> should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't:
> 
>     class A extends B {
>         A(int i) {}
> 
>         class C extends B {
>             class D extends S {
>                 D(float f) {
>                     C.super.ref.super(); // ok
>                 }
>             }
>         }
>     }
> 
>     class B {
>         B ref;
>         class S {}
>     }
> 
> so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not.
> 
> TIA

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5149

From vromero at openjdk.java.net  Tue Aug 17 20:51:28 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 17 Aug 2021 20:51:28 GMT
Subject: RFR: 8270835: regression after JDK-8261006
In-Reply-To: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>
References: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>
Message-ID: <pVxBrBuGZndklWcq6qiNaBHd9A5SkM4--ds_sQC3o8o=.ce4acb3d-a677-4682-b4b3-df099b28e7d2@github.com>

On Tue, 17 Aug 2021 16:57:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec:
> 
> 
> According to: 8.1.3 Inner Classes and Enclosing Instances:
> 
> A construct (statement, local variable declaration statement, local class declaration,
> local interface declaration, or expression) occurs in a static context if the innermost:
> ...
>     ? explicit constructor invocation statement
> 
> which encloses the construct is one of the following:
>     ? an explicit constructor invocation statement (?8.8.7.1)
> ...
> ...
> The purpose of a static context is to demarcate code that must not refer explicitly or
> implicitly to the current instance of the class whose declaration lexically encloses the static
> context. Consequently, code that occurs in a static context is restricted in the following
> ways:
>     ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1).
> 
> also from: 15.13 Method Reference Expressions:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> Meaning that code like:
> 
> this(Feature.super::getString); or
> this(Feature.super.getString());
> 
> should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't:
> 
>     class A extends B {
>         A(int i) {}
> 
>         class C extends B {
>             class D extends S {
>                 D(float f) {
>                     C.super.ref.super(); // ok
>                 }
>             }
>         }
>     }
> 
>     class B {
>         B ref;
>         class S {}
>     }
> 
> so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not.
> 
> TIA

thanks for the review

-------------

PR: https://git.openjdk.java.net/jdk/pull/5149

From vromero at openjdk.java.net  Tue Aug 17 20:51:30 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 17 Aug 2021 20:51:30 GMT
Subject: Integrated: 8270835: regression after JDK-8261006
In-Reply-To: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>
References: <ILoBQpQjZTiKF_GNZU498jHzZEDDKWryIC7NSmI4FXM=.049e2cf5-cda9-4d6a-8646-6b1efde5de6d@github.com>
Message-ID: <kEkQorlRLoks0YaqotVUH6eL0k6F-sczTgE2ZrskUqo=.bd6e120f-6c54-4072-aac7-c3cf048cbd99@github.com>

On Tue, 17 Aug 2021 16:57:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This patch is fixing a regression introduced by the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006), which was trying to fix a long standing bug in javac. These are the related sections in the spec:
> 
> 
> According to: 8.1.3 Inner Classes and Enclosing Instances:
> 
> A construct (statement, local variable declaration statement, local class declaration,
> local interface declaration, or expression) occurs in a static context if the innermost:
> ...
>     ? explicit constructor invocation statement
> 
> which encloses the construct is one of the following:
>     ? an explicit constructor invocation statement (?8.8.7.1)
> ...
> ...
> The purpose of a static context is to demarcate code that must not refer explicitly or
> implicitly to the current instance of the class whose declaration lexically encloses the static
> context. Consequently, code that occurs in a static context is restricted in the following
> ways:
>     ? Field accesses, method invocations, and method references may not be qualified by super (?15.11.2, ?15.12.3, ?15.13.1).
> 
> also from: 15.13 Method Reference Expressions:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> Meaning that code like:
> 
> this(Feature.super::getString); or
> this(Feature.super.getString());
> 
> should be rejected by the compiler and it wasn't before the fix for [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006). The regression was introduced because after [JDK-8261006](https://bugs.openjdk.java.net/browse/JDK-8261006) this code was rejected when it shouldn't:
> 
>     class A extends B {
>         A(int i) {}
> 
>         class C extends B {
>             class D extends S {
>                 D(float f) {
>                     C.super.ref.super(); // ok
>                 }
>             }
>         }
>     }
> 
>     class B {
>         B ref;
>         class S {}
>     }
> 
> so it is OK to use `super` in the constructor's invocation qualifier but not in its arguments. So while processing the arguments or the qualifier of a constructor invocation, the compiler needs to know precisely what portion of the expression it is dealing with as different rules apply for the use of `this` or `super` in them. This is why this fix is adding a new flag to AttrContext to indicate if we are dealing with a constructor invocation argument or not.
> 
> TIA

This pull request has now been integrated.

Changeset: 14623cde
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/14623cde3a20962e902043b556c5058ac208711f
Stats:     52 lines in 4 files changed: 51 ins; 0 del; 1 mod

8270835: regression after JDK-8261006

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/5149

From turbanoff at gmail.com  Wed Aug 18 07:50:25 2021
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 18 Aug 2021 10:50:25 +0300
Subject: Suspicious 'noOuterThisPath' variable in
 com.sun.tools.javac.comp.Attr#visitIdent
Message-ID: <CAF+DQ5dQ6VW4QD1vkR3eT7KF12BU39CCP0q5+D6OX-CvFcvsmw@mail.gmail.com>

Hello.

During investigation of results of IDEA inspections I found suspicious
code in a method 'com.sun.tools.javac.comp.Attr#visitIdent'
https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4194

Env<AttrContext> symEnv = env;
boolean noOuterThisPath = false;
if (env.enclClass.sym.owner.kind != PCK && // we are in an inner class
    sym.kind.matches(KindSelector.VAL_MTH) &&
    sym.owner.kind == TYP &&
    tree.name != names._this && tree.name != names._super) {

    // Find environment in which identifier is defined.
    while (symEnv.outer != null &&
           !sym.isMemberOf(symEnv.enclClass.sym, types)) {
        if ((symEnv.enclClass.sym.flags() & NOOUTERTHIS) != 0)
            noOuterThisPath = false;
        symEnv = symEnv.outer;
    }
}


Variable 'noOuterThisPath' has initially assigned a 'false' value.
And then in cycle it again can be set to 'false'.
There are only 2 places where noOuterThisPath is assigned.
It seems it should be set to 'true' in one of the places.


Andrey Turbanov

From jan.lahoda at oracle.com  Wed Aug 18 08:37:21 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 18 Aug 2021 10:37:21 +0200
Subject: Suspicious 'noOuterThisPath' variable in
 com.sun.tools.javac.comp.Attr#visitIdent
In-Reply-To: <CAF+DQ5dQ6VW4QD1vkR3eT7KF12BU39CCP0q5+D6OX-CvFcvsmw@mail.gmail.com>
References: <CAF+DQ5dQ6VW4QD1vkR3eT7KF12BU39CCP0q5+D6OX-CvFcvsmw@mail.gmail.com>
Message-ID: <2e70abbd-f956-e1be-f1ec-6922ee4b8ec4@oracle.com>

Hi Andrey,


Thanks for the report. I believe this is a leftover from -source <= 5 
removal. The original code was:

noOuterThisPath = !allowAnonOuterThis;


where allowAnonOuterThis was true for -source >= 5, and with the 
removal, "!allowAnonOuterThis" was changed to always be false.


I've filled:

https://bugs.openjdk.java.net/browse/JDK-8272618


Thanks,

 ???? Jan


On 18. 08. 21 9:50, Andrey Turbanov wrote:
> Hello.
>
> During investigation of results of IDEA inspections I found suspicious
> code in a method 'com.sun.tools.javac.comp.Attr#visitIdent'
> https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4194
>
> Env<AttrContext> symEnv = env;
> boolean noOuterThisPath = false;
> if (env.enclClass.sym.owner.kind != PCK && // we are in an inner class
>      sym.kind.matches(KindSelector.VAL_MTH) &&
>      sym.owner.kind == TYP &&
>      tree.name != names._this && tree.name != names._super) {
>
>      // Find environment in which identifier is defined.
>      while (symEnv.outer != null &&
>             !sym.isMemberOf(symEnv.enclClass.sym, types)) {
>          if ((symEnv.enclClass.sym.flags() & NOOUTERTHIS) != 0)
>              noOuterThisPath = false;
>          symEnv = symEnv.outer;
>      }
> }
>
>
> Variable 'noOuterThisPath' has initially assigned a 'false' value.
> And then in cycle it again can be set to 'false'.
> There are only 2 places where noOuterThisPath is assigned.
> It seems it should be set to 'true' in one of the places.
>
>
> Andrey Turbanov

From jlahoda at openjdk.java.net  Wed Aug 18 11:50:35 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 18 Aug 2021 11:50:35 GMT
Subject: RFR: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath
Message-ID: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>

This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed:
https://bugs.openjdk.java.net/browse/JDK-8011044

-------------

Commit messages:
 - 8272618: Unnecessary Attr.visitIndent.noOuterThisPath

Changes: https://git.openjdk.java.net/jdk/pull/5163/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5163&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272618
  Stats: 11 lines in 1 file changed: 0 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5163/head:pull/5163

PR: https://git.openjdk.java.net/jdk/pull/5163

From jlahoda at openjdk.java.net  Wed Aug 18 13:55:45 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 18 Aug 2021 13:55:45 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of Object
 methods on interfaces
Message-ID: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>

Consider these declarations:

    interface I {
        public String toString();
    }
    interface J extends I {}


There are two issues with the `toString` inherited from `I` into `J`:
-`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
-as a slightly less problematic case, consider:

I i = null;
i.toString(); //AST and classfile contain call to I.toString()
J j = null;
j.toString(); //AST and classfile contain call to j.l.Object.toString()


I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.

-------------

Commit messages:
 - 8272564: Incorrect attribution of method invocations of Object methods on interfaces

Changes: https://git.openjdk.java.net/jdk/pull/5165/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5165&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272564
  Stats: 169 lines in 5 files changed: 166 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5165.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5165/head:pull/5165

PR: https://git.openjdk.java.net/jdk/pull/5165

From jlaskey at openjdk.java.net  Wed Aug 18 14:19:29 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 18 Aug 2021 14:19:29 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces
In-Reply-To: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
Message-ID: <UBLFX4Iu5l-sB616w-B2lfPlvlqG0_31ZwS3c3cWdJM=.d2912f17-6c79-40af-b3c0-d0db42f036de@github.com>

On Wed, 18 Aug 2021 13:46:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these declarations:
> 
>     interface I {
>         public String toString();
>     }
>     interface J extends I {}
> 
> 
> There are two issues with the `toString` inherited from `I` into `J`:
> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
> -as a slightly less problematic case, consider:
> 
> I i = null;
> i.toString(); //AST and classfile contain call to I.toString()
> J j = null;
> j.toString(); //AST and classfile contain call to j.l.Object.toString()
> 
> 
> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.

Marked as reviewed by jlaskey (Reviewer).

test/langtools/tools/javac/api/TestIsAccessible.java line 61:

> 59:             for (Element member : ct.getElements().getAllMembers(name)) {
> 60:                 if (!trees.isAccessible(s, member, (DeclaredType) name.asType())) {
> 61:                     trees.isAccessible(s, member, (DeclaredType) name.asType());

Why is this statement necessary?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5165

From vromero at openjdk.java.net  Wed Aug 18 15:38:24 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 18 Aug 2021 15:38:24 GMT
Subject: RFR: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath
In-Reply-To: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>
References: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>
Message-ID: <2IK3bQ_WDRtYs057Vdmv0KyadEzOFx0i8WVMsYFAAcA=.03f971ac-b661-4eb1-b169-6889557e90d9@github.com>

On Wed, 18 Aug 2021 11:42:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed:
> https://bugs.openjdk.java.net/browse/JDK-8011044

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5163

From vromero at openjdk.java.net  Wed Aug 18 18:59:24 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 18 Aug 2021 18:59:24 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces
In-Reply-To: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
Message-ID: <EbEAhldBE-rzlLQTFXMngwqOW_LlPD2n3EGttrihqRA=.19fc71ad-c649-4dc6-84f9-f8b5f4d7aa83@github.com>

On Wed, 18 Aug 2021 13:46:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these declarations:
> 
>     interface I {
>         public String toString();
>     }
>     interface J extends I {}
> 
> 
> There are two issues with the `toString` inherited from `I` into `J`:
> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
> -as a slightly less problematic case, consider:
> 
> I i = null;
> i.toString(); //AST and classfile contain call to I.toString()
> J j = null;
> j.toString(); //AST and classfile contain call to j.l.Object.toString()
> 
> 
> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.

I think that this one deserves a CSR, plus please consider also running the JCK tests just to double check

-------------

PR: https://git.openjdk.java.net/jdk/pull/5165

From vromero at openjdk.java.net  Thu Aug 19 02:59:22 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 19 Aug 2021 02:59:22 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces
In-Reply-To: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
Message-ID: <PIzCWcRjHVERM6A0dU3bRlxfQFBJvmms7kAH_xdQsvs=.86054134-46df-4318-8ccd-8eafadb4030b@github.com>

On Wed, 18 Aug 2021 13:46:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these declarations:
> 
>     interface I {
>         public String toString();
>     }
>     interface J extends I {}
> 
> 
> There are two issues with the `toString` inherited from `I` into `J`:
> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
> -as a slightly less problematic case, consider:
> 
> I i = null;
> i.toString(); //AST and classfile contain call to I.toString()
> J j = null;
> j.toString(); //AST and classfile contain call to j.l.Object.toString()
> 
> 
> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.

question shouldn't field `supertype_field` in ClassType be assigned something different than j.l.Objet for interfaces with no super interface after your change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5165

From jlahoda at openjdk.java.net  Thu Aug 19 12:56:58 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 19 Aug 2021 12:56:58 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v2]
In-Reply-To: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
Message-ID: <IWraNEjQ33oLeT-82yvCJh-u-5E5vypBQxUC2mkAIB4=.fc8ec1aa-499b-4d28-a618-89e12ec2a50f@github.com>

> Consider these declarations:
> 
>     interface I {
>         public String toString();
>     }
>     interface J extends I {}
> 
> 
> There are two issues with the `toString` inherited from `I` into `J`:
> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
> -as a slightly less problematic case, consider:
> 
> I i = null;
> i.toString(); //AST and classfile contain call to I.toString()
> J j = null;
> j.toString(); //AST and classfile contain call to j.l.Object.toString()
> 
> 
> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Removing unnecessary method call.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5165/files
  - new: https://git.openjdk.java.net/jdk/pull/5165/files/1a672cef..9ea15dcc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5165&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5165&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5165.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5165/head:pull/5165

PR: https://git.openjdk.java.net/jdk/pull/5165

From jlahoda at openjdk.java.net  Thu Aug 19 12:57:00 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 19 Aug 2021 12:57:00 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces
In-Reply-To: <EbEAhldBE-rzlLQTFXMngwqOW_LlPD2n3EGttrihqRA=.19fc71ad-c649-4dc6-84f9-f8b5f4d7aa83@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <EbEAhldBE-rzlLQTFXMngwqOW_LlPD2n3EGttrihqRA=.19fc71ad-c649-4dc6-84f9-f8b5f4d7aa83@github.com>
Message-ID: <u-1xyIfy09-DbfAAo9NRwO5yjSfDvYSbgLZpYEfKmRI=.4c25198c-028d-40a9-b2a9-11b2f173dea7@github.com>

On Wed, 18 Aug 2021 18:55:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think that this one deserves a CSR, plus please consider also running the JCK tests just to double check

Thanks, I've started to file the CSR here, please take a look:
https://bugs.openjdk.java.net/browse/JDK-8272564

> question shouldn't field `supertype_field` in ClassType be assigned something different than j.l.Objet for interfaces with no super interface after your change?

Not having interfaces "subclass" `j.l.Object` would be an alternative variant of the fix (it would probably remove the need to these changes altogether). In my experiments, it seemed quite complex to do, however. I can try again, if desired.

Thanks for the comments!

-------------

PR: https://git.openjdk.java.net/jdk/pull/5165

From jlahoda at openjdk.java.net  Thu Aug 19 12:57:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 19 Aug 2021 12:57:06 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces [v2]
In-Reply-To: <UBLFX4Iu5l-sB616w-B2lfPlvlqG0_31ZwS3c3cWdJM=.d2912f17-6c79-40af-b3c0-d0db42f036de@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <UBLFX4Iu5l-sB616w-B2lfPlvlqG0_31ZwS3c3cWdJM=.d2912f17-6c79-40af-b3c0-d0db42f036de@github.com>
Message-ID: <Qi75Apt5ZzqHJZRq8PJHBiv4K5ZeC0-rAqyWeGW_rrc=.d8f7a41c-b624-438c-9191-7aaae4c7dae0@github.com>

On Wed, 18 Aug 2021 14:16:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary method call.
>
> test/langtools/tools/javac/api/TestIsAccessible.java line 61:
> 
>> 59:             for (Element member : ct.getElements().getAllMembers(name)) {
>> 60:                 if (!trees.isAccessible(s, member, (DeclaredType) name.asType())) {
>> 61:                     trees.isAccessible(s, member, (DeclaredType) name.asType());
> 
> Why is this statement necessary?

Ooops, that is a leftover from testing (so that I can easily put a breakpoint on the call when false).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5165

From vromero at openjdk.java.net  Thu Aug 19 14:32:27 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 19 Aug 2021 14:32:27 GMT
Subject: RFR: 8272564: Incorrect attribution of method invocations of
 Object methods on interfaces
In-Reply-To: <u-1xyIfy09-DbfAAo9NRwO5yjSfDvYSbgLZpYEfKmRI=.4c25198c-028d-40a9-b2a9-11b2f173dea7@github.com>
References: <ME6gVIQlffLKg9MuS_AMOTODIWX_kzYz8QBy8TnINCY=.79f10d6b-fbfd-4b93-9de7-5137068a9466@github.com>
 <EbEAhldBE-rzlLQTFXMngwqOW_LlPD2n3EGttrihqRA=.19fc71ad-c649-4dc6-84f9-f8b5f4d7aa83@github.com>
 <u-1xyIfy09-DbfAAo9NRwO5yjSfDvYSbgLZpYEfKmRI=.4c25198c-028d-40a9-b2a9-11b2f173dea7@github.com>
Message-ID: <5CVG_-l9Av-hjgiJDz58Admat4eMHeCedv_X0hDKxGg=.2e376193-c2b5-49ce-a804-75b82fd2316e@github.com>

On Thu, 19 Aug 2021 12:53:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > I think that this one deserves a CSR, plus please consider also running the JCK tests just to double check
> 
> Thanks, I've started to file the CSR here, please take a look:
> https://bugs.openjdk.java.net/browse/JDK-8272564
> 
> > question shouldn't field `supertype_field` in ClassType be assigned something different than j.l.Objet for interfaces with no super interface after your change?
> 
> Not having interfaces "subclass" `j.l.Object` would be an alternative variant of the fix (it would probably remove the need to these changes altogether). In my experiments, it seemed quite complex to do, however. I can try again, if desired.
> 
> Thanks for the comments!

yep I was also considering that it would be a big change, but seems like the right thing to do, I let it to your consideration

-------------

PR: https://git.openjdk.java.net/jdk/pull/5165

From github.com+741251+turbanoff at openjdk.java.net  Thu Aug 19 21:13:24 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 Aug 2021 21:13:24 GMT
Subject: RFR: 8272618: Unnecessary Attr.visitIdent.noOuterThisPath
In-Reply-To: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>
References: <qAoyphrPdu9AaqryZdeA2vUmnMMI1NYpnTrM6yH2c4c=.aeb6ff68-e772-40c7-aed2-4241739228ee@github.com>
Message-ID: <PycwNHOxjdxU4XhNwcvzlc4pqutvOrHZnE3fl6-t5Bg=.8cb2a3a5-d977-4324-8720-f486b0c4d8b7@github.com>

On Wed, 18 Aug 2021 11:42:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch removes an unnecessary variable, which was not removed when `-source <= 5` was removed:
> https://bugs.openjdk.java.net/browse/JDK-8011044

Marked as reviewed by turbanoff at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5163

From manoj.palat at in.ibm.com  Fri Aug 20 11:37:16 2021
From: manoj.palat at in.ibm.com (Manoj Palat)
Date: Fri, 20 Aug 2021 11:37:16 +0000
Subject: [17][Pattern Switch] NPE not thrown for a null with default,
 (non-total) type pattern case labels
Message-ID: <OFA3E804F8.8836891B-ON00258737.003DCF1A-00258737.003FD693@ibm.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210820/60f79bb2/attachment-0001.htm>

From brian.goetz at oracle.com  Fri Aug 20 12:41:58 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 20 Aug 2021 08:41:58 -0400
Subject: [17][Pattern Switch] NPE not thrown for a null with default,
 (non-total) type pattern case labels
In-Reply-To: <OFA3E804F8.8836891B-ON00258737.003DCF1A-00258737.003FD693@ibm.com>
References: <OFA3E804F8.8836891B-ON00258737.003DCF1A-00258737.003FD693@ibm.com>
Message-ID: <ad177c4e-513b-3bda-3b5b-8afd02520f06@oracle.com>

Agree, this should NPE.

On 8/20/2021 7:37 AM, Manoj Palat wrote:
> Hi,
> ?Consider the following case:
> class X {
> public void foo(Object o) {
>          switch (o) {
>            default: break;
>            case String s :System.out.println(s); break;
>          }
> }
> public static void main(String[] args) {
>          (new X()).foo(null); // NPE expected, but prints null
> }
> }
> javac (17+ea35)? prints a null rather than an NPE. I believe it should 
> throw NullPointerException (rather? javac should generate code for 
> Null check to raise NPE at run-time).
> Reasoning behind this is [based on 
> https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3 
> <https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3>]:
> section 14.11.3, see the second rule:
> ...
> Otherwise, if the result of evaluating the selector expression is null, and no switch label in the resolved switch block applies then a NullPointerException is thrown...
> I don't think?either of the switch labels?apply here
> [based on sec 14.11.1
> If the value is the null reference, then we determine the first (if any) switch label in the switch block that applies to the value as follows:
>
> A switch label...]
> Hence I believe an NPE should be thrown for null.
> [A longer version of reasoning at: 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4>]
> Please let me know your take on this.
> Regards,
> Manoj
> [Note: If the case labels are swapped, ie if its in the order shown 
> below, NPE is thrown at run-time
> case String s :System.out.println(s); break;
> default: break; ]
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210820/b0e999bf/attachment.htm>

From jan.lahoda at oracle.com  Fri Aug 20 13:04:56 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 20 Aug 2021 15:04:56 +0200
Subject: [17][Pattern Switch] NPE not thrown for a null with default,
 (non-total) type pattern case labels
In-Reply-To: <OFA3E804F8.8836891B-ON00258737.003DCF1A-00258737.003FD693@ibm.com>
References: <OFA3E804F8.8836891B-ON00258737.003DCF1A-00258737.003FD693@ibm.com>
Message-ID: <af529d17-7758-ffce-4c99-fa2aa1affcd5@oracle.com>

Hi Manoj,


Thanks for the report, filled as:

https://bugs.openjdk.java.net/browse/JDK-8272776


Jan


On 20. 08. 21 13:37, Manoj Palat wrote:
> Hi,
> ?Consider the following case:
> class X {
> public void foo(Object o) {
>          switch (o) {
>            default: break;
>            case String s :System.out.println(s); break;
>          }
> }
> public static void main(String[] args) {
>          (new X()).foo(null); // NPE expected, but prints null
> }
> }
> javac (17+ea35)? prints a null rather than an NPE. I believe it should 
> throw NullPointerException (rather? javac should generate code for 
> Null check to raise NPE at run-time).
> Reasoning behind this is [based on 
> https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3 
> <https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3>]:
> section 14.11.3, see the second rule:
> ...
> Otherwise, if the result of evaluating the selector expression is null, and no switch label in the resolved switch block applies then a NullPointerException is thrown...
> I don't think?either of the switch labels?apply here
> [based on sec 14.11.1
> If the value is the null reference, then we determine the first (if any) switch label in the switch block that applies to the value as follows:
>
> A switch label...]
> Hence I believe an NPE should be thrown for null.
> [A longer version of reasoning at: 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4>]
> Please let me know your take on this.
> Regards,
> Manoj
> [Note: If the case labels are swapped, ie if its in the order shown 
> below, NPE is thrown at run-time
> case String s :System.out.println(s); break;
> default: break; ]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210820/58ee5373/attachment-0001.htm>

From alex.buckley at oracle.com  Fri Aug 20 17:20:57 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 20 Aug 2021 10:20:57 -0700
Subject: [17][Pattern Switch] NPE not thrown for a null with default,
 (non-total) type pattern case labels
In-Reply-To: <ad177c4e-513b-3bda-3b5b-8afd02520f06@oracle.com>
References: <OFA3E804F8.8836891B-ON00258737.003DCF1A-00258737.003FD693@ibm.com>
 <ad177c4e-513b-3bda-3b5b-8afd02520f06@oracle.com>
Message-ID: <c1da7f9a-7d9a-4121-99a5-86ae7d64b615@oracle.com>

It would be ideal for 14.11.1 to say, in a note, what every reader will 
otherwise be pondering: "Note that a default switch label never applies 
to a null value."

Alex

On 8/20/2021 5:41 AM, Brian Goetz wrote:
> Agree, this should NPE.
> 
> On 8/20/2021 7:37 AM, Manoj Palat wrote:
>> Hi,
>> ?Consider the following case:
>> class X {
>> public void foo(Object o) {
>>          switch (o) {
>>            default: break;
>>            case String s :System.out.println(s); break;
>>          }
>> }
>> public static void main(String[] args) {
>>          (new X()).foo(null); // NPE expected, but prints null
>> }
>> }
>> javac (17+ea35)? prints a null rather than an NPE. I believe it should 
>> throw NullPointerException (rather? javac should generate code for 
>> Null check to raise NPE at run-time).
>> Reasoning behind this is [based on 
>> https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3 
>> <https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.11.3>]:
>> section 14.11.3, see the second rule:
>> ...
>> Otherwise, if the result of evaluating the selector expression is null, and no switch label in the resolved switch block applies then a NullPointerException is thrown...
>> I don't think?either of the switch labels?apply here
>> [based on sec 14.11.1
>> If the value is the null reference, then we determine the first (if any) switch label in the switch block that applies to the value as follows:
>>
>> A switch label...]
>> Hence I believe an NPE should be thrown for null.
>> [A longer version of reasoning at: 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4 
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=575051#c4>]
>> Please let me know your take on this.
>> Regards,
>> Manoj
>> [Note: If the case labels are swapped, ie if its in the order shown 
>> below, NPE is thrown at run-time
>> case String s :System.out.println(s); break;
>> default: break; ]
>>
>>
> 

From jjg at openjdk.java.net  Fri Aug 20 18:53:33 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 20 Aug 2021 18:53:33 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
Message-ID: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>

On Fri, 6 Aug 2021 12:24:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass through FIXMEs and TODOs
>   
>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.

Generally impressive piece of work.

src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 291:

> 289: 
> 290:     /**
> 291:      * Visits a SnippetTree node.

There's been a recent update, and these class names should now be wrapped in `{@code }`

src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java line 32:

> 30: /**
> 31:  * A tree node for an {@code @snippet} inline tag, as specified by
> 32:  * <a href="http://openjdk.java.net/jeps/413">JEP 413</a>.

The reference to a JEP is unusual.  The public spec for a snippet should be in the tag spec.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 513:

> 511: 
> 512:     /**
> 513:      * {@inheritDoc} This implementation scans the children in left to right order.

(minor)
I would suggest/recommend a line-break after the `{@inheritDoc}`
Likewise for similar occurrences elsewhere.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 516:

> 514:      *
> 515:      * @param node  {@inheritDoc}
> 516:      * @param p  {@inheritDoc}

Do you need the `{@inheritDoc}` ... isn't that the default behavior if no tag is specified?

Likewise for similar occurrences elsewhere.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 923:

> 921:          * probably be considered on a case-by-case basis, for an attribute
> 922:          * value of the {@snippet} tag we do not recurse.
> 923:          */

This discussion does not belong here.

We should specify simple defensible rules (in the spec) and implement them accordingly.
If there is nothing more obvious, I suggest the rules for (Unicode) identifiers.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1249:

> 1247: //                    messages.warning(
> 1248: //                            ch.getDocTreePath(see), "doclet.see.class_or_package_not_found",
> 1249: //                            tagName, seeText);

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 399:

> 397:                         classes.add(n.name());
> 398:                     } else if (s instanceof Style.Link l) {
> 399:                         assert !linkEncountered; // FIXME: do not assert; pick the first link

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 406:

> 404:                             // diagnostic output
> 405:                         }
> 406:                     } else if (s instanceof Style.Markup) {

Is the empty `if` expected?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 87:

> 85:     snippet,
> 86:     //</editor-fold>
> 87: 

Suggest removing the editor-fold comments.  It'll be listed as not-yet-categorized by virtue of being in the initial list.

If the code generates standard styles, they should be listed here, so that they get documented in the sometime-forthcoming stylesheet spec.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 360:

> 358: 
> 359: doclet.tag.attribute.repeated=\
> 360:  repeated attribute: "{0}"

check the resource file for other quoted values; I think you'll find single quotes are the prevailing standard.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 39:

> 37: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.Parser;
> 38: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.StyledText;
> 39: import jdk.javadoc.internal.doclets.toolkit.util.Utils;

The langtools/javac/javadoc convention is to put standard JavaSE imports (`java.*`, `javax.*` ) first.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 96:

> 94:             // recently encountered of two, the iteration order might differ
> 95:             // from the source order
> 96:             error(writer, holder, a, "doclet.tag.attribute.repeated", a.getName().toString());

Can we use a `LinkedHashMap` or similar to preserve encounter order?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 178:

> 176:         }
> 177: 
> 178:         // FIXME cache parsed external snippet (WeakHashMap)

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 260:

> 258:      * There's a separate issue of mapping discrepancies back to their
> 259:      * originating source in the doc comment and the external file. Maybe there
> 260:      * is a value in it, or may be there isn't. In any case, accurate mapping

"maybe"

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 274:

> 272:     private StyledText parse(String content) throws ParseException {
> 273:         // FIXME: need to be able to process more fine-grained, i.e. around a particular region...
> 274:         // or, which is even better, cache the styled text

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 287:

> 285: 
> 286:     // FIXME: figure out how to do that correctly
> 287:     // FIXME: consider returning null from this method so it can be used as oneliner

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 69:

> 67: // FIXME: How to treat Form Feed? (i.e. is it vertical or horizontal whitespace?)
> 68: // FIXME: what to do with lines not covered by any markup? (i.e. in between markup)
> 69: // FIXME: all parsing errors must be localized.

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 134:

> 132:             this.eolMarker = eolMarker;
> 133:             // capture the rightmost eolMarker (e.g. "//")
> 134:             // The bellow Pattern.compile should never throw PatternSyntaxException

"below" ?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 177:

> 175:                 }
> 176:                 thisLineTags.addAll(parsedTags);
> 177:                 for (var tagIterator = thisLineTags.iterator(); tagIterator.hasNext(); ) {

oooh, not wrong; just unexpected mix of styles ;-)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 186:

> 184:                 }
> 185:                 if (parsedTags.isEmpty()) { // (2)
> 186:                     // TODO: log this with NOTICE;

does this need to be addressed?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 207:

> 205: 
> 206:             append(text, Set.of(), line);
> 207:             // FIXME: mark up trailing whitespace!

FIXME

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 376:

> 374: 
> 375:     public TypeElement getReferencedClass(Element e) {
> 376:         Utils utils = configuration.utils;

Whinge. This new method does not really belong here, also implying that the body of the old method does not belong here (in the class) either.  Generally, queries on elements belong in `Utils`, not `CommentHelper`.

But, OK for now, I guess.

--

As a one-off, it was OK to let this slide. Given there are repeated similar occurrences later on, can you file an RFE to move the `Element` / non-`DocTree` methods to `Utils`.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 406:

> 404: 
> 405:     public Element getReferencedMember(Element e) {
> 406:         Utils utils = configuration.utils;

Same whinge as above.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 431:

> 429:     }
> 430: 
> 431:     public PackageElement getReferencedPackage(Element e) {

ditto

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 444:

> 442:     }
> 443: 
> 444:     public ModuleElement getReferencedModule(Element e) {

ditto

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 27:

> 25:  * @test
> 26:  * @bug 8201533
> 27:  * @library /tools/lib ../../lib

need @summary

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 81:

> 79: 
> 80:     public static void main(String... args) throws Exception {
> 81:         new TestSnippetTag().runTests(m -> new Object[]{Paths.get(m.getName())});

This is just a suggestion for future convenience.
For big tests like this, for ease of debugging, it can be useful to be able to specify the method(s) to be executed.   Maybe there should be a variants of `runTests` that takes a `String[]` or `List<String>`

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 1508:

> 1506:                 )
> 1507: // Uncomment when parser has improved (this would allow to write meta snippets,
> 1508: // i.e. snippets showing how to write snippets.

Just a question: what are the limitations in the parser that are getting in the way here?

test/langtools/tools/javac/doctree/SnippetTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8201533

Need `@summary`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Sat Aug 21 03:16:39 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 21 Aug 2021 03:16:39 GMT
Subject: RFR: JDK-8265253: javac -Xdoclint:all gives "no comment" warning for
 code that can't be commented
Message-ID: <fXGm9RZMy77DUrw3b0q122JA50quka_YXJksYdyKm-U=.00b33b40-070f-4377-9262-040d08a658cb@github.com>

Please review a simple update for doclint, to suppress "missing comment" warnings on the internally-synthesized class resulting from use of an anonymous class body in a member declaration in an enum class..

-------------

Commit messages:
 - JDK-8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented

Changes: https://git.openjdk.java.net/jdk/pull/5206/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5206&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265253
  Stats: 60 lines in 3 files changed: 59 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5206.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5206/head:pull/5206

PR: https://git.openjdk.java.net/jdk/pull/5206

From serb at openjdk.java.net  Sun Aug 22 06:28:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 06:28:18 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
Message-ID: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>

This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951

In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");

This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
absolutePath.getBytes(StandardCharsets.UTF_8);

The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.

This change includes:
 * demo/utils
 * jdk.xx packages
 * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage.

Some performance discussion: https://github.com/openjdk/jdk/pull/5063

Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later).

Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

-------------

Commit messages:
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - Cleanup the UnsupportedEncodingException
 - aliases for ISO_8859_1
 - Update imageio
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/5210/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272805
  Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

PR: https://git.openjdk.java.net/jdk/pull/5210

From weijun at openjdk.java.net  Sun Aug 22 13:22:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 22 Aug 2021 13:22:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

The security related change looks fine to me.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5210

From alanb at openjdk.java.net  Sun Aug 22 15:12:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Aug 2021 15:12:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:

> 340: 
> 341:         try {
> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {

The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From github.com+741251+turbanoff at openjdk.java.net  Sun Aug 22 18:34:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 22 Aug 2021 18:34:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From serb at openjdk.java.net  Sun Aug 22 23:02:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 23:02:06 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00-01

  Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

PR: https://git.openjdk.java.net/jdk/pull/5210

From naoto at openjdk.java.net  Mon Aug 23 00:26:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Aug 2021 00:26:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <YDjqMHQFk2IHLNrmd3MahBp6vvL4D3x4ncTa3PvvQWY=.39eace25-57d6-4981-a1ad-31901c061b25@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644

Looks good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5210

From dfuchs at openjdk.java.net  Mon Aug 23 09:36:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 23 Aug 2021 09:36:40 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <iwz79djzNlUzGYlpBbrLcycsmNcDy3bZF7qc4vozQAI=.e4aa79aa-f9cd-413a-bb5a-dc95023dc410@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644

Changes to http server look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5210

From hannesw at openjdk.java.net  Mon Aug 23 12:59:31 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 23 Aug 2021 12:59:31 GMT
Subject: RFR: JDK-8265253: javac -Xdoclint:all gives "no comment" warning
 for code that can't be commented
In-Reply-To: <fXGm9RZMy77DUrw3b0q122JA50quka_YXJksYdyKm-U=.00b33b40-070f-4377-9262-040d08a658cb@github.com>
References: <fXGm9RZMy77DUrw3b0q122JA50quka_YXJksYdyKm-U=.00b33b40-070f-4377-9262-040d08a658cb@github.com>
Message-ID: <1ekvRzAVGtgHy_BxyZJ3sgckF327v-71dtrLJhlxwp4=.d5d5af05-212d-4c30-aede-7e657e719736@github.com>

On Sat, 21 Aug 2021 03:08:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple update for doclint, to suppress "missing comment" warnings on the internally-synthesized class resulting from use of an anonymous class body in a member declaration in an enum class..

Looks good.

-------------

Marked as reviewed by hannesw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5206

From prappo at openjdk.java.net  Mon Aug 23 14:08:52 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 14:08:52 GMT
Subject: RFR: 8266666: Implementation for snippets [v8]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <3xHiNyTqxKK4xHo1s5mucwvbIc9x8T0O7pbKCFGZ_4o=.5d7f6a13-e185-4df6-b92f-91c6520a5ad0@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into 8266666
 - Pass through FIXMEs and TODOs
   
   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
 - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
   
   Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
 - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
   
   Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
 - Change AnnotatedText<T> to StyledText
   
   Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style".
 - Restructure ...toolkit.taglets.snippet.** packages
   
   This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package.
 - Make CSS rules more specific
 - Improve comments
   
   This commit adds trivial commentary to some of the Java declarations. This commit also adds the "This is NOT part of any supported API..." disclaimer.
 - Update @since tags
 - Update copyright years
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/b7f75c0a...e1dbd98d

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=07
  Stats: 4716 lines in 44 files changed: 4689 ins; 4 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 14:08:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 14:08:53 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <0Wi4TkCH6CinNMMZnY56KyT1YWBz34P2kwiXOo0ZrUg=.80c9f0ab-1af9-446e-9d36-697104019f64@github.com>

On Fri, 20 Aug 2021 17:45:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 291:
> 
>> 289: 
>> 290:     /**
>> 291:      * Visits a SnippetTree node.
> 
> There's been a recent update, and these class names should now be wrapped in `{@code }`

I was aware of that update and hoped to incorporate it properly with the next merge, which I've just done: e1dbd98dfa51f7568e787b1b72a6e30bfc6f4987

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 15:22:35 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 15:22:35 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <Ol3_bDxdVr96D7TjGIWuFWTXiUO11-oftgl4FVZM9SQ=.0b082b6e-3f68-45cb-9443-49d50fd404b2@github.com>

On Fri, 20 Aug 2021 17:49:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 513:
> 
>> 511: 
>> 512:     /**
>> 513:      * {@inheritDoc} This implementation scans the children in left to right order.
> 
> (minor)
> I would suggest/recommend a line-break after the `{@inheritDoc}`
> Likewise for similar occurrences elsewhere.

See https://github.com/openjdk/jdk/pull/4795#discussion_r694070081. Let's NOT do it in this PR.

> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 516:
> 
>> 514:      *
>> 515:      * @param node  {@inheritDoc}
>> 516:      * @param p  {@inheritDoc}
> 
> Do you need the `{@inheritDoc}` ... isn't that the default behavior if no tag is specified?
> 
> Likewise for similar occurrences elsewhere.

I don't think that I need `{@inheritDoc}` to inherit the comments in that and the similar cases in that file. I used that style because other parts of the file use it and I didn't want to update the file inconsistently. If we don't like that style, we are free to change it. That said, let's NOT do it in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 15:31:08 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 15:31:08 GMT
Subject: RFR: 8266666: Implementation for snippets [v9]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <8npES8SI6DiPj2CIU2FPqcFUw6G10V-cfCQVNus6ZfU=.f7f7e83f-a68a-4a89-9300-4c14397851d7@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Remove JEP link from SnippetTree

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/e1dbd98d..942b1e98

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 15:31:13 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 15:31:13 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <l8k9QTCdnfWkJ4-GeRTFs4o7SZJgZ_hHqAcoa0XGzsc=.aabc119b-6ab7-4eaa-bdd2-5352e288fc83@github.com>

On Fri, 20 Aug 2021 17:46:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java line 32:
> 
>> 30: /**
>> 31:  * A tree node for an {@code @snippet} inline tag, as specified by
>> 32:  * <a href="http://openjdk.java.net/jeps/413">JEP 413</a>.
> 
> The reference to a JEP is unusual.  The public spec for a snippet should be in the tag spec.

Fixed in 942b1e9874f1f103b75c9d1b737b289296254dc7.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 16:04:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 16:04:34 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <sbBmVd7mJ8LGMVSFhGQtpBCuJ6hK6DJhzodAbKb9oUs=.ec5f206e-2c19-499a-b8c5-0ad521a933d1@github.com>

On Fri, 20 Aug 2021 17:54:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This discussion does not belong here.

I've hoped to specify tag syntax before we push this PR. Until the syntax has been specified, the comment has to be stored somewhere. What would be an appropriate place to store that comment in?

> I suggest the rules for (Unicode) identifiers

What do those rules look like? Do you have a link handy?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 16:12:00 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 16:12:00 GMT
Subject: RFR: 8266666: Implementation for snippets [v10]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <yzFbLQJhxcO1DASdGpCrWVS7blQ6j3oio1sXf5iFPro=.1e95333d-8863-409a-8bd0-9c1666914335@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Remove superfluous editor-fold

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/942b1e98..731a1a6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=08-09

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 16:12:05 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 16:12:05 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <JPFYNmlQGj9YOmSggK-GHc6zUcuX-JmNr4CgNKD8RrM=.1751b115-4984-4fbb-8cd0-cf6cb92074b0@github.com>

On Fri, 20 Aug 2021 18:03:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 87:
> 
>> 85:     snippet,
>> 86:     //</editor-fold>
>> 87: 
> 
> Suggest removing the editor-fold comments.  It'll be listed as not-yet-categorized by virtue of being in the initial list.
> 
> If the code generates standard styles, they should be listed here, so that they get documented in the sometime-forthcoming stylesheet spec.

Fixed in 731a1a6be1a.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From vromero at openjdk.java.net  Mon Aug 23 16:25:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 23 Aug 2021 16:25:44 GMT
Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object
 differently
Message-ID: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>

Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this.

TIA

-------------

Commit messages:
 - 8268148: unchecked warnings handle ? and ? extends Object differently

Changes: https://git.openjdk.java.net/jdk/pull/5224/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5224&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268148
  Stats: 46 lines in 3 files changed: 43 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5224/head:pull/5224

PR: https://git.openjdk.java.net/jdk/pull/5224

From prappo at openjdk.java.net  Mon Aug 23 17:18:33 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 17:18:33 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <2iWH0I7EWTfC6BjytMqzwNiGfz4ThWzW06SpDyM6urY=.10eb237b-b287-4a4c-a243-bf42f330a17b@github.com>

On Fri, 20 Aug 2021 18:25:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 177:
> 
>> 175:                 }
>> 176:                 thisLineTags.addAll(parsedTags);
>> 177:                 for (var tagIterator = thisLineTags.iterator(); tagIterator.hasNext(); ) {
> 
> oooh, not wrong; just unexpected mix of styles ;-)

Can you be more specific? In what sense is this unexpected?

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 186:
> 
>> 184:                 }
>> 185:                 if (parsedTags.isEmpty()) { // (2)
>> 186:                     // TODO: log this with NOTICE;
> 
> does this need to be addressed?

I think that it does. It's the case of spurious markup. Such a case likely requires author's attention.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Mon Aug 23 17:34:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 23 Aug 2021 17:34:34 GMT
Subject: Integrated: JDK-8265253: javac -Xdoclint:all gives "no comment"
 warning for code that can't be commented
In-Reply-To: <fXGm9RZMy77DUrw3b0q122JA50quka_YXJksYdyKm-U=.00b33b40-070f-4377-9262-040d08a658cb@github.com>
References: <fXGm9RZMy77DUrw3b0q122JA50quka_YXJksYdyKm-U=.00b33b40-070f-4377-9262-040d08a658cb@github.com>
Message-ID: <v0jFH4d5rCDVs5y8Fq-qAcSR3jl3oGMuTpmZAZK6jvQ=.2881fcd3-8629-4ec3-b4aa-6b45a328e63c@github.com>

On Sat, 21 Aug 2021 03:08:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple update for doclint, to suppress "missing comment" warnings on the internally-synthesized class resulting from use of an anonymous class body in a member declaration in an enum class..

This pull request has now been integrated.

Changeset: 18840724
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18840724749c839259688bfa052652a1f34a378a
Stats:     60 lines in 3 files changed: 59 ins; 0 del; 1 mod

8265253: javac -Xdoclint:all gives "no comment" warning for code that can't be commented

Reviewed-by: hannesw

-------------

PR: https://git.openjdk.java.net/jdk/pull/5206

From jjg at openjdk.java.net  Mon Aug 23 17:39:36 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 23 Aug 2021 17:39:36 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <sbBmVd7mJ8LGMVSFhGQtpBCuJ6hK6DJhzodAbKb9oUs=.ec5f206e-2c19-499a-b8c5-0ad521a933d1@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <sbBmVd7mJ8LGMVSFhGQtpBCuJ6hK6DJhzodAbKb9oUs=.ec5f206e-2c19-499a-b8c5-0ad521a933d1@github.com>
Message-ID: <McZcJN1VUIkDrqnx5BrygJaVI_f-o2isDNLfIwAHAww=.26db7491-38cb-436a-a941-876bcfb81f54@github.com>

On Mon, 23 Aug 2021 16:01:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 923:
>> 
>>> 921:          * probably be considered on a case-by-case basis, for an attribute
>>> 922:          * value of the {@snippet} tag we do not recurse.
>>> 923:          */
>> 
>> This discussion does not belong here.
>> 
>> We should specify simple defensible rules (in the spec) and implement them accordingly.
>> If there is nothing more obvious, I suggest the rules for (Unicode) identifiers.
>
>> This discussion does not belong here.
> 
> I've hoped to specify tag syntax before we push this PR. Until the syntax has been specified, the comment has to be stored somewhere. What would be an appropriate place to store that comment in?
> 
>> I suggest the rules for (Unicode) identifiers
> 
> What do those rules look like? Do you have a link handy?

Check `Character.isUnicodeIdentifierStart` / `Character.isUnicodeIdentifierPart`
Variant suggestion (if different) ... use the identifier rules for the name of the attribute

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Mon Aug 23 17:44:28 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 23 Aug 2021 17:44:28 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <McZcJN1VUIkDrqnx5BrygJaVI_f-o2isDNLfIwAHAww=.26db7491-38cb-436a-a941-876bcfb81f54@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <sbBmVd7mJ8LGMVSFhGQtpBCuJ6hK6DJhzodAbKb9oUs=.ec5f206e-2c19-499a-b8c5-0ad521a933d1@github.com>
 <McZcJN1VUIkDrqnx5BrygJaVI_f-o2isDNLfIwAHAww=.26db7491-38cb-436a-a941-876bcfb81f54@github.com>
Message-ID: <J3qTvJOwplW8OHy3KuGnljZA8mAdyZvUp06T0wAOJ7U=.283df618-78ee-456c-8a3b-64b17fdd75bf@github.com>

On Mon, 23 Aug 2021 17:36:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> This discussion does not belong here.
>> 
>> I've hoped to specify tag syntax before we push this PR. Until the syntax has been specified, the comment has to be stored somewhere. What would be an appropriate place to store that comment in?
>> 
>>> I suggest the rules for (Unicode) identifiers
>> 
>> What do those rules look like? Do you have a link handy?
>
> Check `Character.isUnicodeIdentifierStart` / `Character.isUnicodeIdentifierPart`
> Variant suggestion (if different) ... use the identifier rules for the name of the attribute

A discussion like that belongs in JBS.  The result of the discussion belongs in spec and/or code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Mon Aug 23 17:44:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 23 Aug 2021 17:44:29 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <u6ZtH6lViaHM5K3c92XGVZFIwCwyDQqpxl8ZfeqYBlk=.488f910e-e15e-4add-8bff-205aa3eeda6a@github.com>

On Fri, 20 Aug 2021 18:46:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 81:
> 
>> 79: 
>> 80:     public static void main(String... args) throws Exception {
>> 81:         new TestSnippetTag().runTests(m -> new Object[]{Paths.get(m.getName())});
> 
> This is just a suggestion for future convenience.
> For big tests like this, for ease of debugging, it can be useful to be able to specify the method(s) to be executed.   Maybe there should be a variants of `runTests` that takes a `String[]` or `List<String>`

I filed JDK-8272853 for us.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 18:06:33 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 18:06:33 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com>

On Fri, 20 Aug 2021 18:09:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 39:
> 
>> 37: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.Parser;
>> 38: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.StyledText;
>> 39: import jdk.javadoc.internal.doclets.toolkit.util.Utils;
> 
> The langtools/javac/javadoc convention is to put standard JavaSE imports (`java.*`, `javax.*` ) first.

Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Aug 23 18:13:56 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Aug 2021 18:13:56 GMT
Subject: RFR: 8266666: Implementation for snippets [v11]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <OB7_1i1GGwB6_ij6yktDDKQZBwLi4kkN0QIvH5drSKU=.f9915031-f1b8-4023-b8b5-e1d14a886cae@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Add @summary to tests
  
  From https://openjdk.java.net/jtreg/faq.html:
  
  The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates.
  
  That said, the JBS synopsis for 8266666 suits those tests just fine.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/731a1a6b..0510287e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=09-10

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From serb at openjdk.java.net  Mon Aug 23 19:34:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:34 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
Message-ID: <KyQxSd0IYEEoEC0acPE16G5CIvwqPTVGVZOP1M9Me8o=.f1d93383-8174-4731-8e16-ef72b415b34a@github.com>

On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.

Updated as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From serb at openjdk.java.net  Mon Aug 23 19:34:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
Message-ID: <aKpPQPgoXRthV1BM7HdtVLagya1bBbQnwQNj68kW_q8=.12c01c5d-b0d5-42a7-b7ce-6a03b5d05b59@github.com>

On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:
> 
>> 340: 
>> 341:         try {
>> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {
> 
> The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

Thank you for the suggestion, I have fixed this and a few other places as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug 23 20:54:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 Aug 2021 20:54:36 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <N67-urPlw_TC9qhch8RkndEzRrP3vUMmVDk-e_nEt-g=.b05fa6c6-04b4-449b-8f93-b00ce5f3e81e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644

Marked as reviewed by turbanoff at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From vromero at openjdk.java.net  Mon Aug 23 23:35:49 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 23 Aug 2021 23:35:49 GMT
Subject: RFR: 8268885: duplicate checkcast when destination type is not first
 type of intersection type
Message-ID: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>

Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like:


class IntersectionTypeTest {
    interface I1 {}
    interface I2 {}
    static class C {}
    void test() {
        I2 i = (I1 & I2) new C();
    }
}

basically when an intersection type is used in a cast expression and the target is not the type in the intersection.

TIA

-------------

Commit messages:
 - 8268885: duplicate checkcast when destination type is not first type of intersection type

Changes: https://git.openjdk.java.net/jdk/pull/5235/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5235&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268885
  Stats: 37 lines in 2 files changed: 24 ins; 3 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5235.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5235/head:pull/5235

PR: https://git.openjdk.java.net/jdk/pull/5235

From prappo at openjdk.java.net  Tue Aug 24 10:27:56 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 10:27:56 GMT
Subject: RFR: 8266666: Implementation for snippets [v12]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <5pYpCnvgOSaVG_1lJtlHEXNrwrmaDtyw0SyRa1jQBgM=.130e1005-309e-4357-8eff-e2468d0502f1@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Fix import layout and typos

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/0510287e..a7cd1551

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=10-11

  Stats: 31 lines in 2 files changed: 15 ins; 14 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 10:27:59 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 10:27:59 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com>
Message-ID: <BnpKBWc2s3CzI4dM9ele3uQUmJLGVTIxf1v5DCKJrZo=.6cb8a6b2-30e7-4826-a557-e20cf1418fa0@github.com>

On Mon, 23 Aug 2021 18:03:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 39:
>> 
>>> 37: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.Parser;
>>> 38: import jdk.javadoc.internal.doclets.toolkit.taglets.snippet.StyledText;
>>> 39: import jdk.javadoc.internal.doclets.toolkit.util.Utils;
>> 
>> The langtools/javac/javadoc convention is to put standard JavaSE imports (`java.*`, `javax.*` ) first.
>
> Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration?

Fixed in a7cd155.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 10:28:05 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 10:28:05 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <tJa6tteqbFnAaqqU4AGEvlVRuBCVKH4bukfbZ0zy0zc=.ab203352-967e-4b87-9b2a-e269d0598729@github.com>

On Fri, 20 Aug 2021 18:13:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 260:
> 
>> 258:      * There's a separate issue of mapping discrepancies back to their
>> 259:      * originating source in the doc comment and the external file. Maybe there
>> 260:      * is a value in it, or may be there isn't. In any case, accurate mapping
> 
> "maybe"

Fixed in a7cd155.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 134:
> 
>> 132:             this.eolMarker = eolMarker;
>> 133:             // capture the rightmost eolMarker (e.g. "//")
>> 134:             // The bellow Pattern.compile should never throw PatternSyntaxException
> 
> "below" ?

Fixed in a7cd155.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 11:33:33 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 11:33:33 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <lJunviL7QcvJ7zS_wCCvX8kQn_OfYBXi0jOG1CanUHU=.043e1c41-654e-4ae1-b85c-3d30bd174cd0@github.com>

On Fri, 20 Aug 2021 18:07:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 360:
> 
>> 358: 
>> 359: doclet.tag.attribute.repeated=\
>> 360:  repeated attribute: "{0}"
> 
> check the resource file for other quoted values; I think you'll find single quotes are the prevailing standard.

I didn't find single quotes to be the prevailing standard neither in `doclet.properties` nor in `compiler.properties`. In fact, it seems to be the opposite: whenever a parameter (not constant) is output, it's either unquoted or double-quoted. Did I look in the right place?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From azvegint at openjdk.java.net  Tue Aug 24 13:09:37 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 24 Aug 2021 13:09:37 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <cI5w9AqyTY2y-cy5LJA9fbGFkB2s_-hhoVOCP6w0CaE=.d56a95c4-0a92-45e2-944b-0d0e3dce165e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From prappo at openjdk.java.net  Tue Aug 24 13:14:57 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 13:14:57 GMT
Subject: RFR: 8266666: Implementation for snippets [v13]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <j3L8GO7XVcDrt_IW3gcn99u1NkxCsAUHRFd4pJI6l7g=.2758bc09-0bfc-4eaf-ba7b-4493e06843f8@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Clarify the attributes order comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/a7cd1551..26de3408

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 13:15:00 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 13:15:00 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <z0iCX2MhKUG1JtrsvHWPCLYA-aHOaIc1VKW3dqWx9V4=.21682432-7f23-434d-8bc9-0bf747a08f6d@github.com>

On Fri, 20 Aug 2021 18:11:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 96:
> 
>> 94:             // recently encountered of two, the iteration order might differ
>> 95:             // from the source order
>> 96:             error(writer, holder, a, "doclet.tag.attribute.repeated", a.getName().toString());
> 
> Can we use a `LinkedHashMap` or similar to preserve encounter order?

If you look closely, you will see that the ordering characteristics of the `Map` implementation used to collect attributes is immaterial. My comment was about the implied (but unspecified) order of attributes in the list returned from the `SnippetTree.getAttributes()` method; see the third paragraph in the description of https://bugs.openjdk.java.net/browse/JDK-8266826

I clarified the comment in 26de34083a3.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Tue Aug 24 14:27:31 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 Aug 2021 14:27:31 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <BnpKBWc2s3CzI4dM9ele3uQUmJLGVTIxf1v5DCKJrZo=.6cb8a6b2-30e7-4826-a557-e20cf1418fa0@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <0qVuBDPSH0SVQCGtJC0jj03eNdjdFrPYXhYlhoAktC8=.8be3b169-bbc6-440d-9846-59f21848e5e8@github.com>
 <BnpKBWc2s3CzI4dM9ele3uQUmJLGVTIxf1v5DCKJrZo=.6cb8a6b2-30e7-4826-a557-e20cf1418fa0@github.com>
Message-ID: <wad2WKaPUjaaIMXNkR2bjTfykS-3jDoj2Mnn9ZslUnU=.5ae0f94c-7c8c-4327-85c5-ada43a4e62ee@github.com>

On Tue, 24 Aug 2021 10:24:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration?
>
> Fixed in a7cd155.

> Since we are here, is there any langtools convention for when to collapse a span of single-import declarations into an import-on-demand (.*) declaration?

langtools does not use import-on-demand, and it is practice e to expand them to single imports if any creep into the code.   Also, imports are ordered with Java SE (`java.*` `javax.*`) imports first, before others.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Tue Aug 24 14:36:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 Aug 2021 14:36:34 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <lJunviL7QcvJ7zS_wCCvX8kQn_OfYBXi0jOG1CanUHU=.043e1c41-654e-4ae1-b85c-3d30bd174cd0@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <lJunviL7QcvJ7zS_wCCvX8kQn_OfYBXi0jOG1CanUHU=.043e1c41-654e-4ae1-b85c-3d30bd174cd0@github.com>
Message-ID: <VzU1oJzPitByr9JY24gWgdTrrtRyC6w6ErOwY2c9NdA=.b8933d8b-738f-4f74-8ad2-236d28656942@github.com>

On Tue, 24 Aug 2021 11:30:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 360:
>> 
>>> 358: 
>>> 359: doclet.tag.attribute.repeated=\
>>> 360:  repeated attribute: "{0}"
>> 
>> check the resource file for other quoted values; I think you'll find single quotes are the prevailing standard.
>
> I didn't find single quotes to be the prevailing standard neither in `doclet.properties` nor in `compiler.properties`. In fact, it seems to be the opposite: whenever a parameter (not constant) is output, it's either unquoted or double-quoted. Did I look in the right place?

OK, it's not as dominant as I thought ... 2 to 1.
Grepping through English properties files `jdk.compiler` and `jdk.javadoc`, there are 142 lines containing `'` and 75 lines containing `"`
Maybe we should have a separate cleanup, after figuring out which form we should use.

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java line 177:
>> 
>>> 175:                 }
>>> 176:                 thisLineTags.addAll(parsedTags);
>>> 177:                 for (var tagIterator = thisLineTags.iterator(); tagIterator.hasNext(); ) {
>> 
>> oooh, not wrong; just unexpected mix of styles ;-)
>
> Can you be more specific? In what sense is this unexpected?

Just the combination of `var`, iterators, and a `for `(;;)` loop, that's all. Not wrong, just uncommon; it took me a double-take to parse it, that's all.   The code is OK, no need to change it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 16:55:39 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 16:55:39 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <-hDrj20tKNB2jnaL3i6ygSGR10XC1XX8Lx9NUV6ZMAs=.e9042f9f-40a2-4cf0-a515-4238d0e1effc@github.com>

On Fri, 20 Aug 2021 18:50:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> Generally impressive piece of work.

@jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Tue Aug 24 17:25:30 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 Aug 2021 17:25:30 GMT
Subject: RFR: 8266666: Implementation for snippets [v13]
In-Reply-To: <j3L8GO7XVcDrt_IW3gcn99u1NkxCsAUHRFd4pJI6l7g=.2758bc09-0bfc-4eaf-ba7b-4493e06843f8@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <j3L8GO7XVcDrt_IW3gcn99u1NkxCsAUHRFd4pJI6l7g=.2758bc09-0bfc-4eaf-ba7b-4493e06843f8@github.com>
Message-ID: <SeJFi3Ecbk9ayU0nwz8VX0nK_uVofX_Sz_Q9n6cB2vQ=.370cbaef-3c29-41d1-bac7-8e170d4fa8b8@github.com>

On Tue, 24 Aug 2021 13:14:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify the attributes order comment

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java line 82:

> 80:      */
> 81:     snippet,
> 82: 

This is OK for now, given that we do not have a "public" way to process these comments at this time. However, we should probably do a cleanup later on (soon), and maybe create a new section in `HtmlStyle` for all snippet related styles ... i.e. including `bold`, `italic` etc, so that all styles end up in the upcoming documentation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Tue Aug 24 17:32:32 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 Aug 2021 17:32:32 GMT
Subject: RFR: 8266666: Implementation for snippets [v13]
In-Reply-To: <oF0h93PSTZszdDPcg7CEshJIULfAeD-Brr-aYCXhmQQ=.9eeb4f21-d782-4dbb-8d09-034b9c594a16@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <oF0h93PSTZszdDPcg7CEshJIULfAeD-Brr-aYCXhmQQ=.9eeb4f21-d782-4dbb-8d09-034b9c594a16@github.com>
Message-ID: <Z97mzfLWKhGCjvQePaxZbzQ-JyIyUg7PD0WyVj2dpUI=.4cbf01b3-9434-48ee-b106-c97973d99680@github.com>

On Mon, 26 Jul 2021 14:31:27 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> I would prefer if variables such as this that are used farther than a few lines from their definition had more meaningful names.

It's also confusing that `r` is a `String` but `r1`, `r2` (lines 209-211) are `StyledText`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 17:46:51 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 17:46:51 GMT
Subject: RFR: 8266666: Implementation for snippets [v14]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <QrB0qoVRM9vvaYb7QAVBZGj-EkkksCod3fUDhhAWwKI=.65645bc1-606c-45cc-95ae-1992f2eb4209@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into 8266666
   
   This merge is to promptly resolve a conflict in src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java.
 - Clarify the attributes order comment
 - Fix import layout and typos
 - Add @summary to tests
   
   From https://openjdk.java.net/jtreg/faq.html:
   
   The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates.
   
   That said, the JBS synopsis for 8266666 suits those tests just fine.
 - Remove superfluous editor-fold
 - Remove JEP link from SnippetTree
 - Merge branch 'master' into 8266666
 - Pass through FIXMEs and TODOs
   
   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
 - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
   
   Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
 - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
   
   Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/d34f17c6...4c5e92b7

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=13
  Stats: 4812 lines in 59 files changed: 4708 ins; 12 del; 92 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Tue Aug 24 21:59:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 24 Aug 2021 21:59:29 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>

On Fri, 20 Aug 2021 18:50:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> Generally impressive piece of work.

> @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.)

It doesn't seem worth a release note ... we're just using the tree in more places ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 21:59:30 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 21:59:30 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
Message-ID: <NKPikVf4msYmfEWaNQuh-qcSZ5bQ8RrS509ddpMXeNw=.5d7cd974-f406-48ad-8cc3-b649f0c33491@github.com>

On Fri, 20 Aug 2021 18:42:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass through FIXMEs and TODOs
>>   
>>   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>
> test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 1508:
> 
>> 1506:                 )
>> 1507: // Uncomment when parser has improved (this would allow to write meta snippets,
>> 1508: // i.e. snippets showing how to write snippets.
> 
> Just a question: what are the limitations in the parser that are getting in the way here?

Both the commented-out code and its description are from a previous version of markup; you can see that the syntax is slightly different from what we have in JEP today. It's good that you asked this question, because this piece is outdated.

Although the markup syntax has changed, the idea for the test remained: there has to be a way to produce a snippet that showcases markup. I will have to implement that idea.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 22:12:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 22:12:34 GMT
Subject: RFR: 8266666: Implementation for snippets [v14]
In-Reply-To: <QrB0qoVRM9vvaYb7QAVBZGj-EkkksCod3fUDhhAWwKI=.65645bc1-606c-45cc-95ae-1992f2eb4209@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <QrB0qoVRM9vvaYb7QAVBZGj-EkkksCod3fUDhhAWwKI=.65645bc1-606c-45cc-95ae-1992f2eb4209@github.com>
Message-ID: <4Q-TLoinrffkDvPKnmpo9478OEe8ZqDNErClMKXml6Q=.34c649f6-28fb-480a-8b5b-b10f3fdc66c0@github.com>

On Tue, 24 Aug 2021 17:46:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into 8266666
>    
>    This merge is to promptly resolve a conflict in src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java.
>  - Clarify the attributes order comment
>  - Fix import layout and typos
>  - Add @summary to tests
>    
>    From https://openjdk.java.net/jtreg/faq.html:
>    
>    The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates.
>    
>    That said, the JBS synopsis for 8266666 suits those tests just fine.
>  - Remove superfluous editor-fold
>  - Remove JEP link from SnippetTree
>  - Merge branch 'master' into 8266666
>  - Pass through FIXMEs and TODOs
>    
>    Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
>  - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
>    
>    Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
>  - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
>    
>    Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/d34f17c6...4c5e92b7

Heads-up: the recent merge 4c5e92b from openjdk:master seems faulty. It fails a test and reports unexpected entries in this PR's "Files changed" tab. Because that merge is the most recent commit in the PR branch, instead of carefully repairing the history with a revert and remerge, I will force push a correct merge. Apologies for any noise or inconvenience.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 22:22:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 22:22:34 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
Message-ID: <eoWwTPqiuAsunj2xoUdaUqgTq4bVFG6XtUFgfEdiVjU=.3df6f10d-cb38-43a7-8d77-c9c3ab263fbc@github.com>

On Tue, 24 Aug 2021 21:56:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> > @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.)
> 
> It doesn't seem worth a release note ... we're just using the tree in more places ... but it wouldn't be wrong to create one ... after all, I guess we did have to change doclint to accommodate the new usage.

Look at it this way. Previously, if you had an instance of `AttributeTree`, you could be sure that it belonged to an instance of `StartElementTree`. After this PR has been merged, this will no longer be the case. I think that this fact should be recorded somewhere besides the API itself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Aug 24 22:26:48 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Aug 2021 22:26:48 GMT
Subject: RFR: 8266666: Implementation for snippets [v15]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <lQeF9uraLzftdPH6a_tLVcPi-jKUBayHUkRhCiOSNR8=.369760f4-6e33-48c0-9e8b-cba725510731@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into 8266666
   
   Redoing a faulty merge and pushing the result forcefully.
 - Clarify the attributes order comment
 - Fix import layout and typos
 - Add @summary to tests
   
   From https://openjdk.java.net/jtreg/faq.html:
   
   The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates.
   
   That said, the JBS synopsis for 8266666 suits those tests just fine.
 - Remove superfluous editor-fold
 - Remove JEP link from SnippetTree
 - Merge branch 'master' into 8266666
 - Pass through FIXMEs and TODOs
   
   Downgrades FIXMEs that do not mark *feature issues* to TODOs, or removes those FIXMEs completely. For example, unlike Style hierarchy, Action hierarchy won't benefit from becoming sealed. So the respective FIXME is removed.
 - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
   
   Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
 - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
   
   Co-authored-by: Hannes Wallnoefer <hannesw at gmail.com>
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/b17b821a...be7ffe5b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=14
  Stats: 4713 lines in 44 files changed: 4686 ins; 4 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From github.com+223869+mryan43 at openjdk.java.net  Wed Aug 25 13:52:23 2021
From: github.com+223869+mryan43 at openjdk.java.net (Manuel Ryan)
Date: Wed, 25 Aug 2021 13:52:23 GMT
Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at
 jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671)
In-Reply-To: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
References: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
Message-ID: <jY-7596H6c4Ex4im23x9y48SURUVYYXy3iD4ObWI2Dk=.62b5d150-aeb1-42bf-9cfe-4ba5d1eaf80e@github.com>

On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs.
> 
> The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same.
> 
> This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method  `TypeAnnotationPosition.updatePosOffset` and add a corresponding test.
> 
> ---
> Steps to reproduce the issue:
> 
> 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details.
> 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details.
> 3. Then the crash occurs.
> 
> Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position.
> 
> The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler.
> 
> ---
> A brief history:
> 
> According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) .
> 
> Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`.
> 
> The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array.
> 
> But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs.
> 
> Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. 
> 
> ---
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This is still preventing me to upgrade from 11 to 15. Please don't let this issue be automatically deleted because of inactivity.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4749

From jonathan.gibbons at oracle.com  Wed Aug 25 15:49:10 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 25 Aug 2021 08:49:10 -0700
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <NKPikVf4msYmfEWaNQuh-qcSZ5bQ8RrS509ddpMXeNw=.5d7cd974-f406-48ad-8cc3-b649f0c33491@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <NKPikVf4msYmfEWaNQuh-qcSZ5bQ8RrS509ddpMXeNw=.5d7cd974-f406-48ad-8cc3-b649f0c33491@github.com>
Message-ID: <bee69479-9ab4-f369-dafe-6221ae39e3cf@oracle.com>


On 8/24/21 2:59 PM, Pavel Rappo wrote:
> Both the commented-out code and its description are from a previous version of markup; you can see that the syntax is slightly different from what we have in JEP today. It's good that you asked this question, because this piece is outdated.
>
> Although the markup syntax has changed, the idea for the test remained: there has to be a way to produce a snippet that showcases markup. I will have to implement that idea.


OK, I see that the markup is potentially an issue. Does it help that 
markup uses the last instance of `//` ... meaning you could protect 
markup that should not be interpreted with an additional trailing `//` 
(possibly including a "dummy" markup tag?)

-- Jon


From prappo at openjdk.java.net  Wed Aug 25 16:00:08 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 16:00:08 GMT
Subject: RFR: 8266666: Implementation for snippets [v16]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <dhl5FfSX3vWJANDa5wnLKgSOgoiIftXG9UUeY27dZIM=.be5e5f30-e6b7-4944-844a-638368213b50@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Format code closer to the ambient style
  
  Makes new constructs look more natural in their context by adopting the surrounding style.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/be7ffe5b..6c33cb6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Aug 25 16:16:00 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 16:16:00 GMT
Subject: RFR: 8266666: Implementation for snippets [v16]
In-Reply-To: <dhl5FfSX3vWJANDa5wnLKgSOgoiIftXG9UUeY27dZIM=.be5e5f30-e6b7-4944-844a-638368213b50@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <dhl5FfSX3vWJANDa5wnLKgSOgoiIftXG9UUeY27dZIM=.be5e5f30-e6b7-4944-844a-638368213b50@github.com>
Message-ID: <xnnM14F4rW3lg3QsmSL68ew7Ng5sksi5XVbHgftcyfw=.94983f28-7538-4a30-af5f-cca9a5b0a213@github.com>

On Wed, 25 Aug 2021 16:00:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format code closer to the ambient style
>   
>   Makes new constructs look more natural in their context by adopting the surrounding style.

Apologies for the recent series of consecutive force pushes. I had muddled the history with two commits before figured out that my IDE was reformatting doc comments behind my back. Every time I formatted the doc comment, the IDE reformatted it immediately before committing the change to the repo. I've configured the IDE not to do it from now on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Aug 25 16:15:57 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 16:15:57 GMT
Subject: RFR: 8266666: Implementation for snippets [v17]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <TJyQWZvPey5BOd1Gc3F7Wz8bW02ayYt6lHjqPQLUyyk=.d3832ec7-ab45-4d78-ae79-ccfddc409019@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Format code closer to the ambient style
  
  Makes new constructs look more natural in their context by adopting the surrounding style.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/6c33cb6a..9ab2cbdd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Aug 25 16:21:55 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 16:21:55 GMT
Subject: RFR: 8266666: Implementation for snippets [v18]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <Y6lmwI-YlP7eSnGAtu4nIGc8wCpJp23ovMLVbNMSlIs=.343fd6af-3a10-4cb8-baae-3ee1d3e333f0@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Format code closer to the ambient style
  
  Makes new constructs look more natural in their context by adopting the surrounding style.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/9ab2cbdd..87e765b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=16-17

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Aug 25 17:09:58 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 17:09:58 GMT
Subject: RFR: 8266666: Implementation for snippets [v19]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <BKbgaMabuiLBQ-61VYCie5mHhAzPdtStYfdSU9N-Q0w=.c439de4a-341a-4186-a08e-414079c82336@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Recover from a sloppy merge
  
  Apparently, I've performed at least one sloppy merge while developing the feature in sandbox. As a result, some changes brought by e4d045402fa1992a1d91586bd4f67362d07f543c were discarded. The specdiff for the CSR actually shows this and has to be regenerated.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/87e765b0..0d9c53a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=17-18

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From vromero at openjdk.java.net  Wed Aug 25 20:05:25 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 25 Aug 2021 20:05:25 GMT
Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at
 jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671)
In-Reply-To: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
References: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
Message-ID: <9RihaG2Ggia1hQLdq2a82g1X4vKkmH7kUZRufadWzz4=.c64d61bc-089c-492b-a99b-92356d32a946@github.com>

On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs.
> 
> The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same.
> 
> This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method  `TypeAnnotationPosition.updatePosOffset` and add a corresponding test.
> 
> ---
> Steps to reproduce the issue:
> 
> 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details.
> 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details.
> 3. Then the crash occurs.
> 
> Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position.
> 
> The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler.
> 
> ---
> A brief history:
> 
> According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) .
> 
> Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`.
> 
> The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array.
> 
> But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs.
> 
> Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. 
> 
> ---
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

from your description it seems like the bug is more on the lombok side than in javac's, if I understand correctly you are saying that the bug is provoked by lombok because it is not generating completely correct ASTs right?, it could be that we need to make sure that the 3 arrays are in sync before generating the class file, but still the information in `lvarOffset` seems to be used so not generating it doesn't seem like the best option. Please let me know if I'm missing something

-------------

PR: https://git.openjdk.java.net/jdk/pull/4749

From prappo at openjdk.java.net  Wed Aug 25 21:15:35 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 21:15:35 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
Message-ID: <AW1onB1aO2vgsPv4wJxW_g91agtxmMsPsUkpHepeq9w=.8132126a-6565-433f-9244-f2f3b2d56165@github.com>

On Tue, 24 Aug 2021 21:56:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Generally impressive piece of work.
>
>> @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.)
> 
> It doesn't seem worth a release note ... we're just using the tree in more places ... but it wouldn't be wrong to create one ... after all, I guess we did have to change doclint to accommodate the new usage.

@jonathan-gibbons, I'm currently cleaning up this PR of unrelated changes. What would you say if I ask you to extract this change of yours into a separate cleanup PR while I delete it from this PR?

https://github.com/openjdk/jdk-sandbox/commit/405c89c35076e73daf7b38d5a20ae83075fb8ae1#diff-e7650e24c581f8df74f8d2bc24110c15c22fd32308f690fba0349c7170f320dfR495-R499

Adding `tagletpath.parameters` and changing `tagletpath.description` has value, but I think you would agree that it's unrelated to snippets.

Separately, when extracting the diff note that that change is a bit inconsistent: while you changed the resource value to `The path for custom taglets`, the option doc comment still refers to `The path to Taglets`: https://github.com/openjdk/jdk-sandbox/blob/405c89c35076e73daf7b38d5a20ae83075fb8ae1/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L268

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Wed Aug 25 21:53:30 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 25 Aug 2021 21:53:30 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
Message-ID: <BBLT_jRwzEKk5i1p4KqaYOhFecjWa1dIzkSCQ9jdhi0=.197090cd-470a-4b35-9ad8-4eeeef753393@github.com>

On Tue, 24 Aug 2021 21:56:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Generally impressive piece of work.
>
>> @jonathan-gibbons, do we need to mention the semantic change to `com.sun.source.doctree.AttributeTree` in the release notes? Before this PR, `AttributeTree` used to only represent HTML attributes. After this PR has been integrated, that interface will also represent attributes of the standard doclet tags. (Currently, the only such tag is `{@snippet}`.)
> 
> It doesn't seem worth a release note ... we're just using the tree in more places ... but it wouldn't be wrong to create one ... after all, I guess we did have to change doclint to accommodate the new usage.

> @jonathan-gibbons, I'm currently cleaning up this PR of unrelated changes. What would you say if I ask you to extract this change of yours into a separate cleanup PR while I delete it from this PR?
> 
> [openjdk/jdk-sandbox at 405c89c#diff-e7650e24c581f8df74f8d2bc24110c15c22fd32308f690fba0349c7170f320dfR495-R499](https://github.com/openjdk/jdk-sandbox/commit/405c89c35076e73daf7b38d5a20ae83075fb8ae1#diff-e7650e24c581f8df74f8d2bc24110c15c22fd32308f690fba0349c7170f320dfR495-R499)
> 
> Adding `tagletpath.parameters` and changing `tagletpath.description` has value, but I think you would agree that it's unrelated to snippets.
> 
> Separately, when extracting the diff note that that change is a bit inconsistent: while you changed the resource value to `The path for custom taglets`, the option doc comment still refers to `The path to Taglets`: https://github.com/openjdk/jdk-sandbox/blob/405c89c35076e73daf7b38d5a20ae83075fb8ae1/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L268

So you're just suggesting that I should handle the parts related to tagletPath, right?  If so, OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Aug 25 22:43:01 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 22:43:01 GMT
Subject: RFR: 8266666: Implementation for snippets [v20]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <ZwmfYwxFqtJRFcjUQq7q0bH2chVbiQ1Iql8suGIEj8Q=.fd1cb624-e9a0-4bef-a479-e15352f74067@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Exclude unrelated changes to resources
  
  Also fixes a typo.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/0d9c53a6..a473e9a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=18-19

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Aug 25 22:58:31 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Aug 2021 22:58:31 GMT
Subject: RFR: 8266666: Implementation for snippets [v7]
In-Reply-To: <BBLT_jRwzEKk5i1p4KqaYOhFecjWa1dIzkSCQ9jdhi0=.197090cd-470a-4b35-9ad8-4eeeef753393@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
 <sttAKEX2er6tBMYoElGK8b8m5rA0KkFlPtyNsGBGuw4=.72d6bef9-1cb7-4e4c-aa5d-78acb1a9e6a7@github.com>
 <rj52rD6XSTMbMX864487MsQXC78OqwQvoWAvXpTntJs=.c39e9522-5b41-446a-877d-f6e329955f56@github.com>
 <Th-1B_-MGbPpHryb-9t1qioxaoUnEjCCCxcTVEK-yb4=.dffe6e3a-0a32-43c8-862e-f38320730395@github.com>
 <BBLT_jRwzEKk5i1p4KqaYOhFecjWa1dIzkSCQ9jdhi0=.197090cd-470a-4b35-9ad8-4eeeef753393@github.com>
Message-ID: <FeRej90YVxE4AWz8U9LFuRgU0S-sMsIbGalYYmn8ynU=.834ac70d-1047-41cc-a039-5468bf2979ed@github.com>

On Wed, 25 Aug 2021 21:50:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> So you're just suggesting that I should handle the parts related to tagletPath, right? If so, OK.

Yes, I am. I have created a separate bug, where I suggested a patch: https://bugs.openjdk.java.net/browse/JDK-8273001

-------------

PR: https://git.openjdk.java.net/jdk/pull/4795

From gli at openjdk.java.net  Thu Aug 26 08:51:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 26 Aug 2021 08:51:30 GMT
Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at
 jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671)
In-Reply-To: <9RihaG2Ggia1hQLdq2a82g1X4vKkmH7kUZRufadWzz4=.c64d61bc-089c-492b-a99b-92356d32a946@github.com>
References: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
 <9RihaG2Ggia1hQLdq2a82g1X4vKkmH7kUZRufadWzz4=.c64d61bc-089c-492b-a99b-92356d32a946@github.com>
Message-ID: <ftkh5Q24e8TaXbNj1FfJJn4V3vTUmVp2O5j_TuaR11M=.def4b024-1e05-438a-85b6-9cd50424421d@github.com>

On Wed, 25 Aug 2021 20:00:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> from your description it seems like the bug is more on the lombok side than in javac's, if I understand correctly you are saying that the bug is provoked by lombok because it is not generating completely correct ASTs right

The lombok may need to be improved. But javac shouldn't crash at this situation. It should compile the sources successfully or report a related warning(maybe a new warning `Wrong Position`). Because the wrong source positions may only affect the positions of the errors or warnings and have not much impact to the syntax and semantics.

> but still the information in `lvarOffset` seems to be used so not generating it doesn't seem like the best option

I can't find a place that the variable `lvarOffset` is used individually without `lvarLength` and `lvarIndex`. I find the `lvarOffset` always be used like the following code. So we should generate or use `lvarOffset`, `lvarLength` and `lvarIndex` together and couldn't use or generate one of them individually.


// com.sun.tools.javac.jvm.ClassWriter
        case RESOURCE_VARIABLE:
            databuf.appendChar(p.lvarOffset.length);  // for table length
            for (int i = 0; i < p.lvarOffset.length; ++i) {
                databuf.appendChar(p.lvarOffset[i]);
                databuf.appendChar(p.lvarLength[i]);
                databuf.appendChar(p.lvarIndex[i]);
            }
            break;


@vicente-romero-oracle can you find the code that `lvarOffset` is used independently after `lvarOffset = new int[]{to};`? Or I am missing something, too.

>  it could be that we need to make sure that the 3 arrays are in sync before generating the class file

Good idea. But I still want to remove `lvarOffset = new int[]{to};` if we can comfirm it is redundant.
And maybe I can `sync before generating the class file` and remove `lvarOffset = new int[]{to};` at the same time to improve the code and prevent the wrong usage in the future.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4749

From serb at openjdk.java.net  Thu Aug 26 17:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 17:42:33 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644

Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From github.com+5709644+fdesu at openjdk.java.net  Thu Aug 26 18:33:27 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Thu, 26 Aug 2021 18:33:27 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <vjfSSXTwCTncHGyKQOw5M3cV_bCdmb89ZEFgZ8ggTkQ=.b617da20-0a0c-4b55-8011-184d1932e2aa@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

@mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are:
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
- src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java

would it make sense to go through them as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From serb at openjdk.java.net  Thu Aug 26 18:38:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 18:38:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <a97uQJLcPbeqHP6UVqNXMtqDq4bf4GytTvBLl4C5HPk=.3a50dcbe-d199-4df4-9af7-a94f7755bfe3@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

> @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. 
> would it make sense to go through them as well?

Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5210

From erikj at openjdk.java.net  Fri Aug 27 17:51:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 Aug 2021 17:51:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <LEmAelLl1suWas8ISeUc4p87XtgSBWwBTRPz5YSPguo=.6a717c6e-1d62-405e-9f65-2b2949f33c30@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644

Build tool change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5210

From vromero at openjdk.java.net  Fri Aug 27 20:35:28 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 27 Aug 2021 20:35:28 GMT
Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at
 jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671)
In-Reply-To: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
References: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
Message-ID: <YuRL7K1KWtvwyl36ArBdqdz_7sm-NkjrmplhliRGFzY=.a134fbf7-f515-406c-8b9c-cacf93a7e25c@github.com>

On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs.
> 
> The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same.
> 
> This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method  `TypeAnnotationPosition.updatePosOffset` and add a corresponding test.
> 
> ---
> Steps to reproduce the issue:
> 
> 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details.
> 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details.
> 3. Then the crash occurs.
> 
> Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position.
> 
> The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler.
> 
> ---
> A brief history:
> 
> According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) .
> 
> Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`.
> 
> The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array.
> 
> But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs.
> 
> Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. 
> 
> ---
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

looks good, thanks for the additional info. I also agree that javac shouldn't fail. I checked the code again and I think that you fix is good, thanks

please update the PR title with the last bug title: "8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition" or please sync both to another version you like better before pushing

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4749

From gli at openjdk.java.net  Sun Aug 29 06:39:47 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 29 Aug 2021 06:39:47 GMT
Subject: RFR: 8268894: forged ASTs can provoke an AIOOBE at
 com.sun.tools.javac.jvm.ClassWriter::writePosition
In-Reply-To: <YuRL7K1KWtvwyl36ArBdqdz_7sm-NkjrmplhliRGFzY=.a134fbf7-f515-406c-8b9c-cacf93a7e25c@github.com>
References: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
 <YuRL7K1KWtvwyl36ArBdqdz_7sm-NkjrmplhliRGFzY=.a134fbf7-f515-406c-8b9c-cacf93a7e25c@github.com>
Message-ID: <coEHd4fZj0jEOlkLNVMiONXx-b26eS8NO8nWUJjKh8k=.dd4402c1-a611-4ada-902a-7447a13f6c06@github.com>

On Fri, 27 Aug 2021 20:32:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs.
>> 
>> The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same.
>> 
>> This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method  `TypeAnnotationPosition.updatePosOffset` and add a corresponding test.
>> 
>> ---
>> Steps to reproduce the issue:
>> 
>> 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details.
>> 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details.
>> 3. Then the crash occurs.
>> 
>> Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position.
>> 
>> The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler.
>> 
>> ---
>> A brief history:
>> 
>> According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) .
>> 
>> Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`.
>> 
>> The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array.
>> 
>> But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs.
>> 
>> Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. 
>> 
>> ---
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> please update the PR title with the last bug title: "8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition" or please sync both to another version you like better before pushing

@vicente-romero-oracle Thanks for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4749

From gli at openjdk.java.net  Sun Aug 29 07:03:32 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 29 Aug 2021 07:03:32 GMT
Subject: RFR: 8266239: Some duplicated javac command-line options have
 repeated effect
In-Reply-To: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
References: <UJabUDvvY1kArtsHt37QwftXns9v2rtOFCIw4TCIxuE=.42a6643e-5385-42ed-b4f7-f91e8880a914@github.com>
Message-ID: <xtR8UrQnGNYYLJ64LPoZW02fsJcz7x2OAymsF8bZ_Xo=.a26f0252-371e-4735-872d-35deffbf1d46@github.com>

On Fri, 28 May 2021 12:29:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Some duplicated info options (`--version`, `--help`, `--help-extra`, `--help-lint`, `--full-version`) have repeated effect. Please see the following example.
> 
> 
> $ javac -version -version
> javac 17-internal
> javac 17-internal
> 
> 
> The patch fixes it and adds a corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

The CSR has been approved. Ping for review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4244

From gli at openjdk.java.net  Sun Aug 29 07:30:01 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sun, 29 Aug 2021 07:30:01 GMT
Subject: Integrated: 8268894: forged ASTs can provoke an AIOOBE at
 com.sun.tools.javac.jvm.ClassWriter::writePosition
In-Reply-To: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
References: <BW3VWgSEcX6icPKcnVwZMGuNcPQBAywckQdmhAx4RpE=.aab501c1-8afd-4d9a-9c3b-16a00a491f13@github.com>
Message-ID: <dPRGWE4HGOh65GSN26XQANt0fYSaEEWil4agXCc2yBw=.16d9f1a8-2833-46e4-8686-c62fbdc787e6@github.com>

On Sun, 11 Jul 2021 09:36:53 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs.
> 
> The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same.
> 
> This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method  `TypeAnnotationPosition.updatePosOffset` and add a corresponding test.
> 
> ---
> Steps to reproduce the issue:
> 
> 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details.
> 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details.
> 3. Then the crash occurs.
> 
> Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position.
> 
> The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler.
> 
> ---
> A brief history:
> 
> According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) .
> 
> Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`.
> 
> The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array.
> 
> But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs.
> 
> Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. 
> 
> ---
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: a9188f23
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a9188f237ec23d4ca2a172e9a7897cb6e2b69857
Stats:     134 lines in 3 files changed: 133 ins; 1 del; 0 mod

8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/4749

From attila.kelemen85 at gmail.com  Sun Aug 29 10:19:25 2021
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Sun, 29 Aug 2021 12:19:25 +0200
Subject: JEP 400 - UTF-8 by Default
Message-ID: <CAKDaPBd+jJKYp_5WPP1vqOMLFexHXd=0FeW68++f_ORJBHukDQ@mail.gmail.com>

Hi,

I have read the description of JEP 400, but it does not mention the default
source encoding. Will javac be changed as well?

Given that standard APIs change, it would be nice, since platform dependent
encoding was just a nuisance anyway, and (at least to me) seems a lot less
risky than the standard API change.

Thanks,
Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210829/5de84c54/attachment.htm>

From jan.lahoda at oracle.com  Mon Aug 30 08:17:27 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 30 Aug 2021 10:17:27 +0200
Subject: JEP 400 - UTF-8 by Default
In-Reply-To: <CAKDaPBd+jJKYp_5WPP1vqOMLFexHXd=0FeW68++f_ORJBHukDQ@mail.gmail.com>
References: <CAKDaPBd+jJKYp_5WPP1vqOMLFexHXd=0FeW68++f_ORJBHukDQ@mail.gmail.com>
Message-ID: <74dbf871-e6fe-5dce-600d-6a652f371ad8@oracle.com>

On 29. 08. 21 12:19, Attila Kelemen wrote:

> Hi,
>
> I have read the description of JEP 400, but it does not mention the 
> default source encoding. Will javac be changed as well?


As far as I can tell, the default encoding that javac itself uses is 
`Charset.defaultCharset().name()`. So I think that when 
`Charset.defaultCharset().name()` starts to return "UTF-8", javac will 
start to read the source files in the UTF-8 encoding, unless a different 
encoding is specified in a javac option, or unless the javac is invoked 
with a custom JavaFileManager which does the conversion on its own.


Jan


>
> Given that standard APIs change, it would be nice, since platform 
> dependent encoding was just a?nuisance anyway, and (at least to me) 
> seems a lot less risky than the standard API change.
>
> Thanks,
> Attila

From naoto.sato at oracle.com  Mon Aug 30 17:00:05 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 30 Aug 2021 10:00:05 -0700
Subject: JEP 400 - UTF-8 by Default
In-Reply-To: <74dbf871-e6fe-5dce-600d-6a652f371ad8@oracle.com>
References: <CAKDaPBd+jJKYp_5WPP1vqOMLFexHXd=0FeW68++f_ORJBHukDQ@mail.gmail.com>
 <74dbf871-e6fe-5dce-600d-6a652f371ad8@oracle.com>
Message-ID: <b93127b9-1a7e-a968-a325-8023aa3ba0ec@oracle.com>

Yes, that is correct.

As long as javac uses the default encoding from 
`Charset.defaultCharset()`, it will automatically use `UTF-8` as the 
default encoding for the input source files.

Naoto

On 8/30/21 1:17 AM, Jan Lahoda wrote:
> On 29. 08. 21 12:19, Attila Kelemen wrote:
> 
>> Hi,
>>
>> I have read the description of JEP 400, but it does not mention the 
>> default source encoding. Will javac be changed as well?
> 
> 
> As far as I can tell, the default encoding that javac itself uses is 
> `Charset.defaultCharset().name()`. So I think that when 
> `Charset.defaultCharset().name()` starts to return "UTF-8", javac will 
> start to read the source files in the UTF-8 encoding, unless a different 
> encoding is specified in a javac option, or unless the javac is invoked 
> with a custom JavaFileManager which does the conversion on its own.
> 
> 
> Jan
> 
> 
>>
>> Given that standard APIs change, it would be nice, since platform 
>> dependent encoding was just a?nuisance anyway, and (at least to me) 
>> seems a lot less risky than the standard API change.
>>
>> Thanks,
>> Attila

From vromero at openjdk.java.net  Mon Aug 30 18:16:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 30 Aug 2021 18:16:44 GMT
Subject: RFR: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke
 getThrownTypes because tree.meth.type is null
Message-ID: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>

Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. 

After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression.

Thanks,
Vicente

-------------

Commit messages:
 - 8262095: NPE in Flow.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null

Changes: https://git.openjdk.java.net/jdk/pull/5307/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5307&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262095
  Stats: 26 lines in 3 files changed: 25 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5307/head:pull/5307

PR: https://git.openjdk.java.net/jdk/pull/5307

From vromero at openjdk.java.net  Mon Aug 30 21:14:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 30 Aug 2021 21:14:31 GMT
Subject: RFR: 8268885: duplicate checkcast when destination type is not
 first type of intersection type
In-Reply-To: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
References: <C9xnnNuWix0tt7UnKyIz_27hXTEpiZm7-j6J8P2FH1k=.ccc07ece-afd3-4e21-bf30-21f0dae82ffd@github.com>
Message-ID: <iAFrwU22sscD9dHTqUvIJkjA5cl7brpqW48k5P1FRAE=.e6563fae-2c51-466c-b74d-e5842b8f867e@github.com>

On Mon, 23 Aug 2021 23:29:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing the following bug: javac is generating duplicate checkcast for cases like:
> 
> 
> class IntersectionTypeTest {
>     interface I1 {}
>     interface I2 {}
>     static class C {}
>     void test() {
>         I2 i = (I1 & I2) new C();
>     }
> }
> 
> basically when an intersection type is used in a cast expression and the target is not the type in the intersection.
> 
> TIA
> 
> PS. I also ran the JCK tests for this patch, same results as without the patch

ping

-------------

PR: https://git.openjdk.java.net/jdk/pull/5235

From vromero at openjdk.java.net  Mon Aug 30 21:46:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 30 Aug 2021 21:46:32 GMT
Subject: RFR: 8268148: unchecked warnings handle ? and ? extends Object
 differently
In-Reply-To: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
References: <zrxvGY6EbCbIbtxUWd4VwFGtgNI7xA-rdc0DJ5qhqo8=.77a759e8-87d4-47ab-a00e-844f799d16cd@github.com>
Message-ID: <bLTveexdokN3Geak4SiQv529mkMbF57P7ByamXdJ_iI=.1478ffd7-ed7c-46a3-a1c9-c4772c7213ed@github.com>

On Mon, 23 Aug 2021 16:17:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR. Currently javac handles differently `?` and `? extends Object` when reporting unchecked warnings when according to the spec they should be handled the same way. This PR is fixing this.
> 
> TIA

ping

-------------

PR: https://git.openjdk.java.net/jdk/pull/5224

From serb at openjdk.java.net  Mon Aug 30 23:46:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Aug 2021 23:46:15 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v3]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <TqRtp_210_WAMsWmEo00_0RH7ZdcoPgWKC0f5bt0YMQ=.a0f183a7-969d-4601-940e-d8a9558bddee@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01-02

  Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

PR: https://git.openjdk.java.net/jdk/pull/5210

From darcy at openjdk.java.net  Tue Aug 31 05:15:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 31 Aug 2021 05:15:46 GMT
Subject: RFR: 8273157: Add convenience methods to Messager
Message-ID: <2110DPlELadese0h1e8tBUHZ4uL0nWyCz16GcfYZkM0=.f52f5de8-f3ff-4149-810b-6a95a54230f6@github.com>

Hello,

Please review the addition of a half dozen convenience methods to Messager to allow code like

    m.printError("Error message")

rather than

    m.printMessage(Kind.ERROR, "Error message")

For each of notes, warnings, and errors, two methods are added: one taking a message, the second taking a message and an element. There are other overloads of the printMessage method with additional arguments, but they are less commonly used and weren't judged to merit dedicated convenience methods.

The changeset also refactors ~125 of ~150 call sites of printMessage in the langtools regression tests to use the new methods. The updated tests (or tests using the updated files) all pass. I became more convinced of the utility of the new methods after using them in the refactoring.

I'll run a script to update the copyright years before any integration.

CSR for review: https://bugs.openjdk.java.net/browse/JDK-8273160

-------------

Commit messages:
 - 8273157

Changes: https://git.openjdk.java.net/jdk/pull/5309/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5309&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273157
  Stats: 297 lines in 85 files changed: 88 ins; 30 del; 179 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5309/head:pull/5309

PR: https://git.openjdk.java.net/jdk/pull/5309

From jlahoda at openjdk.java.net  Tue Aug 31 07:32:39 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 Aug 2021 07:32:39 GMT
Subject: RFR: 8272776: NullPointerException not reported
Message-ID: <4Fld7kLSi-ib_IkmeS04RUU7RFt-Trb9oZ2If5D3FJc=.2a82a5e1-d68e-4062-ad41-94e3ee5e4a74@github.com>

Code like:

public void foo(Object o) {
        switch (o) {
          default: break;
          case String s :System.out.println(s); break;
        } 
}
public static void main(String[] args) {
        (new X()).foo(null); // NPE expected, but prints null
}


Should lead to a NPE when executed, because `default` does not cover `null` and there is no total pattern in the switch, but the NPE is not thrown. The reason is that when generating the code, a `hasTotalPattern` flag is used, which means "has a total pattern or default". The code needs to check whether there is a real total pattern (which covers `null`) or not. That is done by looking for the `default` case label, but the code only checks the last case for `default`. It needs to check all cases to differentiate between a switch with a real total pattern and a switch with a `default`.

-------------

Commit messages:
 - 8272776: NullPointerException not reported

Changes: https://git.openjdk.java.net/jdk/pull/5312/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5312&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272776
  Stats: 18 lines in 2 files changed: 14 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5312.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5312/head:pull/5312

PR: https://git.openjdk.java.net/jdk/pull/5312

From prappo at openjdk.java.net  Tue Aug 31 12:16:47 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 31 Aug 2021 12:16:47 GMT
Subject: RFR: 8266666: Implementation for snippets [v21]
In-Reply-To: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
References: <CY9Wn1HaWAEIQIj7vhgaAbCbSKSWdas50tzE7c8QqEA=.f3d14ccf-1421-4242-85ab-98f7262a7ca5@github.com>
Message-ID: <n1dGvv5VX_Pj9rvr1tsw8jte7jXjKPJGhfVPmcDjmS0=.5f9cdbd5-d6f5-4fed-bf14-66a36793e3f8@github.com>

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8266666
 - Clean up tag parsing
   
   Removes two methods from an older implementation where HTML and javadoc tag attributes were modelled by different DocTree subtypes. Moves the `tagAttrs` method to TagParser responsible for parsing `@snippet` because `:` attribute terminator is specific to `@snippet`. Makes parser stop on `:`. Removes chatty discussion comments from code as suggested by Jonathan Gibbons.
 - Exclude unrelated changes to resources
   
   Also fixes a typo.
 - Recover from a sloppy merge
   
   Apparently, I've performed at least one sloppy merge while developing the feature in sandbox. As a result, some changes brought by e4d045402fa1992a1d91586bd4f67362d07f543c were discarded. The specdiff for the CSR actually shows this and has to be regenerated.
 - Format code closer to the ambient style
   
   Makes new constructs look more natural in their context by adopting the surrounding style.
 - Merge branch 'master' into 8266666
   
   Redoing a faulty merge and pushing the result forcefully.
 - Clarify the attributes order comment
 - Fix import layout and typos
 - Add @summary to tests
   
   From https://openjdk.java.net/jtreg/faq.html:
   
   The @summary tag describes the condition that is checked by the test. It is especially useful for non-regression tests, which by definition don't have bug numbers, but even if there's a bug number it's helpful to include a summary. Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates.
   
   That said, the JBS synopsis for 8266666 suits those tests just fine.
 - Remove superfluous editor-fold
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5185dbde...b2b604fb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=20
  Stats: 4657 lines in 44 files changed: 4631 ins; 4 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From jlahoda at openjdk.java.net  Tue Aug 31 15:09:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 Aug 2021 15:09:28 GMT
Subject: RFR: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke
 getThrownTypes because tree.meth.type is null
In-Reply-To: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>
References: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>
Message-ID: <tC6kwZhBvrl2PlDJ-JRSNsmoS_VOvzcLNGfKt8HB0fk=.2e716770-3397-40a0-800a-4c17ffd3bd96@github.com>

On Mon, 30 Aug 2021 18:08:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. 
> 
> After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression.
> 
> Thanks,
> Vicente

Seems sensible to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5307

From vromero at openjdk.java.net  Tue Aug 31 15:26:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 31 Aug 2021 15:26:26 GMT
Subject: RFR: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke
 getThrownTypes because tree.meth.type is null
In-Reply-To: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>
References: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>
Message-ID: <IPaAE1CEm85a0jLDd7m5s1Pcdqe1tSZuei8KfJvkXM0=.cdbb04a3-94c4-4977-860a-10b5e1850bbd@github.com>

On Mon, 30 Aug 2021 18:08:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. 
> 
> After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression.
> 
> Thanks,
> Vicente

thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/5307

From vromero at openjdk.java.net  Tue Aug 31 15:43:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 31 Aug 2021 15:43:33 GMT
Subject: Integrated: 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot
 invoke getThrownTypes because tree.meth.type is null
In-Reply-To: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>
References: <WNW02yNByg-RZTJb9knGVGarxcGaOvCIc0V-GPnVPaQ=.aa356334-4101-4305-b1fc-27c1ddae1f36@github.com>
Message-ID: <vjO5m3zleJIXL5SKDt7qeRviVAn6UktkE3sddC4wdvM=.98f82c44-369a-4ef7-a144-05c51786a6fc@github.com>

On Mon, 30 Aug 2021 18:08:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is not filtering errors for cases when the error is reported in a lambda expression. Before the fix for [JDK-8205418](https://bugs.openjdk.java.net/browse/JDK-8205418) javac was a bit more aggressive reporting errors found during recovery. 
> 
> After the fix mentioned above, the intention was to try to generate better error messages by attributing deferred nodes with more precise targets. But for some cases like the one reported in the bug entry, javac would swallow the error report. This fix is just reporting the errors right away if its position is a lambda expression.
> 
> Thanks,
> Vicente

This pull request has now been integrated.

Changeset: 75d987a0
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/75d987a0dd6f8cc41808f7ba566e914817e465dc
Stats:     26 lines in 3 files changed: 25 ins; 0 del; 1 mod

8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Vicente Romero <vromero at openjdk.org>
Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/5307

From mullan at openjdk.java.net  Tue Aug 31 19:03:46 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 31 Aug 2021 19:03:46 GMT
Subject: RFR: 8269039: Disable SHA-1 Signed JARs
Message-ID: <J4MCUoSBhLUtzL7BAQ2dy_x7xuiT29TedRY8i2Ix-tY=.afd81721-2fcb-4688-b9e4-16c8be021398@github.com>

This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155.

Some additional notes about the fix:

- This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows:
    - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive.
    - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications  using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint.
 - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue.
 - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms.

-------------

Commit messages:
 - Fix trailing whitespace.
 - Initial revision.

Changes: https://git.openjdk.java.net/jdk/pull/5320/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5320&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269039
  Stats: 643 lines in 27 files changed: 301 ins; 214 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5320/head:pull/5320

PR: https://git.openjdk.java.net/jdk/pull/5320

From serb at openjdk.java.net  Tue Aug 31 20:16:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:16:43 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <uq5KBwVStP5yT1Qu-wOx_RkCg1RTa6qMjDn2rLpwLpg=.efeffb26-2d1f-4f91-bab8-93ebd9838106@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

Any volunteers to take a look at the tests update?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5098

From serb at openjdk.java.net  Tue Aug 31 20:17:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:17:25 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v4]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=02-03

  Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

PR: https://git.openjdk.java.net/jdk/pull/5210

From forax at univ-mlv.fr  Tue Aug 31 21:46:43 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 31 Aug 2021 23:46:43 +0200 (CEST)
Subject: JShell does not recognize "non-sealed" as a keyword at top level
Message-ID: <625284020.968439.1630446403486.JavaMail.zimbra@u-pem.fr>

Hi all,
this code does not work in JShell.

sealed interface Component permits Label, Button, Canvas {}
record Label(String name) implements Component {}
final class Button implements Component {}
non-sealed class Canvas implements Component {}

We had a very similar bug with "sealed" not a long ago :(

regards,
R?mi