Compile to Java 11 with module-info#21
Conversation
Removes Automatic-Module-Name manifest entry and replaces it with module-info
overheadhunter
left a comment
There was a problem hiding this comment.
When no longer targeting Java 8, maven.compiler.release performs stricter validation. See this SO answer explaining the differences
| <maven.compiler.source>1.8</maven.compiler.source> | ||
| <maven.compiler.target>1.8</maven.compiler.target> | ||
| <maven.compiler.source>9</maven.compiler.source> | ||
| <maven.compiler.target>9</maven.compiler.target> |
There was a problem hiding this comment.
When moving to newer Java, I'd suggest to also move to using <maven.compiler.release>.
There was a problem hiding this comment.
That is fine. I need to bump the maven-compiler-plugin version to do that but no problem.
There was a problem hiding this comment.
Ok, changed to use maven.compiler.release and pushed that commit.
There was a problem hiding this comment.
Why not target Java 11 instead?
There was a problem hiding this comment.
I have no problem with Java 11. Shall I change it to 11?
There was a problem hiding this comment.
Ok, I have changed it to compile to java 11 @Emily-Jiang
There was a problem hiding this comment.
@Emily-Jiang @overheadhunter @Ladicek , are you guys happy with this PR now? Ok to approve it? Anything else to adjust on it?
There was a problem hiding this comment.
I'm happy, but since I have no say in jakarta my approval doesn't really make a difference 😉
|
I'm looking at https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan, specifically this part:
There was also a discussion about this on the My understanding is that we don't intend to do any changes in Jakarta Inject, so I guess it would be best to stay on 8 and just add a generated Would that make sense? (Genuine question. There's too many things I don't really understand here :-) ) |
You are correct, it can. I have modified #20 such that it isn't a multi-version jar.
I don't mind (or don't get a vote per say) but I'd also suggest we could do both? That is, release a version 2.0.1 that compiles using Java 8 (with module-info via moditech) and then additionally release a 3.0.0 version using Java 11? In that I think it's going to be nicer longer term to maintain Java 11 without the moditech plugin etc and anyone stuck on java 8 would have the 2.0.0 and 2.0.1 artifacts available to them. |
Note that we need to use a recent version of maven-compiler-plugin for this.
|
I had a second thought on this. Since CDI depends on this, if CDI wants to support Java 8, this spec should compile on Java 8 as well. Otherwise, this will force CDI to move up to Java 11. We should discuss this at CDI spec @Ladicek before we can merge this PR. |
Emily-Jiang
left a comment
There was a problem hiding this comment.
Please don't merge this as yet until we discuss the mininum supported Java version in the CDI spec.
hence merge & release #20 before this one, as proposed by @rbygrave in #19 |
|
Personally, I'd just merge #20, which lets us do a micro release, have a |
|
I guess this PR is not needed. Shall we close this PR for now? |
|
Yes, I think we can close this for now. I am happy to submit another PR if we want to release a java 11 based artifact. |
Removes Automatic-Module-Name manifest entry and replaces it with module-info