8361570: Incorrect 'sealed is not allowed here' compile-time error

[lahodaj]

Consider code like this:

$ cat /tmp/T.java 
import java.lang.ref.*;
public class T {
    public static void main(String[] args) {
        new WeakReference<>(null) {};
    }
}

Compiling this with JDK 25/26 leads to:

$ ./jdk-25/bin/javac /tmp/T.java
/tmp/T.java:4: error: modifier sealed not allowed here
        new WeakReference<>(null) {};
                                  ^
1 error

Which does not make much sense.

The reason for this is as follows:

• the type parameter for WeakReference is marked with @jdk.internal.RequiresIdentity, and the WeakReference's constructor has a parameter whose type is this type parameter.
• as a consequence, this parameter has internally in javac flag REQUIRES_IDENTITY. Note this flag has currently the same long value as SEALED, as the value is reused to mean different things for different Symbol kinds.
• when creating the anonymous class, javac creates a constructor, copying the REQUIRES_IDENTITY together with the constructor's parameter
• then javac goes on and checks whether the flags on the parameter are correct. And it sees the value for SEALED is set, and reports the error

Ultimately, I don't think we can reuse the value of SEALED to mean different things (and the same for all other similar cases). This PR assigns a different value for SEALED, and tries to add a test that strives to hopefully prevent similar cases in the future by saying that no Flags in ExtendedStandardFlags can be reused.

---

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-8361570: Incorrect 'sealed is not allowed here' compile-time error (Bug - P2)

Reviewers

• Maurizio Cimadamore (@mcimadamore - Reviewer)
• Vicente Romero (@vicente-romero-oracle - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26181

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jlahoda! 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]

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

8361570: Incorrect 'sealed is not allowed here' compile-time error

Reviewed-by: mcimadamore, 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 13 new commits pushed to the master branch:

• 63e08d4: 8361175: JFR: Document differences between method sample events
• 5c67e3d: 8361353: [PPC64] C2: Add nodes UMulHiL, CmpUL3, UMinV, UMaxV, NegVI
• 2349304: 8361040: compiler/codegen/TestRedundantLea.java#StringInflate fails with failed IR rules
• ... and 10 more: https://git.openjdk.org/jdk/compare/ec3bb93d7901c7756d7ff4cc18e4ae9d88942f93...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]

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

• compiler

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]

Webrevs

• 01: Full - Incremental (118503f0)
• 00: Full (efc83ed9)

[liach]

Why do we need to add RESTRCITED this time?

[lahodaj]

For every long value, the needs to be a enum Flag constant (which is weak, of course, as there are conceptually multiple flags using the same value, so the mapping to the enum would need to include the Symbol kind). As sealed now has a different number than RESTRICTED, RESTRICTED needs its own constant.

[liach]

If we are performing general flag checks, I recommend including checks to ensure there is exactly one bit set (like Long.lowestOneBit(flag) == flag)

So we no longer need a map, but can use a Field[64] and use Long.numberOfTrailingZeros to map to the array index.

[lahodaj]

I don't think this check is very general, it is more like a test checking one corner that is apparently problematic. Maurizio proposed a more general test below. There are constants in Flags that have multiple bits set (like ExtendedStandardFlags). We could filter those out, but having the map allows to collect all flags with the same value, not only 1+1.

[mcimadamore]

Fix looks good -- and thanks for the test.

I think we might be able to take the test a step further (in a separate PR) by introducing annotations to all flags, to denote whether a non-standard flag applies to:

• everything (such as extended standard flags)
• var-only (e.g. HAS_INIT)
• method-only (e.g. BRIDGE)
• type-only (e.g. ACYCLIC)

If we do this work, then we can write a test to make sure non-standard flags are truly disjoint. The test could also report an error when it finds any flag that doesn't have the associated annotation.

[mbien]

kudos to @lahodaj and colleagues who are working on the fixes - you guys are super fast. This PR appeared ~10h after the Apache NetBeans smoke test found it, the CCE issue (JDK-8361445) before that is also already fixed.

[lahodaj]

/integrate

[openjdk]

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

• 63e08d4: 8361175: JFR: Document differences between method sample events
• 5c67e3d: 8361353: [PPC64] C2: Add nodes UMulHiL, CmpUL3, UMinV, UMaxV, NegVI
• 2349304: 8361040: compiler/codegen/TestRedundantLea.java#StringInflate fails with failed IR rules
• ... and 10 more: https://git.openjdk.org/jdk/compare/ec3bb93d7901c7756d7ff4cc18e4ae9d88942f93...master

Your commit was automatically rebased without conflicts.

[openjdk]

@lahodaj Pushed as commit 8533194.

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

[lahodaj]

/backport :jdk25

[openjdk]

@lahodaj the backport was successfully created on the branch backport-lahodaj-85331943-jdk25 in my personal fork of openjdk/jdk. To create a pull request with this backport targeting openjdk/jdk:jdk25, just click the following link:

➡️ Create pull request

The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 85331943 from the openjdk/jdk repository.

The commit being backported was authored by Jan Lahoda on 8 Jul 2025 and was reviewed by Maurizio Cimadamore and Vicente Romero.

Thanks!

If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk:

$ git fetch https://github.com/openjdk-bots/jdk.git backport-lahodaj-85331943-jdk25:backport-lahodaj-85331943-jdk25
$ git checkout backport-lahodaj-85331943-jdk25
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk.git backport-lahodaj-85331943-jdk25