Multiple versions of a non-exported dependency
cowwoc at bbs.darktech.org
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 module-info.java 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
> > 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  and also in the Advanced
> > Modularity talks at JavaOne and Devoxx last year .
> > -Alan
> >  http://openjdk.java.net/projects/jigsaw/spec/sotms/
> >  http://openjdk.java.net/projects/jigsaw/talks/
> Yes, I'm familiar and aware of these. What I meant is:
> Is the benefit of incremental migration (automatic modules provide) that
> 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.
> 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: http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713398.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.
More information about the jigsaw-dev