Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 549647

Summary:	bogusly ambiguous binding for java.util.Map$Entry
Product:	[Eclipse Project] JDT	Reporter:	Stephan Herrmann <stephan.herrmann>
Component:	Core	Assignee:	Stephan Herrmann <stephan.herrmann>
Status:	CLOSED NOT_ECLIPSE	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, jarthana, register.eclipse
Version:	4.13
Target Milestone:	4.13 M3
Hardware:	All
OS:	All
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=540922 https://bugs.eclipse.org/bugs/show_bug.cgi?id=562727
Whiteboard:

Description Stephan Herrmann

2019-07-29 18:02:41 EDT

attachment 279426 [details] from bug 540738 causes a ProblemReferenceBinding(Ambiguous) to be created for type java.util.Map$Entry with contributing packages from java.base and java.logging. This is wrong.

Comment 1 Stephan Herrmann

2019-07-29 18:31:24 EDT

Turns out to be a known issue in ClasspathJrtWithReleaseOption.findClass(String, String, String, String, boolean, Predicate<String>)

We ask module java.logging (or java.prefs, not deterministically) for type java.util.Map$Entry, and a seemingly valid ClassFileReader is returned, despite the fact that the given module does not contain that type.

This is caused by the JDK bug around https://bugs.openjdk.java.net/browse/JDK-8199521 : the file ct.sym from some releases does not specify sufficient information to associate types to modules when using the --release option.

Comment 2 Stephan Herrmann

2019-07-29 18:41:18 EDT

On further investigation I could reproduce the issue only when the project is configured for --release 10 whereas the actual JRE is 11 (openjdk).

In this case we already report (on the Compiler Properties page):

"""
The system libraries from the selected release 10 will be used with '--release' compiler option using current JRE 11. When using --release, it is recommended to use a JRE version 12 or greater.
"""

Indeed, using JRE 12 fixes the issue for me.

We could discuss making this warning more prominent and/or more drastic. But beyond that there's nothing we can do, I'm afraid.