8334714: Implement JEP 484: Class-File API #19826

asotona · 2024-06-21T11:56:37Z

Class-File API is leaving preview.
This is a removal of all @PreviewFeature annotations from Class-File API.
It also bumps all @since tags and removes jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API.

Please review.

Thanks,
Adam

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 a JEP request to be targeted
Change requires CSR request JDK-8334720 to be approved

Issues

JDK-8334714: Implement JEP 484: Class-File API (Sub-task - P4)
JDK-8334712: JEP 484: Class-File API (JEP)
JDK-8334720: Implement JEP 484: Class-File API (CSR)

Reviewers

Vicente Romero (@vicente-romero-oracle - Reviewer) Review applies to e5f96464
Chen Liang (@liach - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19826

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2024-06-21T11:57:08Z

👋 Welcome back asotona! 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-21T11:57:20Z

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

8334714: Implement JEP 484: Class-File API

Reviewed-by: liach, vromero

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

6cdebf0: 8343599: Kmem limit and max values swapped when printing container information
a672138: 8344161: Argument type mismatch for jfr_type_id
3245f56: 8344164: [s390x] ProblemList hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java
5e27608: 8344188: Cleanup sun.net.www.protocol.jar.JarFileFactory after JEP 486 integration

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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-21T11:57:48Z

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

compiler
core-libs

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.

mlbridge · 2024-06-21T12:00:31Z

Webrevs

08: Full (807e8b2a)
07: Full (97fdf4ed)
06: Full (29936e33)
05: Full (4a51c456)
04: Full (bb857e58)
03: Full (9571ecb9)
02: Full (aeebc58c)
01: Full (e5f96464)
00: Full (56c8573a)

liach · 2024-06-21T12:24:05Z

Do we intend to do it after we finish our planned API changes or as soon as possible? Also we might need to look at the preview-enabled test treatments.

AlanBateman · 2024-06-21T12:31:05Z

Looks like this has been accidentally created as a sub-task of the JEP issue, I assume you'll fix that. Will there be another issue to update the tests and drop @enablePreview?

asotona · 2024-06-21T12:33:04Z

Any potential API changes should be merged first, to avoid impression of changing a non-preview API.
However any discussion and approval processes of API and documentation changes should not block the JEP process (and each other).

Cleaning up preview-enabled tests has a lower priority and should follow.

asotona · 2024-06-21T12:37:13Z

Looks like this has been accidentally created as a sub-task of the JEP issue, I assume you'll fix that. Will there be another issue to update the tests and drop @enablePreview?

I thought the implementation is usually created as a subtask of JEP, however I can make it a standalone bug if neede.

Yes, there will be follow up task to clean all the @enablePreview mess, I'll create it.

ExE-Boss · 2024-07-15T13:26:39Z

Note that Utf8Entry::equalsString has inconsistent behaviour when called with a null value, which I’ve reported as JI‑9077307, and should probably be fixed before this API leaves preview.

liach · 2024-07-17T00:07:09Z

@ExE-Boss Your report has been promoted to https://bugs.openjdk.org/browse/JDK-8336430 and will be addressed in a separate patch.

vicente-romero-oracle

lgtm

bridgekeeper · 2024-08-15T23:27:55Z

@asotona 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!

xxDark · 2024-08-24T03:05:14Z

I've been trying to work with classfile api, and:

~~AttributesProcessingOption is unused, does nothing?~~ That seems to be just a weird way to write a check... Yikes.

jdk/src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Line 104 in 5671f83

? ATTRIBUTE_STABILITY_COUNT - attr.attributeMapper().stability().ordinal() > processingOption.ordinal()
Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as JAVA_1_VERSION exist in java.lang.classfile.ClassFile.

liach · 2024-08-24T03:45:03Z

Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as JAVA_1_VERSION exist in java.lang.classfile.ClassFile.

Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, for release N, we will not support correct parsing or writing of preview class files from N-1, N-2, etc.

While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):

jdk/src/hotspot/share/classfile/classFileParser.cpp

Lines 2332 to 2334 in 5671f83

    
           max_stack = cfs->get_u2_fast(); 
        
           max_locals = cfs->get_u2_fast(); 
        
           code_length = cfs->get_u4_fast();

Nor by the JVMS: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.7.3

