On 2018-04-13T12:11:41 +0100 Neil Bartlett <njbartl...@gmail.com> wrote: > > 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.
I'm not sure if we're talking about the same thing. It also seems a little strange to hear that: For me one of the main attractions about OSGi is that I get to state what's visible to the outside world and what isn't. This gives me the freedom to change things without breaking consumers. For the sake of the discussion, we could assume that bundles in the new magic OSGi container are all open for reflective access (but that the non-exported parts are still inaccessible, as with JPMS modules). Mainly what I'm referring to is that I'd want the VM to believe that any assumptions that it can make about a JPMS module, for optimization purposes, it could also make those same assumptions about a bundle in our container. The same goes for assumptions that javac can make (but this is less interesting because it's easy to make something that's both an OSGi bundle and a JPMS module at compile time). There was a recent thread on the amber-experts list, for example, that talked about modifying the exhaustiveness check for switches over enum values based on whether the enum type is the same module as the switch or not. I got the feeling that this idea was rejected, but the point is that there's this looming possibility that language features will depend on module boundaries sooner or later, and so we should probably want to allow OSGi bundles to be treated as equals to JPMS modules, and for the VM and JIT to see them as the same thing. > > > > 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... Yes, agreed. I phrased it poorly. My point was more that you depend on something that is almost certainly provided by a bundle (perhaps via the system bundle exporting packages from a JPMS module). For the sake of limiting the scope a bit, I introduced the notion that "bundles depend on bundles" so that people wouldn't think I was talking about bundles being able to depend on arbitrary JPMS modules outside of the container without anything special being done by the container to make this work. > > 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. Would you intend this to be a fundamental primitive such that the JPMS would be reimplemented in terms of this callback? How and where would one implement this callback? If I have multiple OSGi containers in the same JVM, along with modules in a separate JPMS system... How many implementations of it are there, and which one "wins" (if any)? -- Mark Raynsford | http://www.io7m.com
pgp48Bm37GVvV.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
