Few questions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Few questions

Michał Zegan
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.
- 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?
How does it all work with serialization?
- 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?
- 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...
- 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.

Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Alan Bateman
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

Reply | Threaded
Open this post in threaded view
|

Re: 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Alan Bateman
On 25/11/2016 22:21, Michał Zegan wrote:

> Well, I specifically mean setAccessible usage between modules.
All I can suggest is to read the javadoc, the proposal for
#AwkwardStrongEncapsulation [1], and of course try out the EA builds [2].

> 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?
The module system has built-in support for services. See Alex's session
on "Modules and Services" from JavaOne 2016 [3] for more on that.


> 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)...
You can do this with dynamic configurations and the layer API. Alex's
"Project Jigsaw: Under the Hook" session from JavaOne 2016 is the
session to watch for more on that topic.

-Alan

[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
[2] https://jdk9.java.net/jigsaw/
[3] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016
Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Michał Zegan
well, about services, the problem is (probably) that services in jigsaw,
last I've checked, were purely static in nature.
That is they cannot dynamically appear and disappear and modules cannot
be notified about it, that wuld be a reason for a service container.

W dniu 26.11.2016 o 09:34, Alan Bateman pisze:

> On 25/11/2016 22:21, Michał Zegan wrote:
>
>> Well, I specifically mean setAccessible usage between modules.
> All I can suggest is to read the javadoc, the proposal for
> #AwkwardStrongEncapsulation [1], and of course try out the EA builds [2].
>
>> 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?
> The module system has built-in support for services. See Alex's session
> on "Modules and Services" from JavaOne 2016 [3] for more on that.
>
>
>> 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)...
> You can do this with dynamic configurations and the layer API. Alex's
> "Project Jigsaw: Under the Hook" session from JavaOne 2016 is the
> session to watch for more on that topic.
>
> -Alan
>
> [1]
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
>
> [2] https://jdk9.java.net/jigsaw/
> [3] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016

Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Jochen Theodorou
In reply to this post by Michał Zegan
On 25.11.2016 23:21, Michał Zegan wrote:
> Well, I specifically mean setAccessible usage between modules.

If your code really requires setAccessible it is going to break with
jigsaw. And there is no way to for example emulate that on java.base
without using command line arguments intended only for the transition to
"real" modules.

> Another question that comes to mind after reading some things: what
> about relation of jigsaw and osgi?

they are different beasts

> Is jigsaw going to replace osgi?

No

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

No. OSGI sits 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)...

multiple versions of the same module can be done... kinda... Just not at
compile-time. You will be required to handle all the layers and read
edges yourself. At compile-time jigsaw does not allow multiple versions
of the same module - not even two distinct modules that use the same
packages (I forgot if that was really only for the exported packages, or
if the non-exported count as well, or if them counting as well was/is a
bug).

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Michał Zegan
I know that osgi sits on top of jigsaw, but osgi was created when jigsaw
did not exist, so it is itself a module system for java that does not
need jigsaw.
So then it would probably look like a module system on top of another
module system... seems weird to me.
What should I do when I would like to write a new application that would
be modular? Use jigsaw directly or not?

W dniu 26.11.2016 o 12:41, Jochen Theodorou pisze:

> On 25.11.2016 23:21, Michał Zegan wrote:
>> Well, I specifically mean setAccessible usage between modules.
>
> If your code really requires setAccessible it is going to break with
> jigsaw. And there is no way to for example emulate that on java.base
> without using command line arguments intended only for the transition to
> "real" modules.
>
>> Another question that comes to mind after reading some things: what
>> about relation of jigsaw and osgi?
>
> they are different beasts
>
>> Is jigsaw going to replace osgi?
>
> No
>
>> 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?
>
> No. OSGI sits 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)...
>
> multiple versions of the same module can be done... kinda... Just not at
> compile-time. You will be required to handle all the layers and read
> edges yourself. At compile-time jigsaw does not allow multiple versions
> of the same module - not even two distinct modules that use the same
> packages (I forgot if that was really only for the exported packages, or
> if the non-exported count as well, or if them counting as well was/is a
> bug).
>
> bye Jochen

Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Alan Bateman
In reply to this post by Jochen Theodorou
On 26/11/2016 11:41, Jochen Theodorou wrote:

