Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support javac as a compiler for Tycho #3350

Merged
merged 1 commit into from
Jan 11, 2024
Merged

Conversation

laeubi
Copy link
Member

@laeubi laeubi commented Jan 11, 2024

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.

@mickaelistria
Copy link
Contributor

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.

@laeubi
Copy link
Member Author

laeubi commented Jan 11, 2024

/request-license-review

@laeubi laeubi marked this pull request as ready for review January 11, 2024 13:32
Copy link

/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):
https://github.com/eclipse-tycho/tycho/actions/runs/7489496537

@laeubi
Copy link
Member Author

laeubi commented Jan 11, 2024

I now made the (very simple) testcase pass by just omit any custom options Tycho adds if not ECJ is selected as compiler.

@laeubi laeubi added the backport-to-tycho-4.0.x Can be added to a PR to trigger an automatic backport of the change label Jan 11, 2024
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(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bootclasspath is a standard javac option. Skipping this might cause surprises.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a standard javac option, too

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)) {
Copy link

@szarnekow szarnekow Jan 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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<>();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@laeubi
Copy link
Member Author

laeubi commented Jan 11, 2024

@szarnekow the javac support is really basic, I think the best would be to merge this first (I already tested it with a smaller Tycho project) and enhance it afterwards by e.g. adding another testcase that makes use of some of the yet not supported option.

Another open issue is that we should upgrade to catch up with the latest changes from the maven-compiler-plugin here:

Copy link

Test Results

  579 files  +3    579 suites  +3   3h 53m 45s ⏱️ - 2m 35s
  382 tests +1    374 ✅ +1   7 💤 ±0  1 ❌ ±0 
1 146 runs  +3  1 123 ✅ +3  22 💤 ±0  1 ❌ ±0 

For more details on these failures, see this check.

Results for commit 7cc26f2. ± Comparison against base commit 36fd6a9.

@laeubi laeubi merged commit 7d9df57 into eclipse-tycho:main Jan 11, 2024
8 of 10 checks passed
Copy link

💔 All backports failed

Status Branch Result
tycho-4.0.x Backport failed because of merge conflicts

You might need to backport the following PRs to tycho-4.0.x:
- Add support for API Tools Annotations to Tycho

Manual backport

To create the backport manually run:

backport --pr 3350

Questions ?

Please refer to the Backport tool documentation and see the Github Action logs for details

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-to-tycho-4.0.x Can be added to a PR to trigger an automatic backport of the change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants