Community
Participate
Working Groups
As per jep 261 (http://openjdk.java.net/jeps/261) there is a new version to java compiler: "The new option --module-version <version> may be used to specify the version strings of the modules being compiled." This option is supported by javac, but not ecj compiler. This can create problems in tools that rely on jep 261, e.g. maven-compiler-plugin which adds the --module-version option regardless of the compiler used. Feature request is to support this compiler option. If simple sample maven project to reproduce issue is required, let me know. See also stackoverflow question https://stackoverflow.com/questions/56534394/fatal-error-compiling-failed-to-run-the-ecj-compiler-unrecognized-option-m
Collecting information about the format of that version: JEP 261 has nothing more than the quote in comment 0. Please note the plurals in "version strings" and "modules being compiled" vs. the lack of any indication how several versions could be set. From this I conclude we need not pay attention to how many modules are being compiled, all will get the same version. JVMS has this in §4.7.25: "module_version_index The value of the module_version_index item must be either zero or a valid index into the constant_pool table. If the value of the item is zero, then no version information about the current module is present. If the value of the item is nonzero, then the constant_pool entry at that index must be a CONSTANT_Utf8_info structure representing the version of the current module." From this it seems that no restrictions whatsoever are imposed on that string.
New Gerrit change created: https://git.eclipse.org/r/144300
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/144300 I implemented the simplest thing that could possibly work. Batch compiler only. @Jay, is this too crude? I mean is it OK to pass this value via LookupEnvironment or do you think we should pass it along the BasicModule -> ModuleDeclaration chain? Do we need any sanity checks? (I can't easily think of any ...).
Well, if JDT had access to https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleDescriptor.Version.html then we could parse() the version string for validation ...
(In reply to Stephan Herrmann from comment #4) > Well, if JDT had access to > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleDescriptor. > Version.html then we could parse() the version string for validation ... In patch set #2 I'm attempting exactly that, via reflection. Note that "ecj -9" on a JRE below 9 fails to initRootModules() anyway, so I don't think we have to worry about requiring JRE 9 for version validation.
Gerrit change https://git.eclipse.org/r/144300 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=1816ae08ce632f4bae69df34b94257f4163cf7fc
(In reply to Eclipse Genie from comment #6) > Gerrit change https://git.eclipse.org/r/144300 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=1816ae08ce632f4bae69df34b94257f4163cf7fc Released for 4.13 M1 with the validation mentioned in comment 5.
(In reply to Stephan Herrmann from comment #3) > (In reply to Eclipse Genie from comment #2) > > New Gerrit change created: https://git.eclipse.org/r/144300 > > I implemented the simplest thing that could possibly work. > > Batch compiler only. > > @Jay, is this too crude? I mean is it OK to pass this value via > LookupEnvironment or do you think we should pass it along the BasicModule -> > ModuleDeclaration chain? > > Do we need any sanity checks? (I can't easily think of any ...). Stephan, sorry I was away and for some time didn't have to my mails. I haven't looked at it yet, but from what you have written, sounds okay to me. I will let you know if I have any concerns.
Verified for Eclipse 4.13 M1 with ecj-I20190709-0610.jar
