Re: Jakarta EE 11 may be changing minimum Java version to 17
Hi, This is more compliance than function, unfortunately. Open Liberty plans to pass the TCK under both 17 and 21 (although only one is required). If the EL jar we use is Java 21 byte code, then we wouldn't be able to run the Jakarta EE 11 features on 17. If Tomcat could compile EL against 17, that would be a huge help. If not, we have workarounds. Volodymyr On Fri, Jan 19, 2024 at 9:41 AM Mark Thomas wrote: > On 19/01/2024 14:20, Volodymyr Siedlecki wrote: > > Hi Mark, > > > > I understand your perspective about changing 21 to 17 so late. > > > > Open Liberty uses Tomcat's Expression Language and we would prefer to > > use a Java 17 binary. However, there are workarounds for us. > > Ack. > > I'll note that the EL code will compile quite happily with Java 17 or > Java 21. > > Can you expand on why you'd prefer Java 17? Ignoring how late in the > process this change is being made, I've yet to hear a logically > consistent argument for selecting Java 17 over Java 21. > > > As for the EL TCK issue, I'd be happy to take a look if you push up a > branch. > > Thanks for the offer but I have already fixed the issue. > > Mark > > > > > > Thank you, > > > > Volodymyr > > > > > > On Fri, Jan 19, 2024 at 6:38 AM Mark Thomas wrote: > > > >> On 16/01/2024 11:44, Rémy Maucherat wrote: > >>> On Tue, Jan 16, 2024 at 11:59 AM Mark Thomas wrote: > >>>> > >>>> Hi all, > >>>> > >>>> I'm not sure what is going on as there has been one significant change > >>>> in the announcement already but it looks to me as if the minimum Java > >>>> version for Jakarta EE 11 is changing to Java 17 rather than Java 21. > >>>> > >>>> https://www.eclipse.org/lists/jakartaee-platform-dev/msg04371.html > >>>> > >>>> It seems far too late in the day for this change to me but I'm not > sure > >>>> that view is going to carry much weight. > >>>> > >>>> I've taken a quick look at the Tomcat 11 code base and a JreCompat for > >>>> Java 21 shouldn't be too much work. I'm not planning on doing anything > >>>> on this until the intentions of the Jakarta EE platform team are > >> clearer. > >>> > >>> That's annoying ... The virtual threads are in the 21 compat. The > >>> Panama for Java 22 and building releases with 22+ should not require > >>> any additional changes. > >> > >> I'm going to be looking at switching Java 17 locally as I have an EL TCK > >> issue I need to investigate that only happens on Java 17. I can push > >> that branch to GitHub if there is interest. However, I am a long way > >> from being ready to support that change for 11.0.x. > >> > >> I ma trying to think about this in terms of what would be best for our > >> user community. > >> > >> Working to a minimum of Java 17 would make Tomcat 11 an option for those > >> using willing to move to Java 17 but unwilling to move to Java 21. What > >> I am not sure about is how big a proportion of our community that is. If > >> I had to guess, I'd say very small. > >> > >> Working to a minimum of Java 21 would mean users could be sure that > >> anything claiming Jakarta 11 compliance would work with Tomcat - whether > >> it required Java 17 or Java 21 as a minimum. > >> > >> Given the above, I'm leaning towards sticking with Java 21 as the > >> minimum unless there is user demand for Java 17. I'll note that we can > >> always reduce the minimum version at any point in the future - even > >> between stable point releases. > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Jakarta EE 11 may be changing minimum Java version to 17
Hi Mark, I understand your perspective about changing 21 to 17 so late. Open Liberty uses Tomcat's Expression Language and we would prefer to use a Java 17 binary. However, there are workarounds for us. As for the EL TCK issue, I'd be happy to take a look if you push up a branch. Thank you, Volodymyr On Fri, Jan 19, 2024 at 6:38 AM Mark Thomas wrote: > On 16/01/2024 11:44, Rémy Maucherat wrote: > > On Tue, Jan 16, 2024 at 11:59 AM Mark Thomas wrote: > >> > >> Hi all, > >> > >> I'm not sure what is going on as there has been one significant change > >> in the announcement already but it looks to me as if the minimum Java > >> version for Jakarta EE 11 is changing to Java 17 rather than Java 21. > >> > >> https://www.eclipse.org/lists/jakartaee-platform-dev/msg04371.html > >> > >> It seems far too late in the day for this change to me but I'm not sure > >> that view is going to carry much weight. > >> > >> I've taken a quick look at the Tomcat 11 code base and a JreCompat for > >> Java 21 shouldn't be too much work. I'm not planning on doing anything > >> on this until the intentions of the Jakarta EE platform team are > clearer. > > > > That's annoying ... The virtual threads are in the 21 compat. The > > Panama for Java 22 and building releases with 22+ should not require > > any additional changes. > > I'm going to be looking at switching Java 17 locally as I have an EL TCK > issue I need to investigate that only happens on Java 17. I can push > that branch to GitHub if there is interest. However, I am a long way > from being ready to support that change for 11.0.x. > > I ma trying to think about this in terms of what would be best for our > user community. > > Working to a minimum of Java 17 would make Tomcat 11 an option for those > using willing to move to Java 17 but unwilling to move to Java 21. What > I am not sure about is how big a proportion of our community that is. If > I had to guess, I'd say very small. > > Working to a minimum of Java 21 would mean users could be sure that > anything claiming Jakarta 11 compliance would work with Tomcat - whether > it required Java 17 or Java 21 as a minimum. > > Given the above, I'm leaning towards sticking with Java 21 as the > minimum unless there is user demand for Java 17. I'll note that we can > always reduce the minimum version at any point in the future - even > between stable point releases. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Translations of LocalStrings.properties are not included in the Tomcat EL API Binary
Hello, I noticed that only the English version of LocalStrings.properties is included in the binary file while the source contains the other translations. For example, if you look in the tomcat-el-api-10.0.12.jar and tomcat-el-api-10.0.12-sources.jar Is this on purpose or should the binary contain the translations? Here's the link to the file in Github: https://github.com/apache/tomcat/blob/main/java/jakarta/el/LocalStrings.properties Link to repo: https://repo1.maven.org/maven2/org/apache/tomcat/tomcat-el-api/10.0.12/ Thanks, Vlad
TCK Signature for EL API
Hello, It appears the TCK Signature tests will not be relaxed (see 1 & 2), and I'm wondering how Tomcat will proceed with the bnd annotation in the EL API? Will it be removed in the next release? Thank you, Volodymyr 1) https://github.com/eclipse-ee4j/jakartaee-tck/issues/643 (Scott's last comment)2) TCK Thread: https://www.eclipse.org/lists/jakartaee-tck-dev/threads.html#01235
10.0.x Release Question
Hello, Since 10.0.0 is still in beta, is there an expected timeframe of a non-beta release? Will it be 10.0.1 or another future release? Thank you for your help, Volodymyr
