Multiple versions of a non-exported dependency

cowwoc cowwoc at bbs.darktech.org
Thu Sep 1 14:28:56 UTC 2016 

> What Sun and now Oracle are continuing to do, is create more stuff 
> that is nothing like what everyone else is doing with modularity and 
> instead create something that is orthogonal to most peoples problem 
> spaces and in the end creates tremendously more “work” for nothing 
> more than compatibility with the new “JVM” environment.

A big +1. The cost/benefit of Jigsaw without version-awareness is very 
poor for end-users.

Our long-term goal should be to "import" the best ideas from existing 
module systems in the Java platform over time. No one is expecting you 
to do this from day one, but the fact that "requires" does not take a 
constant version number from day one prevents this kind of evolution 
from ever taking place.

On 2016-09-01 10:00 AM, Alan Bateman [via jigsaw-dev] wrote:
> So I think what we have ended up with sane and not difficult to explain.
> It favors migration and good interop over green field. Sure, there will
> be periodic complaints when people try to deploy modules with
> overlapping packages on the application module path. Anyone using Maven
> Shade Plugin and the like can continue to do this. Finally, it's not
> hard to create your own "launcher" that instantiates the configuration
> with Layer.defineModulesWithManyLoaders if you really want. 

It would help if you could publish a sample "launcher" to show people 
how easy it really is. This won't resolve my outstanding problem with 
the specification (lack of a version number in "requires") but at least 
then we can move the discussion to whether a (simple) concrete 
implementation is able to do what we want.

Gili

