On 28/07/2016 1:52 AM, Stephen Colebourne wrote:
On 27 July 2016 at 16:26, Remi Forax <fo...@univ-mlv.fr> wrote:
to get back to our issue,
there are 4 possibilities when exporting a package, for a public type,
(1) don't see it at compile time, don't see it at runtime (can't reflect on it)
(2) don't see it at compile time, see it at runtime (this is the OSGI/JBoss
model for not exported)
(3) see it at compile time, may not exist at runtime (so be prepared to get an
exception then)
(4) see it at compile time and see it at runtime
Agreed
The default can not be (3) because it's a corner case,
Agreed
it can not be (4) because in that case we lost the 'strong encapsulation' that
a module should provide by default,
That is what this thread discusses. It seems to me that the "strong
encapsulation" goal is met providing that a package can be hidden if
desired, and that the set of packages a module exports is still known
and limited (just automated by the compiler). Option (4) also
mitigates the issue that David Holmes has repeatedly indicated, where
jigsaw is currently planning on changing the meaning of "public".
I think you meant David Lloyd.
I have no issue with modules defining a new accessibility boundary.
Seems perfectly natural to me, and something that has been postulated
since the original superpackages proposal - JSR-294. I find it
incomprehensible to be "this close" to the end and find people arguing
for a reversal of the basic premises.
Cheers,
David Holmes
------------
The key point is that because modules are being added to Java late,
the only appropriate design is for them to be easily opt-in. While the
module system goes a fair way towards that goal, it would be further
aided by specifying packages to hide, rather than packages to export.
I agree with the rest of the mail, notably that unless we get this
right, there will be very little incentive to use the module system in
open source or applications.
Stephen
so the default can be either (1), either (2) or to force the user to choose
between (1) and (2) when declaring a module.
The problem with (1) is that:
- it makes most of the code that use reflection not working (and as Stephen
said, at lot of codes use reflection (or bytecode generation)),
- it will slow down the adoption of jigsaw (not jdk9 which will be run with a
-classpth) but the modularization of the already existing jars, so we will end
up with a module system which will be not used or worst, some jars will be
modularized, some will not and we will be in the same sad state of Python now
with 2 mostly compatible worlds *.
The problem of letting users to choose is that the hope to educate them by
forcing them to make their own choices will be destroyed because in practice
IDEs will chose for them (e.printStackTrace() anyone ?)
So the only valid choice seem to be (2), which
- still enable JDK and application server implementation modules to not export
some types at runtime, so the security will improve and by example, it will
avoid most of the access control bugs Christina talk about.
- the default behavior will make the move to convert their jars to modularized
jars easier because people will not conflate the problem of the modularization
itself with the problem of the access control at runtime.
- everybody will be happy and we will not see angry ponies on slides about Java
9.
cheers,
dalibor topic
cheers,
Rémi
* Or, at some point, someone will also find that by using jlink and creating
its own module Layer, he can have a 'Java' launcher with its own defaults.
