Support javac as a compiler for Tycho #3350
Conversation
|
This is an interesting feature also for people who want to build/use plugins leveraging very new Java features which aren't yet supported by ECJ. |
|
/request-license-review |
License review requests: After all reviews have concluded, re-run the license-vetting check from the Github Actions web-interface to update its status. Workflow run (with attached summary files): |
|
I now made the (very simple) testcase pass by just omit any custom options Tycho adds if not ECJ is selected as compiler. |
laeubi
added
the
backport-to-tycho-4.0.x
Currently Tycho is strictly using ecj as a compiler but in general it might be there are situations one wants to use javac for compilation even though it might not has full features supported (e.g. package restrictions). This is an attempt to make it possible to use javac at a very basic level.
| @@ -851,14 +855,22 @@ private void configureBootClassPath(CompilerConfiguration compilerConfiguration, | |||
| if (includeParent != null) { | |||
| Xpp3Dom[] includes = includeParent.getChildren("include"); | |||
| if (includes.length > 0) { | |||
| compilerConfiguration.addCompilerCustomArgument("-bootclasspath", scanBootclasspath( | |||
| addCompilerCustomArgument(compilerConfiguration, "-bootclasspath", scanBootclasspath( | |||
There was a problem hiding this comment.
Bootclasspath is a standard javac option. Skipping this might cause surprises.
There was a problem hiding this comment.
It seems not to be a standard plexus compiler option so I'm not sure how to handle this gracefully...
| @@ -738,7 +742,7 @@ protected CompilerConfiguration getCompilerConfiguration(List<String> compileSou | |||
| if (jreClasspathEntry.isModule()) { | |||
| Collection<String> modules = jreClasspathEntry.getLimitModules(); | |||
| if (!modules.isEmpty()) { | |||
| compilerConfiguration.addCompilerCustomArgument("--limit-modules", String.join(",", modules)); | |||
| addCompilerCustomArgument(compilerConfiguration, "--limit-modules", String.join(",", modules)); | |||
There was a problem hiding this comment.
This is a standard javac option, too
There was a problem hiding this comment.
It seems not to be a standard plexus compiler option so I'm not sure how to handle this gracefully...
| @@ -581,7 +582,7 @@ public List<String> getClasspathElements() throws MojoExecutionException { | |||
| .filter(AbstractOsgiCompilerMojo::isValidLocation).distinct(); | |||
| classpathLocations.forEach(location -> { | |||
| String path = location.getAbsolutePath(); | |||
| String entry = path + toString(cpe.getAccessRules()); | |||
| String entry = path + toString(cpe.getAccessRules(), useAccessRules); | |||
| if (seen.add(entry)) { | |||
There was a problem hiding this comment.
For all but the first entry seen.add(entry) will be false. The included paths and the classpath will miss entries. (with javac that is)
There was a problem hiding this comment.
For all but the first entry
seen.add(entry)will be false. The included paths and the classpath will miss entries. (with javac that is)
I'm not sure I understand what you want to suggest here, the whole "see" part is that a path could apear multiple times (e.g. with different environments) so it is to make the list not contain it more than once ...
| @@ -573,6 +573,7 @@ public List<String> getClasspathElements() throws MojoExecutionException { | |||
| final List<String> classpath = new ArrayList<>(); | |||
There was a problem hiding this comment.
@laeubi This class AbstractOsgiCompilerMojo does not contain any JavaDoc on the class declaration itself. It makes me wonder if it is even supposed to work with javac, given that the plain Java compiler does not have any understanding of OSGI semantics.
There was a problem hiding this comment.
Compilation actually do not require much of OSGi, ECJ supports "restrictions" on classpath entries but javac not as far as I know so thats the main difference here, also the target and source levels are derived from the manifest if possible.
|
@szarnekow the Another open issue is that we should upgrade to catch up with the latest changes from the maven-compiler-plugin here: |
Test Results 579 files +3 579 suites +3 3h 53m 45s ⏱️ - 2m 35s For more details on these failures, see this check. Results for commit 7cc26f2. ± Comparison against base commit 36fd6a9. |
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
Currently Tycho is strictly using ecj as a compiler but in general it might be there are situations one wants to use javac for compilation even though it might not has full features supported (e.g. package restrictions).
This is an attempt to make it possible to use javac at a very basic level.