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.
Gili
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] http://openjdk.java.net/projects/jigsaw/spec/sotms/
> > [1] 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
> 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:
> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713397.html
>
>
> To unsubscribe from Multiple versions of a non-exported dependency,
> click here
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5713364&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTcxMzM2NHwxNTc0MzIxMjQ3>.
> NAML
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
--
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.
