8224243: Add implSpec's to AccessibleObject and seal Executable #4133

jddarcy · 2021-05-20T17:14:57Z

Conceptually, AccessbileObject is a sealed class with a protected constructor stating

Constructor: only used by the Java Virtual Machine.

With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.

Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.

Please also review the corresponding CSR:

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

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8224243: Add implSpec's to AccessibleObject and seal Executable

Reviewers

Alan Bateman (@AlanBateman - Reviewer) ⚠️ Review applies to 8d0ba44

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4133/head:pull/4133
$ git checkout pull/4133

Update a local copy of the PR:
$ git checkout pull/4133
$ git pull https://git.openjdk.java.net/jdk pull/4133/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4133

View PR using the GUI difftool:
$ git pr show -t 4133

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4133.diff

jddarcy · 2021-05-20T17:15:10Z

/csr

bridgekeeper · 2021-05-20T17:15:53Z

👋 Welcome back darcy! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-05-20T17:17:30Z

@jddarcy this pull request will not be integrated until the CSR request JDK-8267506 for issue JDK-8224243 has been approved.

openjdk · 2021-05-20T17:20:48Z

@jddarcy The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-05-20T17:26:14Z

Webrevs

AlanBateman · 2021-05-20T17:31:12Z

I think this will require reaching out to Google Guava, I think its their Invokable API that extends AccessibleObject outside of the JDK. We ran this when doing the module system where we didn't initially take into account sub-classes that were outside of java.base.

mlbridge · 2021-05-20T22:01:05Z

Mailing list message from Éamonn McManus on core-libs-dev:

Thanks for the tip, Alan. Guava's public Invokable
<https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html>
class does inherit from AccessibleObject. It would probably not be too hard
to make it stop doing so. That's technically a breaking API change, but the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
<https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html>.
That's not to say that nobody else does it, but apparently cases are rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

On Thu, 20 May 2021 at 10:36, Alan Bateman <alanb at openjdk.java.net> wrote:

mlbridge · 2021-05-20T22:01:07Z

Mailing list message from Éamonn McManus on core-libs-dev:

Thanks for the tip, Alan. Guava's public Invokable
<https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html>
class does inherit from AccessibleObject. It would probably not be too hard
to make it stop doing so. That's technically a breaking API change, but the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
<https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html>.
That's not to say that nobody else does it, but apparently cases are rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

On Thu, 20 May 2021 at 10:36, Alan Bateman <alanb at openjdk.java.net> wrote:

mlbridge · 2021-05-20T22:49:04Z

Mailing list message from Joe Darcy on core-libs-dev:

Hi ?amonn,

On 5/20/2021 2:59 PM, ?amonn McManus wrote:

Thanks for the tip, Alan. Guava's public Invokable
<https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html>
class does inherit from AccessibleObject. It would probably not be too hard
to make it stop doing so. That's technically a breaking API change, but the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
<https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html>.
That's not to say that nobody else does it, but apparently cases are rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

The intent of the constructor's text to me implies the class is not
intended to be subclassed outside of the JDK. (I'm not sure why the
constructor isn't package private as all its subclasses are in the same
package which would have accomplished that, but the SCM history from
circa JDK 1.2 would need to be consulted for guidance.)

