Dynamic modules and bidirectional interoperation
Thomas Watson
tjwatson at us.ibm.com
Mon Oct 24 19:40:06 UTC 2016
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.
> >
More information about the jpms-spec-observers
mailing list