You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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?
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:
While the
ClassFile
could use its enclosingIJavaProject
to detect the--release 19
option, we indirectly useJRTUtil.getClassfileContent()
which constantly passesnull
as therelease
ingetJrtSystem()
. 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:
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 inJrtFileSystem.getClassfileContent()
/JrtFileSystem.getFileBytes(String, String)
, which have no override inJrtFileSystemWithOlderRelease
.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.
The text was updated successfully, but these errors were encountered: