From numeralnathan at gmail.com  Sat Jul  2 16:41:15 2022
From: numeralnathan at gmail.com (Nathan Reynolds)
Date: Sat, 2 Jul 2022 10:41:15 -0600
Subject: Records for Annotation Values
Message-ID: <CALMUwcoHCQkg+yYrPr3zd4_h+PNKR0JpLKZ0iDkpHzSDRRQPRw@mail.gmail.com>

If I understand correctly, records are immutable.  Annotation values
require immutable values.  Can we allow records for annotation values?
What would be the problems with this?

For example, I would love for Duration to be made into a record and then
Duration can be put into an annotation.

@Retry(maxAttempts = 3, delay = Duration.ofSeconds(10))

... as opposed to what is required today ...

@Retry(maxAttempts = 3, delay = 10, durationUnit = ChronoUnit.SECONDS)  //
This is error prone because the value and units are separated and the
reader may make a mistake

If Duration, Instant, etc. hasn't been made into a record, I realize that
this might need to wait so that the classes evolve slowly.  Let's ignore
that possible constraint for this discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220702/71914ebd/attachment.htm>

From brian.goetz at oracle.com  Sat Jul  2 21:10:04 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 2 Jul 2022 21:10:04 +0000
Subject: Records for Annotation Values
In-Reply-To: <CALMUwcoHCQkg+yYrPr3zd4_h+PNKR0JpLKZ0iDkpHzSDRRQPRw@mail.gmail.com>
References: <CALMUwcoHCQkg+yYrPr3zd4_h+PNKR0JpLKZ0iDkpHzSDRRQPRw@mail.gmail.com>
Message-ID: <16CA3C44-59F7-4551-BCF5-186799A08ED7@oracle.com>

You?ve got the Causality backwards. Annotation values are immutable, but that doesn?t mean any immutable quantity can be an annotation value.  (And records aren?t even immutable, they are only shallowly immutable.)

Annotation values have much stricter constraints. They need to be constant pool constants, With the exception of several types that are part of the language and that have suitable classfile encodings.  An anno value can be a number, a string, a class, an enum constant, an annotation, or an array of one of these things.

A more apt example of something we might extend annotations to support is method references. They meet all the philosophical and practical requirements, as they are symbolic references to methods, but even this would still be a significant amount of work, because it touches the class file format, the VM, reflection, etc.  So I wouldn?t hold your breath for that either, but that?s a much more realistic possibility than arbitrary supposedly immutable objects.



Sent from my iPad

On Jul 2, 2022, at 12:41 PM, Nathan Reynolds <numeralnathan at gmail.com> wrote:

?
If I understand correctly, records are immutable.  Annotation values require immutable values.  Can we allow records for annotation values?  What would be the problems with this?

For example, I would love for Duration to be made into a record and then Duration can be put into an annotation.

@Retry(maxAttempts = 3, delay = Duration.ofSeconds(10))

... as opposed to what is required today ...

@Retry(maxAttempts = 3, delay = 10, durationUnit = ChronoUnit.SECONDS)  // This is error prone because the value and units are separated and the reader may make a mistake

If Duration, Instant, etc. hasn't been made into a record, I realize that this might need to wait so that the classes evolve slowly.  Let's ignore that possible constraint for this discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220702/45eee90c/attachment-0001.htm>

From hunor.szegi at gmail.com  Mon Jul  4 12:26:46 2022
From: hunor.szegi at gmail.com (Hunor Szegi)
Date: Mon, 4 Jul 2022 13:26:46 +0100
Subject: Keyword of the pattern guard
Message-ID: <CAJSbYaUcTEebu_Su6CHF89a3TKkevfRyqjZ3PmKtORMOXkGXLw@mail.gmail.com>

Hi all,

At the current proposal instead of the && guards a "when" keyword will be
used. I would like to ask isn't it possible to use the "if" keyword
instead? It would be shorter and perfectly matching to the role of a
pattern guard. Do we need a new keyword? (I guess it won't be a reserved
word, only a contextual keyword.)

Regards,
Hunor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220704/98d14cfd/attachment.htm>

From orionllmain at gmail.com  Mon Jul  4 19:50:37 2022
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Tue, 5 Jul 2022 01:50:37 +0600
Subject: Keyword of the pattern guard
In-Reply-To: <CAJSbYaUcTEebu_Su6CHF89a3TKkevfRyqjZ3PmKtORMOXkGXLw@mail.gmail.com>
References: <CAJSbYaUcTEebu_Su6CHF89a3TKkevfRyqjZ3PmKtORMOXkGXLw@mail.gmail.com>
Message-ID: <CAF2POUdaZTft8WeQKjQ+t5zYHFvREfZb9GdsXSA7wu8JJsjO1Q@mail.gmail.com>

https://mail.openjdk.org/pipermail/amber-dev/2022-March/007247.html

??, 5 ???. 2022 ?. ? 01:21, Hunor Szegi <hunor.szegi at gmail.com>:

> Hi all,
>
> At the current proposal instead of the && guards a "when" keyword will be
> used. I would like to ask isn't it possible to use the "if" keyword
> instead? It would be shorter and perfectly matching to the role of a
> pattern guard. Do we need a new keyword? (I guess it won't be a reserved
> word, only a contextual keyword.)
>
> Regards,
> Hunor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220705/0c9eb8d6/attachment.htm>

From some-java-user-99206970363698485155 at vodafonemail.de  Sun Jul 10 19:35:56 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Sun, 10 Jul 2022 21:35:56 +0200
Subject: Proposal: `finally` block exception suppression
Message-ID: <1ea9142d81b14c268b5b2de179dd6bed@vodafonemail.de>

This is not a formal JEP because I am not a OpenJDK member, and also because I would
still like to get some feedback on this proposal. But it would be great if you could
create a JEP if you consider this to be a useful proposal.
This proposal originated from https://mail.openjdk.org/pipermail/core-libs-dev/2022-April/089016.html
Thanks a lot already for David Holmes' initial feedback.


# Summary

Add automatic exception suppression when exceptions are thrown by `finally` blocks
to preserve exceptions which occurred in `try` or `catch` blocks.


# Description

If exception E1 causes a `finally` block to be executed and the `finally` block is exited due
to a thrown exception E2 (E2 may be the same as E1), then E1 is added as suppressed exception
to E2.

E1 can be an exception which occurred in the `try` block, or any of the `catch` blocks.

This requires only changes in the compiler, the language reference and the tests.
The language grammar is not affected.

The behavior would be the same as the one shown by this code, where every line prefixed
with # would be the code generated by the compiler:
```
# Throwable e1 = null;
try {
    # try {
        ... // content of try block
    # } catch (Throwable t) {
    #    e1 = t;
    #    throw e1;
    # }
} catch (...) {
    # e1 = null;
    # try {
        ... // content of catch block
    # } catch (Throwable t) {
    #    e1 = t;
    #    throw e1;
    # }
} finally {
    # try {
        ... // content of finally block
    # } catch (Throwable e2) {
    #    if (e1 != null) {
    #        e2.addSuppressed(e1);
    #    }
    #    throw e2;
    # }
}
```


# Rationale

