Method org.eclipse.jdt.internal.core.builder.ClasspathJar.initializeModule() tries to find module-info.class in a version-specific folder.
- This support seems incomplete as it cannot find module-info.class in a version lower than the single version in field
#compliance (e.g., when requesting version 24, whereas only version 17 provides module-info.class). If no exact match is found, we directly fall back to the unversioned source folder.
- actually
compliance is assigned only in the constructors of sub class ClasspathMultiReleaseJar
- Also
initializeModule() is overridden in ClasspathMultiReleaseJar
This looks like the implementation in ClasspathJar is both wrong and unneeded 😄
While at it, we might want to double check, which version is actually set as compliance, I see it derived from the version-sourcefolder mapping in a multi-release project, and many call paths passing JavaCore.NO_RELEASE.
Method
org.eclipse.jdt.internal.core.builder.ClasspathJar.initializeModule()tries to find module-info.class in a version-specific folder.#compliance(e.g., when requesting version 24, whereas only version 17 provides module-info.class). If no exact match is found, we directly fall back to the unversioned source folder.complianceis assigned only in the constructors of sub classClasspathMultiReleaseJarinitializeModule()is overridden inClasspathMultiReleaseJarThis looks like the implementation in
ClasspathJaris both wrong and unneeded 😄While at it, we might want to double check, which version is actually set as
compliance, I see it derived from the version-sourcefolder mapping in a multi-release project, and many call paths passingJavaCore.NO_RELEASE.