Multiple versions of a non-exported dependency

cowwoc cowwoc at
Thu Sep 1 20:04:13 UTC 2016

Another possibility (not saying it's better, just putting it out there) 
is to do the following:

 1. Provide a tool like "javah" that would generate for
    non-modularized JAR files.
 2. Provide a mechanism to "glue" the generated module-info files to the
    original non-modularized JAR files without modification (as if the
    files were inside the JAR file, but they aren't).
 3. Developers could use the generated templates as-is or customize them
    further after generation.

This way everything would be a real module and you'd get extra 
customization that is currently not available with automatic modules. 
This process moves the "glue" from runtime to package-time.


On 2016-09-01 3:34 PM, Richard Opalka [via jigsaw-dev] wrote:
> On 09/01/2016 06:58 PM, Alan Bateman wrote:
> > On 01/09/2016 17:34, Richard Opalka wrote:
> > Further I can't see the real benefit of automatic modules (they read
> > UNNAMED module(s) and all other explicit modules).
> >> I am aware of two real world usecases it might solve:
> >>  1) to workaround licensing issues of dead java projects (where
> >> consumers are disallowed to change them in any way)
> >>  2) automatic module placed on --upgrade-module-path (to allow smooth
> >> migration for EE APIs without need to define module-info.class for 
> them)
> > Automatic modules facilitate top-level migration, you can migrate to
> > modules without waiting for everything that you transitively depend to
> > migrate. They also allow bridging to the class path - say where you
> > move just your direct dependences while leaving the rest on the class
> > path. The topic is covered in the STOMS [1] and also in the Advanced
> > Modularity talks at JavaOne and Devoxx last year [2].
> >
> > -Alan
> >
> > [1]
> > [1]
> Yes, I'm familiar and aware of these. What I meant is:
> Is the benefit of incremental migration (automatic modules provide) that
> valuable?
> What's bad with "modularize all or nothing" kind of migration?
> There would be no need for bridges to the classpath if automatic modules
> would disappear.
> Richard
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> To unsubscribe from Multiple versions of a non-exported dependency, 
> click here 
> <>.
> <> 

View this message in context:
Sent from the jigsaw-dev mailing list archive at

More information about the jigsaw-dev mailing list