Clarify adoption of JPMS Java modules in webapps
Hey there, I'm currently preparing a Java upgrade of my Tomcat application from 17 to 25. In JDK 24 (https://openjdk.org/jeps/472) a new runtime warning was added if a class tries to use native methods, which is the the case in one of my libraries. I'm currently trying to figure out whether I can avoid this warning without having to resort to `|--enable-native-access=ALL-UNNAMED|` which would enable native access for the entire class-path (and not selectively only for the part that needs it). The library performing the native access is an automatic module, so if I started the JVM with it on the module path I should be able to say `|--enable-native-access=my.module|` instead. The trouble is of course that my JVM only starts running the tomcat classes, and tomcat will then later load my classes (i.e. tomcat decides where the classes should go, not `java`). I have only found one question on the users list from someone struggling with a similar Issue (https://marc.info/?l=tomcat-user&m=157356882531534&w=2), but unfortunately that thread go into much detail. So my concrete questions are: 1. Am I correct in saying that there is no way to make the tomcat webapp classloader load (some of) my classes onto the module-path instead of the class-path? And if that is the case, is this a deliberate decision (or just not implemented yet) by tomcat or are there other, bigger reasons? 2. Could I circumvent this by including my JPMS modules in the `java` command line which would otherwise only start the tomcat classes (As I understand I should be able to access them from the webapp if I enabled the delegate option in the loader, see https://tomcat.apache.org/tomcat-10.1-doc/config/loader.html)? Then I suppose I should be able to restrict native access to this module, but I'm wondering if that would break something else in tomcat/my webapp? 3. Is there any other way except giving ALL-UNNAMED access to native access (and all of the other restricted Java features which may be in use by parts of my webapp) that I'm missing? It just seems like a bad idea to me so I thought that maybe I'm missing something. (I know that this is how java always used to work, but it's clearly not the direction Java is moving in right now) Thanks! Best, Christian
Re: Clarify adoption of JPMS Java modules in webapps
Okay, thanks for the quick reply! On 9/23/25 12:13, Mark Thomas wrote: External Message - Please be cautious when opening links or attachments On 23/09/2025 10:49, Christian Ortlepp wrote: So my concrete questions are: 1. Am I correct in saying that there is no way to make the tomcat webapp classloader load (some of) my classes onto the module-path instead of the class-path? Yes. And if that is the case, is this a deliberate decision (or just not implemented yet) by tomcat or are there other, bigger reasons? The Servlet spec (and Jakarta EE more generally) defines the web application class loader behaviour in terms of class path, not modules. I'll add that I'm not seeing a great deal of interest in doing the work to change that. 2. Could I circumvent this by including my JPMS modules in the `java` command line which would otherwise only start the tomcat classes (As I understand I should be able to access them from the webapp if I enabled the delegate option in the loader, see https://tomcat.apache.org/ tomcat-10.1-doc/config/loader.html)? Maybe. It should work... Then I suppose I should be able to restrict native access to this module, but I'm wondering if that would break something else in tomcat/my webapp? A single web application would be fine. However, there are potential complications. The issues are: - You can no longer just deploy a WAR file or a directory. You need to update these other libraries too and none of the standard deployment tooling will do that for you. - If you have multiple web applications and they need different versions of the same library you can't support that. 3. Is there any other way except giving ALL-UNNAMED access to native access (and all of the other restricted Java features which may be in use by parts of my webapp) that I'm missing? It just seems like a bad idea to me so I thought that maybe I'm missing something. (I know that this is how java always used to work, but it's clearly not the direction Java is moving in right now) In Tomcat, no. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