And as such, it falls out of the goals of the API, and is likely not going to be added. You most likely will resort to a third party library to handle such frozen format, as the main issue ClassFile API is solving is that a library built against JDK 21 may not run on JDK 23 unless it bumps its ASM dependency to support reading JDK 23 Class File format, which doesn't exist for the said oak format.

xxDark · 2024-08-24T04:04:02Z

While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):

jdk/src/hotspot/share/classfile/classFileParser.cpp

Lines 2332 to 2334 in 5671f83

max_stack = cfs->get_u2_fast();

max_locals = cfs->get_u2_fast();

code_length = cfs->get_u4_fast();

Interesting. I guess handling of oak classfiles was removed a long time ago by this commit.
But, does this mean that now, Hotspot blindly accepts classfiles with version 45 with, technically, incorrect data?

java -cp . Test
Hello, World

jdk-1.8.0_402\bin\java -cp . Test
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.ClassFormatError: Invalid code attribute name index 10 in class file Test
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)

Also now, this library which took special care to parse oak files ~~reports wrong instructions~~ does not parse classfile at all.

		byte[] bytes = ClassFile.of(ClassFile.StackMapsOption.GENERATE_STACK_MAPS)
				.build(ClassDesc.ofInternalName("Test"), builder -> {
					builder.withVersion(ClassFile.JAVA_1_VERSION, 0);
					builder.withMethod(
							"main",
							MethodTypeDesc.ofDescriptor("([Ljava/lang/String;)V"),
							AccessFlags.ofMethod(AccessFlag.PUBLIC, AccessFlag.STATIC).flagsMask(),
							mb -> {
								mb.withCode(cb -> {
									ClassDesc printStream = PrintStream.class.describeConstable().orElseThrow();
									cb.getstatic(System.class.describeConstable().orElseThrow(), "out", printStream)
											.ldc("Hello, World")
											.invokevirtual(printStream, "println", MethodTypeDesc.ofDescriptor("(Ljava/lang/String;)V"))
											.return_();
								});
							});
					builder.with(SourceFileAttribute.of("Test Attr"));
				});
		Path path = Path.of("Test.class");
		Files.write(path, bytes);
		var file = new ClassFileReader().read(bytes);

As noted about Hotspot technically parsing invalid data now (if you could consider that "invalid") and we make a correct oak classfile:

jdk-1.8.0_402\bin\java -cp . Test
Hello World

JDK 17
java -cp . Test
Error: LinkageError occurred while loading main class Test
        java.lang.ClassFormatError: Invalid method Code length 2986347538 in class file Test

liach · 2024-08-24T04:56:34Z

I think so. See https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039795.html for some context. There are also historical evaluations available at https://bugs.openjdk.org/browse/JDK-8232890 and https://bugs.openjdk.org/browse/JDK-8232967, notably the judgement in Compatibility Risk Description:

Class files with versions < 45.3 predate Java.

But, does this mean that now, Hotspot blindly accepts classfiles with version 45 with, technically, incorrect data?

It appears so. See note in ClassFileFormatVersion:

jdk/src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java

Lines 413 to 414 in 5671f83

    
           // RELEASE_0 and RELEASE_1 both have a major version of 45; 
        
           // return RELEASE_1 for an argument of 45.

It seems that now major version 45, regardless of the minor version, is simply seen as the Class File format for Java 1.1.

Also now, this library which took special care to parse oak files reports wrong instructions does not parse classfile at all.

Indeed, it would be a good RFE to allow users to override default attribute mappers to parse attributes; this would be extremely useful if users wish to support previous previews that only differed in the attribute formats.

jdk-1.8.0_402\bin\java -cp . Test
Hello World

