Dynamic modules and bidirectional interoperation

[Thomas Watson]

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.
> >