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

Handle java source/target defined at extension level #188

Merged
merged 1 commit into from
Oct 18, 2024

Conversation

Arthurm1
Copy link
Contributor

This will take into account the java plugin source/target compatibility settings.
e.g. using...

java {
  targetCompatibility = JavaVersion.VERSION_1_8
  sourceCompatibility = JavaVersion.VERSION_1_9
}

instead of

tasks.withType(JavaCompile) {
  sourceCompatibility = JavaVersion.VERSION_1_8
  targetCompatibility = JavaVersion.VERSION_1_9
}

I'm not sure if this is enough to fix redhat-developer/vscode-java#3721. The source/target compatibility in JVMBuildTarget will have changed but the javac options will still contain --release 8. Hopefully that will be ok for the eclipse settings.

I note that here it says to configure the compileJava task with source/target and not the java plugin when using Jabel

I've also extended the POJO constructor copying used in DefaultSourceSets to the language extensions. It's not needed for normal running but it's a pain when debugging as all the variables/watches just show the proxy classes.

@jdneo
Copy link
Member

jdneo commented Aug 28, 2024

I've also extended the POJO constructor copying used in DefaultSourceSets to the language extensions. It's not needed for normal running but it's a pain when debugging as all the variables/watches just show the proxy classes.

There is an issue about this: #175. I also did some investigation and turns out the copy constructor is not needed for running.

I'm thinking that, for debugging purpose, maybe override toString() is a better approach than using the copy constructor?


Update:

The copy constructor is required. If we remove all the copy constructor, here:

The sourceset is a proxy wrapperred type, and it will encounter some problem

image

@Arthurm1
Copy link
Contributor Author

The copy constructor is required. If we remove all the copy constructor, here:

Shall I leave my changes to DefaultJavaExtension/DefaultScalaExtension then or do you want them gone?

@jdneo
Copy link
Member

jdneo commented Aug 29, 2024

Shall I leave my changes to DefaultJavaExtension/DefaultScalaExtension

I think you can leave as it is. Until we find a way to get rid of the copy constructor entirely

@jdneo
Copy link
Member

jdneo commented Sep 3, 2024

@Arthurm1

I think we should use javaCompile.getSourceCompatibility() and javaCompile.getTargetCompatibility().

AFAIK, there are three different kind of ways to set the source/target level.

java {
  targetCompatibility = JavaVersion.VERSION_1_8
  sourceCompatibility = JavaVersion.VERSION_1_9
}
tasks.withType(JavaCompile) {
  sourceCompatibility = JavaVersion.VERSION_1_8
  targetCompatibility = JavaVersion.VERSION_1_9
}
sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_9

The current approach cannot get the version in case 2. While using the JavaCompile instance can cover all three cases.

Considering JavaCompile is official API which no need to use reflection, I prefer to use it directly.

@jdneo jdneo added this to the 0.4.0 milestone Sep 3, 2024
@jdneo jdneo added the bug Something isn't working label Sep 3, 2024
@jdneo
Copy link
Member

jdneo commented Sep 12, 2024

Hi @Arthurm1, would you like to update the PR?

Or do you have any concern about javaCompile.getSourceCompatibility() and javaCompile.getTargetCompatibility()

@Arthurm1
Copy link
Contributor Author

@jdneo Will look at it this weekend and probably change the PR

@jdneo
Copy link
Member

jdneo commented Sep 13, 2024

@Arthurm1 Thank you.

My thought is that we can just simply get the source/target level from JavaCompile, no need to inspecting from compile args. (Correct me if this is working for any cases)

@Arthurm1
Copy link
Contributor Author

Arthurm1 commented Oct 9, 2024

@jdneo I've changed it so that the source/target compatibility is populated purely from the JavaCompile task. JavacOptions are still passed back for BSP but they are ignored for compatibility settings.

This seems to reflect more how people use the Gradle settings, i.e. set source/target compatibility in JavaCompile for IDE usage and the JavacOptions for jar and release.

@jdneo jdneo merged commit 0654447 into microsoft:develop Oct 18, 2024
4 checks passed
@jdneo
Copy link
Member

jdneo commented Oct 18, 2024

Thank you @Arthurm1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

'Type Pattern' being reported as an error even though Java source level is above 16
2 participants