Despite the existence of the try-with-resources statement which properly handles exception
suppression, there are still situations where a regular try-(catch-)finally statement has
to be used for clean-up actions, for example to call Lock.unlock().
Usually the `try` block contains the main business logic and the `finally` block contains
code for cleaning up resources or restoring a previous state. Therefore an exception which
occurs in the `try` block is usually important to debug any application failures.

The problem is that if the `finally` block is exited because an exception is thrown, then
the original exception from the `try` block is lost; it is not even added as suppressed
exception. A very simplified example for this is the following:
```
try {
    throw new Exception("try");
} finally {
    throw new Exception("finally");
}
```
(in more realistic code, instead of the `throw` statements there would be method calls which
might throw exceptions)

Here the original exception `new Exception("try")` is completely lost. This can make
debugging or reconstructing failures extremely difficult.

This issue was also mentioned in the original try-with-resources / automatic resource
management proposal (https://mail.openjdk.org/pipermail/coin-dev/2009-February/000011.html).
However, back then it appears no proposal was made to adjust the behavior of `finally`
blocks, most likely because suppressed exceptions was only an optional feature initially.
(Note that I have not looked at all mails from the coin-dev mailing list, so I might have
missed a discussion about this.)


# Risks / considerations

The proposed change would affect all source code which is recompiled; already compiled
code would not be affected.

- Noticeable behavior change
  The behavior change described in this proposal would be noticeable to applications
  which access the suppressed exceptions explicitly or implicitly (e.g. by printing
  the stack trace). However, it is unlikely that applications expect certain suppressed
  exceptions, especially since using expressions for regular control flow is discouraged.

- Memory usage impact
  The proposed change could have a performance impact because it would keep the exception
  thrown by the `try` or one of the `catch` blocks alive for a longer time. However,
  due to the improved debuggability this provides, that might be acceptable.

- Execution time impact
  The proposed change might have a negative effect on the execution time of `try` statements
  with `finally` blocks, possibly also negatively affecting the analysis performed by the
  JIT compiler.
  javac could however omit the exception suppression if the statements in the `finally`
  block are guaranteed to never throw exceptions.

- `addSuppressed` call causing StackOverflowError and OutOfMemoryError
  The call to `addSuppressed` in the `finally` block could trigger a StackOverflowError
  or an OutOfMemoryError. This would cause all previous exceptions to be lost.
  The StackOverflowError could possibly be avoided by using @ReservedStackAccess
  (introduced by JEP 270)?

- Self suppression
  Currently the proposal allows E1 and E2 to be the same exception instance. However,
  calling `e.addSuppressed(e)` is forbidden and will cause an IllegalArgumentException
  to be thrown. Such a situation could occur when the thrown exception had been stored
  in a field and is then rethrown by the clean-up actions.
  Not checking for self-suppression and accepting the risk of an IllegalArgumentException
  would match the current behavior of the try-with-resources statement.
  It should be discussed if that behavior is desired. At least the IllegalArgumentException
  is currently constructed with the self-suppressed exception as cause, so it is not "lost".


# Related issues / code segments

- https://bugs.openjdk.org/browse/JDK-4988583
  Seems to be the same as this proposal, but was (erroneously?) closed when suppressed
  exceptions were added, even though suppressed exceptions on their own do not solve
  this issue.
- https://bugs.openjdk.org/browse/JDK-5108147
  Suggests the addition of a `finally (Throwable) { ... }`. With such a construct
  it would at least be easier to write code which manually suppress exceptions
  which occur in the `finally` block.
- https://github.com/openjdk/jdk/blob/d53b02eb9fceb6d170e0ea8613c2a064a7175892/src/java.base/share/classes/java/util/stream/Streams.java#L837-L887
  Acts very similar to what is described in this proposal, except that there the
  exception from the `try` block is considered the "main" exception, and exceptions
  from the `finally` block are added as suppressed ones.
- https://github.com/openjdk/jdk/blob/d53b02eb9fceb6d170e0ea8613c2a064a7175892/src/java.net.http/share/classes/jdk/internal/net/http/websocket/WebSocketImpl.java#L737-L763
  Acts similar except that the resulting exception is not rethrown but logged.
- https://bugs.openjdk.org/browse/JDK-7172206
  Affected by exactly the flaw outlined in the rationale of this proposal.
- https://bugs.openjdk.org/browse/JDK-8267532
  Optimization problems with try-finally.


# Further notes

These notes are not part of the proposal itself, but highlight related issues.
Some of them had been described in https://mail.openjdk.org/pipermail/core-libs-dev/2022-April/088435.html
and the replies to it.

- Which expression should be rethrown, which should be suppressed?
  Currently the proposal suggests to keep the behavior of treating the exception from
  the `finally` block as "main" exception, and adding the exception from the `try` or
  `catch` block as suppressed exception.
  However, as also highlighted during the discussion for the try-with-resources statement,
  the exception from the `try` or `catch` block is most likely the more important exception,
  whereas the exception from the `finally` block is not as important. In fact the exception
  from the `finally` block might have only occurred due to the original failure in the
  `try` block which had left the application in an inconsistent state.
  The try-with-resources statement behaves like this and treats the exceptions from the
  `close()` invocation as suppressed. Maybe it would be worth to consider whether the
  behavior of `finally` should be changed to match this, but that might cause backward
  compatibility issue.

- Other control flow statements in `finally`
  The `finally` clause has similar issues when it is exited with other control flow
  statements, such as `return`, `break` or `continue`. For all of these the original
  exception would be lost, even with the changes of this proposal. Additionally, these
  statements can also "overrule" other control flow statements in the body of `try` or
  `catch`:
  ```
  while (...) {
      try {
          // Has no effect
          return 0;
      } finally {
          continue;
      }
  }
  ```
  
- Further enhancements for exception handling
  There are other exception handling situations which currently require rather verbose
  code, most notably:
    - Given an existing exception E1 (for example from a `catch` clause) and an action
      which has to be executed but may throw an exception:
      Perform the action and add any exception E2 (of specific type?) thrown by that
      action as suppressed exception to E1 and throw E1.
      (Possibly also a variant where E1 may be null in which case E2 is thrown.)

    - Given multiple actions which all have to be executed but may throw exceptions:
      Execute all of them, record the first occurred exception E1 and add any subsequent
      exception E2 as suppressed one to E1. Then at the end throw E1.

  See also https://bugs.openjdk.org/browse/JDK-8073382.
  However, such changes would require language changes or introduction of new utility
  classes and methods.


From joe.darcy at oracle.com  Thu Jul 14 05:37:04 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 13 Jul 2022 22:37:04 -0700
Subject: Proposal: `finally` block exception suppression
In-Reply-To: <1ea9142d81b14c268b5b2de179dd6bed@vodafonemail.de>
References: <1ea9142d81b14c268b5b2de179dd6bed@vodafonemail.de>
Message-ID: <e64925d2-b53a-f159-d302-21735b5361fe@oracle.com>

Besides the compatibility concerns of changing the operational semantics 
of code that has been written for year or even decades, IMO any 
investigation of a feature in this vein should judge how often 
suppressedExceptions are looked at today. JDK 7 with try-with-resources 
shipped in July 2011 so there has been ample time for developers to take 
advantage of the suppressed exceptions information.

If few people have, that would weigh further against a proposal to 
redefine the long-standing meaning of try-finally.

-Joe

On 7/10/2022 12:35 PM, 
some-java-user-99206970363698485155 at vodafonemail.de wrote:
> This is not a formal JEP because I am not a OpenJDK member, and also because I would
> still like to get some feedback on this proposal. But it would be great if you could
> create a JEP if you consider this to be a useful proposal.
> This proposal originated from https://mail.openjdk.org/pipermail/core-libs-dev/2022-April/089016.html
> Thanks a lot already for David Holmes' initial feedback.
>
>
> # Summary
>
> Add automatic exception suppression when exceptions are thrown by `finally` blocks
> to preserve exceptions which occurred in `try` or `catch` blocks.
>
>
> # Description
>
> If exception E1 causes a `finally` block to be executed and the `finally` block is exited due
> to a thrown exception E2 (E2 may be the same as E1), then E1 is added as suppressed exception
> to E2.
>
> E1 can be an exception which occurred in the `try` block, or any of the `catch` blocks.
>
> This requires only changes in the compiler, the language reference and the tests.
> The language grammar is not affected.
>
> The behavior would be the same as the one shown by this code, where every line prefixed
> with # would be the code generated by the compiler:
> ```
> # Throwable e1 = null;
> try {
>      # try {
>          ... // content of try block
>      # } catch (Throwable t) {
>      #    e1 = t;
>      #    throw e1;
>      # }
> } catch (...) {
>      # e1 = null;
>      # try {
>          ... // content of catch block
>      # } catch (Throwable t) {
>      #    e1 = t;
>      #    throw e1;
>      # }
> } finally {
>      # try {
>          ... // content of finally block
>      # } catch (Throwable e2) {
>      #    if (e1 != null) {
>      #        e2.addSuppressed(e1);
>      #    }
>      #    throw e2;
>      # }
> }
> ```
>
>
> # Rationale
>
> Despite the existence of the try-with-resources statement which properly handles exception
> suppression, there are still situations where a regular try-(catch-)finally statement has
> to be used for clean-up actions, for example to call Lock.unlock().
> Usually the `try` block contains the main business logic and the `finally` block contains
> code for cleaning up resources or restoring a previous state. Therefore an exception which
> occurs in the `try` block is usually important to debug any application failures.
>
> The problem is that if the `finally` block is exited because an exception is thrown, then
> the original exception from the `try` block is lost; it is not even added as suppressed
> exception. A very simplified example for this is the following:
> ```
> try {
>      throw new Exception("try");
> } finally {
>      throw new Exception("finally");
> }
> ```
> (in more realistic code, instead of the `throw` statements there would be method calls which
> might throw exceptions)
>
> Here the original exception `new Exception("try")` is completely lost. This can make
> debugging or reconstructing failures extremely difficult.
>
> This issue was also mentioned in the original try-with-resources / automatic resource
> management proposal (https://mail.openjdk.org/pipermail/coin-dev/2009-February/000011.html).
> However, back then it appears no proposal was made to adjust the behavior of `finally`
> blocks, most likely because suppressed exceptions was only an optional feature initially.
> (Note that I have not looked at all mails from the coin-dev mailing list, so I might have
> missed a discussion about this.)
>
>
> # Risks / considerations
>
> The proposed change would affect all source code which is recompiled; already compiled
> code would not be affected.
>
> - Noticeable behavior change
>    The behavior change described in this proposal would be noticeable to applications
>    which access the suppressed exceptions explicitly or implicitly (e.g. by printing
>    the stack trace). However, it is unlikely that applications expect certain suppressed
>    exceptions, especially since using expressions for regular control flow is discouraged.
>
> - Memory usage impact
>    The proposed change could have a performance impact because it would keep the exception
>    thrown by the `try` or one of the `catch` blocks alive for a longer time. However,
>    due to the improved debuggability this provides, that might be acceptable.
>
> - Execution time impact
>    The proposed change might have a negative effect on the execution time of `try` statements
>    with `finally` blocks, possibly also negatively affecting the analysis performed by the
>    JIT compiler.
>    javac could however omit the exception suppression if the statements in the `finally`
>    block are guaranteed to never throw exceptions.
>
> - `addSuppressed` call causing StackOverflowError and OutOfMemoryError
>    The call to `addSuppressed` in the `finally` block could trigger a StackOverflowError
>    or an OutOfMemoryError. This would cause all previous exceptions to be lost.
>    The StackOverflowError could possibly be avoided by using @ReservedStackAccess
>    (introduced by JEP 270)?
>
> - Self suppression
>    Currently the proposal allows E1 and E2 to be the same exception instance. However,
>    calling `e.addSuppressed(e)` is forbidden and will cause an IllegalArgumentException
>    to be thrown. Such a situation could occur when the thrown exception had been stored
>    in a field and is then rethrown by the clean-up actions.
>    Not checking for self-suppression and accepting the risk of an IllegalArgumentException
>    would match the current behavior of the try-with-resources statement.
>    It should be discussed if that behavior is desired. At least the IllegalArgumentException
>    is currently constructed with the self-suppressed exception as cause, so it is not "lost".
>
>
> # Related issues / code segments
>
> - https://bugs.openjdk.org/browse/JDK-4988583
>    Seems to be the same as this proposal, but was (erroneously?) closed when suppressed
>    exceptions were added, even though suppressed exceptions on their own do not solve
>    this issue.
> - https://bugs.openjdk.org/browse/JDK-5108147
>    Suggests the addition of a `finally (Throwable) { ... }`. With such a construct
>    it would at least be easier to write code which manually suppress exceptions
>    which occur in the `finally` block.
> - https://github.com/openjdk/jdk/blob/d53b02eb9fceb6d170e0ea8613c2a064a7175892/src/java.base/share/classes/java/util/stream/Streams.java#L837-L887
>    Acts very similar to what is described in this proposal, except that there the
>    exception from the `try` block is considered the "main" exception, and exceptions
>    from the `finally` block are added as suppressed ones.
> - https://github.com/openjdk/jdk/blob/d53b02eb9fceb6d170e0ea8613c2a064a7175892/src/java.net.http/share/classes/jdk/internal/net/http/websocket/WebSocketImpl.java#L737-L763
>    Acts similar except that the resulting exception is not rethrown but logged.
> - https://bugs.openjdk.org/browse/JDK-7172206
>    Affected by exactly the flaw outlined in the rationale of this proposal.
> - https://bugs.openjdk.org/browse/JDK-8267532
>    Optimization problems with try-finally.
>
>
> # Further notes
>
> These notes are not part of the proposal itself, but highlight related issues.
> Some of them had been described in https://mail.openjdk.org/pipermail/core-libs-dev/2022-April/088435.html
> and the replies to it.
>
> - Which expression should be rethrown, which should be suppressed?
>    Currently the proposal suggests to keep the behavior of treating the exception from
>    the `finally` block as "main" exception, and adding the exception from the `try` or
>    `catch` block as suppressed exception.
>    However, as also highlighted during the discussion for the try-with-resources statement,
>    the exception from the `try` or `catch` block is most likely the more important exception,
>    whereas the exception from the `finally` block is not as important. In fact the exception
>    from the `finally` block might have only occurred due to the original failure in the
>    `try` block which had left the application in an inconsistent state.
>    The try-with-resources statement behaves like this and treats the exceptions from the
>    `close()` invocation as suppressed. Maybe it would be worth to consider whether the
>    behavior of `finally` should be changed to match this, but that might cause backward
>    compatibility issue.
>
> - Other control flow statements in `finally`
>    The `finally` clause has similar issues when it is exited with other control flow
>    statements, such as `return`, `break` or `continue`. For all of these the original
>    exception would be lost, even with the changes of this proposal. Additionally, these
>    statements can also "overrule" other control flow statements in the body of `try` or
>    `catch`:
>    ```
>    while (...) {
>        try {
>            // Has no effect
>            return 0;
>        } finally {
>            continue;
>        }
>    }
>    ```
>    
> - Further enhancements for exception handling
>    There are other exception handling situations which currently require rather verbose
>    code, most notably:
>      - Given an existing exception E1 (for example from a `catch` clause) and an action
>        which has to be executed but may throw an exception:
>        Perform the action and add any exception E2 (of specific type?) thrown by that
>        action as suppressed exception to E1 and throw E1.
>        (Possibly also a variant where E1 may be null in which case E2 is thrown.)
>
>      - Given multiple actions which all have to be executed but may throw exceptions:
>        Execute all of them, record the first occurred exception E1 and add any subsequent
>        exception E2 as suppressed one to E1. Then at the end throw E1.
>
>    See also https://bugs.openjdk.org/browse/JDK-8073382.
>    However, such changes would require language changes or introduction of new utility
>    classes and methods.
>

From jlahoda at openjdk.org  Fri Jul 15 09:57:53 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Jul 2022 09:57:53 GMT
Subject: git: openjdk/amber: created branch desugaring-experiment based on the
 branch templated-strings containing 215 unique commits
Message-ID: <cd1e4c72-0132-47f6-b4b5-44a80634f7ac@openjdk.org>

The following commits are unique to the desugaring-experiment branch:
========================================================
86467f9d: Experiment
a36a34a3: Cleanup
e8ab77b4: Adding a sample testcase.
30b6b6cd: Cleanup.
64782a75: 8288623: Move Continuation classes out of javaClasses.hpp
9dc9a64f: 8287281: adjust guarantee in Handshake::execute for the case of target thread being current
17aacde5: 8288669: compiler/vectorapi/VectorFPtoIntCastTest.java still fails with "IRViolationException: There were one or multiple IR rule failures."
925084c4: 8288976: classfile parser 'wrong name' error message has the names the wrong way around
fdc8455c: 8288495: [test] Make OutputAnalyzer exception more informative
0d2952e5: 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current
239b4bb0: 8289095: (fs) UnixCopyFile build error on linux-x86
f67c5361: 8288935: Remove excessive includes introduced in loom
9918b6d3: 8288609: Update --release 19 symbol information for JDK 19 build 28
4cdb9789: 8289098: clean up ported serviceability/jvmti tests
08288819: 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java
53b37fe1: 8288130: compiler error with AP and explicit record accessor
e93be3ac: 8286389: Address possibly lossy conversions in jdk.crypto.ec
a5c25d88: 8286395: Address possibly lossy conversions in java.security.jgss
de746714: 8266670: Better modeling of access flags in core reflection
62e1e795: 8289147: unify os::infinite_sleep on posix platforms
47fe9ef5: 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl
7905788e: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent
ddb55ede: 8135292: Remove duplicate code in <OS>Address.java in SA
64f95cfb: 8012675: javax.swing.JEditorPane is unclear on the handling of unsupported HTML script tags
210a06a2: 8287227: Shenandoah: A couple of virtual thread tests failed with iu mode even without Loom enabled.
be6be15e: 8288750: IGV: Improve Shortcuts
f3f07884: 8288746: HttpClient resources could be reclaimed more eagerly
354ed103: 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker
3f5e48a4: 8288781: C1: LIR_OpVisitState::maxNumberOfOperands too small
4c9ea7e6: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames
a716f793: 8288589: Files.readString ignores encoding errors for UTF-16
1f9521e6: 8287076: Document.normalizeDocument() produces different results
651cbebb: 8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE
b0db3333: 8288528: broken links in java.desktop
bdf9902f: 8288120: VerifyError with JEP 405 pattern match
20f55abd: 8289044: ARM32: missing LIR_Assembler::cmove metadata type support
7ac40f3b: 8288983: broken link in com.sun.net.httpserver.SimpleFileServer
9c92da52: 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing
7e13cdb7: 8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with "RuntimeException: Test failed"
d4b040f4: Merge
40bf3b11: 8288993: Make AwtFramePackTest generic by removing @requires tag
e322e77e: 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name
ca78f7bd: 8286259: Password cleanup after KeyStore.PasswordProtection in P11KeyStore
784fa0ad: 8282036: Change java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions
33369719: 8289258: ProblemList some failing custom loader tests with ZGC
b4ab5fe1: 8288396: Always create reproducible builds
aa438242: 8289138: G1: Remove redundant is-marking-active checks in C1 barrier
549c6c22: 8287818: Shenandoah: adapt nmethod arming from Loom
d4eeeb82: 8271252: os::reserve_memory should not use mtOther as default NMT flag
88fe19c5: 8289071: Compute allocation sizes of stubs and nmethods outside of lock protection
1f36ed1f: 8288013: jpackage: test utility Windows registry enhancement
c67149be: 8288961: jpackage: test MSI installation fix
af008807: 8284640: CollectorImpl class could be a record class
784a0f04: 8288683: C2: And node gets wrong type due to not adding it back to the worklist in CCP
699ad45b: 8289093: BlockLocationPrinter fails to decode addresses with G1
2c8ada68: 8289188: SegmentAllocator:allocateArray(*) default behavior mismatch to spec
77466648: 8280826: Document set of strings javac recognizes for SuppressWarnings
28913f47: 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper
caa6b74b: 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode
17ef8cae: 8288524: Allow @systemProperty to appear in overview documentation
2efa89a8: 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java
b4490386: 8288445: AArch64: C2 compilation fails with guarantee(!true || (true && (shift != 0))) failed: impossible encoding
adbd200d: 8289228: SegmentAllocator::allocateArray null handling is too lax
9048cef7: 8288425: Footprint regression due MH creation when initializing StringConcatFactory
6f9717b4: 8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided
a814293e: 8275784: Bogus warning generated for record with compact constructor
c42b796f: 8288058: Broken links on constant-values page
9b7805e3: 8289069: Very slow C1 arraycopy jcstress tests after JDK-8279886
15048048: 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again
86dc760f: Merge
7b3bf977: 8289401: Add dump output to TestRawRSACipher.java
910053b7: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test
779b4e1d: 8287001: Add warning message when fail to load hsdis libraries
b96ba198: 8289182: NMT: MemTracker::baseline should return void
108cd695: 8283726: x86_64 intrinsics for compareUnsigned method in Integer and Long
167ce4da: 8289421: No-PCH build for Minimal VM was broken by JDK-8287001
2961b7ee: 8285364: Remove REF_ enum for java.lang.ref.Reference
0709a6a1: 8284942: Proxy building can just iterate superinterfaces once
ba670ecb: 8289094: [JVMCI] reduce JNI overhead and other VM rounds trips in JVMCI
b6bd190d: 8288985: P11TlsKeyMaterialGenerator should work with ChaCha20-Poly1305
15efb2bd: 8289238: Refactoring changes to PassFailJFrame Test Framework
dbc6e110: 8289399: Update SourceVersion to use snippets
57089749: 8288596: Random:from() adapter does not delegate to supplied generator in all cases
cf715449: 8289252: Recommend Locale.of() method instead of the constructor
048bffad: Merge
dddd4e7c: 8289291: HttpServer sets incorrect value for "max" parameter in Keep-Alive header value
31e50f2c: 8286104: use aggressive liveness for unstable_if traps
da6d1fc0: 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
28c5e483: 8287094: IGV: show node input numbers in edge tooltips
7b5bd251: 8286397: Address possibly lossy conversions in jdk.hotspot.agent
1305fb5c: 8287984: AArch64: [vector] Make all bits set vector sharable for match rules
c3addbb1: 8288895: LdapContext doesn't honor set referrals limit
feb223aa: 8288707: javax/swing/JToolBar/4529206/bug4529206.java: setFloating does not work correctly
00d06d4a: 8289440: Remove vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded003 from ProblemList.txt
c20b3aa9: 8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and can_support_virtual_threads
918068a1: Merge
124c63c1: 8288294: [vector] Add Identity/Ideal transformations for vector logic operations
d260a4e7: 8289434: x86_64: Improve comment on gen_continuation_enter()
f190f4e6: 8288444: Remove the workaround for frame.pack() in ModalDialogTest
b9b900a6: 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP
a8fe2d97: 8289512: Fix GCC 12 warnings for adlc output_c.cpp
09b4032f: 8289534: Change 'uncomplicated' hotspot runtime options
c43bdf71: 8289257: Some custom loader tests failed due to symbol refcount not decremented
e291a67e: 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB
2dd00f58: 8170762: Document that ISO10126Padding pads with random bytes
44e8c462: 8289603: Code change for JDK-8170762 breaks all build
cdf69792: 8289230: Move PlatformXXX class declarations out of os_xxx.hpp
dee5121b: 8289385: Cleanup redundant synchronization in Http2ClientImpl
95497772: 8284358: Unreachable loop is not removed from C2 IR, leading to a broken graph
604ea90d: 8289549: ISO 4217 Amendment 172 Update
20124ac7: 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
8e01ffb3: 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec
99250140: 8280320: C2: Loop opts are missing during OSR compilation
cfc9a881: 8288854: getLocalGraphicsEnvironment() on for multi-screen setups throws exception NPE
9515560c: 8288703: GetThreadState returns 0 for virtual thread that has terminated
f5cdabad: 8245268: -Xcomp is missing from java launcher documentation
70f56933: Merge
d8444aa4: 8286610: Add additional diagnostic output to java/net/DatagramSocket/InterruptibleDatagramSocket.java
649f2d88: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java fails because Popup is one pixel off
8e7a3cb5: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
e31003a0: 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry
a8edd7a1: 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl
d53b02eb: 8287312: G1: Early return on first failure in VerifyRegionClosure
b5d96565: 8288971: AArch64: Clean up stack and register handling in interpreter
bad9ffe4: 8288947: G1: Consolidate per-region is-humongous query in G1CollectedHeap
9ccae707: 8287593: ShortResponseBody could be made more resilient to rogue connections
df063f7d: 8289484: Cleanup unnecessary null comparison before instanceof check in java.rmi
688712f7: 8289633: Forbid raw C-heap allocation functions in hotspot and fix findings
1b997db7: 8289427: compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java failed with null setting
4c997ba8: 8289520: G1: Remove duplicate checks in G1BarrierSetC1::post_barrier
fd1bb078: 8287603: Avoid redundant HashMap.containsKey calls in NimbusDefaults.getDerivedColor
a5934cdd: 8289698: AArch64: Need to relativize extended_sp in frame
77c3bbf1: 8289617: Remove test/jdk/java/net/ServerSocket/ThreadStop.java
c45d613f: 8289687: [JVMCI] bug in HotSpotResolvedJavaMethodImpl.equals
d48694d0: 8283335: Add exists and readAttributesIfExists methods to FileSystemProvider
35156041: 8280481: Duplicated stubs to interpreter for static calls
fafe8b3f: 8289604: compiler/vectorapi/VectorLogicalOpIdentityTest.java failed on x86 AVX1 system
f783244c: 8289706: (cs) Avoid redundant TreeMap.containsKey call in AbstractCharsetProvider
d8f4e97b: 8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output
4ad18cf0: 8289730: Deprecated code sample in java.lang.ClassCastException
ac6be165: 8289695: [TESTBUG] TestMemoryAwareness.java fails on cgroups v2 and crun
83418952: 8289739: Add G1 specific GC breakpoints for testing
cbaf6e80: 8288022: c2: Transform (CastLL (AddL into (AddL (CastLL when possible
83a5d599: 8278479: RunThese test failure with +UseHeavyMonitors and +VerifyHeavyMonitors
75c0a5b8: 8288824: [arm32] Display isetstate in register output
cc2b7927: 8288992: AArch64: CMN should be handled the same way as CMP
82a8bd7e: 8287596: Reorg jdk.test.lib.util.ForceGC
dfb24ae4: 8289060: Undefined Behaviour in class VMReg
9f37ba44: 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean)
35387d5c: 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec
c4dcce4b: 8289619: JVMTI SelfSuspendDisablerTest.java failed with RuntimeException: Test FAILED: Unexpected thread state
dc4edd3f: 8289183: jdk.jfr.consumer.RecordedThread.getId references Thread::getId, should be Thread::threadId
5b5bc6c2: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
1a271645: 8287851: C2 crash: assert(t->meet(t0) == t) failed: Not monotonic
0dff3276: 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl
f640fc5a: 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags
29ea6429: 8287847: Fatal Error when suspending virtual thread after it has terminated
30e134e9: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj()
0b6fd482: 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads)
b3a0e482: 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability
0526402a: 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
2a6ec88c: Merge
a40c17b7: 8289775: Update java.lang.invoke.MethodHandle[s] to use snippets
403a9bc7: 8289436: Make the redefine timer statistics more accurate
569de453: 8289620: gtest/MetaspaceUtilsGtests.java failed with unexpected stats values
a79ce4e7: 8286941: Add mask IR for partial vector operations for ARM SVE
d1249aa5: 8198668: MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java still failing
cce77a70: 8289799: Build warning in methodData.cpp memset zero-length parameter
e05b2f2c: 8289856: [PPC64] SIGSEGV in C2Compiler::init_c2_runtime() after JDK-8289060
532a6ec7: 7124313: [macosx] Swing Popups should overlap taskbar
77ad998b: 8289778: ZGC: incorrect use of os::free() for mountpoint string handling after JDK-8289633
013a5eee: 8137280: Remove eager reclaim of humongous controls
86f63f97: 8289164: Convert ResolutionErrorTable to use ResourceHashtable
74ca6ca2: 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early
8e7b45b8: 8282986: Remove "system" in boot class path names
95e3190d: 8210708: Use single mark bitmap in G1
a694e9e3: 8288838: jpackage: file association additional arguments
5564effe: 8289763: Remove NULL check in CDSProtectionDomain::init_security_info()
f7b18305: 8289538: Make G1BlockOffsetTablePart unaware of block sizes
3e60e828: 8289301: P11Cipher should not throw out of bounds exception during padding
f93beacd: 8252329: runtime/LoadClass/TestResize.java timed out
8cdead0c: 8278923: Document Klass::is_loader_alive
f804f2ce: 8284851: Update javax.crypto files to use proper javadoc for mentioned classes
3f1174aa: 8289646: configure script failed on WSL
ef3f2ed9: 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows
32b650c0: 8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper
55fa19b5: 8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java
9a0fa824: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing
8f24d251: 6509045: {@inheritDoc} only copies one instance of the specified exception
8dd94a2c: 8289196: Pattern domination not working properly for record patterns
889150b4: 8289558: Need spec clarification of j.l.foreign.*Layout
a8eb7286: 8289779: Map::replaceAll javadoc has redundant @throws clauses
3212dc9c: 8289486: Improve XSLT XPath operators count efficiency
01b9f95c: Merge
1fec62f2: 8289710: Move Suspend/Resume classes out of os.hpp
ac399e97: 8286957: Held monitor count
1b8f466d: 8289740: Add verification testing during all concurrent phases in G1
f1967cfa: 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option
a13af650: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions
d852e99a: 8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad
e7795851: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
9c86c820: 8282714: synthetic arguments are being added to the constructors of static local classes
1877533f: 6522064: Aliases from Microsoft CryptoAPI has bad character encoding
6aaf141f: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException
54b4576f: 8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent
3c08e6b3: 8289780: Avoid formatting stub names when Forte is not enabled
81ee7d28: 8289186: Support predicated vector load/store operations over X86 AVX2 targets.
87aa3ce0: 8289274: Cleanup unnecessary null comparison before instanceof check in security modules
e9d9cc6d: 8290027: Move inline functions from vm_version_x86.hpp to cpp
4ab77ac6: 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice
e2598207: 8290019: Refactor HeapRegion::oops_on_memregion_iterate()
0225eb43: 8290018: Remove dead declarations in G1BlockOffsetTablePart
6f2db3da: Merge branch 'master' into desugaring-experiment
3c40d718: Post merge fix.
985d3a1d: Resolve trailing accummulator.

From some-java-user-99206970363698485155 at vodafonemail.de  Sun Jul 17 12:10:24 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Sun, 17 Jul 2022 14:10:24 +0200
Subject: Proposal: `finally` block exception suppression
In-Reply-To: <7902aeb4293c41a5a9695f0ba723ba25@vodafonemail.de>
Message-ID: <796599f67b6040f9b242d83c198b7bef@vodafonemail.de>

> Besides the compatibility concerns of changing the operational semantics
> of code that has been written for year or even decades

There might be a risk of compatibility issues, but I think it is rather low. As outlined in my proposal
it would mostly affect applications which inspect the suppressed exceptions in some way.
I can definitely understand your concerns regarding compatibility, but I am also a bit afraid that
this whole proposal is rejected due to theoretical issues which might never occur in practice.

> should judge how often suppressedExceptions are looked at today. JDK 7 with try-with-resources
> shipped in July 2011 so there has been ample time for developers to take advantage of the
> suppressed exceptions information

That is probably difficult to measure, but this would also then turn this whole discussion into
a discussion about whether suppressed exceptions as a whole are useful.

I have done a quick search and found the following blog posts / websites describing this issue.
Some have been written before the introduction of try-with-resources, but as outlined in the
proposal, it is not possible to use try-with-resources in all situations.
- https://stackoverflow.com/q/25751709
- https://stackoverflow.com/q/3779285
- https://stackoverflow.com/q/59360652
- https://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ311_014.htm
- https://accu.org/journals/overload/12/62/barrettpowell_236/
- https://errorprone.info/bugpattern/Finally
- https://wiki.sei.cmu.edu/confluence/display/java/ERR05-J.+Do+not+let+checked+exceptions+escape+from+a+finally+block

In addition to these  there are the OpenJDK bug reports I mentioned in the proposal:
- JDK-4988583: which is the same as this proposal
- JDK-7172206: bug which is caused by this flaw and still exists today (if I see that correctly)

One could now argue that this issue has been so widely discussed that developers
should by now all be aware of this issue and avoid it. But I think it is quite the opposite:
The current behavior is flawed and developers (who might even be aware of this issue)
keep running into this issue and therefore try to warn each other about it. And any
solutions or workarounds to this are pretty verbose and quite error-prone.

Of course it would have been ideal if suppressed exceptions existed from the beginning
and the `finally` block behaved like try-with-resources statements with regards to exception
suppression. But I think with the current situation it would at least be good to improve it in
the best way possible.

If you and the other OpenJDK members think that this proposal is definitely not going to be
included (or also independently from this decision), what do you think about reviving JDK-5108147?
This would at least make manual exception suppression in `finally` blocks easier:
```
try {
    someAction();
}
finally (Throwable t) {
    try {
        cleanUp();
    }
    catch (Throwable t2) {
        if (t == null) {
            throw t2;
        } else {
            t.addSuppressed(t2);
        }
    }
}
```

Kind regards


From duke at openjdk.org  Fri Jul 22 08:46:23 2022
From: duke at openjdk.org (duke)
Date: Fri, 22 Jul 2022 08:46:23 GMT
Subject: git: openjdk/amber: desugaring-experiment: 2 new changesets
Message-ID: <d90c89cb-e93e-4308-a3e9-358b00e8e7c1@openjdk.org>

Changeset: 47e10250
Author:    Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Date:      2022-07-15 18:48:33 +0000
URL:       https://git.openjdk.org/amber/commit/47e1025064454cb91e75dd4ba2ac5d9cffe6a9c0

Fix nested unconditional

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
! test/langtools/tools/javac/patterns/DeconstructionDesugaring.java

Changeset: 784d0451
Author:    Jan Lahoda <51319204+lahodaj at users.noreply.github.com>
Committer: GitHub <noreply at github.com>
Date:      2022-07-22 10:45:06 +0000
URL:       https://git.openjdk.org/amber/commit/784d0451ceb524973418d40556bc462438e21072

Fix nested unconditional in the new desugaring




From jlahoda at openjdk.org  Wed Jul 27 10:04:21 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 27 Jul 2022 10:04:21 GMT
Subject: git: openjdk/amber: desugaring-experiment: 4 new changesets
Message-ID: <e99c8dca-9487-46ba-a543-b65157821909@openjdk.org>

Changeset: c3d836e2
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-13 15:44:56 +0000
URL:       https://git.openjdk.org/amber/commit/c3d836e220a93dad705e24c01e066c387f078211

Attempting to improve desugaring.

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+ test/langtools/tools/javac/patterns/PatternDesugaring.java

Changeset: 42b893f7
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-15 13:03:24 +0000
URL:       https://git.openjdk.org/amber/commit/42b893f79a68505a056b6ccc8f9336e357a24629

Avoiding synthetic accessor caller methods by better use of the exception table.

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! test/langtools/tools/javac/patterns/TypedDeconstructionPatternExc.java

Changeset: 876424d8
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-22 10:45:50 +0000
URL:       https://git.openjdk.org/amber/commit/876424d837bbad32da0b41ac625c03d70c91210a

Merge branch 'desugaring-experiment' of github.com:openjdk/amber into desugaring-experiment

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java

Changeset: 88267051
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-27 10:54:38 +0000
URL:       https://git.openjdk.org/amber/commit/88267051a4b3efb1dcd8ad2f098c7c05228bea7f

Adding new indy bootstrap for testing, adding ability to test variants.

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+ src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatternsUnmodified.java


From jlahoda at openjdk.org  Wed Jul 27 10:08:06 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 27 Jul 2022 10:08:06 GMT
Subject: git: openjdk/amber: desugaring-experiment: Fixing bugs in desugaring
 and runtime
Message-ID: <e0b45c77-aeaf-436e-a392-595a560ee20f@openjdk.org>

Changeset: 9011218b
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-27 12:04:33 +0000
URL:       https://git.openjdk.org/amber/commit/9011218be6fa540cfd7b0808ed2cfa80839c2519

Fixing bugs in desugaring and runtime

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
! test/langtools/tools/javac/patterns/Switches.java


From claytonwohl at gmail.com  Wed Jul 27 18:26:52 2022
From: claytonwohl at gmail.com (Clayton Wohl)
Date: Wed, 27 Jul 2022 13:26:52 -0500
Subject: Record Pattern Bug in Java 19
Message-ID: <CAO7pUDWpmsFo3VQFc=1F5cbucf0ikHNZVgx5FnBD-Ov96=bBRQ@mail.gmail.com>

// The example given in Brian Goetz's article:
https://www.infoq.com/articles/data-oriented-programming-java/
sealed interface Opt<T> {
    record Some<T>(T value) implements Opt<T> { }
    record None<T>() implements Opt<T> { }
}

// This works: Exhaustive switch without default case, but no record pattern
public static void thisWorks1(int value) {
    Opt<String> optValue = doSomethingThatReturnsOpt(value);
    switch (optValue) {
        case Opt.Some<String> some -> System.out.printf("got string: %s%n",
some.value());
        case Opt.None<String> none -> System.out.println("got none");
    };
}

// This works: record pattern in a switch statement with a default case.
public static void thisWorks2(int value) {
    Opt<String> optValue = doSomethingThatReturnsOpt(value);
    switch (optValue) {
        case Opt.Some<String>(String v) -> System.out.printf("got string:
%s%n", v);
        case Opt.None<String> none -> System.out.println("got none");
        default -> System.out.printf("default%n");
    };
}

// This does NOT compile: Exhaustive switch without default case + record
pattern
public static void thisDoesNotWork(int value) {
    Opt<String> optValue = doSomethingThatReturnsOpt(value);
    switch (optValue) {
        case Opt.Some<String>(String v) -> System.out.printf("got string:
%s%n", v);
        case Opt.None<String> none -> System.out.println("got none");
    };
}

This is with the latest public JDK 19 build: build 19-ea+32-2220

I hope I'm posting to the correct list. If this list is for internal Java
developers only, I'm sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220727/d5f40ca4/attachment-0001.htm>

From forax at univ-mlv.fr  Wed Jul 27 18:35:10 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 27 Jul 2022 20:35:10 +0200 (CEST)
Subject: Record Pattern Bug in Java 19
In-Reply-To: <CAO7pUDWpmsFo3VQFc=1F5cbucf0ikHNZVgx5FnBD-Ov96=bBRQ@mail.gmail.com>
References: <CAO7pUDWpmsFo3VQFc=1F5cbucf0ikHNZVgx5FnBD-Ov96=bBRQ@mail.gmail.com>
Message-ID: <1031392675.16038284.1658946910258.JavaMail.zimbra@u-pem.fr>

> From: "Clayton Wohl" <claytonwohl at gmail.com>
> To: "amber-dev" <amber-dev at openjdk.org>
> Sent: Wednesday, July 27, 2022 8:26:52 PM
> Subject: Record Pattern Bug in Java 19

> // The example given in Brian Goetz's article: [
> https://www.infoq.com/articles/data-oriented-programming-java/ |
> https://www.infoq.com/articles/data-oriented-programming-java/ ]
> sealed interface Opt<T> {
> record Some<T>(T value) implements Opt<T> { }
> record None<T>() implements Opt<T> { }
> }

> // This works: Exhaustive switch without default case, but no record pattern
> public static void thisWorks1(int value) {
> Opt<String> optValue = doSomethingThatReturnsOpt(value);
> switch (optValue) {
> case Opt.Some<String> some -> System.out.printf("got string: %s%n",
> some.value());
> case Opt.None<String> none -> System.out.println("got none");
> };
> }

> // This works: record pattern in a switch statement with a default case.
> public static void thisWorks2(int value) {
> Opt<String> optValue = doSomethingThatReturnsOpt(value);
> switch (optValue) {
> case Opt.Some<String>(String v) -> System.out.printf("got string: %s%n", v);
> case Opt.None<String> none -> System.out.println("got none");
> default -> System.out.printf("default%n");
> };
> }

> // This does NOT compile: Exhaustive switch without default case + record
> pattern
> public static void thisDoesNotWork(int value) {
> Opt<String> optValue = doSomethingThatReturnsOpt(value);
> switch (optValue) {
> case Opt.Some<String>(String v) -> System.out.printf("got string: %s%n", v);
> case Opt.None<String> none -> System.out.println("got none");
> };
> }

> This is with the latest public JDK 19 build: build 19-ea+32-2220

> I hope I'm posting to the correct list. If this list is for internal Java
> developers only, I'm sorry.

oops, i can reproduce it 

~/jdk/jdk-19.jdk/Contents/Home/bin/javac --enable-preview -source 19 Opt.java 
Opt.java:7: error: the switch statement does not cover all possible input values 
switch (optValue) { 
^ 
Note: Opt.java uses preview features of Java SE 19. 
Note: Recompile with -Xlint:preview for details. 
1 error 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220727/b1f1fc68/attachment.htm>

From brian.goetz at oracle.com  Wed Jul 27 20:04:31 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 Jul 2022 16:04:31 -0400
Subject: Record Pattern Bug in Java 19
In-Reply-To: <CAO7pUDWpmsFo3VQFc=1F5cbucf0ikHNZVgx5FnBD-Ov96=bBRQ@mail.gmail.com>
References: <CAO7pUDWpmsFo3VQFc=1F5cbucf0ikHNZVgx5FnBD-Ov96=bBRQ@mail.gmail.com>
Message-ID: <8718c980-8f83-ec30-f208-c26a7e1bc240@oracle.com>

Thanks for the bug report! This is the right place for bug reports like 
this.

I believe this is the same as a bug we're currently working on; the way 
we've specified exhaustiveness is almost, but not quite, right with 
respect to generics.? Stay tuned for an update.

On 7/27/2022 2:26 PM, Clayton Wohl wrote:
> // The example given in Brian Goetz's article: 
> https://www.infoq.com/articles/data-oriented-programming-java/
> sealed interface Opt<T> {
> ? ? record Some<T>(T value) implements Opt<T> { }
> ? ? record None<T>() implements Opt<T> { }
> }
>
> // This works: Exhaustive switch without default case, but no record 
> pattern
> public static void thisWorks1(int value) {
> ? ? Opt<String> optValue = doSomethingThatReturnsOpt(value);
> ? ? switch (optValue) {
> ? ? ? ? case Opt.Some<String> some -> System.out.printf("got string: 
> %s%n", some.value());
> ? ? ? ? case Opt.None<String> none -> System.out.println("got none");
> ? ? };
> }
>
> // This works: record pattern in a switch statement with a default case.
> public static void thisWorks2(int value) {
> ? ? Opt<String> optValue = doSomethingThatReturnsOpt(value);
> ? ? switch (optValue) {
> ? ? ? ? case Opt.Some<String>(String v) -> System.out.printf("got 
> string: %s%n", v);
> ? ? ? ? case Opt.None<String> none -> System.out.println("got none");
> ? ? ? ? default -> System.out.printf("default%n");
> ? ? };
> }
>
> // This does NOT compile: Exhaustive switch without default case + 
> record pattern
> public static void thisDoesNotWork(int value) {
> ? ? Opt<String> optValue = doSomethingThatReturnsOpt(value);
> ? ? switch (optValue) {
> ? ? ? ? case Opt.Some<String>(String v) -> System.out.printf("got 
> string: %s%n", v);
> ? ? ? ? case Opt.None<String> none -> System.out.println("got none");
> ? ? };
> }
>
> This is with the latest public JDK 19 build: build 19-ea+32-2220
>
> I hope I'm posting to the correct list. If this list is for internal 
> Java developers only, I'm sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220727/2b576a34/attachment.htm>

From jlahoda at openjdk.org  Thu Jul 28 05:54:59 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Jul 2022 05:54:59 GMT
Subject: git: openjdk/amber: desugaring-experiment: 2 new changesets
Message-ID: <f773eeff-8875-4225-b27d-2a194bc8d6eb@openjdk.org>

Changeset: 53581701
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-28 07:53:52 +0000
URL:       https://git.openjdk.org/amber/commit/535817013dbec99a6bea69e6cedb417c696ee4f9

Properly linearizing generated when guards.

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+ test/langtools/tools/javac/patterns/TranslationTest.java

Changeset: 796eea4e
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-28 07:54:11 +0000
URL:       https://git.openjdk.org/amber/commit/796eea4eb7cb7b6172324cdcfca92133e70f32e5

Really calling the original translation.

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java


From jlahoda at openjdk.org  Thu Jul 28 11:36:07 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Jul 2022 11:36:07 GMT
Subject: git: openjdk/amber: desugaring-experiment: Improve categorization code
 by jumping over blocks of same types.
Message-ID: <7bb70cea-b316-4d96-9698-126087bdcc5d@openjdk.org>

Changeset: cf5f4a06
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2022-07-28 11:17:37 +0000
URL:       https://git.openjdk.org/amber/commit/cf5f4a06e505bec3a99a4b07f34fd6b5dc8c40db

Improve categorization code by jumping over blocks of same types.

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java


From vab2048 at gmail.com  Fri Jul 29 21:41:05 2022
From: vab2048 at gmail.com (Vikram Bakshi)
Date: Fri, 29 Jul 2022 22:41:05 +0100
Subject: Resolving methods for all in a sealed hierarchy
Message-ID: <CANExk-6oeEpa6U6Ui7ap-JmrDiAx_Xyx_Ds=MacYoWb2BR=0iQ@mail.gmail.com>

Hello all,

Suppose we have the following sealed hierarchy (I've removed the fields
from the records for brevity):

```java
    sealed interface Command permits A, B, C {}
    public record A() implements Command {}
    public record B() implements Command {}
    public record C() implements Command {}
```

And the following class:

```java
    public class CommandHandler {

        public void handle(A a) { System.out.println("Handling A"); }
        public void handle(B a) { System.out.println("Handling B); }
        public void handle(C a) { System.out.println("Handling C"); }
    }
```

If we then try to pass a `Command` to an instance of `CommandHandler` we
get an error:

```java
        var commandHandler = new CommandHandler();
        Command command = new A();
        commandHandler.handle(command); // ERROR: cannot resolve method
```

Obviously casting it works:

```java
        switch(command) {
            case A cmd-> commandHandler.handle(cmd);
            case B cmd-> commandHandler.handle(cmd);
            case C cmd-> commandHandler.handle(cmd);
        }
```

My question is will the Java compiler ever be able to resolve the method
automatically given that the sealed hierarchy has a corresponding method.

I realise this would be a low priority on your delivery path but was
interested in understanding if there is something that would stop it from
being delivered in the future.

Cheers,
Vikram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220729/c363cd8c/attachment.htm>

From brian.goetz at oracle.com  Fri Jul 29 21:45:08 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 29 Jul 2022 17:45:08 -0400
Subject: Resolving methods for all in a sealed hierarchy
In-Reply-To: <CANExk-6oeEpa6U6Ui7ap-JmrDiAx_Xyx_Ds=MacYoWb2BR=0iQ@mail.gmail.com>
References: <CANExk-6oeEpa6U6Ui7ap-JmrDiAx_Xyx_Ds=MacYoWb2BR=0iQ@mail.gmail.com>
Message-ID: <b8012a7a-945a-e082-873c-1eaa11cb905c@oracle.com>

The three methods in your CommandHandler are overloads.? Method overload 
selection in Java is always done on the _static_ types of the 
arguments.? If you want dispatch on the _dynamic_ type of the argument, 
you have three choices:

 ?- virtual method dispatch (declaration-site polymorphism)
 ?- Visitor pattern (make Command know about CommandHandler, and put a 
handle(handler) method in Command)
 ?- Pattern matching (use-site polymorphism)

Short answer: for your case, use pattern matching.


On 7/29/2022 5:41 PM, Vikram Bakshi wrote:
> Hello all,
>
> Suppose we have the following sealed hierarchy?(I've removed the 
> fields from the records for brevity):
>
> ```java
> ? ? sealed interface Command permits A, B, C {}
> ? ? public record A() implements Command {}
> ? ? public record B() implements Command {}
> ? ? public record C() implements Command {}
> ```
>
> And the following class:
>
> ```java
> ? ? public class CommandHandler {
>
> ? ? ? ? public void handle(A a) { System.out.println("Handling A"); }
> ? ? ? ? public void handle(B a) { System.out.println("Handling B); }
> ? ? ? ? public void handle(C a) { System.out.println("Handling C"); }
> ? ? }
> ```
>
> If we then try to pass a `Command` to an instance of `CommandHandler` 
> we get an error:
>
> ```java
> ? ? ? ? var commandHandler = new CommandHandler();
> ? ? ? ? Command command = new A();
> ? ? ? ? commandHandler.handle(command); // ERROR: cannot resolve method
> ```
>
> Obviously casting it works:
>
> ```java
> ? ? ? ? switch(command) {
> ? ? ? ? ? ? case A cmd-> commandHandler.handle(cmd);
> ? ? ? ? ? ? case B cmd-> commandHandler.handle(cmd);
> ? ? ? ? ? ? case C cmd-> commandHandler.handle(cmd);
> ? ? ? ? }
> ```
>
> My question is will the Java compiler ever be able to resolve the 
> method automatically given that the sealed hierarchy has a 
> corresponding method.
>
> I realise this would be a low priority on your delivery path but was 
> interested in understanding if there is something that would stop it 
> from being delivered in the future.
>
> Cheers,
> Vikram
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220729/7f4b6ca7/attachment-0001.htm>