Reconciler doesn't leverage --release option

[stephan-herrmann]

In a project using a recent JDK (e.g., 23) that is configured with --release 19, the reconciler will see class files from the most recent version (here 23), despite the --release option.

Classes are read in this call stack:

ClassFileReader.<init>(byte[], char[], boolean) line: 242	
ClassFile.getJarBinaryTypeInfo() line: 228	
ClassFile.existsUsingJarTypeCache() line: 147	
NameLookup.seekTypesInBinaryPackage(String, IPackageFragment, boolean, int, IJavaElementRequestor) line: 1475	
NameLookup.seekTypes(String, IPackageFragment, boolean, int, IJavaElementRequestor, boolean) line: 1442	
NameLookup.findType(String, IPackageFragment, boolean, int, boolean, boolean) line: 988	
NameLookup.findType(String, String, boolean, int, boolean, boolean, boolean, IProgressMonitor, IPackageFragmentRoot[]) line: 815	
NameLookup.findType(String, String, boolean, int, boolean, IPackageFragmentRoot[]) line: 734	
CancelableNameEnvironment(SearchableEnvironment).find(String, String, IPackageFragmentRoot[]) line: 191	
CancelableNameEnvironment(SearchableEnvironment).findType(char[], char[][], char[]) line: 549	
LookupEnvironment.fromSplitPackageOrOracle(IModuleAwareNameEnvironment, ModuleBinding, PackageBinding, char[]) line: 473	
LookupEnvironment.lambda$1(IModuleAwareNameEnvironment, PackageBinding, char[], ModuleBinding) line: 346	
0x00007f6213aac050.apply(Object) line: not available	
LookupEnvironment.askForTypeFromModules(ModuleBinding, ModuleBinding[], Function<ModuleBinding,NameEnvironmentAnswer>) line: 440	

While the ClassFile could use its enclosing IJavaProject to detect the --release 19 option, we indirectly use JRTUtil.getClassfileContent() which constantly passes null as the release in getJrtSystem(). This, btw, seems the prevalent use of that method!

To observe this behavior, use the above project configuration and inside a method catching MalformedURLException type the following without saving:

URL.of(null, null);

You will not see an error until the file is saved. This demonstrates that in fact the 23 version is used by the reconciler, where the method exists (since 21).

Manually tweaking getJrtSystem() to use release "19" (in the debugger) does not suffice, because the logic used to locate the class file is in JrtFileSystem.getClassfileContent() / JrtFileSystem.getFileBytes(String, String), which have no override in JrtFileSystemWithOlderRelease.

I'm not even sure if its a good idea to amend the code to respect the release version, because there's a lot of caching going on, where I don't readily see if those caches are multi-version aware??

In fact, I don't readily see if there is any low hanging fruit, or whether the inconsistency is actually tolerable in face of the complexity.

[stephan-herrmann]

After saving, we have this inconsistency on URL.of(null, null)

• an error is shown "The method of(null, null) is undefined for the type URL"
• pressing F3 will navigate to that method (in JDK 23).
• Ctrl+Shift hover will show the javadoc of that method (in JDK 23).

[stephan-herrmann]

Notifying a few people having worked in this area, @jarthana @jukzi @iloveeclipse @HannesWell @laeubi -- do any of you have an opinion they want to share? Has this perhaps been discussed before?