The original impetus for 8224243 was the implementation of certain
overridable methods in AccessibleObject (getAnnotation,
getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing
their behavior. The behavior is to thrown an error as the method should
be overridden in the subclasses. If all the subclasses are within the
JDK and the class is sealed, that @implSpec'ing need not occur.

If all the subclasses were in the JDK (which we know is not that case),
it is preferable to avoid the @implSpec'ing throwing the exception as
that is just an implementation-internal comment.

HTH,

-Joe

mlbridge · 2021-05-20T22:49:06Z

Mailing list message from Joe Darcy on core-libs-dev:

Hi ?amonn,

On 5/20/2021 2:59 PM, ?amonn McManus wrote:

Thanks for the tip, Alan. Guava's public Invokable
<https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html>
class does inherit from AccessibleObject. It would probably not be too hard
to make it stop doing so. That's technically a breaking API change, but the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
<https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html>.
That's not to say that nobody else does it, but apparently cases are rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

The intent of the constructor's text to me implies the class is not
intended to be subclassed outside of the JDK. (I'm not sure why the
constructor isn't package private as all its subclasses are in the same
package which would have accomplished that, but the SCM history from
circa JDK 1.2 would need to be consulted for guidance.)

The original impetus for 8224243 was the implementation of certain
overridable methods in AccessibleObject (getAnnotation,
getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing
their behavior. The behavior is to thrown an error as the method should
be overridden in the subclasses. If all the subclasses are within the
JDK and the class is sealed, that @implSpec'ing need not occur.

If all the subclasses were in the JDK (which we know is not that case),
it is preferable to avoid the @implSpec'ing throwing the exception as
that is just an implementation-internal comment.

HTH,

-Joe

mlbridge · 2021-05-21T00:50:06Z

Mailing list message from Éamonn McManus on core-libs-dev:

Hi Joe,

I see that I blogged
<https://www.artima.com/weblogs/viewpost.jsp?thread=164042> about
AccessibleObject in 2006 and already complained about its protected
constructor back then. :-)

Still, if the main motivation of sealing it is to avoid adding @implSpec to
a few methods, perhaps it would be better just to bite the bullet and do
that? We can fix Guava's Invokable class so it no longer inherits from
AccessibleObject, and I think we probably should, but it would still be the
case that an app using a version of Guava from before the fix would fail
when deployed to a JDK with this change.

Thanks,
?amonn

On Thu, 20 May 2021 at 15:47, Joe Darcy <joe.darcy at oracle.com> wrote:

Hi ?amonn,

On 5/20/2021 2:59 PM, ?amonn McManus wrote:

Thanks for the tip, Alan. Guava's public Invokable
<
https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html

class does inherit from AccessibleObject. It would probably not be too
hard
to make it stop doing so. That's technically a breaking API change, but
the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
<https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html
.
That's not to say that nobody else does it, but apparently cases are
rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

The intent of the constructor's text to me implies the class is not
intended to be subclassed outside of the JDK. (I'm not sure why the
constructor isn't package private as all its subclasses are in the same
package which would have accomplished that, but the SCM history from
circa JDK 1.2 would need to be consulted for guidance.)

The original impetus for 8224243 was the implementation of certain
overridable methods in AccessibleObject (getAnnotation,
getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing
their behavior. The behavior is to thrown an error as the method should
be overridden in the subclasses. If all the subclasses are within the
JDK and the class is sealed, that @implSpec'ing need not occur.

If all the subclasses were in the JDK (which we know is not that case),
it is preferable to avoid the @implSpec'ing throwing the exception as
that is just an implementation-internal comment.

HTH,

-Joe

mlbridge · 2021-05-21T00:50:07Z

Mailing list message from Éamonn McManus on core-libs-dev:

Hi Joe,

I see that I blogged
<https://www.artima.com/weblogs/viewpost.jsp?thread=164042> about
AccessibleObject in 2006 and already complained about its protected
constructor back then. :-)

Still, if the main motivation of sealing it is to avoid adding @implSpec to
a few methods, perhaps it would be better just to bite the bullet and do
that? We can fix Guava's Invokable class so it no longer inherits from
AccessibleObject, and I think we probably should, but it would still be the
case that an app using a version of Guava from before the fix would fail
when deployed to a JDK with this change.

Thanks,
?amonn

On Thu, 20 May 2021 at 15:47, Joe Darcy <joe.darcy at oracle.com> wrote:

Hi ?amonn,

On 5/20/2021 2:59 PM, ?amonn McManus wrote:

Thanks for the tip, Alan. Guava's public Invokable
<
https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html

class does inherit from AccessibleObject. It would probably not be too
hard
to make it stop doing so. That's technically a breaking API change, but
the
class is marked @Beta so that's fair game.

I looked in Google's code base and I found one other project that extends
AccessibleObject, picocli, here
<https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html
.
That's not to say that nobody else does it, but apparently cases are
rare.

I do wonder what the purpose of the change would be. The constructor
javadoc text doesn't say you *can't* extend this class. Is there some
benefit from making it not work anymore?

The intent of the constructor's text to me implies the class is not
intended to be subclassed outside of the JDK. (I'm not sure why the
constructor isn't package private as all its subclasses are in the same
package which would have accomplished that, but the SCM history from
circa JDK 1.2 would need to be consulted for guidance.)

The original impetus for 8224243 was the implementation of certain
overridable methods in AccessibleObject (getAnnotation,
getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing
their behavior. The behavior is to thrown an error as the method should
be overridden in the subclasses. If all the subclasses are within the
JDK and the class is sealed, that @implSpec'ing need not occur.

If all the subclasses were in the JDK (which we know is not that case),
it is preferable to avoid the @implSpec'ing throwing the exception as
that is just an implementation-internal comment.

HTH,

-Joe

jddarcy · 2021-05-21T02:42:57Z

Pushed an updated version of the fix that deprecates the AccessibleObject constructor, adds the @implSpec tags, and makes Executable a sealed class.

AlanBateman · 2021-05-22T16:37:51Z

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java

     * @throws NullPointerException {@inheritDoc}
     * @since 1.5
     */
    @Override
    public <T extends Annotation> T getAnnotation(Class<T> annotationClass) {
-        throw new AssertionError("All subclasses should override this method");
+        throw new IllegalStateException("All subclasses should override this method");


I'm not sure that ISE is the most appropriate exception here because there isn't an alternative state that would accept the input. UOE might be better.

The new proposal to just seal Executable looks reasonable.

mlbridge · 2021-05-23T17:18:35Z

Mailing list message from Kasper Nielsen on core-libs-dev:

On Fri, 21 May 2021 at 03:44, Joe Darcy <darcy at openjdk.java.net> wrote:

Conceptually, AccessbileObject is a sealed class with a protected
constructor stating
Constructor\: only used by the Java Virtual Machine\.
With the language now supporting sealed classes, the AccessbileObject
should be marked as sealed.

Executable and Field are the subclasses of AccessbileObject in the JDK;
as Executable has subclasses, it is marked as non-sealed.

Please also review the corresponding CSR:

https://bugs.openjdk.java.net/browse/JDK-8224243
Joe Darcy has updated the pull request incrementally with one additional
commit since the last revision:

Update in response to review feedback.

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

The implementation of setAccessible(boolean) is identical on both
Method/Constructor/Field so it could probably be pulled down into
AccessibleObject, similar to trySetAccessible().

/Kasper

remkop · 2021-05-24T08:47:08Z

Hi all, I am the author of picocli.

I will look into moving away from extending AccessibleObject in picocli, but Éamonn McManus's comment about Guava equally applies to picocli: even with such a change, older versions of the library would fail on JDK 17.

So, thank you for reconsidering sealing AccessibleObject and choosing to seal Executable instead. That is a relief. :-)

(And many thanks to @kaspernielsen for making me aware of this issue!)

kaspernielsen · 2021-05-24T08:59:30Z

Missed the part about only Executable being made sealed. But if Executable is sealed, setAccessible(boolean) could still be moved from Method/Constructor down to Executable.

…ct`. There was no strong reason for this inheritance. Additionally, it is an accident that `AccessibleObject` is subclassable at all outside its class; its constructor is `protected` but should really have been package-private. That's an API mistake that was made in Java 1.2 and is hard to correct now, but the protected constructor is [being deprecated](openjdk/jdk#4133). (My related rant from 15 years ago is [here](https://www.artima.com/weblogs/viewpost.jsp?thread=164042).) `Invokable` also no longer implements `GenericDeclaration`. `Invokable` does continue to provide instance methods with the same signatures as the ones inherited from `AccessibleObject` and `GenericDeclaration`, as they stood in Java 8. This change is technically a breaking API change. In principle users could have assigned an instance of `Invokable` to a variable of type `AccessibleObject`. No code does that in Google's giant code base so it seems unlikely in practice. (In fact we only have a couple of dozen uses of `Invokable` overall.) Also, this API is `@Beta` so a hypothetical-but-very-unlikely breakage is acceptable. RELNOTES=`Invokable` no longer inherits from `AccessibleObject` or `GenericDeclaration`, though it continues to define instance methods with the same signatures as the formerly-inherited ones. This is technically a breaking API change to this `@Beta` API. We think it very unlikely that anyone is affected in practice. PiperOrigin-RevId: 375191535

mlbridge · 2021-05-24T22:04:36Z

Mailing list message from Joe Darcy on core-libs-dev:

Hi Alan,

On 5/22/2021 9:41 AM, Alan Bateman wrote:

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:
Conceptually, AccessbileObject is a sealed class with a protected constructor stating
 Constructor\: only used by the Java Virtual Machine\.
With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.

Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.

Please also review the corresponding CSR:

https://bugs.openjdk.java.net/browse/JDK-8224243
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Update in response to review feedback.
src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 533:
531: @Override
532: public <T extends Annotation> T getAnnotation(Class<T> annotationClass) {
533: throw new IllegalStateException("All subclasses should override this method");
I'm not sure that ISE is the most appropriate exception here because there isn't an alternative state that would accept the input. UOE might be better.

The new proposal to just seal Executable looks reasonable.

Yeah; I was looking over which exception type to use. On the whole, UOE
looks a bit better; I've updated the PR accordingly.

Thanks,

-Joe

mlbridge · 2021-05-24T22:04:38Z

Mailing list message from Joe Darcy on core-libs-dev:

On 5/24/2021 2:05 AM, Kasper Nielsen wrote:

On Fri, 21 May 2021 02:42:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:
Conceptually, AccessbileObject is a sealed class with a protected constructor stating
 Constructor\: only used by the Java Virtual Machine\.
With the language now supporting sealed classes, the AccessbileObject should be marked as sealed.

Executable and Field are the subclasses of AccessbileObject in the JDK; as Executable has subclasses, it is marked as non-sealed.

Please also review the corresponding CSR:

https://bugs.openjdk.java.net/browse/JDK-8224243
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Update in response to review feedback.
Missed the part about only Executable being made sealed. But if Executable is sealed, setAccessible(boolean) could still be moved from Method/Constructor down to Executable.

Perhaps; the caller sensitive nature of the methods may preclude or
complicate that. I don't plan to add such method hoisting to this PR.

Thanks,

-Joe

…ct`. There was no strong reason for this inheritance. Additionally, it is an accident that `AccessibleObject` is subclassable at all outside its class; its constructor is `protected` but should really have been package-private. That's an API mistake that was made in Java 1.2 and is hard to correct now, but the protected constructor is [being deprecated](openjdk/jdk#4133). (My related rant from 15 years ago is [here](https://www.artima.com/weblogs/viewpost.jsp?thread=164042).) `Invokable` also no longer implements `GenericDeclaration`. `Invokable` does continue to provide instance methods with the same signatures as the ones inherited from `AccessibleObject` and `GenericDeclaration`, as they stood in Java 8. This change is technically a breaking API change. In principle users could have assigned an instance of `Invokable` to a variable of type `AccessibleObject`. No code does that in Google's giant code base so it seems unlikely in practice. (In fact we only have a couple of dozen uses of `Invokable` overall.) Also, this API is `@Beta` so a hypothetical-but-very-unlikely breakage is acceptable. RELNOTES=`Invokable` no longer inherits from `AccessibleObject` or `GenericDeclaration`, though it continues to define instance methods with the same signatures as the formerly-inherited ones. This is technically a breaking API change to this `@Beta` API. We think it very unlikely that anyone is affected in practice. PiperOrigin-RevId: 375566405

AlanBateman

The updated proposal looks good although the JBS issue should probably be renamed as the proposal is no longer to seal AccessibleObject.

openjdk · 2021-05-25T17:54:22Z

@jddarcy This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8224243: Add implSpec's to AccessibleObject and seal Executable

Reviewed-by: alanb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

jddarcy · 2021-05-25T18:03:47Z

/integrate

openjdk · 2021-05-25T18:05:14Z

@jddarcy Pushed as commit 0b77359.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8224243: Make AccessibleObject a sealed class

f605cfa

openjdk bot added the rfr Pull request is ready for review label May 20, 2021

openjdk bot added the csr Pull request needs approved CSR before integration label May 20, 2021

openjdk bot added the core-libs core-libs-dev@openjdk.org label May 20, 2021

Update in response to review feedback.

be517cd

AlanBateman reviewed May 22, 2021

View reviewed changes

kaspernielsen mentioned this pull request May 23, 2021

java.lang.reflect.AccessibleObject to be sealed in Java 17 remkop/picocli#1372

Closed

jddarcy added 3 commits May 24, 2021 11:33

Merge branch 'master' into 8224243

98be7fb

Change to UnsupportedOperationException.

66a4aeb

Minor fixes.

8d0ba44

copybara-service bot mentioned this pull request May 24, 2021

Invokable no longer inherits from java.lang.reflect.AccessibleObject. google/guava#5569

Merged

AlanBateman approved these changes May 25, 2021

View reviewed changes

jddarcy changed the title ~~8224243: Make AccessibleObject a sealed class~~ 8224243: Add implSpec's to AccessibleObject and seal Executable May 25, 2021

openjdk bot removed the csr Pull request needs approved CSR before integration label May 25, 2021

openjdk bot added the ready Pull request is ready to be integrated label May 25, 2021

jddarcy added 2 commits May 25, 2021 10:59

Merge branch 'master' into 8224243

9811a16

Update copyright.

2d8d2cd

openjdk bot closed this May 25, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 25, 2021

jddarcy deleted the 8224243 branch June 10, 2021 20:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8224243: Add implSpec's to AccessibleObject and seal Executable #4133

8224243: Add implSpec's to AccessibleObject and seal Executable #4133

jddarcy commented May 20, 2021 •

edited by openjdk bot

Loading

jddarcy commented May 20, 2021

bridgekeeper bot commented May 20, 2021

openjdk bot commented May 20, 2021

openjdk bot commented May 20, 2021

mlbridge bot commented May 20, 2021 •

edited

Loading

AlanBateman commented May 20, 2021 •

edited

Loading

mlbridge bot commented May 20, 2021

mlbridge bot commented May 20, 2021

mlbridge bot commented May 20, 2021

mlbridge bot commented May 20, 2021

mlbridge bot commented May 21, 2021

mlbridge bot commented May 21, 2021

jddarcy commented May 21, 2021

AlanBateman May 22, 2021

mlbridge bot commented May 23, 2021

remkop commented May 24, 2021 •

edited by bridgekeeper bot

Loading

kaspernielsen commented May 24, 2021 •

edited by bridgekeeper bot

Loading

mlbridge bot commented May 24, 2021

mlbridge bot commented May 24, 2021

AlanBateman left a comment •

edited

Loading

openjdk bot commented May 25, 2021 •

edited

Loading

jddarcy commented May 25, 2021

openjdk bot commented May 25, 2021

8224243: Add implSpec's to AccessibleObject and seal Executable #4133

8224243: Add implSpec's to AccessibleObject and seal Executable #4133

Conversation

jddarcy commented May 20, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

jddarcy commented May 20, 2021

bridgekeeper bot commented May 20, 2021

openjdk bot commented May 20, 2021

openjdk bot commented May 20, 2021

mlbridge bot commented May 20, 2021 • edited Loading

Webrevs

AlanBateman commented May 20, 2021 • edited Loading

mlbridge bot commented May 20, 2021

mlbridge bot commented May 20, 2021

mlbridge bot commented May 20, 2021

mlbridge bot commented May 20, 2021

mlbridge bot commented May 21, 2021

mlbridge bot commented May 21, 2021

jddarcy commented May 21, 2021

AlanBateman May 22, 2021

Choose a reason for hiding this comment

mlbridge bot commented May 23, 2021

remkop commented May 24, 2021 • edited by bridgekeeper bot Loading

kaspernielsen commented May 24, 2021 • edited by bridgekeeper bot Loading

mlbridge bot commented May 24, 2021

mlbridge bot commented May 24, 2021

AlanBateman left a comment • edited Loading

Choose a reason for hiding this comment

openjdk bot commented May 25, 2021 • edited Loading

jddarcy commented May 25, 2021

openjdk bot commented May 25, 2021

jddarcy commented May 20, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented May 20, 2021 •

edited

Loading

AlanBateman commented May 20, 2021 •

edited

Loading

remkop commented May 24, 2021 •

edited by bridgekeeper bot

Loading

kaspernielsen commented May 24, 2021 •

edited by bridgekeeper bot

Loading

AlanBateman left a comment •

edited

Loading

openjdk bot commented May 25, 2021 •

edited

Loading