From mbaesken at openjdk.org  Thu Sep  5 13:54:02 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Sep 2024 13:54:02 GMT
Subject: RFR: 8339591: Mark jdk/jshell/ExceptionMessageTest.java intermittent
Message-ID: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>

We see a number of intermittent errors in test jdk/jshell/ExceptionMessageTest.java , so it would be beneficial to mark the test intermittent.
[JDK-8184445](https://bugs.openjdk.org/browse/JDK-8184445)  might later deal with some of those issues currently causing test failures.

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

Commit messages:
 - JDK-8339591

Changes: https://git.openjdk.org/jdk/pull/20870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339591
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20870/head:pull/20870

PR: https://git.openjdk.org/jdk/pull/20870

From prappo at openjdk.org  Thu Sep  5 21:53:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Sep 2024 21:53:58 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
Message-ID: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>

This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:

  - [JLS]
  - [JVMS]

Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.

[issues]: https://bugs.openjdk.org/browse/JDK-8339558
[JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
[JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20879/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339631
  Stats: 37 lines in 21 files changed: 0 ins; 0 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/20879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20879/head:pull/20879

PR: https://git.openjdk.org/jdk/pull/20879

From darcy at openjdk.org  Thu Sep  5 21:53:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Sep 2024 21:53:59 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <5ZAsYJjpuLQrxcpRMOY3h8H_IpO7tgAmczbmoIVkYts=.089531e7-6b14-4dd4-9395-ae7afc1cafbb@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

Looks fine; thanks.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2284138298

From jjg at openjdk.org  Thu Sep  5 22:04:49 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 5 Sep 2024 22:04:49 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2284150971

From liach at openjdk.org  Thu Sep  5 22:10:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Sep 2024 22:10:48 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
Message-ID: <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>

On Thu, 5 Sep 2024 22:01:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`

For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch does not wrap `instanceof` in a code tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2332713929

From prappo at openjdk.org  Thu Sep  5 22:17:48 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Sep 2024 22:17:48 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <6Wo4aRZTzGB7uAQpabk4DeRZJQkzHoCn9Gx3JVIEPb8=.10ad1cf7-2e3f-434f-b8c1-2ae1b168da09@github.com>
 <J2E7Llmf7xOUywyB7a3rZniUl6WoiofU0s4PJPdXCok=.7d14af84-aa14-45e0-94fa-3c51062988bf@github.com>
Message-ID: <-j2KsqOYz6TMGTQ1j6CS3fp7azbiNXcXIaFrvnwX32c=.5cd321a0-d4f0-4187-b635-ab10be5782e0@github.com>

On Thu, 5 Sep 2024 22:08:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> > possibly for later, a separate pass might be to review and make consistent the use of `{@code }` in the tags, such as in `The ... Attribute`
> 
> 
> 
> For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch does not wrap `instanceof` in a code tag.

Typography issues are less severe than those fixed in this PR, but I can fix them too.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2332721312

From prappo at openjdk.org  Fri Sep  6 09:16:28 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 09:16:28 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

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

  Link to 8.1.3 instead of 8.5.1
  
  8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
  Alternatively, the link can be deleted altogether.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20879/files
  - new: https://git.openjdk.org/jdk/pull/20879/files/51ffa5ee..2c3d47aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/20879

From prappo at openjdk.org  Fri Sep  6 12:11:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 6 Sep 2024 12:11:49 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

I understand that a PR might not be the best place for a comment like this. Still, it's highly relevant to the review feedback I've got so far. Also, a PR comment will be seen by more people sooner than a JBS comment. This is by the virtue of being fanned out by the mailing lists.

Some reviewers suggested fixing the typography. I could do it, but I think it will pay us more if we pause and think what the broken typography tells us, which I think is that the design of these tags is not entirely what it should be. 

Currently, these tags are really a specialised form of `@see` and `@linkplain`. The block variant corresponds to `@see` and the inline variant corresponds to `@linkplain`.

Since the tag links to a specific resource, it saves the documentation author keystrokes on typing the link to that resource. Along with the visual consistency of the generated documentation, the author also gets some integrity: the tag links to the same version of the specification as that of the documentation.

Unfortunately, mismatching versions is not the only source of broken integrity. Even if initially the tag is accurate, it may degrade over time by various means. This PR is a good evidence that specification sections can be reordered and that their text can be changed. The problem is not the degradation per se, but that it stays unnoticed indefinitely.

In similar situations, we use external checkers as a post-build documentation test. While it's much better than nothing and is more flexible than changing the tags, failing tests are prone to stay problem-listed indefinitely. Which gets us back to square one.

If like me you think that a broken or irrelevant link is bad, we could make these tags provide more integrity. The tags could check their contents against the actual specification and report an error if the contents are not the same (subject to some typographic and formatting leeway). As for the visual consistency, the tags could also make sure the text they generate is of a particular form by automatically carrying over (some) typography from the specification to the generated documentation.

In my mind, this will require having (an extract from) the specification accessible to the tag. Because build system don't typically have access to the Internet, the specification could be stored in the repo and updated every release, which happens every 6 months.

One problem though is what to do when (not if) a spec is not up-to-date. For example, consider these `@jls` tags in JDK 23:

    package java.lang.runtime;
       ...
     * @jls 5.7.1 Exact Testing Conversions
     * @jls 5.7.2 Unconditionally Exact Testing Conversions
       ...
     * @since 23
     */
    public final class ExactConversionsSupport {

These tags relate to a preview feature, which is documented not in JLS but in an annex to it, which is currently missing due to a build error. If the tags are to strictly check their integrity, a problem like this would prevent a documentation build.

Thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2333914768

From lucy at openjdk.org  Fri Sep  6 12:53:51 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 6 Sep 2024 12:53:51 GMT
Subject: RFR: 8339591: Mark jdk/jshell/ExceptionMessageTest.java
 intermittent
In-Reply-To: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>
References: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>
Message-ID: <1qYjkGsqqViuTYlCGTT1hGMV-QpOltxuI1LYtPVyh2Q=.f1f62b65-6386-4716-a7a7-d5d1f3afd4c9@github.com>

On Thu, 5 Sep 2024 13:49:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see a number of intermittent errors in test jdk/jshell/ExceptionMessageTest.java , so it would be beneficial to mark the test intermittent.
> [JDK-8184445](https://bugs.openjdk.org/browse/JDK-8184445)  might later deal with some of those issues currently causing test failures.

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20870#pullrequestreview-2286196150

From jjg at openjdk.org  Fri Sep  6 15:13:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 6 Sep 2024 15:13:04 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
 <ulciTMmGlEnWOPTa4ItNwyJysrTeqJRbVt5b-ng-XjI=.96d4f659-942c-4eca-ad65-145cd5aae437@github.com>
Message-ID: <0eesrQjIjIPQpmWyNkorSyQAWTCwWduwpfFHAnFdXTA=.ce7dcc1d-cbdc-4dcf-ac8f-85984a9713ab@github.com>

On Fri, 6 Sep 2024 12:09:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thoughts?

My initial thought is, at least we're working with specific tags (`@jls` and `@jvms`) rather than generic HTML links (`<a href=...>...</a>`), since that permits the kind of detailed analysis and checking you are doing.

Preview-ness is a pervasive feature of JDK these days, on the command-line and in APIs. Perhaps the tags here can be augmented to indicate that a feature is a preview feature, for example, `@jls preview 5.7.2 Unconditionally Exact Testing Conversions`. This could be used not only to affect the generated output, perhaps with <sup>PREVIEW</sup>, but could be used to help both determine the target for such links, and to review such links in subsequent releases. Such management should be part of the responsibilities of the preview-feature owner.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2334271942

From liach at openjdk.org  Fri Sep  6 16:04:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Sep 2024 16:04:11 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <04Yd7RQbg2OlP3ITFXQoioYo1SfsP8HwUTRejGUJKWM=.6ce414d0-b567-4a24-a066-bb4f5481c7b0@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

I think we can ignore the title style aspect for now; the key of these tags has always been to provide a correct link to the specs, so fixing trailing period or section number is more important.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2286639738

From mbaesken at openjdk.org  Mon Sep  9 06:45:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Sep 2024 06:45:08 GMT
Subject: RFR: 8339591: Mark jdk/jshell/ExceptionMessageTest.java
 intermittent
In-Reply-To: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>
References: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>
Message-ID: <fZs6B317ciDupDqPdnIde_pMLwt_2Cn6MeFpKNYwzlk=.8b2fad23-aca1-4df7-95fb-0b805de8ed4a@github.com>

On Thu, 5 Sep 2024 13:49:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see a number of intermittent errors in test jdk/jshell/ExceptionMessageTest.java , so it would be beneficial to mark the test intermittent.
> [JDK-8184445](https://bugs.openjdk.org/browse/JDK-8184445)  might later deal with some of those issues currently causing test failures.

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/20870#issuecomment-2337254983

From mbaesken at openjdk.org  Mon Sep  9 06:45:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Sep 2024 06:45:08 GMT
Subject: Integrated: 8339591: Mark jdk/jshell/ExceptionMessageTest.java
 intermittent
In-Reply-To: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>
References: <aAidp7SlZvYkGemOX9SjJdYC64fLdWUO6155Mn6LwRo=.4fe04ecf-42af-4ad4-9a6a-0d181b210fd6@github.com>
Message-ID: <aK9yVZ_xhMK2MX3vtGg3YuFjlTmtAODptIJT2kEEfLQ=.7e28089c-2791-4497-805d-0e1beb5a8450@github.com>

On Thu, 5 Sep 2024 13:49:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see a number of intermittent errors in test jdk/jshell/ExceptionMessageTest.java , so it would be beneficial to mark the test intermittent.
> [JDK-8184445](https://bugs.openjdk.org/browse/JDK-8184445)  might later deal with some of those issues currently causing test failures.

This pull request has now been integrated.

Changeset: cb5c60b5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb5c60b530dd744e7d78ef69f15eef7521c4f1cc
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8339591: Mark jdk/jshell/ExceptionMessageTest.java intermittent

Reviewed-by: lucy

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

PR: https://git.openjdk.org/jdk/pull/20870

From prappo at openjdk.org  Mon Sep  9 09:19:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 09:19:38 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v3]
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

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

  Update copyright years
  
  Note: any commit hashes below might be outdated due to subsequent
  history rewriting (e.g. git rebase).
  
   + update src/java.base/share/classes/java/lang/ClassLoader.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/Record.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/StackWalker.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/reflect/AccessFlag.java due to 51ffa5ee21b
   + update src/java.base/share/classes/java/lang/reflect/InvocationHandler.java due to 51ffa5ee21b
   + update src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java due to 51ffa5ee21b
   + update src/java.compiler/share/classes/javax/lang/model/type/NullType.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java due to 2c3d47aad82
   + update src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java due to 51ffa5ee21b
   + update src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java due to 51ffa5ee21b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20879/files
  - new: https://git.openjdk.org/jdk/pull/20879/files/2c3d47aa..c9518c85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20879&range=01-02

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20879/head:pull/20879

PR: https://git.openjdk.org/jdk/pull/20879

From prappo at openjdk.org  Mon Sep  9 09:19:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 09:19:38 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v2]
In-Reply-To: <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <fn2frHMIHp84txoIhSiWKEOcFy8zRXWZYJt5wCTZqPQ=.1c637492-9640-4ee4-803f-10626517d698@github.com>
Message-ID: <w1Tp8gpthta4aiyckqPCgYBYT-d48cE7zYiIhtf6M38=.80190c3b-e495-4eef-a313-58da5ac99fe8@github.com>

On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Link to 8.1.3 instead of 8.5.1
>   
>   8.5.1 was removed in JDK 16. 8.1.3 seems an appropriate substitution.
>   Alternatively, the link can be deleted altogether.

Ugh... The most recent change to copyright years caused the bot to remove the "ready" label. Please re-review; thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20879#issuecomment-2337578863

From liach at openjdk.org  Mon Sep  9 12:09:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Sep 2024 12:09:06 GMT
Subject: RFR: 8339631: Fix block @jls and @jvms tags [v3]
In-Reply-To: <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
 <x9nRqO4apwchJsD0zBJunrK_fHvaNxFx-PRLRrpuzQI=.16ee325b-9ea3-42f1-9801-d0761c8a23a5@github.com>
Message-ID: <19ozWfaawKNwfzfhGYjnNfSB-S9SYGmPSvFYT5CRob0=.07c930ac-f9e7-4d38-81d3-3528608c5eb0@github.com>

On Mon, 9 Sep 2024 09:19:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
>> 
>>   - [JLS]
>>   - [JVMS]
>> 
>> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
>> 
>> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
>> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
>> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years
>   
>   Note: any commit hashes below might be outdated due to subsequent
>   history rewriting (e.g. git rebase).
>   
>    + update src/java.base/share/classes/java/lang/ClassLoader.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/Record.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/StackWalker.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/reflect/AccessFlag.java due to 51ffa5ee21b
>    + update src/java.base/share/classes/java/lang/reflect/InvocationHandler.java due to 51ffa5ee21b
>    + update src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java due to 51ffa5ee21b
>    + update src/java.compiler/share/classes/javax/lang/model/type/NullType.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java due to 2c3d47aad82
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java due to 51ffa5ee21b
>    + update src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java due to 51ffa5ee21b

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20879#pullrequestreview-2289709280

From prappo at openjdk.org  Mon Sep  9 12:09:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Sep 2024 12:09:07 GMT
Subject: Integrated: 8339631: Fix block @jls and @jvms tags
In-Reply-To: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
References: <o5_Aqbr3LIyfXY6HfmCckxxvSzZQokiwbebDHh8ogww=.c13d740c-606c-42ea-b6d6-b1a2bed65aa3@github.com>
Message-ID: <562NEVvPnRZm-wYVGCbsiMk1JR0xzN1BUOSQ1tlv2YU=.0c338c07-d988-4f94-b1d1-fcfd0736d13e@github.com>

On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes some of the recently discovered [issues] with the block variants of the specification tags. While reviewing, please check the proposed changes against the actual specifications. Since the specifications for JDK 23 are not yet available in the HTML format, you can use the specifications for JDK 22, which are reasonably up-to-date:
> 
>   - [JLS]
>   - [JVMS]
> 
> Note that this PR does NOT address any issues with the inline variants of the said tags. Those are harder to check. Even flagging suspicious tags requires a human. If you have some time, consider performing similar checks for inline `@jls` and `@jvms` tags in your area. Thanks.
> 
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/javase/specs/jvms/se22/html/index.html

This pull request has now been integrated.

Changeset: 88cccc14
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88cccc14db168876a60b5ea2ae9d0fda7969af9a
Stats:     54 lines in 22 files changed: 1 ins; 1 del; 52 mod

8339631: Fix block @jls and @jvms tags

Reviewed-by: liach, darcy, jjg

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

PR: https://git.openjdk.org/jdk/pull/20879

From sven.reimers at gmail.com  Wed Sep 25 14:26:51 2024
From: sven.reimers at gmail.com (Sven Reimers)
Date: Wed, 25 Sep 2024 17:26:51 +0300
Subject: sourceToSnippets and diagnostik information
Message-ID: <CAP+Jvx7XEmw3UHo8t6e1VY78_JbXm8J1f9-F8c3Lw6U=8oCe=Q@mail.gmail.com>

Hi,

I am working on a rich client Java Notebook using JShell in the backend.

Jan Lahoda suggested I could provide error information as the user types
code into a cell. We figured out, that all the information is there, but is
sitting behind a check, sono diagnostics are returned.

Could anyone shed some light on the problem?Is this as expected? Just some
nasty side effect?

Thanks

Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240925/8e30b0ba/attachment.htm>

From liach at openjdk.org  Wed Sep 25 17:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:03:18 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v2]
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <GKg-t65YV-Pwx_WUWaT5pFckkFNSUzheHIyquDvanME=.7a568491-5f13-4cb4-9fe4-5d3964429b0f@github.com>

> Please review this change that adds a new dynamic proxies implementation as hidden classes.
> 
> Summary:
> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

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

 - Flip flags, hidden is enabled only by choice
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - Missing changes to commit
 - Condense legacy and modern impl
 - Clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Cleanup...
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - Fixes
 - ... and 2 more: https://git.openjdk.org/jdk/compare/fb703258...16906bfb

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

Changes: https://git.openjdk.org/jdk/pull/19356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19356&range=01
  Stats: 82 lines in 6 files changed: 53 ins; 1 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/19356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19356/head:pull/19356

PR: https://git.openjdk.org/jdk/pull/19356

From liach at openjdk.org  Wed Sep 25 17:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:03:18 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <aZ9HstlDYKpub8B6r4sTh_If0VbSrHYKrEN4cdPJ5QI=.fc57d345-aad9-4698-a87c-d57c907cc862@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that adds a new dynamic proxies implementation as hidden classes.
> 
> Summary:
> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

Will have to rework since this is in conflict with #19410. Converting into draft for now.

This patch has been reworked. Now the new implementation is opt-in, which should allow for early adoption to ease the transition. Please review the associated CSR and release note as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2133466043
PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2374651015

From liach at openjdk.org  Wed Sep 25 17:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Sep 2024 17:03:18 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v2]
In-Reply-To: <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
Message-ID: <eOf79lY0E4SPdzlOpco7G-PEHWd0oyDHLt1fgnRSQyM=.16cf0758-36ef-4634-bc9c-acd4a23074c0@github.com>

On Mon, 27 May 2024 00:04:07 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Flip flags, hidden is enabled only by choice
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>>  - Missing changes to commit
>>  - Condense legacy and modern impl
>>  - Clean up
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>  - Cleanup...
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>>  - Fixes
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/fb703258...16906bfb
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 624:
> 
>> 622:             "true".equals(props.getProperty("jdk.disableSerialConstructorChecks"));
>> 623: 
>> 624:         useLegacyProxyImpl &= !useOldSerializableConstructor;
> 
> Suggestion:
> 
>         useLegacyProxyImpl |= useOldSerializableConstructor;

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1631392934

From jan.lahoda at oracle.com  Mon Sep 30 11:32:24 2024
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 30 Sep 2024 13:32:24 +0200
Subject: sourceToSnippets and diagnostik information
In-Reply-To: <CAP+Jvx7XEmw3UHo8t6e1VY78_JbXm8J1f9-F8c3Lw6U=8oCe=Q@mail.gmail.com>
References: <CAP+Jvx7XEmw3UHo8t6e1VY78_JbXm8J1f9-F8c3Lw6U=8oCe=Q@mail.gmail.com>
Message-ID: <3ec43822-c650-4ff5-b45f-1aaa28fcbe26@oracle.com>

Hi Sven,


I've filled this:
https://bugs.openjdk.org/browse/JDK-8341176


and opened a PR:
https://github.com/openjdk/jdk/pull/21261


Please let me know what you think.


Thanks for the report,

 ??? Jan


On 25. 09. 24 16:26, Sven Reimers wrote:
> Hi,
>
> I am working on a rich client Java Notebook using JShell in the backend.
>
> Jan Lahoda suggested I could provide error information as the user 
> types code into a cell. We figured out, that all the information is 
> there, but is sitting behind a check, sono diagnostics are returned.
>
> Could anyone shed some light on the problem?Is this as expected? Just 
> some nasty side effect?
>
> Thanks
>
> Sven

From jlahoda at openjdk.org  Mon Sep 30 11:36:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 30 Sep 2024 11:36:06 GMT
Subject: RFR: 8341176: Permit access to diagnostics for transient snippets
Message-ID: <jMe6RVqjj_5uG_2ggwNfw908tjctTYda03bpsPRbhXQ=.a3aa7969-1095-4cc9-8ff9-0ed1a5dd7be9@github.com>

JShell permits to create transient snippets using `SourceCodeAnalysis.sourceToSnippets`, for the purpose of alternative UI clients. But, the alternative UI clients might need to get the diagnostics for the snippets, but the existing `JShell.diagnostics(Snippet)` will not work for the transient snippets.

This patch proposes to enhance the `JShell.diagnostics(Snippet)` with an ability to return best-effort diagnostics for these transient snippets.

Please also review the CSR:
https://bugs.openjdk.org/browse/JDK-8341200

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

Commit messages:
 - Updating copyright years.
 - 8341176: Permit access to diagnostics for temporary snippets

Changes: https://git.openjdk.org/jdk/pull/21261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341176
  Stats: 91 lines in 4 files changed: 84 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21261/head:pull/21261

PR: https://git.openjdk.org/jdk/pull/21261

From sven.reimers at gmail.com  Mon Sep 30 15:33:12 2024
From: sven.reimers at gmail.com (Sven Reimers)
Date: Mon, 30 Sep 2024 18:33:12 +0300
Subject: sourceToSnippets and diagnostik information
In-Reply-To: <3ec43822-c650-4ff5-b45f-1aaa28fcbe26@oracle.com>
References: <CAP+Jvx7XEmw3UHo8t6e1VY78_JbXm8J1f9-F8c3Lw6U=8oCe=Q@mail.gmail.com>
 <3ec43822-c650-4ff5-b45f-1aaa28fcbe26@oracle.com>
Message-ID: <CAP+Jvx5xhLF3f5HvXtO=mbU1HHbnt_3bXYDKc78b+-p1yU9VRA@mail.gmail.com>

Hi Jan,

thanks for the fast response. Looks will try to do a custom openjdk build
to see if it works in my use case...

Sven

Jan Lahoda <jan.lahoda at oracle.com> schrieb am Mo., 30. Sept. 2024, 13:32:

> Hi Sven,
>
>
> I've filled this:
> https://bugs.openjdk.org/browse/JDK-8341176
>
>
> and opened a PR:
> https://github.com/openjdk/jdk/pull/21261
>
>
> Please let me know what you think.
>
>
> Thanks for the report,
>
>      Jan
>
>
> On 25. 09. 24 16:26, Sven Reimers wrote:
> > Hi,
> >
> > I am working on a rich client Java Notebook using JShell in the backend.
> >
> > Jan Lahoda suggested I could provide error information as the user
> > types code into a cell. We figured out, that all the information is
> > there, but is sitting behind a check, sono diagnostics are returned.
> >
> > Could anyone shed some light on the problem?Is this as expected? Just
> > some nasty side effect?
> >
> > Thanks
> >
> > Sven
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240930/28c9585c/attachment-0001.htm>