Few questions

[Michał Zegan]

Well, I specifically mean setAccessible usage between modules.

Another question that comes to mind after reading some things: what
about relation of jigsaw and osgi? Is jigsaw going to replace osgi?
Well, what I exactly mean is, I know you try to make jigsaw and osgi
work together. I just mean, is jigsaw module system going to work in
such a way that you would be able to use it for modularizing
applications without osgi, assuming that either the app does not use
dynamic services, or it does, but there would be a service manager built
on top of jigsaw?
Specifically, what about multiple versions of the same module per jvm
and multiple packages with the same name per jvm (either private, or
exported non transitively)...

W dniu 25.11.2016 o 23:05, Alan Bateman pisze:
> On 25/11/2016 19:33, Michał Zegan wrote:
> 
>> Hello.
>>
>> I have a few questions about project jigsaw and things that are related.
>>
>> - Does, or will, the jlink tool allow creating executables? I mean,
>> packing app with the runtime not in a directory, but in an executable
>> file of some sort? Or, will it be extendable in such a direction? Some
>> people would like something similar, although such an exe would be
>> really big.
> jlink creates a run-time image so it's not a single .exe file. The
> details on the run-time image layout are in JEP 220 but might be easier
> to just try it out to see how it works. There are lots of opportunities
> to do static linking and other things but they beyond the current scope
> of JEP 282 and JEP 275.
> 
> 
>> - Is it possible to, in any way, circumvent module access control?
>> Reflection works to see, currently, all classes and interfaces, all
>> methods/fields/constructors of theirs whether private, protected or
>> whatever, and may be used to circumvent all such access restrictions.
>> What about deliberate circumventing of access from one module to
>> another, when an accessed class would be from a package that is not
>> exported?
> All places that do access checks have been updated to work with modules.
> In the case of core reflection then you can discover private fields and
> methods that aren't accessible so it's not really any different to how
> core reflection has always worked (ignoring setAccessible).
> 
>> How does it all work with serialization?
> Java serialization works exactly as before, no changes. Custom
> serialization on the other hand is a challenge. There are specialized
> APIs in the jdk.unsupported module to allow custom serialization
> libraries to work with modules, even if the serial form includes fields
> of types in non-exported/non-open packages.
> 
> 
>> - And, what about module unloading?
>>  From what I know, classes are never unloaded, unless they have no active
>> references to any of their objects and class object/etc, and unless
>> their class loader is collectable, that requires all other classes not
>> to be referenced/etc. How does this extend to modules? When modules are
>> unloaded?
> The granularity of unloading is the module layer, not individual
> modules. To be GC'ed then a strongly reachable object can't reference
> something in the module.
> 
> 
>> - How to dynamically load modules? Does it require a new layer to be
>> created? Can you base a layer you create directly on the empty layer?
>> for example to run an app in a different environment, isolated from most
>> of the modules of another app...
> Every module reads java.base which is in the boot layer so minimally you
> will have the boot layer as the parent rather than the empty layer.
> 
>> - Probably the last question: are security providers per module/layer,
>> or per java virtual machine? Sometimes it at least seems useful for
>> two... javaee apps to have two versions of bouncycastle jcajce provider
>> running without conflict.
> The security provider mechanism was updated some time ago to use
> ServiceLoader and so works with modules. I believe it will only
> automatically locate service provider on the module path or class path.
> When doing dynamic configuration (and use the resolveRequiresAndUses)
> then security providers will be resolved but I don't think will be used
> by the security APIs by default. This is really a topic for the
> security-dev list.
> 
> -Alan
>