> On 25.11.2016 23:21, Michał Zegan wrote:
>> Well, I specifically mean setAccessible usage between modules.
>
> If your code really requires setAccessible it is going to break with
> jigsaw.
To be more specific, it will be a problem for code that attempts to use
setAccessible to break into JDK classes (aside from jdk.unsupported then
the JDK modules don't open any packages for deep reflection).


> multiple versions of the same module can be done... kinda... Just not
> at compile-time. You will be required to handle all the layers and
> read edges yourself. At compile-time jigsaw does not allow multiple
> versions of the same module - not even two distinct modules that use
> the same packages (I forgot if that was really only for the exported
> packages, or if the non-exported count as well, or if them counting as
> well was/is a bug).
The rule is that a module m can't read two or modules that export the
same package to m. If you are doing dynamic configuration and using the
layer APi then you usually don't need to do anything with "read edges".
Applications or libraries doing code generation or using method handles
may need to but they are advanced cases.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Alan Bateman
In reply to this post by Michał Zegan
On 26/11/2016 10:50, Michał Zegan wrote:

> well, about services, the problem is (probably) that services in jigsaw,
> last I've checked, were purely static in nature.
> That is they cannot dynamically appear and disappear and modules cannot
> be notified about it, that wuld be a reason for a service container.
Layers can be created and be GC'ed. If you look at jlink or javac then
you'll see that they create a layer to load service providers (jlink
plugins in the case of jlink). So a different model so what you might be
looking for. All I can suggest is to try things out to get familiar with
how it all works.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Jochen Theodorou
In reply to this post by Michał Zegan
On 26.11.2016 12:53, Michał Zegan wrote:
> I know that osgi sits on top of jigsaw, but osgi was created when jigsaw
> did not exist, so it is itself a module system for java that does not
> need jigsaw.
> So then it would probably look like a module system on top of another
> module system... seems weird to me.

That is because jigsaw does not try to be a replacement for OSGI. OSGI
for example does normally not do anything for you at compile time.
jigsaw on the other hand does not allow you using multiple versions.

> What should I do when I would like to write a new application that would
> be modular? Use jigsaw directly or not?

It depends then on your requirements

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Michał Zegan
well...

But jigsaw itself can become a foundation for such a higher level
framework build directly on top of jigsaw that adds such dynamic
capabilities?
       
W dniu 26.11.2016 o 18:18, Jochen Theodorou pisze:

> On 26.11.2016 12:53, Michał Zegan wrote:
>> I know that osgi sits on top of jigsaw, but osgi was created when jigsaw
>> did not exist, so it is itself a module system for java that does not
>> need jigsaw.
>> So then it would probably look like a module system on top of another
>> module system... seems weird to me.
>
> That is because jigsaw does not try to be a replacement for OSGI. OSGI
> for example does normally not do anything for you at compile time.
> jigsaw on the other hand does not allow you using multiple versions.
>
>> What should I do when I would like to write a new application that would
>> be modular? Use jigsaw directly or not?
>
> It depends then on your requirements
>
> bye Jochen

Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Jochen Theodorou
On 26.11.2016 18:29, Michał Zegan wrote:
> well...
>
> But jigsaw itself can become a foundation for such a higher level
> framework build directly on top of jigsaw that adds such dynamic
> capabilities?

if you want more than jigsaw offers out of the box, you have add runtime
capabilities and you can do so to some extend. Like making a new layer
and defining modules in their on your own, in which you then set the
read edges and such.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Few questions

Michał Zegan
as for multiple version, there seems to be an open issue for that, do
not remember the hashtag. But well, there seems to be only one month left.

W dniu 26.11.2016 o 18:53, Jochen Theodorou pisze:

> On 26.11.2016 18:29, Michał Zegan wrote:
>> well...
>>
>> But jigsaw itself can become a foundation for such a higher level
>> framework build directly on top of jigsaw that adds such dynamic
>> capabilities?
>
> if you want more than jigsaw offers out of the box, you have add runtime
> capabilities and you can do so to some extend. Like making a new layer
> and defining modules in their on your own, in which you then set the
> read edges and such.
>
> bye Jochen