Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 7 commits into from

Conversation

@jddarcy
Copy link
Member

@jddarcy jddarcy commented May 20, 2021

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

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
Copy link
Member Author

@jddarcy jddarcy commented May 20, 2021

/csr

Loading

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 20, 2021

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

Loading

@openjdk openjdk bot added the rfr label May 20, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 20, 2021

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

Loading

@openjdk openjdk bot added the csr label May 20, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 20, 2021

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

Loading

@openjdk openjdk bot added the core-libs label May 20, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2021

Loading

@AlanBateman
Copy link
Contributor

@AlanBateman AlanBateman commented May 20, 2021

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.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2021

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:

Loading

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2021

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:

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2021

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

Loading

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2021

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

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 21, 2021

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

Loading

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 21, 2021

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

Loading

@jddarcy
Copy link
Member Author

@jddarcy jddarcy commented May 21, 2021

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

Loading

* @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");
Copy link
Contributor

@AlanBateman AlanBateman May 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 23, 2021

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

Loading

@remkop
Copy link

@remkop remkop commented May 24, 2021

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!)

Loading

@kaspernielsen
Copy link

@kaspernielsen kaspernielsen commented May 24, 2021

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.

Loading

copybara-service bot pushed a commit to google/guava that referenced this issue May 24, 2021
…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
copybara-service bot pushed a commit to google/guava that referenced this issue May 24, 2021
…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
copybara-service bot pushed a commit to google/guava that referenced this issue May 24, 2021
…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
Copy link

@mlbridge mlbridge bot commented May 24, 2021

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

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 24, 2021

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

Loading

copybara-service bot pushed a commit to google/guava that referenced this issue May 24, 2021
…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
Copy link
Contributor

@AlanBateman AlanBateman left a comment

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

Loading

@jddarcy jddarcy changed the title 8224243: Make AccessibleObject a sealed class 8224243: Add implSpec's to AccessibleObject and seal Executable May 25, 2021
@openjdk openjdk bot removed the csr label May 25, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 25, 2021

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

Loading

@openjdk openjdk bot added the ready label May 25, 2021
@jddarcy
Copy link
Member Author

@jddarcy jddarcy commented May 25, 2021

/integrate

Loading

@openjdk openjdk bot closed this May 25, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels May 25, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 25, 2021

@jddarcy Pushed as commit 0b77359.

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

Loading

@jddarcy jddarcy deleted the 8224243 branch Jun 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants