8225763: Inflater and Deflater should implement AutoCloseable #19675

jaikiran · 2024-06-12T10:45:30Z

Can I please get a review of this enhancement which proposes to enhance java.util.zip.Deflater/Inflater classes to now implement AutoCloseable?

The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:

https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html

To summarize those discussions, we had concluded that:

Deflater and Inflater will implement the AutoCloseable interface
In the close() implementation we will invoke the end() method (end() can be potentially overridden by subclasses).
close() will be specified and implemented to be idempotent. Calling close() a second time or more will be a no-op.
Calling end() and then close(), although uncommon, will also support idempotency and that close() call will be a no-op.
However, calling close() and then end() will not guarantee idempotency and depending on the implementing subclass, the end() may throw an exception.

New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.

I'll file a CSR shortly.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8343768 to be approved

Issues

JDK-8225763: Inflater and Deflater should implement AutoCloseable (Enhancement - P4)
JDK-8343768: Inflater and Deflater should implement AutoCloseable (CSR)

Reviewers

Lance Andersen (@LanceAndersen - Reviewer)
Roger Riggs (@RogerRiggs - Reviewer)
Stuart Marks (@stuart-marks - Reviewer) Review applies to 19f2db96
Alan Bateman (@AlanBateman - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675
$ git checkout pull/19675

Update a local copy of the PR:
$ git checkout pull/19675
$ git pull https://git.openjdk.org/jdk.git pull/19675/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19675

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19675.diff

Using Webrev

Link to Webrev Comment

jaikiran · 2024-06-12T10:45:38Z

/csr needed

bridgekeeper · 2024-06-12T10:46:06Z

👋 Welcome back jpai! 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 · 2024-06-12T10:46:21Z

@jaikiran 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:

8225763: Inflater and Deflater should implement AutoCloseable

Reviewed-by: lancea, rriggs, alanb, smarks

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 18 new commits pushed to the master branch:

06ff4c1: 8347146: Convert IncludeLocalesPluginTest to use JUnit
db76f47: 8347720: [BACKOUT] Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION
e6902cf: 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order
a01e92c: 8347724: Replace SIZE_FORMAT in jfr directory
d002933: 8347286: (fs) Remove some extensions from java/nio/file/Files/probeContentType/Basic.java
d532019: 8347143: [aix] Fix strdup use in os::dll_load
dfd215b: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413
a49f833: 8346045: Cleanup of security library tests calling Security Manager APIs
56c7800: 8347381: Upgrade jQuery UI to version 1.14.1
1c64a45: 8347501: Make static-launcher fails after JDK-8346669
... and 8 more: https://git.openjdk.org/jdk/compare/c1d322fff42720146dfb3846bd7d8514b1bdf383...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this 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.

openjdk · 2024-06-12T10:46:56Z

@jaikiran has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@jaikiran please create a CSR request for issue JDK-8225763 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

openjdk · 2024-06-12T10:47:31Z

@jaikiran 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 · 2024-06-12T10:53:37Z

Webrevs

liach · 2024-06-12T21:07:25Z

src/java.base/share/classes/java/util/zip/Deflater.java

+    @Override
+    public void close() {
+        synchronized (zsRef) {
+            // check if already closed


Should we comment // in case subclasses override the closed check in end() instead? Otherwise the duplicate comments and checks are confusing.

Hello Chen, we want the close() to be idempotent irrespective of whether or not end() is overridden. That check in close() and the code comment on that line is to indicate that. If the comment is adding to confusion, I can remove it - I don't think it's a must to have it to understand the check.

I mean, we have updated the default implementation of end() to be idempotent. It now just appears confusing to readers that close() seems to perform redundant checks for idempotence until they realize subclasses can override end() to make it non-idempotent.

My suggestion is that our comment should say why we have this check here even though there's already an identical check in end().

My suggestion is that our comment should say why we have this check here even though there's already an identical check in end().

I now see what you mean. I'll update this appropriately tomorrow.

liach · 2024-06-12T21:08:11Z

src/java.base/share/classes/java/util/zip/Inflater.java

+    @Override
+    public void close() {
+        synchronized (zsRef) {
+            // check if already closed


Same remark, we should mention subclass override close risk

liach · 2024-06-12T21:08:35Z

test/jdk/java/util/zip/DeflaterClose.java

@@ -0,0 +1,286 @@
+/*
+ * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.


Suggested change

* Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

* Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Same for InflaterClose.java.

Hello Chen, these tests were actually introduced in a RFR back in 2019, so the original year is correct. I've now converted these tests to junit and updated the PR and updated the copyright years as well.

stuart-marks · 2024-06-17T06:52:18Z

Hi Jai, thanks for picking this up. Several points of discussion here. Nothing fatal, but as I said in 2019 :-) just a few wrinkles to iron out. I looked mainly at Deflater, but I think the issues also all apply to Inflater too.

class specification

I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.

end() specification

I don't think that "may throw an exception" is strong enough. Also, on these classes (not subclasses) end() is idemopotent, isn't it? If so, this should be specified. The end() specs need to say something like, closes and releases resources, etc., henceforth operations will throw an exception (which? -- see below) but that subsequent calls to end() do nothing.

Which exceptions on closed Deflater/Inflater?

Oddly, it doesn't seem to be specified anywhere what exceptions are thrown if operations are attempted on a closed object. And the implementation actually throws NPE??!? Ideally we should specify what exception is thrown in this circumstance, but NPE seems wrong. Maybe we want to change the behavior to throw a different exception type. IllegalStateException seems like a reasonable candidate.

close() specification

The 2019 discussion kind of assumed that we want close() to be idempotent. I'm not sure this is necessary. Alan said the implementation might need to be "heroic" but Peter Levart's arrangement (carried through here, apparently) isn't terribly bad. And @liach suggests more comments on this code, quite reasonably... but the comment begs the question, why do we need to avoid calling end() more than once? I'm rethinking the need for close() to be idempotent. Maybe close() should simply call end(). It would simplify the implementation and the specs -- the implSpec would simply say that it calls the end() method.

This would only be a problem if a) some arrangement of TWR ends up calling close() twice, which apparently it doesn't; b) there is a subclass; and c) the subclass's end() method is not idempotent. As far as I can tell we haven't found any example of any of these. It thus seems to me that having extra logic in close() to avoid calling end() more than once is solving a non-problem. It also fits more closely to the model of "close() is simply a synonym for end()".

bridgekeeper · 2024-07-15T09:25:21Z

@jaikiran This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

jaikiran · 2024-07-15T09:31:57Z

Please keep open, I'm running some experiments for the proposed alternative and I'll update this PR shortly.

bridgekeeper · 2024-08-12T12:22:49Z

@jaikiran This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2024-09-09T15:54:14Z

@jaikiran This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

jaikiran · 2024-11-07T14:11:31Z

/open

openjdk · 2024-11-07T14:12:18Z

@jaikiran This pull request is now open

jaikiran · 2024-11-07T14:33:03Z

Thank you Stuart for your inputs.

class specification

I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.

I've now updated the class level javadoc of both Inflater and Deflater to be more explicit on the purpose of close() method and how it relates to the end() method.

end() specification

I don't think that "may throw an exception" is strong enough. Also, on these classes (not subclasses) end() is idemopotent, isn't it? If so, this should be specified. The end() specs need to say something like, closes and releases resources, etc., henceforth operations will throw an exception (which? -- see below) but that subsequent calls to end() do nothing.

I've updated both the end() and close() method javadocs. It now states that end() is idempotent and at the same time states that calling several other methods on a closed Inflater/Deflater will throw a specific exception (noted below). I copied over the sentence which states "Several other methods defined..." from an existing Java SE API.

Which exceptions on closed Deflater/Inflater?

Oddly, it doesn't seem to be specified anywhere what exceptions are thrown if operations are attempted on a closed object. And the implementation actually throws NPE??!? Ideally we should specify what exception is thrown in this circumstance, but NPE seems wrong. Maybe we want to change the behavior to throw a different exception type. IllegalStateException seems like a reasonable candidate.

Yes, it is indeed odd that it's throwing a NullPointerException when ensuring the Inflater/Deflater is open. I have changed that part to throw an IllegalStateException and make a mention of this exception in the end() method specification. Clearly, changing NullPointerException to IllegalStateException is a change in behaviour of public APIs and ideally should be done separately. But, given the context that it gets thrown only from an instance that's already closed (and thus of no real use), I think the chances of this change severly impacting applications is very limited. So, in my opinion, it's perhaps OK to include this change of exception type as part of this change and have it recorded through the same CSR that we use for this current enhancement. Do let me know if we should do that change separately.

close() specification

The 2019 discussion kind of assumed that we want close() to be idempotent. I'm not sure this is necessary. Alan said the implementation might need to be "heroic" but Peter Levart's arrangement (carried through here, apparently) isn't terribly bad. And @liach suggests more comments on this code, quite reasonably... but the comment begs the question, why do we need to avoid calling end() more than once? I'm rethinking the need for close() to be idempotent. Maybe close() should simply call end(). It would simplify the implementation and the specs -- the implSpec would simply say that it calls the end() method.

I ran various corpus experiments. Based on that what I have noticed is that, in that corpus, there are extremely few (less than 10) classes which override end() of either the Inflater or Deflater class. Furthermore, all these implementations have implemented their end() in a manner that calling it more than once will act as a no-op for subsequent invocations. So I think, like you note, we should just specify that close() calls end() and stop trying to prevent end() being called more than once. Given this, I've now updated the PR to do just that and also updated the new tests to match this specification updates.

tier testing is currently in progress for this current state of the PR. If the current state of the PR looks reasonable, then I'll focus on the CSR text for these changes.

RogerRiggs · 2024-11-07T14:28:34Z

src/java.base/share/classes/java/util/zip/Deflater.java

+     * @since 24
+     */
+    @Override
+    public void close() {


Can/should this method be final? The real/original cleanup method is end and if both close() and end() are overriddable, there may be some confusion about which to implement.

Hello Roger, I think that's a good idea. At least until there is a real reason for close() to be overridden by subclasses. I went back and checked the mailing list discussions (linked in this PR description) and I don't think marking close() as final has been suggested or rejected before. I will give others a chance to provide their inputs before I do this change.

I agree with marking these close methods as final as long as the previous corpus search did not find any user-defined close method in subclasses.

Hello Chen, corpus analysis shows that there are no subclasses of Inflater/Deflater which have a close() method.

Great news! Feel free to make their close final.

I have updated the PR to follow Roger's suggestion of marking this new close() method on Inflater and Deflater classes as final.

RogerRiggs · 2024-11-07T14:34:23Z

src/java.base/share/classes/java/util/zip/Inflater.java

+     * @since 24
+     */
+    @Override
+    public void close() {


Ditto, should this be final to be clear about what should be overridden to perform cleanup.

Inflater/Deflater date from JDK 1.1 so I think there is some risk to adding a final no-arg close method. I understand that a corpus analysis has been done, and the intention of making it final is for subclasses to know which method to override, but it doesn't take from the possibility that it might break subclasses developed years ago. If it goes ahead as reviewed, then we'll to do some outreach and be prepared to back out this change in the event that breakage is reported before GA.

Hello Alan,

If it goes ahead as reviewed, then we'll to do some outreach and be prepared to back out this change in the event that breakage is reported before GA.

I agree that if the final close() causes issues, then backing this change out and reconsidering a non-final close() would be the right thing to do. Once/if this gets integrated into 24, I will work with the outreach team to have this change noted in their EA mails.

Adding a final close method is both source and binary incompatible so I don't think the CSR can be approved without more justification. So I think the issues of introducing a non-final close should be examined again.

Hello Alan, I've now reverted the change which had marked this new close() method on Inflater and Deflater as final. With this update to this PR, this method is no longer final. Given this change, one additional sentence has been added to the Inflater/Deflater class level javadoc, in @apiNote section providing guidance to the subclasses on which method to override for cleaning up resources they hold:

Subclasses should override {@linkplain #end()} to clean up the resources acquired by the subclass.

No other changes have been done.

Requesting your and other's inputs if this updated change looks reasonable.

tmccombs · 2025-01-07T16:30:32Z

Please keep open

RogerRiggs · 2025-01-07T20:37:32Z

src/java.base/share/classes/java/util/zip/Deflater.java

@@ -799,6 +812,8 @@ public int getAdler() {
     * and therefore cannot return the correct value when it is greater
     * than {@link Integer#MAX_VALUE}.
     *
+     * @throws IllegalStateException if the Deflater is closed


@throws should follow @return; (Style notes in https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html).

Done - I've updated the PR to fix this and the other places that were introduced in this PR to follow that style guide.

RogerRiggs · 2025-01-07T20:37:59Z

src/java.base/share/classes/java/util/zip/Deflater.java

@@ -829,6 +845,8 @@ public long getBytesRead() {
     * and therefore cannot return the correct value when it is greater
     * than {@link Integer#MAX_VALUE}.
     *
+     * @throws IllegalStateException if the Deflater is closed


Ditto @throws throws should follow @return

RogerRiggs · 2025-01-07T20:41:02Z

src/java.base/share/classes/java/util/zip/Inflater.java

@@ -646,6 +660,8 @@ public long getBytesRead() {
     * and therefore cannot return the correct value when it is greater
     * than {@link Integer#MAX_VALUE}.
     *
+     * @throws IllegalStateException if the Inflater is closed


Ditto @throws should follow @return

LanceAndersen

Overall looks good Jai.

Roger is right on moving the @throws IAE further down

RogerRiggs

Thanks for the updates.

jaikiran · 2025-01-14T06:20:22Z

Thank you all for the reviews and the inputs. The CSR has been approved. I'll go ahead and integrate this shortly.

AlanBateman · 2025-01-14T06:35:04Z

src/java.base/share/classes/java/util/zip/Deflater.java

@@ -49,29 +49,33 @@
 * thrown.
 * <p>
 * This class deflates sequences of bytes into ZLIB compressed data format.
- * The input byte sequence is provided in either byte array or byte buffer,
+ * The input byte sequence is provided in either byte array or {@link ByteBuffer},


We should probably fix this sentence to say "in either a byte array or ...".

AlanBateman · 2025-01-14T08:14:21Z

src/java.base/share/classes/java/util/zip/Deflater.java

+ * To release resources used by the {@code Deflater}, applications must close the
+ * {@code Deflater} by calling either the {@link #end()} or the {@link #close()} method.
+ * After the {@code Deflater} has been closed, subsequent calls to several methods
+ * of the {@code Deflater} will throw an {@link IllegalStateException}.


This paragraph uses the definite article but there isn't a specific Deflater to speak of, and it's not a singleton. The first sentence of this paragraph might be better if re-worded "To release the resources used a Deflater, an application must close it by invoking its end() or close() method".

I have reworded the sentence to follow your input. Addtionally, I've removed the second sentence, since as you note, relevant methods on the Inflater/Deflater (as part of this PR) already have been updated to state that they throw an IllegalStateException if the Inflater/Deflater is already closed.

AlanBateman · 2025-01-14T08:16:11Z

src/java.base/share/classes/java/util/zip/Deflater.java

+     * Closes and releases the resources held by this {@code Deflater}
+     * and discards any unprocessed input.
+     * <p>
+     * If this method is invoked multiple times, the second and subsequent calls do nothing.


I think this could be clearer if you replace this sentence with "If the Deflater is already closed then invoking this method has no effect."

AlanBateman · 2025-01-14T08:18:57Z

src/java.base/share/classes/java/util/zip/Deflater.java

+ * This class implements {@link AutoCloseable} to facilitate its usage with
+ * {@code try}-with-resources statement. The {@linkplain Deflater#close() close() method} simply
+ * calls {@code end()}. Subclasses should override {@linkplain #end()} to clean up the
+ * resources acquired by the subclass.


I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note.

I believe an @implSpec only restricts the implementation of this immediate method, such as those seen on default methods, and has no impact on the overrides. If we need to specify something for overrides to abide to, I believe they usually stay in the API specification itself.

I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note.

Stuart, in his inputs here #19675 (comment) and here #19675 (comment) had noted that it would be useful to add this guidance to subclasses. But I see that he wasn't fully convinced whether it must be a apiNote or something else. Given what you note about moving this detail for subclasses to a @implSpec on the end() method, I have now updated the PR accordingly.

Hello Chen,

I believe an @implSpec only restricts the implementation of this immediate method, such as those seen on default methods, and has no impact on the overrides.

Based on the details about these tags here https://openjdk.org/jeps/8068562, I think the @implSpec is the most relevant one for this text:

Interface implementors or class subclassers use the information here in order to decide whether it is sensible or necessary to override a particular method

AlanBateman

Thanks for the updates, looks good now.

LanceAndersen

Latest Updates look good Jai

jaikiran · 2025-01-15T01:03:48Z

Thank you all for the reviews. tier1, tier2 and tier3 tests pass with this change. I'll now go ahead and integrate this.

jaikiran · 2025-01-15T01:04:05Z

/integrate

openjdk · 2025-01-15T01:04:44Z

Going to push as commit 36b7abd.
Since your change was applied there have been 26 commits pushed to the master branch:

d6d45c6: 8303884: jlink --add-options plugin does not allow GNU style options to be provided
0ee6ba9: 8347596: Update HSS/LMS public key encoding
ec2aaaa: 8326236: assert(ce != nullptr) failed in Continuation::continuation_bottom_sender
02d2493: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java
10d08db: 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload
9b1bed0: 8290043: serviceability/attach/ConcAttachTest.java failed "guarantee(!CheckJNICalls) failed: Attached JNI thread exited without being detached"
2de71d0: 8347129: cpuset cgroups controller is required for no good reason
4c30933: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large index is out of bounds
06ff4c1: 8347146: Convert IncludeLocalesPluginTest to use JUnit
db76f47: 8347720: [BACKOUT] Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION
... and 16 more: https://git.openjdk.org/jdk/compare/c1d322fff42720146dfb3846bd7d8514b1bdf383...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-01-15T01:04:51Z

@jaikiran Pushed as commit 36b7abd.

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

8225763: Inflater and Deflater should implement AutoCloseable

d4f965b

openjdk bot added the csr Pull request needs approved CSR before integration label Jun 12, 2024

openjdk bot added the core-libs core-libs-dev@openjdk.org label Jun 12, 2024

fix whitespace

6e32965

openjdk bot added the rfr Pull request is ready for review label Jun 12, 2024

liach reviewed Jun 12, 2024

View reviewed changes

jaikiran added 2 commits June 13, 2024 12:11

convert the tests to junit

79e68e9

Chen's suggestion - improve code comment

4a52fe2

bridgekeeper bot closed this Sep 9, 2024

jaikiran added 5 commits October 20, 2024 12:54

merge latest from master branch

6eb8975

merge latest from master branch

8bd9d59

Stuart's review - improve class level javadoc

2aa87f9

Stuart's review - update the close() and end() expectations

f12829f

update tests to match the new specification

c4e84dd

openjdk bot reopened this Nov 7, 2024

RogerRiggs reviewed Nov 7, 2024

View reviewed changes

RogerRiggs reviewed Jan 7, 2025

View reviewed changes

LanceAndersen reviewed Jan 7, 2025

View reviewed changes

fix javadoc tag ordering - "@throws" after "@return"

4fbbc83

LanceAndersen approved these changes Jan 8, 2025

View reviewed changes

RogerRiggs approved these changes Jan 8, 2025

View reviewed changes

openjdk bot added ready Pull request is ready to be integrated and removed csr Pull request needs approved CSR before integration labels Jan 14, 2025

jaikiran added 2 commits January 14, 2025 07:18

merge latest from master branch

5f4d635

merge latest from master branch

fa16d8d

AlanBateman reviewed Jan 14, 2025

View reviewed changes

jaikiran added 3 commits January 14, 2025 13:57

add missing "a" in the javadoc

8e66632

Alan's input - simplify the class level javadoc

d0b92ad

Improve the javadoc on #end() methods

1cd16c4

openjdk bot removed the ready Pull request is ready to be integrated label Jan 14, 2025

Move the guidance to subclasses to the end() method

45bad0e

AlanBateman approved these changes Jan 14, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 14, 2025

LanceAndersen approved these changes Jan 14, 2025

View reviewed changes

RogerRiggs approved these changes Jan 14, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jan 15, 2025

openjdk bot closed this Jan 15, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 15, 2025

jaikiran deleted the 8225763 branch January 15, 2025 01:08

		@@ -0,0 +1,286 @@
		/*
		* Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

	* Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
	* Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

8225763: Inflater and Deflater should implement AutoCloseable #19675

8225763: Inflater and Deflater should implement AutoCloseable #19675

Conversation

jaikiran commented Jun 12, 2024 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Reviewing

jaikiran commented Jun 12, 2024

bridgekeeper bot commented Jun 12, 2024

openjdk bot commented Jun 12, 2024 • edited Loading

openjdk bot commented Jun 12, 2024

openjdk bot commented Jun 12, 2024

mlbridge bot commented Jun 12, 2024 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stuart-marks commented Jun 17, 2024

bridgekeeper bot commented Jul 15, 2024

jaikiran commented Jul 15, 2024

bridgekeeper bot commented Aug 12, 2024

bridgekeeper bot commented Sep 9, 2024

jaikiran commented Nov 7, 2024

openjdk bot commented Nov 7, 2024

jaikiran commented Nov 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaikiran Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

tmccombs commented Jan 7, 2025 • edited by bridgekeeper bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LanceAndersen left a comment

Choose a reason for hiding this comment

RogerRiggs left a comment

Choose a reason for hiding this comment

jaikiran commented Jan 14, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlanBateman left a comment

Choose a reason for hiding this comment

LanceAndersen left a comment

Choose a reason for hiding this comment

jaikiran commented Jan 15, 2025

jaikiran commented Jan 15, 2025

openjdk bot commented Jan 15, 2025

openjdk bot commented Jan 15, 2025

jaikiran commented Jun 12, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Jun 12, 2024 •

edited

Loading

mlbridge bot commented Jun 12, 2024 •

edited

Loading

jaikiran Dec 2, 2024 •

edited

Loading

tmccombs commented Jan 7, 2025 •

edited by bridgekeeper bot

Loading