8330954: since-checker - Fix remaining @ since tags in java.base #18954

nizarbenalla · 2024-04-25T14:29:27Z

Please review this PR that aims to add all the remaining needed @since tags in java.base, and group them into a single fix.
This is related to #18934 and my work around the @since checker feature.
Explicit @since tags are needed for some overriding methods for the purpose of the checker.

I will only give the example with the CompletableFuture class but here is the before where the methods only appeared in "Methods declared in interface N"

and after where the method has it's own javadoc, the main description is added and the @since tags are added as intended.

I don't have an account on https://cr.openjdk.org/ but I could host the generated docs somewhere if that is needed.

TIA

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

Issue

JDK-8330954: since-checker - Fix remaining @ since tags in java.base (Sub-task - P4)

Reviewers

Chen Liang (@liach - Committer)
Naoto Sato (@naotoj - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18954

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

Using diff file

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

Webrev

Link to Webrev Comment

bridgekeeper · 2024-04-25T14:30:31Z

👋 Welcome back nizarbenalla! 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-04-25T14:31:56Z

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

8330954: since-checker - Fix remaining @ since tags in java.base

Reviewed-by: liach, naoto

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

3050ba0: 8335654: Remove stale hyperlink in divnode.cpp
da0ffa8: 8334031: Generated JfrNativeSettings seems off
b0efd77: 8314653: Metaspace: remove allocation guard feature
6a47279: 8332072: Convert package.html files in java.naming to package-info.java
7e378fc: 8335667: Fix simple -Wzero-as-null-pointer-constant warnings in compiler code
ced9906: 8334371: [AIX] Beginning with AIX 7.3 TL1 mmap() supports 64K memory pages
916db07: 8335532: [JVMCI] Export VM_Version::L1_line_size in JVMCI
c0604fb: 8334890: Missing unconditional cross modifying fence in nmethod entry barriers
cf1be87: 8335663: Fix simple -Wzero-as-null-pointer-constant warnings in C2 code
0bb9c76: 8324089: Fix typo in the manual page for "jcmd" (man jcmd)
... and 63 more: https://git.openjdk.org/jdk/compare/c798316bc4cb33fd902f926030d8a0b6870d661a...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@liach, @naotoj) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

openjdk · 2024-04-25T14:32:45Z

@nizarbenalla The following labels will be automatically applied to this pull request:

core-libs
i18n
security

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

liach · 2024-04-25T16:43:50Z

I think your changes mostly group in these categories:

New API methods provided in superclasses/superinterfaces, this class provides a more concrete implementation:
Examples being CompletableFuture, FileInputStream, DelayQueue, FutureTask
I don't think you should add since tags for these; without explicit javadoc, the methods inherit the superclass/superinterface docs, and appear in Methods declared in class/interface Xxx (supertype) section, which already have the correct since tags.
There's one scenario where such addition may be meaningful, however: that's if the supertype's since version is newer than this class/interfaces's since version, so we might need to specify here.
(On a side note, it would be great if we can mark the since version of an interface, notorious example being ZipFile retrofitted to implement Closeable in 1.7 and breaks compile target 1.6)
Remove unnecessary since tags for existing API methods with newer implementation
Examples being Reference, RsaPrivateKey. These make sense.
API methods with different return types
Examples being ClassSignature, ClassDesc. These make sense too, as older version may return different types. But problem here is should we count methods with only signature (but not descriptor) differences, like ClassSignature::superinterfaceSignatures()?

src/java.base/share/classes/java/lang/classfile/ClassSignature.java

src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java

src/java.base/share/classes/java/lang/constant/ClassDesc.java

nizarbenalla · 2024-04-25T18:35:29Z

I think your changes mostly group in these categories:

New API methods provided in superclasses/superinterfaces, this class provides a more concrete implementation:
Examples being CompletableFuture, FileInputStream, DelayQueue, FutureTask
I don't think you should add since tags for these; without explicit javadoc, the methods inherit the superclass/superinterface docs, and appear in Methods declared in class/interface Xxx (supertype) section, which already have the correct since tags.
There's one scenario where such addition may be meaningful, however: that's if the supertype's since version is newer than this class/interfaces's since version, so we might need to specify here.
(On a side note, it would be great if we can mark the since version of an interface, notorious example being ZipFile retrofitted to implement Closeable in 1.7 and breaks compile target 1.6)

Remove unnecessary since tags for existing API methods with newer implementation
Examples being Reference, RsaPrivateKey. These make sense.

API methods with different return types
Examples being ClassSignature, ClassDesc. These make sense too, as older version may return different types. But problem here is should we count methods with only signature (but not descriptor) differences, like ClassSignature::superinterfaceSignatures()?

@liach

I am only looking at code added in JDK 9-current and do not plan on checking old code for now (in case there are questions on why certain methods weren't affected)
I want generify-ing methods to be fine, so I am leaving ClassSignature::superinterfaceSignatures(). It will be changed eventually once the class goes out of Preview

liach · 2024-04-25T23:08:40Z

For case 1 I mentioned, the new since tags in CompletableFuture, FileInputStream, DelayQueue, FutureTask are not necessary: their docs are carried from the superclass/superinterfaces, and those superclass/superinterface methods already have the correct since tags.

nizarbenalla · 2024-04-26T00:55:29Z

Recent [offline] discussions have showed that dealing with @since in overriding methods is complicated.
The solution is to add an explicit @since to some overriding methods that do not have any javadoc as the only @since we can infer is that of the enclosing class.
The positive part is that these cases are very rare, and would help the checker have precise rules and match those of javadoc.

liach · 2024-04-26T02:54:57Z

Please consider this scenario where class A extends B, both from earlier versions, and there's B::method added in a new version X. Why are we adding a @since tag on the method A::method when it doesn't have its own doc and just refers to B::method, which already includes a @since tag?

For your convenience, I will reiterate with the javadoc output API specification instead of just the source code. These are most likely caused by bugs in your analyais tool:

CompletableFuture::exceptionallyComposeAsync CompletableFuture::resultNow etc. already have the correct @since tags inherited from superclass/superinterfaces javadocs. Notice if a method doesn't have javadoc, it carries the javadoc from its overridden method and it doesn't appear in this class's Method Summary section.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/CompletableFuture.html#methods-inherited-from-class-java.util.concurrent.CompletionStage
Affected classes: CompletableFuture, ForkJoinTask, FutureTask, and ChoiceFormat.
FileInputStream::readNBytes is explicitly overridden in JDK 12 for a better implementation, but it is already a valid method since JDK 9 when InputStream::readNBytes was added. This @since 12 does not make sense.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/io/FileInputStream.html#methods-inherited-from-class-java.io.InputStream
Affected classes: FileInputStream, DelayQueue.

All other changes look correct.

nizarbenalla · 2024-04-26T09:30:23Z

We will effectively enforce javadoc comment for some method overrides with the checker (we want to match the rules for javadoc tool which doesn't have any special handing for @since tags in inherited methods), and for that we need to fix some of the existing tags. But turns out it's not too many as we are only checking JDK 9-current.
Regarding FileInputStream::readNBytes, the method int java.io.FileInputStream.readNBytes(byte[],int,int) was available since JDK 9.
The one I added an @since 11 is a different method byte[] java.io.FileInputStream.readNBytes(int) with different return type and parameters.
Link to JDK 9 docs with the method

liach · 2024-04-26T14:52:08Z

We will effectively enforce javadoc comment for some method overrides with the checker

Those overriding methods don't even appear on the javadoc output. If you go to search for CompletableFuture.resultNow on https://docs.oracle.com/en/java/javase/22/docs/api/ you will find nothing. Why are we fixing "broken since tags" that don't even exist in the first place?

Also have you looked at the output documentation? Without the @inheritDoc tags the content will only have a since tag, which is definitely wrong.

liach · 2024-04-26T19:28:24Z

FYI you can generate the documentation with make docs and upload it to https://cr.openjdk.org and link it for review purposes. (You just need to include the changed classes and the stylesheet.css)

I don't want to reiterate again, but if a method is declared so:

/**
 * Class One.
 *
 * @since 42
 */
public class One {
    /**
     * Method.
     *
     * @since 48
     */
    public void method() {}
}

/**
 * Class Two.
 *
 * @since 42
 */
public class Two extends One {
    @Override
    public void method() {}
}

The generated docs for Two will list method only in "Method declared in class One" section instead of the "Method Summary" section, and the link in "Method declared in ..." section links to the method declaration in class One where there's a correct @since version.

What's wrong with you that you ask Two::method to have a redundant javadoc and since tag?

nizarbenalla · 2024-04-27T10:33:42Z

We will effectively enforce javadoc comment for some method overrides with the checker

Those overriding methods don't even appear on the javadoc output. If you go to search for CompletableFuture.resultNow on https://docs.oracle.com/en/java/javase/22/docs/api/ you will find nothing. Why are we fixing "broken since tags" that don't even exist in the first place?

Also have you looked at the output documentation? Without the @inheritDoc tags the content will only have a since tag, which is definitely wrong.

For overriding methods we don't look into the supertype because that's what javadoc (the tool) is doing, javadoc doesn't look into the supertype and has no special handling or support for @since tags in inherited methods.
If javadoc changes how it deals with method overriding in the future we will match it's behavior and look into the supertype for overriding methods.
What is important is that we have to match the rules used in javadoc.
You can't have both, either you add explicit javadoc comments to these methods or use rules that go against the current behavior or javadoc

liach · 2024-04-27T12:23:14Z

I'm sorry, you have always mentioned "match the javadoc rules" "javadoc doesn't look into supertype" "go against current behavior", but there is no problem with these @since tags in the current output documentation because those overriding methods without javadoc are treated as if they don't exist by javadoc tool.

For overriding methods we don't look into the supertype

We indeed don't because we treat it as if it does not exist, and then the current docs are right. Please, just take a look at the javadoc output once and reach your own conclusion.

liach · 2024-04-27T12:25:06Z

Recent [offline] discussions have showed that dealing with @since in overriding methods is complicated.
The solution is to add an explicit @since to some overriding methods that do not have any javadoc as the only @since we can infer is that of the enclosing class.

If possible, I wish the others who joined the offline discussion can take part here. It seems you have some trouble understanding that overriding methods without explicit documentation are ignored by javadoc, and this ignorance makes the @since tags correct...

nizarbenalla · 2024-04-27T15:57:06Z

When I said "For overriding methods we don't look into the supertype" I meant my checker tool doesn't do that.

It seems you have some trouble understanding that overriding methods without explicit documentation are ignored by javadoc

This is still a Draft PR, I meant to add the {@inheritDoc} or other needed content to the javadoc and cleanup before opening. Should fix the issue you have with this change.

Others can join the discussion if they want, I'll let them know on monday but you might just get the same answer. For now the decision is that the every time an overload like the ones in this Draft PR is added, we would need to add explicit javadoc comment as we can't infer the @since from the overriden method.

pavelrappo · 2024-04-29T16:07:14Z

src/java.base/share/classes/java/io/FileInputStream.java

+     * @throws    IllegalArgumentException {@inheritDoc}
+     * @throws    IOException {@inheritDoc}
+     * @throws    OutOfMemoryError {@inheritDoc}


Re: inheriting unchecked exception documentation here and elsewhere in this PR

This PR's title suggests that the PR has nothing to do with exception documentation. If you feel that it should be addressed, please file a separate bug and move these changes there.

FWIW, I agree that @throws ... {@inheritDoc} for such exceptions are at least worth being considered. It's a common misconception that all exception documentation is inherited automatically.

This is because the tool from #18934 has no easy way to fetch the doc comment from a superclass/superinterface overridden method when this class only has a plain override. Javadoc handles this in complex logic in VisibleMemberTable; it's hard for other clients to try to emulate the behavior of doc finding, and the tool just incorrectly assumes such methods (what I have been talking about before) are reusing @since from the class docs.

Pavel, can I simply change the PR/issue title to be more descriptive?
As I want to include the the inherit doc because of the unchecked exceptions, rather than clean this up in a different PR

Pavel, can I simply change the PR/issue title to be more descriptive? As I want to include the the inherit doc because of the unchecked exceptions, rather than clean this up in a different PR

I suggest dropping all the changes that are irrelevant to @since from this PR, unless you have PRs with similar mixed changes integrated. As far as I know, @since is not a normative part of documentation, whereas @throws is. So the latter is a bigger change and would require more scrutiny and more area experts during review.

In the future, we might want to have yet another aid/tool: a "@throws checker" that finds all overriding methods that do not declare some of the unchecked exceptions that the methods they override do.

pavelrappo · 2024-04-29T20:02:32Z

Also have you looked at the output documentation? Without the @inheritDoc tags the content will only have a since tag, which is definitely wrong.

This is not how I remember it. Unless written around, {@inheritDoc} in a main description is redundant. Let me clarify what I mean. Suppose we have a method:

/** Foos. */
foo()

and a couple of other methods that override that method:

@Override
foo()

/**
 */
@Override
foo()

/**
 * {@inheritDoc}
 */
@Override
foo()

Now, as far as the main description goes, the above three are equivalent, and the main description is inherited. While the third variant is arguably the most readable, its {@inheritDoc} is unnecessary. Explicit {@inheritDoc} is only necessary if we want to "write around" the inherited part. For example:

/**
 * Foos with extra steps.
 * 
 * {@inheritDoc}
 * 
 * Also bars if baz is true.
 */
@Override
foo()

In this case, the generated documentation would be as follows:

Foos with extra steps.
Foos.
Also bars if baz is true.

@since is a block tag. Block tags do not belong to the main description. So, if the goal is to only add a block tag, one does not need to implicitly {@inheritDoc} the main description. Does it make sense, Chen?

liach · 2024-04-29T22:54:47Z

Thanks for the explanation @pavelrappo. Also I recall inheritDoc has weird interactions with block tags like user-defined @apiNote in the JDK, would be nice if you can share more about these (also about the behaviors of inheriting @throws etc.

liach · 2024-05-13T17:52:23Z

src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights reserved.


This diff is redundant but no-op. You should merge openjdk/jdk's master branch to your PR branch, so the diff displayed by GitHub is up-to-date and this will go away.

I don't want to merge or rebase on an active PR. It should get fixed once this is integrated.

Sure, this comment serves as a note to reviewers that these 2 header changes have been committed in other changes and thus can be safely ignored.

There is no harm in merging the upstream master, using git merge, to bring your branch more up-to-date. And it can be helpful in cases like this where it might help reviewers avoid extraneous information. It is also recommended in other cases (e.g., a long-running PR where there is a lot of drift between the PR source branch and the upstream target branch).

Skara will squash all commits anyway when integrating so the results will be identical.

Btw, one thing you should not do is rebase a source branch of an active PR.

jonathan-gibbons · 2024-06-03T16:09:42Z

I disagree somewhat with the statements in the comments that the checker should follow the javadoc rules, whatever they are.

The important thing is to decide what the rules for @since should be, in terms of changes to the set of signatures in the class. Generally, I think the rule should be that every declaration should have @since except that members need not have the tag if it would be the same as for the enclosing class or interface. As far as adding an overriding method is concerned, if it has the same VM descriptor as the overridden method, it is not a "new" method in the class; if it has a covariant return type, that is a significant change to the descriptor and so such methods should have @since.

As a practical rule for deciding whether any declaration is new or not, imagine writing a test program that refers to the most specific form of the declaration. If that test program does not compile on JDK version N-1 and does compile on version N, then it warrants having @since N. Put another way, @since N should identify the first release in which the declaration can be used in the given form.

Note, these rules are stated without reference to what javadoc does. javadoc should follow these rules as well; it is a bug if the tool generates incorrect documentation based on @since tags following these rules.

Also, while the proposed new Since Checker should follow these rules when analysing declarations, it may go further when making suggestions to correct errors that it finds. For example, instead of simply saying No @since tag found here, it might analyze the history and say No @since tag found here; the declaration was introduced in X for an appropriate X.

liach · 2024-06-26T12:36:17Z

src/java.base/share/classes/java/lang/classfile/ClassSignature.java

@@ -41,7 +41,10 @@ public sealed interface ClassSignature
    /** {@return the type parameters of this class} */
    List<Signature.TypeParam> typeParameters();

-    /** {@return the instantiation of the superclass in this signature} */
+    /** {@return the instantiation of the superclass in this signature}


Suggested change

/** {@return the instantiation of the superclass in this signature}

/**

* {@return the instantiation of the superclass in this signature}

I think this is our preference if we have multi-line specs.

Fixed in 91df97f, Thanks.

naotoj · 2024-06-26T17:53:07Z

src/java.base/share/classes/java/text/ChoiceFormat.java

+    /**
+     * @since 23
+     */


IIUC, this addition will add & inherit the javadoc from NumberFormat, which is not the case before. The description for NumberFormat does not fit with ChoiceFormat. Probably that needs to be addressed with a different issue.

My review is for the ChoiceFormat class only. So asking for more Reviews for other area
/reviewers 2 reviewer

Thanks, I will leave this open for a few more days to let more people from the relevant areas review it.

naotoj · 2024-06-26T18:03:55Z

/reviewers 2 reviewer

openjdk · 2024-06-26T18:05:25Z

@naotoj
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 2 Reviewers).

naotoj · 2024-07-03T16:55:22Z

OK, I look at other areas and I believe they are fine.
/reviewers 1 reviewer

openjdk · 2024-07-03T16:55:45Z

@naotoj
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 1 (with at least 1 Reviewer).

nizarbenalla · 2024-07-04T14:35:30Z

Thank you Naoto for checking, and thanks Chen!

/integrate

openjdk · 2024-07-04T14:36:07Z

@nizarbenalla
Your change (at version afca07b) is now ready to be sponsored by a Committer.

liach · 2024-07-04T15:43:36Z

/sponsor

openjdk · 2024-07-04T15:44:58Z

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

3050ba0: 8335654: Remove stale hyperlink in divnode.cpp
da0ffa8: 8334031: Generated JfrNativeSettings seems off
b0efd77: 8314653: Metaspace: remove allocation guard feature
6a47279: 8332072: Convert package.html files in java.naming to package-info.java
7e378fc: 8335667: Fix simple -Wzero-as-null-pointer-constant warnings in compiler code
ced9906: 8334371: [AIX] Beginning with AIX 7.3 TL1 mmap() supports 64K memory pages
916db07: 8335532: [JVMCI] Export VM_Version::L1_line_size in JVMCI
c0604fb: 8334890: Missing unconditional cross modifying fence in nmethod entry barriers
cf1be87: 8335663: Fix simple -Wzero-as-null-pointer-constant warnings in C2 code
0bb9c76: 8324089: Fix typo in the manual page for "jcmd" (man jcmd)
... and 63 more: https://git.openjdk.org/jdk/compare/c798316bc4cb33fd902f926030d8a0b6870d661a...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-07-04T15:45:05Z

@liach @nizarbenalla Pushed as commit f4fa35e.

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

add tags to elements from java.base

63bdc37

openjdk bot added security [email protected] core-libs [email protected] i18n [email protected] labels Apr 25, 2024

liach suggested changes Apr 25, 2024

View reviewed changes

remove two extra spaces

33e3a44

add {@inheritdoc} to new javadoc comments

9146622

nizarbenalla mentioned this pull request Apr 28, 2024

8331051: Add an @since checker test for java.base module #18934

Closed

3 tasks

nizarbenalla added 2 commits April 29, 2024 03:09

add @throws declarations to javadoc

2f7b0f0

add one more {inheritDoc} to CompletableFuture.state

06bdaf9

liach approved these changes Apr 29, 2024

View reviewed changes

pavelrappo reviewed Apr 29, 2024

View reviewed changes

Pull request is now only about @since tags, might add an other commit

cb6a306

liach reviewed May 13, 2024

View reviewed changes

Merge remote-tracking branch 'upstream/master' into 8330954

b3574b9

nizarbenalla changed the title ~~8330954: Fix remaining @since tags in java.base~~ 8330954: since-checker - Fix remaining @since tags in java.base Jun 3, 2024

nizarbenalla changed the title ~~8330954: since-checker - Fix remaining @since tags in java.base~~ 8330954: since-checker - Fix remaining @ since tags in java.base Jun 4, 2024

Merge remote-tracking branch 'upstream/master' into 8330954

dbef517

liach approved these changes Jun 26, 2024

View reviewed changes

Add new line when having multi-line doc comment

91df97f

liach approved these changes Jun 26, 2024

View reviewed changes

naotoj approved these changes Jun 26, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jun 26, 2024

openjdk bot removed the ready Pull request is ready to be integrated label Jun 26, 2024

Merge remote-tracking branch 'upstream/master' into 8330954

afca07b

openjdk bot added the ready Pull request is ready to be integrated label Jul 3, 2024

openjdk bot added the sponsor Pull request is ready to be sponsored label Jul 4, 2024

openjdk bot added the integrated Pull request has been integrated label Jul 4, 2024

openjdk bot closed this Jul 4, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Jul 4, 2024

nizarbenalla deleted the 8330954 branch September 19, 2024 00:35

		@@ -1,5 +1,5 @@
		/*
		* Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights reserved.

	/** {@return the instantiation of the superclass in this signature}
	/**
	* {@return the instantiation of the superclass in this signature}

8330954: since-checker - Fix remaining @ since tags in java.base #18954

8330954: since-checker - Fix remaining @ since tags in java.base #18954

Conversation

nizarbenalla commented Apr 25, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Apr 25, 2024

openjdk bot commented Apr 25, 2024 • edited Loading

openjdk bot commented Apr 25, 2024

liach commented Apr 25, 2024

nizarbenalla commented Apr 25, 2024 • edited Loading

liach commented Apr 25, 2024

nizarbenalla commented Apr 26, 2024 • edited Loading

liach commented Apr 26, 2024

nizarbenalla commented Apr 26, 2024 • edited Loading

liach commented Apr 26, 2024

liach commented Apr 26, 2024

nizarbenalla commented Apr 27, 2024

liach commented Apr 27, 2024

liach commented Apr 27, 2024 • edited Loading

nizarbenalla commented Apr 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavelrappo Apr 29, 2024 • edited Loading

Choose a reason for hiding this comment

pavelrappo commented Apr 29, 2024

liach commented Apr 29, 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

jonathan-gibbons commented Jun 3, 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

naotoj commented Jun 26, 2024

openjdk bot commented Jun 26, 2024

naotoj commented Jul 3, 2024

openjdk bot commented Jul 3, 2024

nizarbenalla commented Jul 4, 2024

openjdk bot commented Jul 4, 2024

liach commented Jul 4, 2024

openjdk bot commented Jul 4, 2024

openjdk bot commented Jul 4, 2024

nizarbenalla commented Apr 25, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Apr 25, 2024 •

edited

Loading

nizarbenalla commented Apr 25, 2024 •

edited

Loading

nizarbenalla commented Apr 26, 2024 •

edited

Loading

nizarbenalla commented Apr 26, 2024 •

edited

Loading

liach commented Apr 27, 2024 •

edited

Loading

nizarbenalla commented Apr 27, 2024 •

edited

Loading

pavelrappo Apr 29, 2024 •

edited

Loading