On 2016-09-01 9:24 AM, Gregg Wonderly [via jigsaw-dev] wrote:
> The important detail for me, is that ClassLoader per module, with the 
> current Class resolution scheme (this ClassLoader and whatever I can 
> find in the parent), provides a lot of issues. The “custom 
> ClassLoaders” or “containers like OSGi” remarks point at the “us and 
> them” attitude that is pretty prevalent in this conversation.  The 
> majority of developers are looking for a module system that is not an 
> “us or them” proposition.   These “all or nothing” compromises are 
> what create the “hell” that dominates conversations here.  What we all 
> want to be able to do, is write software once, target it to “THE Java 
> platform”, and be done.
>
> What Sun and now Oracle are continuing to do, is create more stuff 
> that is nothing like what everyone else is doing with modularity and 
> instead create something that is orthogonal to most peoples problem 
> spaces and in the end creates tremendously more “work” for nothing 
> more than compatibility with the new “JVM” environment.
>
> The real goal here needs to be making all of the other module and 
> container systems obsolete.  Those systems should “want” to provide 
> support for the awesome, new module system that will make in 
> unnecessary for them to roll their own details any longer.
>
> Yes, that is a long road and a tall measure for success.  But frankly, 
> even the lack of any visibility of the style of modules that Netbeans 
> has used for decades makes it clear that this groups view at Oracle is 
> extremely narrow and perhaps even more uninformed about what the 
> community actually needs.
>
> Gregg
>
> > On Sep 1, 2016, at 7:29 AM, David M. Lloyd <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5713387&i=0>> wrote:
> >
> > It seems like there is no good reason why the application modules 
> aren't loaded with classloader-per-module now.  The platform stuff 
> could all be in one, but the application stuff?  Problems like this 
> are going to come up a lot otherwise; let's consider making that change.
> >
> > On 08/31/2016 07:45 PM, Neil Bartlett wrote:
> >> Remi,
> >>
> >> Actually I don’t think that statically linking will work. This 
> would produce modules that have overlapping private (non-exported) 
> packages, and such modules also cannot be used in Java 9 on the 
> modulepath.
> >>
> >> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by 
> creating two modules both containing a private package 
> org.example.util. The following exception resulted: 
>  java.lang.reflect.LayerInstantiationException: Package 
> org.example.util in both module a and module b.
> >>
> >> Again this could be “solved” by using custom ClassLoaders or a 
> ClassLoader-based module system like OSGi on Java 9.
> >>
> >> Neil
> >>
> >>
> >>
> >>> On 31 Aug 2016, at 20:28, Remi Forax <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5713387&i=1>> wrote:
> >>>
> >>> The other solution is to statically link the right version of 
> slf4j inside guava and jsoup.
> >>> A tool like jarjar can be updated to merge two modular jars (merge 
> two module-info).
> >>>
> >>> cheers,
> >>> Rémi
> >>>
> >>> ----- Mail original -----
> >>>> De: "Neil Bartlett" <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5713387&i=2>>
> >>>> À: [hidden email] 
> </user/SendEmail.jtp?type=node&node=5713387&i=3>, "Alex Buckley" 
> <[hidden email] </user/SendEmail.jtp?type=node&node=5713387&i=4>>
> >>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5713387&i=5>>
> >>>> Envoyé: Mercredi 31 Août 2016 20:54:44
> >>>> Objet: Re: Multiple versions of a non-exported dependency
> >>>
> >>>> Gili,
> >>>>
> >>>> As Alex points out: your use-case can be supported in Java 9 but 
> only with the
> >>>> addition of custom ClassLoaders, or by using an existing 
> ClassLoader-based
> >>>> module system such as OSGi.
> >>>>
> >>>> The same is also true of Java 8, and Java 7, etc.
> >>>>
> >>>> Regards,
> >>>> Neil
> >>>>
> >>>>
> >>>>> On 31 Aug 2016, at 19:29, Alex Buckley <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5713387&i=6>> wrote:
> >>>>>
> >>>>> On 8/31/2016 10:56 AM, cowwoc wrote:
> >>>>>> I recently became aware of the fact that the Jigsaw 
> specification declared
> >>>>>> "version-selection" as a non-goal. While I understand how we 
> ended up here,
> >>>>>> I am hoping that you were able to support the following (very 
> common)
> >>>>>> use-case:
> >>>>>>
> >>>>>> * Module "HelloWorld" depends on modules "Guava" and "JSoup".
> >>>>>> * Module "Guava" depends on module slf4j version 1 (requires 
> but does not
> >>>>>> export it).
> >>>>>> * Module "JSoup" depends on module slf4j version 2 (requires 
> but does not
> >>>>>> export it).
> >>>>>> * slf4j version 2 and is not backwards-compatible with version 1.
> >>>>>>
> >>>>>> What happens at runtime? Will Jigsaw (out of the box, without 
> 3rd-party
> >>>>>> tools like Maven or OSGI) be smart enough to provide different 
> versions of
> >>>>>> slf4j to "Guava" and "JSoup"?
> >>>>>
> >>>>> (You mean Guava/JSoup requires slf4j version 1/2 and does not 
> "re-export" it
> >>>>> a.k.a. 'requires public'.)
> >>>>>
> >>>>> This use case isn't possible on JDK 8 for JARs on the classpath, 
> and it's not
> >>>>> supported on JDK 9 for modular JARs on the modulepath:
> >>>>>
> >>>>> - If you have two versions of a modular JAR slf4j.jar in 
> different directories
> >>>>> on the modulepath, then the first one to be found will dominate, 
> and that's
> >>>>> what will be resolved for both Guava and JSoup.
> >>>>>
> >>>>> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on 
> the modulepath,
> >>>>> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then 
> launching 'java
> >>>>> -m HelloWorld' will fail. The boot layer will refuse to map the 
> "same" packages
> >>>>> from different slf4j_v* modules to the application class loader.
> >>>>>
> >>>>> The use case _is_ supported on JDK 9 for modular JARs loaded 
> into custom loaders
> >>>>> of custom layers. That is, the Java Platform Module System is 
> perfectly capable
> >>>>> of supporting the use case -- please see any of my "Jigsaw: 
> Under The Hood"
> >>>>> presentations. The use case just isn't supported "out of the 
> box" by the 'java'
> >>>>> launcher for JARs on the modulepath.
> >>>>>
> >>>>> Alex
> >>
> >
> > --
> > - DML
>
>
>
> ------------------------------------------------------------------------
> 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-tp5713364p5713387.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-tp5713364p5713390.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.

More information about the jigsaw-dev mailing list