build(deps): update dependency org.eclipse.jdt:org.eclipse.jdt.core to v3.39.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.eclipse.jdt:org.eclipse.jdt.core (source)	3.38.0 -> 3.39.0

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[SirYwell]

It looks like JDT dropped support for targeting Java 1.7. So the minimum compliance level must be 8 now.

[I-Al-Istannen]

public class Action<Request extends BroadcastRequest<Request>, ShardRequest> {
    private final Request request;
    protected void performOperation(final int shardIndex) {
        ShardRequest shardRequest = newShardRequest(request);
        shardRequest.setParentTask(foobar);
    }
}

This is MWE for the failing stackoverflow test. The new version of JDT does not have a variable binding for the setParentTask method call, as it does not seem to find the definition of the local variable.
Prerequisites:

• Request is a recursive generic
• request is passed to newShardRequest
• The input of setParentTask is an undefined variable (otherwise the declaring type resolves to null even in older JDT versions)

I am not sure if this can reasonably be construed a JDT bug. There is basically nothing valid left in the code, though the connection to the variable feels quite easy to make…

[MartinWitt]

@I-Al-Istannen I had a look at the issue. It seems this will be fixed in 3.40?

[I-Al-Istannen]

@MartinWitt Sounded like it :)

[MartinWitt]

Hmm we could mark the failing testcases as ignored and accept the regression? Otherwise, we would need to wait till January?

[I-Al-Istannen]

We could use @GithubIssue (and reference this PR?) with fixed=false? This way it will automatically fail in the next bump PR, if it were to be fixed.

[MartinWitt]

Ah yes this is way better.

[MartinWitt]

Okay some random changes later everything is green

[I-Al-Istannen]

Neat. Then I guess we can merge this. I will do that tomorrow, or you can do it before :P

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.