On Fri, Apr 13, 2018 at 11:45 AM, Mark Raynsford <list+org.o...@io7m.com>
wrote:
> On 2018-04-13T09:32:30 +0100
> Neil Bartlett <njbartl...@gmail.com> wrote:
> >
> > Interop already works just fine in one direction: OSGi bundles depending
> on
> > JPMS modules...
>
> Please indulge me in a bit of brain storming...
>
> Let's assume hypothetically that the goal now is to produce an OSGi
> container that can use (possibly nonexistent) APIs in the JPMS to get
> the same degree of VM-enforced separation between OSGi bundles as JPMS
> modules get between each other (I'm aware that OSGi bundles get cleaner
> separation today than JPMS modules in some regards). Let's assume that
> we want to do this simply because we don't want to be left out in the
> cold when it comes to future language and VM features that might be
> module-dependent.
>
To be clear, I'm not convinced OSGi would ever want to do this. If we did,
we would likely invert the default from "closed" to "open". Closing off a
bundle to ALL access, even reflectively, seems like an extreme measure that
would only be necessary in fairly unusual circumstances, so I believe that
JPMS has the default the wrong way around. It's useful to compare with Java
classes, which can be made final but are not final by default.
>
> Let's assume that, for the perspective of someone using this magic new
> OSGi container, the goal is to have it behave pretty much like an OSGi
> container already behaves (modulo the R7 java.* changes): An OSGi
> bundle can only depend on OSGi bundles,
Note quite true. OSGi bundles depend on capabilities, the most important of
which are Java packages. The Framework arranges to wire my Import-Package
to a suitable provider and creates a ClassLoader that delegates across the
wire, but my bundle shouldn't care what kind of thing it is wired to. It
would be quite simple to represent JPMS modules in OSGi as a kind of
virtual bundle (at least, modules that don't export in the java.*
namespace).
> and if you want to be able to
> talk to external system JPMS modules, you have to do it via the
> system/framework bundle. Let's also assume that we're not interested in
> having JPMS modules outside of the OSGi container be capable of
> depending on OSGi bundles running inside the container. This is similar
> to the situation today; it's not too easy (or desirable) to have things
> on the classpath depend on things running inside the OSGi container.
>
> Let's also assume that the magic new OSGi container needs the same
> capabilities that existing OSGi containers already have: Module
> loading/unloading, multiple bundle versions without conflicts, etc, etc.
>
Yup.
>
> I'm not sure, for the sake of discussion, whether or not the OSGi
> bundles in question happen to contain JPMS metadata already (such that
> if you took the OSGi bundle and put it on the module path, it'd behave
> correctly as a JPMS module).
>
> This magic new OSGi container would be much like the JPMS analogue of
> the existing classpath-based OSGi world: You have the classpath, and
> you have the OSGi container, and dependencies from one to the other
> have to occur through well-defined portals (the system/framework
> bundle).
>
> What additions to the JPMS APIs would be needed to make this a reality
> today?
>
I think the starting point is as simple as a callback interface along these
lines:
void checkAccess(Class from, Class to) throws IllegalAccessException;
The JVM would call this each time it needs to check whether "from" is
allowed to access "to". It would be able to cache the answer because when
an OSGi bundle is updated we get a new ClassLoader and a new Class
identity. The JVM would also have some built-in checks before invoking this
method, to allow it to lock out the application layer from JVM internals.
The above should work at runtime for both OSGi and JPMS. To implement
compile-time checks you need something else to stand in for the identities
or locations of the two input types.
>
> --
> Mark Raynsford | http://www.io7m.com
>
>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
