Dynamic modules and bidirectional interoperation

[forax at univ-mlv.fr]

Hi Thomas, 
first, sorry, 
I'm not able to parse my own mail correctly. 

Let's try again, 
currently a way to solve your issue is to allow a Layer to have several parents, 
i really dislike this idea because it introduces an arbitrary order that is hidden deep in the code thus makes really hard to reason about which Layer resolve what, 
for me it's not different to add a kind of classpath resolution in the middle of the module resolution. 

Currently, you control the classloaders, so you can load a hand crafted class in the module (you just have to patch the class name to have the right package, you can use the patching capabilities of defineAnonymousClass for that, but you can also call defineClass on the right classloader as again, you control the classloaders). 
Once you are able to execute arbitrary code in a module you can call addReads, addExports (and soon addOpens) on the j.l.r.Module. 

regards, 
Rémi 

> De: "Thomas Watson" <tjwatson at us.ibm.com>
> À: forax at univ-mlv.fr, "mark reinhold" <mark.reinhold at oracle.com>,
> "jpms-spec-observers" <jpms-spec-observers at openjdk.java.net>
> Envoyé: Lundi 24 Octobre 2016 21:40:06
> Objet: Re: Dynamic modules and bidirectional interoperation

> Can you explain more about how monkey patching would be done in a JVM
> implementation neutral way? If I understand correctly your suggestion would
> require monkey patching in order to add functionality to the module classes
> provided by the boot layer (Module, Layer, Configuration etc.). This additional
> functionality would allow an OSGi Framework implementation to represent the
> dynamic set of bundle wirings in an OSGi Framework as JPMS modules.

> In order to do that it seems we would need extensive knowledge of the internal
> implementation details of the classes we are monkey patching in order to modify
> their internal structures. I can see how using Unsafe would give us the power
> to hack into the implementation details of jigsaw, but I don't view that as a
> satisfactory solution to the problem. It would bind us to a particular internal
> implementation of Java 9 in order to work correctly. It places a new dependency
> on Unsafe class which is from the jdk.unsupported module. I don't think new
> dependencies on the jdk.unsupported module should be advocated. Doing so has a
> high probability of breaking on a future version of Java if Unsafe is removed
> by default or the implementation details of the module classes change.

> Tom

> "jpms-spec-observers" <jpms-spec-observers-bounces at openjdk.java.net> wrote on
> 10/21/2016 08:24:38 AM:

> > From: Remi Forax <forax at univ-mlv.fr>
> > To: mark reinhold <mark.reinhold at oracle.com>
> > Cc: jpms-spec-experts at openjdk.java.net
> > Date: 10/21/2016 08:25 AM
> > Subject: Re: Dynamic modules and bidirectional interoperation
> > Sent by: "jpms-spec-observers" <jpms-spec-observers-bounces at openjdk.java.net>

> > Hi Mark,
> > I see an other way to solve the wiring issue,
> > use VM anonymous classes (via unsafe.defineAnonymousClass) to
> > generate the glue code (as lambda meta factory does to implement the
> > functional interface at runtime) and method handles as wires (once
> > created a method handle do not do any security check anymore, so the
> > requirement to be in a module with specific parents can be lifted).
> > With that, you don't need to generate the wiring code inside a new
> > module and when a new bundle need to be re-wire, you can mutate the
> > wire (the method handle) by using a mutable callsite.

> > Said differently, loading/unloading an OSGI bundle is equivalent to
> > doing monkey patching in a dynamic language, so there is no reason
> > to not use the tools we provide for dynamic languages to wire OSGI bundles.

> > so i vote strongly against that proposal mostly because it's too
> > late to change requirements and because some obvious design options
> > to implement OSGI on top of JPMS have not been tested.

> > regards,
> > Rémi

> > ----- Mail original -----
> > > De: "mark reinhold" <mark.reinhold at oracle.com>
> > > À: jpms-spec-experts at openjdk.java.net
> > > Envoyé: Jeudi 6 Octobre 2016 19:07:59
> > > Objet: Dynamic modules and bidirectional interoperation

> > > The agreed requirements for this JSR mandate a modest degree of dynamic
> > > configuration [1]. They do not mandate _dynamic modules_, i.e., the
> > > fine-grained dynamic configuration or "hot deployment" that is possible
> > > with other module systems, such as OSGi and JBoss, in which individual
> > > modules can be installed, updated, and uninstalled at any time.

> > > The requirements also mandate that it "be possible for another module
> > > system, such as OSGi, to locate Java modules and resolve them using its
> > > own resolver, except possibly for core system modules" [2]. They do not
> > > mandate _bidirectional interoperation_, which in the case of OSGi would
> > > be the ability to arrange for bundles to refer to JPMS modules and also
> > > vice versa, i.e., for JPMS modules to refer to bundles.