Skip to content

8381965: NullPointerException in TypeAnnotationPositions#30679

Open
lahodaj wants to merge 2 commits intoopenjdk:masterfrom
lahodaj:JDK-8381965
Open

8381965: NullPointerException in TypeAnnotationPositions#30679
lahodaj wants to merge 2 commits intoopenjdk:masterfrom
lahodaj:JDK-8381965

Conversation

@lahodaj
Copy link
Copy Markdown
Contributor

@lahodaj lahodaj commented Apr 10, 2026

Consider code like this:

import java.lang.annotation.ElementType;
import java.lang.annotation.Target;
import java.util.function.Consumer;
import java.util.List;

class Test {
    static final Consumer<List<@TypeAnno String>> TEST = id((List<@TypeAnno String> arg) -> {});


    private static <T> Consumer<T> id(Consumer<T> t) { return t;}
}

@Target(ElementType.TYPE_USE)
@interface TypeAnno { }

There's an explicit lambda here, (List<@TypeAnno String> arg) -> {}. javac will create a helper block for it in DeferredAttr.attribSpeculativeLambda:

{
    List<@TypeAnno String> arg;
    {}
}

and will then speculative-attribute this block. But, when the parameters are placed into the block, they are still marked/flagged as parameters. And since the fix for https://bugs.openjdk.org/browse/JDK-8371155, the type annotations positions on the local variable type get resolved earlier in the pipeline, and even during the speculative attribution. But when the position for the type annotation is being resolved during this speculative attribution, the variable is interpreted as a parameter, but there's no (meaningful) enclosing lambda. So javac either fails with an exception, or assigns nonsensical position to the type annotation.

The primary proposal in the PR is to avoid resolving type annotations while doing speculative attribution.



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-8381965: NullPointerException in TypeAnnotationPositions (Bug - P2)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 30679

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

Using diff file

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

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link
Copy Markdown

bridgekeeper bot commented Apr 10, 2026

👋 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
Copy link
Copy Markdown

openjdk bot commented Apr 10, 2026

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added the compiler compiler-dev@openjdk.org label Apr 10, 2026
@openjdk
Copy link
Copy Markdown

openjdk bot commented Apr 10, 2026

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

@openjdk openjdk bot added the rfr Pull request is ready for review label Apr 10, 2026
@mlbridge
Copy link
Copy Markdown

mlbridge bot commented Apr 10, 2026

Webrevs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

compiler compiler-dev@openjdk.org rfr Pull request is ready for review

Development

Successfully merging this pull request may close these issues.

1 participant