[External] : Re: provides and requires static ... runtime error

[Andrejus Chaliapinas]

 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.
Andrejus
    On Wednesday, April 26, 2023 at 08:21:25 AM GMT+1, Tim Feuerbach <webseiten.designer at googlemail.com> wrote:  
 
 > - 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)

One of the use cases is listed here:
https://openjdk.org/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs
- " Provide a means to create an executable modular “uber-JAR” that
contains more than one module, preserving module identities and
boundaries, so that an entire application can  shipped as a single
artifact."

This is a common way of deploying an application built with a
framework like Spring, however the question is if this is still
relevant today when the trend goes towards shipping containers instead
of jars, where you don't care about the granularity of files inside.
In the end, the proper way of deploying a modular Java web application
remains creating an application-specific image with jlink, which I'm
sure of can be added to a container image in a way that the base JDK
modules form a layer that is shared between multiple containers from
different applications.

My personal interest in multi-module jars would be enforcing
architectural boundaries in a modular monolith at compile time. I
could see using modules for different domains or even layers like
API/core/persistence, allowing fine grained control over what gets
exported to whom and which layers are allowed to require which
dependency. For example, the web API layer would have no business
importing JPA types. As a bonus you could also limit the attack
surface for reflection gadgets. Instead of opening everything to the
framework for deep reflection (which, as I've learned recently, is not
preventable by using package based opens due to being able to define a
class inside the target package at runtime), I could encapsulate
high-security areas further, without having to change my build
process.

Of course, this comes down more to tools like Maven making it (seem)
cumbersome to create multiple jars per dependency management unit,
which is a weak motivation to change the JDK.

-- Tim
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230426/e144465c/attachment.htm>