<html><head></head><body><div class="ydpfe13df82yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
        <div dir="ltr" data-setdir="false">Would it be more appropriate in case of "uber-JAR" to introduce then "module feature" concept, i.e. the one which would allow grouping (and then enforcing of their needed presence within final "uber-JAR") of modules? That "module feature" then could have it's own handling mechanism and semantics and will not clash with separate module granularity/boundaries.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Andrejus</div><div><br></div>
        
        </div><div id="yahoo_quoted_3016120636" class="yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Wednesday, April 26, 2023 at 08:21:25 AM GMT+1, Tim Feuerbach <webseiten.designer@googlemail.com> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir="ltr">> - For my own personal interest, what are the other motivations for supporting multiple modules in a single jar? (If these other motivations are high that improves our chances of seeing this solution happen)<br></div><div dir="ltr"><br></div><div dir="ltr">One of the use cases is listed here:<br></div><div dir="ltr"><a href="https://openjdk.org/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs" target="_blank">https://openjdk.org/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs</a><br></div><div dir="ltr">- " Provide a means to create an executable modular “uber-JAR” that<br></div><div dir="ltr">contains more than one module, preserving module identities and<br></div><div dir="ltr">boundaries, so that an entire application can  shipped as a single<br></div><div dir="ltr">artifact."<br></div><div dir="ltr"><br></div><div dir="ltr">This is a common way of deploying an application built with a<br></div><div dir="ltr">framework like Spring, however the question is if this is still<br></div><div dir="ltr">relevant today when the trend goes towards shipping containers instead<br></div><div dir="ltr">of jars, where you don't care about the granularity of files inside.<br></div><div dir="ltr">In the end, the proper way of deploying a modular Java web application<br></div><div dir="ltr">remains creating an application-specific image with jlink, which I'm<br></div><div dir="ltr">sure of can be added to a container image in a way that the base JDK<br></div><div dir="ltr">modules form a layer that is shared between multiple containers from<br></div><div dir="ltr">different applications.<br></div><div dir="ltr"><br></div><div dir="ltr">My personal interest in multi-module jars would be enforcing<br></div><div dir="ltr">architectural boundaries in a modular monolith at compile time. I<br></div><div dir="ltr">could see using modules for different domains or even layers like<br></div><div dir="ltr">API/core/persistence, allowing fine grained control over what gets<br></div><div dir="ltr">exported to whom and which layers are allowed to require which<br></div><div dir="ltr">dependency. For example, the web API layer would have no business<br></div><div dir="ltr">importing JPA types. As a bonus you could also limit the attack<br></div><div dir="ltr">surface for reflection gadgets. Instead of opening everything to the<br></div><div dir="ltr">framework for deep reflection (which, as I've learned recently, is not<br></div><div dir="ltr">preventable by using package based opens due to being able to define a<br></div><div dir="ltr">class inside the target package at runtime), I could encapsulate<br></div><div dir="ltr">high-security areas further, without having to change my build<br></div><div dir="ltr">process.<br></div><div dir="ltr"><br></div><div dir="ltr">Of course, this comes down more to tools like Maven making it (seem)<br></div><div dir="ltr">cumbersome to create multiple jars per dependency management unit,<br></div><div dir="ltr">which is a weak motivation to change the JDK.<br></div><div dir="ltr"><br></div><div dir="ltr">-- Tim<br></div></div>
            </div>
        </div></body></html>