For the behavioral inconsistencies, we can backport this special handling removal to active jdk update projects or even request specification changes on LTS versions (see https://github.com/openjdk/jdk8u-ri) if this is deemed important enough.

xxDark · 2024-08-24T05:03:33Z

Indeed, it would be a good RFE to allow users to override default attribute mappers to parse attributes; this would be extremely useful if users wish to support previous previews that only differed in the attribute formats.

I don't think at this point in time there would be any change in the format of any existing attributes, as that would be a binary incompatible change.
But yes, having a way to override parsing of builtin attributes would be nice.

For the behavioral inconsistencies, we can backport this special handling removal to active jdk update projects or even request specification changes on LTS versions (see https://github.com/openjdk/jdk8u-ri) if this is deemed important enough.

I don't think that many projects use pre-Java 1 format at this point. While I saw some libraries that kept their version set to versions like Java 4 for no apparent reason... Hey, at least it's not Java 1 version.
If Hotspot now parses these files incorrectly, it might be worth to just throw UnsupportedClassVersionError for oak class files?

Col-E · 2024-08-24T06:41:22Z

Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, for release N, we will not support correct parsing or writing of preview class files from N-1, N-2, etc.

I understand that there is no explicit goal for this API to be used for general purposes, but it seems really odd that I cannot safely assume that classes that are successfully loaded in the current runtime will be parsable. Oak classes are a notable exception, and nobody should realistically expect to see an oak class ever. However, if we only can guarantee that the current class file version will be supported and not even N-1 then no application/library expecting reliability (without constant recompilation to ensure the class versions are current) should use the API.

~~Again, its clearly not listed as a goal but it seems disappointing that this new API is unrealistic to use if this statement is to be taken at face value.~~

Edit: I missed the word preview in the quote. Does this only apply to preview class file features?

liach · 2024-08-24T13:53:32Z

If Hotspot now parses these files incorrectly, it might be worth to just throw UnsupportedClassVersionError for oak class files?

This would be an important decision; I would wait till Monday when more engineers are back to discuss about the histroy of dropping support for such files, why this format never made its way to the JVMS, and the correct way to handle so as to avoid inconsistency between different versions.

Edit: I missed the word preview in the quote. Does this only apply to preview class file features?

Yes, Class-File API is supposed to handle whatever the VM handles. It's actually considered a "JVM API" in Oracle's documentations: https://docs.oracle.com/en/java/javase/22/vm/class-file-api.html

OpenJDK's preview version policy allows shipping the preview features for testing to a wider audience without any implied burden of long-term maintenance. So for example, if the Nullable Types JEP preview adds ~ as a null marker in Signature attribute but changes it to ? in a subsequent preview, the JVM and core libraries will act as if a previous iteration with ~ marker never existed; the policy is similar to that for preview libraries.

Unfortunately, there seems to be some misunderstanding around the role of preview, so some are asking if preview features that is largely unchanged and finalized in a future release can become finalized in an LTS as well. Short answer, no: it's an experiment format enabled by the new 6-month release schedule.

And note that javap uses ClassFile API, and as a result, javap for release N cannot correctly decompile Class Files with version N-1.65535, etc. We are planning to decompile on a best-effort basis, that we try to interpret such as class as if it's N.65535 (maybe emit a warning), trying to salvage the most out of the Class File and printing errors (but continue to output) if we encounter anything we don't expect.

liach · 2024-08-26T19:02:02Z

If Hotspot now parses these files incorrectly, it might be worth to just throw UnsupportedClassVersionError for oak class files?

I was informed in offline discussion that this is unlikely to be changed and this change is unlikely to be backported unless for security purposes.

openjdk · 2024-08-27T14:11:04Z

@asotona this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8334714-final
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

# Conflicts: # src/java.base/share/classes/java/lang/classfile/AccessFlags.java # src/java.base/share/classes/java/lang/classfile/ClassBuilder.java # src/java.base/share/classes/java/lang/classfile/ClassElement.java # src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java # src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java # src/java.base/share/classes/java/lang/classfile/ClassModel.java # src/java.base/share/classes/java/lang/classfile/ClassReader.java # src/java.base/share/classes/java/lang/classfile/ClassSignature.java # src/java.base/share/classes/java/lang/classfile/CodeBuilder.java # src/java.base/share/classes/java/lang/classfile/CodeElement.java # src/java.base/share/classes/java/lang/classfile/CodeModel.java # src/java.base/share/classes/java/lang/classfile/CompoundElement.java # src/java.base/share/classes/java/lang/classfile/FieldBuilder.java # src/java.base/share/classes/java/lang/classfile/FieldElement.java # src/java.base/share/classes/java/lang/classfile/Instruction.java # src/java.base/share/classes/java/lang/classfile/MethodBuilder.java # src/java.base/share/classes/java/lang/classfile/MethodElement.java # src/java.base/share/classes/java/lang/classfile/TypeKind.java # src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java # src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java # src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java # src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java # src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java # src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java # src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/DynamicConstantPoolEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/FieldRefEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/InterfaceMethodRefEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/LoadableConstantEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/MethodRefEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/ModuleEntry.java # src/java.base/share/classes/java/lang/classfile/constantpool/PackageEntry.java # src/java.base/share/classes/java/lang/classfile/instruction/NewMultiArrayInstruction.java

ExE-Boss · 2024-10-21T15:53:18Z

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

It should probably be possible for ClassFile::verify(…) to be able to verify the bytecode of java.lang.Object, java.lang.Class, java.lang.String, and java.lang.Throwable, as the main reason the HotSpot verifier skips those is that there’s circular verification bootstrap dependencies between those, but the Class‑File API verifier uses the offline ClassHierarchyResolver instead for determining assignability checks.

jdk/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java

Lines 144 to 150 in 18bcbf7

public static boolean is_eligible_for_verification(VerificationWrapper klass) {

String name = klass.thisClassName();

return !java_lang_Object.equals(name) &&

!java_lang_Class.equals(name) &&

!java_lang_String.equals(name) &&

!java_lang_Throwable.equals(name);

}

VerifierImpl should be the best possible 1:1 transcription of the HotSpot verifier (for easy maintenance). I also have to suppress itching to rewrite it ;) Fortunately why would someone need to verify Object, Class, String or Throwable.

# Conflicts: # src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java

liach

The latest merge of PreviewFeature.java looks good.

# Conflicts: # src/java.base/share/classes/java/lang/classfile/CustomAttribute.java

liach

It's finally the time to set sail!

asotona · 2024-11-15T14:35:26Z

Thank you!

/integrate

openjdk · 2024-11-15T14:38:18Z

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

6cdebf0: 8343599: Kmem limit and max values swapped when printing container information
a672138: 8344161: Argument type mismatch for jfr_type_id
3245f56: 8344164: [s390x] ProblemList hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java
5e27608: 8344188: Cleanup sun.net.www.protocol.jar.JarFileFactory after JEP 486 integration

Your commit was automatically rebased without conflicts.

openjdk · 2024-11-15T14:38:29Z

@asotona Pushed as commit 84ffb64.

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

liach · 2024-11-15T15:05:41Z

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java

@@ -74,8 +74,6 @@ public enum Feature {
        SCOPED_VALUES,
        @JEP(number=480, title="Structured Concurrency", status="Third Preview")
        STRUCTURED_CONCURRENCY,
-        @JEP(number=466, title="ClassFile API", status="Second Preview")
-        CLASSFILE_API,


Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.

lukellmann · 2024-11-29T17:44:12Z

The @since 24 tags added in #20761 are still there and should probably be removed.

nizarbenalla · 2024-11-29T18:16:57Z

Thanks for reporting luca, we still don't test for redundant tags so I missed this.

ExE-Boss · 2024-12-09T18:02:44Z

@asotona

I wish that the concrete PoolEntry subtypes had of(…) factory methods...

Please forward the proposal on clasfile-api-dev mailing list, where it can be discussed. Thank you.

I filed JDK‑8345737 for that, and would prefer that at least jdk.internal.classfile.impl.TemporaryConstantPool were fully implemented in JDK 24 (see JDK‑8345734).

liach · 2024-12-09T18:39:32Z

I fear that promoting creation of unbound PoolEntry may be a bad move - they are there only for temporary components of attributes. We should promote creating a local pool entry whenever possible - this is one of the tricks for CodeBuilder optimization, where the usage of CodeBuilder convenience factories elide the creation of intermediate instruction and non-local pool entry objects.

Also for TemporaryConstantPool - it has a few weird behaviors, especially that its elements have bad indices. The TemporaryConstantPool itself is never used as a ConstantPoolBuilder, and it can be refitted to only implement ConstantPool with minimal impact. (Well, aside from these blunt cast-and use cases you've shown)

ExE-Boss · 2024-12-09T20:15:44Z

Thanks to TemporaryConstantPool, I have been able to find JI‑9077904.

asotona added 2 commits June 21, 2024 13:28

8334714: Class-File API leaves preview

bf8fee1

bumped @SInCE tag

56c8573

openjdk bot added csr Pull request needs approved CSR before integration rfr Pull request is ready for review labels Jun 21, 2024

openjdk bot added core-libs [email protected] compiler [email protected] labels Jun 21, 2024

asotona mentioned this pull request Jul 8, 2024

8335727: since-checker: Add @since tags to ClassFile::transformClass and CodeBuilder #20041

Closed

3 tasks

Merge branch 'master' into JDK-8334714-final

e5f9646

vicente-romero-oracle approved these changes Jul 18, 2024

View reviewed changes

asotona changed the title ~~8334714: Class-File API leaves preview~~ 8334714: Implement JEP 484: Class-File API Aug 27, 2024

openjdk bot added the jep label Oct 1, 2024

openjdk bot added merge-conflict Pull request has merge conflict with target branch and removed jep labels Oct 8, 2024

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Oct 21, 2024

ExE-Boss reviewed Oct 21, 2024

View reviewed changes

Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final

97fdf4e

# Conflicts: # src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java

liach approved these changes Nov 12, 2024

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 Nov 14, 2024

asotona added 2 commits November 14, 2024 11:46

Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final

8d089f3

Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final

807e8b2

# Conflicts: # src/java.base/share/classes/java/lang/classfile/CustomAttribute.java

openjdk bot removed the ready Pull request is ready to be integrated label Nov 15, 2024

asotona requested review from vicente-romero-oracle and liach November 15, 2024 12:49

liach approved these changes Nov 15, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Nov 15, 2024

openjdk bot added the integrated Pull request has been integrated label Nov 15, 2024

openjdk bot closed this Nov 15, 2024

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

liach reviewed Nov 15, 2024

View reviewed changes

	public static boolean is_eligible_for_verification(VerificationWrapper klass) {
	String name = klass.thisClassName();
	return !java_lang_Object.equals(name) &&
	!java_lang_Class.equals(name) &&
	!java_lang_String.equals(name) &&
	!java_lang_Throwable.equals(name);
	}

8334714: Implement JEP 484: Class-File API #19826

8334714: Implement JEP 484: Class-File API #19826

Conversation

asotona commented Jun 21, 2024 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Reviewing

bridgekeeper bot commented Jun 21, 2024

openjdk bot commented Jun 21, 2024 • edited Loading

openjdk bot commented Jun 21, 2024

mlbridge bot commented Jun 21, 2024 • edited Loading

Webrevs

liach commented Jun 21, 2024

AlanBateman commented Jun 21, 2024

asotona commented Jun 21, 2024

asotona commented Jun 21, 2024

ExE-Boss commented Jul 15, 2024

liach commented Jul 17, 2024

vicente-romero-oracle left a comment

Choose a reason for hiding this comment

bridgekeeper bot commented Aug 15, 2024

xxDark commented Aug 24, 2024 • edited Loading

liach commented Aug 24, 2024 • edited Loading

xxDark commented Aug 24, 2024 • edited Loading

liach commented Aug 24, 2024

xxDark commented Aug 24, 2024 • edited Loading

Col-E commented Aug 24, 2024 • edited Loading

liach commented Aug 24, 2024 • edited Loading

liach commented Aug 26, 2024

openjdk bot commented Aug 27, 2024

ExE-Boss Oct 21, 2024

Choose a reason for hiding this comment

asotona Nov 12, 2024

Choose a reason for hiding this comment

liach left a comment

Choose a reason for hiding this comment

liach left a comment

Choose a reason for hiding this comment

asotona commented Nov 15, 2024

openjdk bot commented Nov 15, 2024

openjdk bot commented Nov 15, 2024

liach Nov 15, 2024

Choose a reason for hiding this comment

asotona Nov 15, 2024

Choose a reason for hiding this comment

asotona Nov 15, 2024

Choose a reason for hiding this comment

lukellmann commented Nov 29, 2024

nizarbenalla commented Nov 29, 2024

ExE-Boss commented Dec 9, 2024

liach commented Dec 9, 2024

ExE-Boss commented Dec 9, 2024

asotona commented Jun 21, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Jun 21, 2024 •

edited

Loading

mlbridge bot commented Jun 21, 2024 •

edited

Loading

xxDark commented Aug 24, 2024 •

edited

Loading

liach commented Aug 24, 2024 •

edited

Loading

xxDark commented Aug 24, 2024 •

edited

Loading

xxDark commented Aug 24, 2024 •

edited

Loading

Col-E commented Aug 24, 2024 •

edited

Loading

liach commented Aug 24, 2024 •

edited

Loading