#7812 Java 17 - compatibility #7811
Conversation
christophs78
changed the title
|
I haven't looked at what is failing but did JDK 17 actually remove those things that used to be warnings about IllegalReflective activities? |
|
Yep. Maybe it´s a issue with OpenEJB comming with TomEE. To some degree it look´s like OpenEJB is dead. Had to replace this with Weld for JakartaEE-branch of Primefaces-test. |
|
Do we need to run with |
|
Here is a good article explaining it all! https://www.infoq.com/news/2021/06/internals-encapsulated-jdk17/ |
|
Looks like we need to use |
|
OK this is tricky if I add to the pom.xml the compiler args thta we need. <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<encoding>${project.build.sourceEncoding}</encoding>
<compilerArgs>
<arg>--add-modules</arg>
<arg>ALL-SYSTEM</arg>
<arg>--add-opens</arg>
<arg>java.base/jdk.internal.util=ALL-UNNAMED</arg>
<arg>--add-opens</arg>
<arg>java.base/java.lang=ALL-UNNAMED</arg>
</compilerArgs>
<argLine>
--add-modules ALL-SYSTEM
--add-opens java.base/jdk.internal.util=ALL-UNNAMED
--add-opens java.base/java.lang=ALL-UNNAMED
</argLine>
</configuration>
```
It fails on JDK8 saying "add-open" is not a valid JDK8 option. So not sure how we are going to make this work for JDK17 unless we add a Compiler plugin in a profile that activates only on JDK17. Which we probably have to do. |
|
in general i thought java17 would break much more as SecurityManager has been removed? maybe the methods are still there but otherwise it would even compile |
|
You are right I think there is going to be much more involved to make JDK17 work and possibly need updates from libraries etc. |
|
Well I got it compiling with this profile. But not sure about it running in a container yet <profile>
<id>java17</id>
<activation>
<jdk>17</jdk>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>11</source>
<target>11</target>
<encoding>${project.build.sourceEncoding}</encoding>
<compilerArgs>
<arg>--add-modules</arg>
<arg>ALL-SYSTEM</arg>
<arg>--add-opens</arg>
<arg>java.base/jdk.internal.util=ALL-UNNAMED</arg>
</compilerArgs>
<argLine>
--add-modules ALL-SYSTEM
--add-opens java.base/jdk.internal.util=ALL-UNNAMED
</argLine>
</configuration>
</plugin>
</plugins>
</build>
</profile>
``` |
|
I'll try https://www.codejava.net/servers/tomcat/how-to-embed-tomcat-server-into-java-web-applications later. Together with adding CDI, MyFaces/Mojarra,... via Maven-Dependency. |
|
Made some progress, but currently stuck to this one: Some idea´s WTF is going on there? (Did already some debugging, but without success.) (With Mojarra. MyFaces has some other issues, i did not analyze yet.) |
|
Made significant progress. This way we should be flexible to test whatever combination we wan´t / need to test. In theory we should be able to test with MyFaces-next too. There are still some rough edges to work on. But for now happy to reached this point. |
|
do we really need to support both weld and owb? for me its ok to have a plain tomcat but we may need to add multiple libs in the future like bval, jpa and so on we may even wait for the next tomee release, which will support java17 |
|
TomEE even does not have a final Jakarta EE 9 release. They have some milestone-release for Jakarta EE 9. But no TomEE embedded yet. From my feeling TomEE makes less progress. Personally i come from the Spring (Boot)-side of things and like the approach of having a simple container and adding the thing you need on your own. (Way more agile compared to what we did with Websphere Traditional before.) |
|
yeah but they have in theory |
|
many impls decided in the apache world to just shade a release for EE9 as the API is completely the same |
|
Overall javax to jakarta is IMO a sad story. Too much work and not enough resources. And overall too much people which say JavaEE / JakartaEE is dying and other negativ things. |
|
true |
|
Hope so. People need to get some faith into Jakarta EE and it´s future. (Not so easy after years of stagnation.) |
|
All (integration-)tests´s green. On Java 8, 11, 16 and 17. :-) I have to do some cleanup-work later to get this PR into "production-quality". |
|
OOOO you can now seal off your shaded packages! RestEasy doesn't support modularization at all, the SPI jar is external to the operations and it throws invalid module definition (the class file has to be in the same jar that calls the serviceloader) Are you using modules? or are the test cases purely still in classpath mode? |
|
@melloware let's try not open up the system or allow illegal access during compilation - is there any reason why that was necessary?? My default build config looks to work without any opening of illegal access |
|
Maybe different expectations? |
|
Ok thanks! Doesn't even compile in JDK 11 now cause of RestEasy now in the default set of dependencies and everything is in the modular compiler - Will make the changes necessary on my end, understandable for JDK 8 compatibility not just using the straight JDK for the rest calls Siiiiiigggghhhhh :) Thanks @christophs78 |
|
Do you know some JAX-RS-impl we may use instead of RestEasy which is compatible with Java 11+ and modules? |
|
I've been hard pressed to find one for a long time, truth is, I doubt we will ever see/need one It's not necessary with the JDK java.net updates, it's quicker to write it in raw Java than it is to add a dependency to the POM file The rest libraries are definitely only for JDK 8 and below, no point in making one for JDK 11 and up, hence, no worries - i can sort it out on my end, also gives a good base for when EE10 comes out on a modular front, EE9 was nothing short of an abortion for this |
christophs78
changed the title
|
same for properties like resteasy.version |
|
OK no problem. Just a warning though you may get multiple dependabot PR's one for each project for things likee Jetty etc. |
|
OWB (instead of Weld) for Integration Tests causes this one: (Via Jetty-Plugin, similar with Tomcat-embedded. Same like a few days ago when i tried it the first time. ) Maybe i should try one more time in a few more days. Or someone some idea´s? @tandraschko: You prefer OWB over Weld because it´s an Apache - project? So switchting Showcase to Weld is not an option? |
|
That OWB error I think I solved in PrimeFaces test with an openwebbeans.properties file. You could try |
|
i prefer OWB for the same reason i prefer MyFaces (perf, footprint, stricter spec compatibility, apache, ...) |
Helps with Jetty-Maven-plugin but not with embedded Tomcat. Maybe part of the complicated "truth" is 'org.apache.webbeans.scanExclusionPaths': |
| /jsr305-, \ | ||
| /guice-, \ | ||
| /jsoup-, \ | ||
| /jakarta.faces- |
There was a problem hiding this comment.
We have a hack which makes OWB working together with Mojarra (Jakarta Faces) and Tomcat embedded.
Holy ....
|
actually the scan exclusions is JUST for faster startup as they are known JARs which doesnt require scanning i will talk with romain again, how we can make it work and either create a issue on mojarra or OWB side |
|
Thanks Thomas for talking with Romain again! Probably one last thing to fix for Mojarra + OWB: First 13 tests pro testclass work, afterwards they break: Do we need to increase some limit, or set .... ? |
|
Can you explain what causes that error? |
Hm. ViewScopeManager#processPostConstructViewMap detects there are too many views in (Mojarra) ACTIVE_VIEW_MAPS. So it decides to remove the eldest. Hm. An initialization-order issue? I currently work around with a HttpSessionListener which sets |
|
Yeah. Mojarra has some special treatment for Weld, but non for OWB. Better to go to bed before i write (more) bad things. |
|
Yeah, thats: eclipse-ee4j/mojarra#4642 Maybe you can create a PR at mojarra side for the most recent branches |
|
Yes, i will do this later this week. MyFaces does this aspect better. I will try do port this good aspects to Mojarra. |
|
The first issue about the scanning exclusions is probably really something that OWB doesnt follow the spec in every detail. I will discuss it and try to fix. Would be great if you can create the PR about the Mojarra issue, to use CDI.current as fallback. |
|
@christophs78 can you set org.apache.webbeans.scanExtensionJars=false instead of the exclude list? this must work and enforces spec compatiblity for this case |
Due to some reasons i don´t understand (yet) |
|
weird but ok |
fix Mojarra + OWB (fix typo) fix Mojarra + OWB OWB instead of Weld ConfirmPopup001Test - GuardAjax Jetty-plugin up and running Jetty-plugin up and running Cleanup test vs compile/runtime - scope and Jetty-Maven-Plugin WIP modify deployment to Tomcat - unused import modify deployment to Tomcat fix maven-scope for MyFaces-next src/main vs src/test; back; something is weird with classpath cleanup src/main vs src/test org.apache.myfaces.USE_LAMBDA_METAFACTORY=false removed one dependency too much MyFaces Next, cleanup cleanup remove Java17 - profile REST(easy) Hibernate Validator + Rollback copy WAR to tempdir copy WAR to tempdir kind of working on MyFacess too? kind of working on Mojarra? Tomcat instead of TomEE - WIP - not working yet and cleanup needed afterwards JDK17 profile JDK17 Profile Reverted Attempt --add-open fix broken with Java 17-ea, what´s our state with Java 16? run integrationtests also on Java 17 run integrationtests also on Java 17 CI - Java 17 instead of Java 16 CI - Java 17 instead of Java 16 CI - Java 17 instead of Java 16 CI - Java 17 instead of Java 16 CI - Java 17 instead of Java 16
christophs78
force-pushed
the
Java17
branch
from
d9ce707
to
aadd6ac
Compare
|
Squashed and rebased onto master. |
No description provided.