Discussion:
Exporting - the wrong default?
(too old to reply)
Stephen Colebourne
2016-07-26 10:30:03 UTC
Permalink
Over recent weeks, there has been a long debate about exporting at
runtime, with other discussions about resources. I want to express my
view that listing specific packages for export seems to be the wrong
approach.

In my last thread [1], I found that just 2.5% of packages in the open
source libraries I looked at were suitable for being non-exported. In
the Strata library, designed for modules, the number rose to 11.7%.

As such, shouldn't we consider that the default for modules should be
changed? Instead of specifying the list of packages that are to be
exported, the module system should specify the list of packages that
are to be restricted:

module com.foo.bar {
requires org.baz.qux;

restricts com.foo.bar.alpha; // package is not exported
restricts com.foo.bar.beta to com.foo.baz; // export only to a friend
restricts at compiletime com.foo.bar.beta; // export "dynamic"
}

This does not appear to change the underlying model of modules
(reliable configuration and strong encapsulation), but would make it
much more practical to use. After all, isn't Java meant to be designed
for the 80% use case? (which is clearly that everything is exported in
most projects)

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008823.html
dalibor topic
2016-07-26 10:48:27 UTC
Permalink
Post by Stephen Colebourne
This does not appear to change the underlying model of modules
(reliable configuration and strong encapsulation), but would make it
much more practical to use.
It wouldn't be as robust in face of change, as it would require
consciously tracking new packages being added to a module and explicitly
marking them as internal, or living with design mistakes (or other
problems) because someone forgot to immediately restrict access to
something that was supposed to be internal.

For a much longer explanation, see "Fail-safe defaults" in
https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Stephen Colebourne
2016-07-26 16:42:47 UTC
Permalink
The purpose of this change is meant to be to enhance Java. While
security may be part of the issue being tackled, it has never been
claimed as the main one. This proposal does not make it much of an
issue either, as the runtime would likely still have a list of
exported packages - it would be the declaration format
(module-info.java) that would change. (javac has a closed set of
packages when compiling a module, so outputting exports in the binary
but using restricts in module-info works just fine)

I think a key problem is that those working on the JDK have a warped
sense of what a typical Java project is like. In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*. The current default to force developers to list all
exports is simply going to slow developers down for no perceived
benefit. (In fact with Java EE and OSGi excluded from modules, they
really don't seem all that useful anyway).

The "robust in the face of change" argument is dubious too. If you
want package exports to be robust in the face of change, the
export/restruction criteria should be in packag-info.java, not
module-info.java, where it would automatically be handled by all
existing tooling for renaming packages.

If the default does not change, then I assume the tools will
effectively work around it. ie. that Maven will have an option to
export all packages not explicitly hidden. Anything else would be far
too annoying for development.

Stephen
PS, I would accept a design where developers could choose to use
exports or restricts (but not both) in module-info.java.
Post by Stephen Colebourne
This does not appear to change the underlying model of modules
(reliable configuration and strong encapsulation), but would make it
much more practical to use.
It wouldn't be as robust in face of change, as it would require consciously
tracking new packages being added to a module and explicitly marking them as
internal, or living with design mistakes (or other problems) because someone
forgot to immediately restrict access to something that was supposed to be
internal.
For a much longer explanation, see "Fail-safe defaults" in
https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Remi Forax
2016-07-26 21:36:42 UTC
Permalink
----- Mail original -----
Envoyé: Mardi 26 Juillet 2016 18:42:47
Objet: Re: Exporting - the wrong default?
The purpose of this change is meant to be to enhance Java. While
security may be part of the issue being tackled, it has never been
claimed as the main one. This proposal does not make it much of an
issue either, as the runtime would likely still have a list of
exported packages - it would be the declaration format
(module-info.java) that would change. (javac has a closed set of
packages when compiling a module, so outputting exports in the binary
but using restricts in module-info works just fine)
it's better if module-info.java and module-info.class are aligned
I think a key problem is that those working on the JDK have a warped
sense of what a typical Java project is like. In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*. The current default to force developers to list all
exports is simply going to slow developers down for no perceived
benefit. (In fact with Java EE and OSGi excluded from modules, they
really don't seem all that useful anyway).
I've sympathy with that idea but i think it's because non-exported package by default means that types are not available at runtime.
non-exported package should have their types visible by reflection at runtime unless the package is declared restricted.
The "robust in the face of change" argument is dubious too. If you
want package exports to be robust in the face of change, the
export/restruction criteria should be in packag-info.java, not
module-info.java, where it would automatically be handled by all
existing tooling for renaming packages.
if you rename a package using ASM 6 (currently in alpha version),
it will also rename the package name in the module-info.class.

i fail to see the issue here, obviously apart from the fact that the tools need to be updated.
If the default does not change, then I assume the tools will
effectively work around it. ie. that Maven will have an option to
export all packages not explicitly hidden. Anything else would be far
too annoying for development.
Stephen
PS, I would accept a design where developers could choose to use
exports or restricts (but not both) in module-info.java.
Rémi
Post by Stephen Colebourne
This does not appear to change the underlying model of modules
(reliable configuration and strong encapsulation), but would make it
much more practical to use.
It wouldn't be as robust in face of change, as it would require consciously
tracking new packages being added to a module and explicitly marking them as
internal, or living with design mistakes (or other problems) because someone
forgot to immediately restrict access to something that was supposed to be
internal.
For a much longer explanation, see "Fail-safe defaults" in
https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
dalibor topic
2016-07-27 12:39:05 UTC
Permalink
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at

for some less anecdotal thoughts on the business value of slightly more
secure software.

It even touches briefly on the utility of modules in JDK 9.

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Remi Forax
2016-07-27 15:26:09 UTC
Permalink
----- Mail original -----
Envoyé: Mercredi 27 Juillet 2016 14:39:05
Objet: Re: Exporting - the wrong default?
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at http://youtu.be/-fC975HLhyc
for some less anecdotal thoughts on the business value of slightly more
secure software.
It even touches briefly on the utility of modules in JDK 9.
Interesting talk !

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

The default can not be (3) because it's a corner case, it can not be (4) because in that case we lost the 'strong encapsulation' that a module should provide by default, 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.
Stephen Colebourne
2016-07-27 15:52:03 UTC
Permalink
Post by Remi Forax
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
Post by Remi Forax
The default can not be (3) because it's a corner case,
Agreed
Post by Remi Forax
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".

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
Post by Remi Forax
so the default can be either (1), either (2) or to force the user to choose between (1) and (2) when declaring a module.
- 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.
Post by dalibor topic
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.
David Holmes
2016-07-28 03:15:05 UTC
Permalink
Post by Stephen Colebourne
Post by Remi Forax
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
Post by Remi Forax
The default can not be (3) because it's a corner case,
Agreed
Post by Remi Forax
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
------------
Post by Stephen Colebourne
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
Post by Remi Forax
so the default can be either (1), either (2) or to force the user to choose between (1) and (2) when declaring a module.
- 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.
Post by dalibor topic
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.
Stephen Colebourne
2016-07-28 07:33:09 UTC
Permalink
Post by David Holmes
I think you meant David Lloyd.
Yeah, sorry!
Post by David Holmes
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.
Adding a new accessibility boundary seems reasonable. How that is done
is open to question - in this thread I am primarily focussed on the
syntax used to express the rules (exports) not the premise of them. By
changing the default, it means that for most users their access
control and reflection will not change and thus module-info can be
added with little impact.
Post by David Holmes
I find it incomprehensible to be
"this close" to the end and find people arguing for a reversal of the basic
premises.
In my view, only recently has there been any kind of meaningful
discussion on the issues, and that has been at a point where it is
allegedly too late to change them. To me, it feels like there is a
long way to go before this should be released.

Stephen
Jason Greene
2016-07-28 20:09:07 UTC
Permalink
Post by David Holmes
Post by Stephen Colebourne
Post by Remi Forax
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
Post by Remi Forax
The default can not be (3) because it's a corner case,
Agreed
Post by Remi Forax
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.
I don’t think its all that surprising given that there is a number of open design impacting issues at the moment (some of them brought up long ago). I have been heartened by recent dialogue with proposals on some of the issues. I hope it continues, and there is a priority to get things right, as opposed to being eternally stuck with something that doesn’t meet existing use cases.

-Jason
Paul Benedict
2016-07-28 20:42:41 UTC
Permalink
I think what Jigsaw has done (to modularize the JDK) is well-achieved and a
round of kudos should go out to Mark, Alan, Alex, and the rest of the
Oracle crowd for spending years on this herculean effort. With that said,
there are many more wrinkles to iron out for everyone else. I believe the
active collaboration, agreements, and disagreements show that being "this
close to the end" is much brighter for the JDK itself than for the rest of
the world. Does anyone else see this divide? What's good for the JDK itself
is sometimes not good for the rest and vice-versa. The contention over
reflection I believe is a pinnacle example, but there are so many more too.
Issues will continue being brought up as such bleeding-edge experts and
hobbyists toy with with these new features.

You can take Stephen's opinion on what reflection has meant to Java
seriously or not, but I think he's right. Reflection has always been a huge
cornerstone of Java's success. Developers can escape the social constructs
laid down in the Java language and go directly into messing with objects,
fields, and methods. Everyone enjoys that freedom. The other huge
cornerstone of Java's success is the near-infinite backward compatibility
that has been provided. Things deprecated for 20 years continue to exist.
Putting both of those concerns together, I cannot escape coming to the same
conclusions as Stephen. I understand "me too" opinions are not in
themselves convincing, but hopefully something I have mentioned is. Please
do not change how reflection operates with regard to package exports.

Cheers,
Paul
Post by Remi Forax
Post by David Holmes
Post by Stephen Colebourne
Post by Remi Forax
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)
Post by David Holmes
Post by Stephen Colebourne
Post by Remi Forax
(2) don't see it at compile time, see it at runtime (this is the
OSGI/JBoss model for not exported)
Post by David Holmes
Post by Stephen Colebourne
Post by Remi Forax
(3) see it at compile time, may not exist at runtime (so be prepared
to get an exception then)
Post by David Holmes
Post by Stephen Colebourne
Post by Remi Forax
(4) see it at compile time and see it at runtime
Agreed
Post by Remi Forax
The default can not be (3) because it's a corner case,
Agreed
Post by Remi Forax
it can not be (4) because in that case we lost the 'strong
encapsulation' that a module should provide by default,
Post by David Holmes
Post by Stephen Colebourne
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.
I don’t think its all that surprising given that there is a number of open
design impacting issues at the moment (some of them brought up long ago). I
have been heartened by recent dialogue with proposals on some of the
issues. I hope it continues, and there is a priority to get things right,
as opposed to being eternally stuck with something that doesn’t meet
existing use cases.
-Jason
David M. Lloyd
2016-07-27 16:13:38 UTC
Permalink
Post by Remi Forax
----- Mail original -----
Envoyé: Mercredi 27 Juillet 2016 14:39:05
Objet: Re: Exporting - the wrong default?
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at http://youtu.be/-fC975HLhyc
for some less anecdotal thoughts on the business value of slightly more
secure software.
It even touches briefly on the utility of modules in JDK 9.
Interesting talk !
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
The default can not be (3) because it's a corner case, it can not be (4) because in that case we lost the 'strong encapsulation' that a module should provide by default, so the default can be either (1), either (2) or to force the user to choose between (1) and (2) when declaring a module.
- 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.
This is all rearranging deck chairs. The critical problem here, lest we
forget, is that none of these solutions allow reflection to work on
modules without an export, even for public types, thus breaking
*everything* eventually. Any valid choice IMO must allow public types
to remain public and thus globally accessible.

Since everyone seems to concede that the migration to any more secure
form for users must be incremental, there is nothing left to be gained
by the existing Jigsaw public access restriction. After all, even if
public is left as public, it is still possible meet any reasonable
standard of encapsulation. That aforementioned incremental migration
could be for users and JDK developers to change public classes to be
non-public; the mechanism which currently allows for exporting packages
to modules is conceptually *very* close to a mechanism to share the
non-public classes in packages with modules.

In other words, users should be able to export packages with a module
target or a wildcard (which allows compile-time and run-time linkage to
connect to those packages), and also specify whether each (non-wildcard)
export should include access to private types (which allows that linkage
to connect types to those non-public members).

In addition to my aforementioned --safe-mode idea, I think it could also
be possible/easy to provide a facility for modules to be marked such
that using setAccessible from that module would be disallowed.

Would this not solve every problem and use case raised thus far, as well
as being far more intuitive for users?
--
- DML
Alan Snyder
2016-07-27 21:17:10 UTC
Permalink
As a lurker to this discussion, I would like to express a casual opinion. I do not claim any original ideas here, nor do I claim to understand the details of the discussion.

I am skeptical of solutions that are motivated by security and yet are not secure. Echoing a previous comment, I would not want to lose functionality for something like that.

Is it considered irrelevant for security that native code can bypass all of these barriers?



I am wondering whether agreement could be reached on this general approach:

1. modules that need unrestricted reflection (as in JDK 8) should declare that desire in some static form (e.g. module info)

2. a deployment time feature (e.g. command line argument) can be used to grant unrestricted reflection privileges to specific modules (but only to those known at deployment time)

3. build tools can offer the convenience of using #1 and #2 to give unrestricted reflection privileges to every module known at deployment time that requests it


An implication is that modules that use unrestricted reflection should be carefully written so that malicious code could not hijack their reflective abilities to cause trouble. (The same would be the case for modules that use native code.)

Alan
Post by Remi Forax
----- Mail original -----
Envoyé: Mercredi 27 Juillet 2016 14:39:05
Objet: Re: Exporting - the wrong default?
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at http://youtu.be/-fC975HLhyc
for some less anecdotal thoughts on the business value of slightly more
secure software.
It even touches briefly on the utility of modules in JDK 9.
Interesting talk !
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
The default can not be (3) because it's a corner case, it can not be (4) because in that case we lost the 'strong encapsulation' that a module should provide by default, so the default can be either (1), either (2) or to force the user to choose between (1) and (2) when declaring a module.
- 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.
This is all rearranging deck chairs. The critical problem here, lest we forget, is that none of these solutions allow reflection to work on modules without an export, even for public types, thus breaking *everything* eventually. Any valid choice IMO must allow public types to remain public and thus globally accessible.
Since everyone seems to concede that the migration to any more secure form for users must be incremental, there is nothing left to be gained by the existing Jigsaw public access restriction. After all, even if public is left as public, it is still possible meet any reasonable standard of encapsulation. That aforementioned incremental migration could be for users and JDK developers to change public classes to be non-public; the mechanism which currently allows for exporting packages to modules is conceptually *very* close to a mechanism to share the non-public classes in packages with modules.
In other words, users should be able to export packages with a module target or a wildcard (which allows compile-time and run-time linkage to connect to those packages), and also specify whether each (non-wildcard) export should include access to private types (which allows that linkage to connect types to those non-public members).
In addition to my aforementioned --safe-mode idea, I think it could also be possible/easy to provide a facility for modules to be marked such that using setAccessible from that module would be disallowed.
Would this not solve every problem and use case raised thus far, as well as being far more intuitive for users?
--
- DML
Remi Forax
2016-07-27 21:42:04 UTC
Permalink
----- Mail original -----
Envoyé: Mercredi 27 Juillet 2016 23:17:10
Objet: Re: Exporting - the wrong default?
As a lurker to this discussion, I would like to express a casual opinion. I do
not claim any original ideas here, nor do I claim to understand the details of
the discussion.
I am skeptical of solutions that are motivated by security and yet are not
secure. Echoing a previous comment, I would not want to lose functionality for
something like that.
Is it considered irrelevant for security that native code can bypass all of these barriers?
1. modules that need unrestricted reflection (as in JDK 8) should declare that
desire in some static form (e.g. module info)
Creating your own module Layer let you to do that for all the modules but the ones of the JDK itself,
otherwise requiring jdk.unsupported (the module that own sun.misc.Unsafe) has that effect too
(see also https://bugs.openjdk.java.net/browse/JDK-8162494),
2. a deployment time feature (e.g. command line argument) can be used to grant
unrestricted reflection privileges to specific modules (but only to those known
at deployment time)
You can do that with a Java Agent.
3. build tools can offer the convenience of using #1 and #2 to give unrestricted
reflection privileges to every module known at deployment time that requests it
not sure what build tools means in that context.
An implication is that modules that use unrestricted reflection should be
carefully written so that malicious code could not hijack their reflective
abilities to cause trouble. (The same would be the case for modules that use
native code.)
yes,
with great power comes responsibility :)
All the runtimes of the languages that run on top of the JVM (Java included) has that issue.
Alan
Rémi
Post by Remi Forax
----- Mail original -----
Envoyé: Mercredi 27 Juillet 2016 14:39:05
Objet: Re: Exporting - the wrong default?
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at http://youtu.be/-fC975HLhyc
for some less anecdotal thoughts on the business value of slightly more
secure software.
It even touches briefly on the utility of modules in JDK 9.
Interesting talk !
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
The default can not be (3) because it's a corner case, it can not be (4) because
in that case we lost the 'strong encapsulation' that a module should provide by
default, so the default can be either (1), either (2) or to force the user to
choose between (1) and (2) when declaring a module.
- 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.
This is all rearranging deck chairs. The critical problem here, lest we forget,
is that none of these solutions allow reflection to work on modules without an
export, even for public types, thus breaking *everything* eventually. Any
valid choice IMO must allow public types to remain public and thus globally
accessible.
Since everyone seems to concede that the migration to any more secure form for
users must be incremental, there is nothing left to be gained by the existing
Jigsaw public access restriction. After all, even if public is left as public,
it is still possible meet any reasonable standard of encapsulation. That
aforementioned incremental migration could be for users and JDK developers to
change public classes to be non-public; the mechanism which currently allows
for exporting packages to modules is conceptually *very* close to a mechanism
to share the non-public classes in packages with modules.
In other words, users should be able to export packages with a module target or
a wildcard (which allows compile-time and run-time linkage to connect to those
packages), and also specify whether each (non-wildcard) export should include
access to private types (which allows that linkage to connect types to those
non-public members).
In addition to my aforementioned --safe-mode idea, I think it could also be
possible/easy to provide a facility for modules to be marked such that using
setAccessible from that module would be disallowed.
Would this not solve every problem and use case raised thus far, as well as
being far more intuitive for users?
--
- DML
Xavier Miró
2016-07-29 09:06:46 UTC
Permalink
I've read very good ideas and I think that we are very close to a
reasonable solution for the majority of use cases. I have imagined how I
would organize my source code in a modular world and this is how I see a
possible solution using your good ideas:

1) I agree completely with Rémi on the default case 2 (don't see it at
compile time, see it at runtime).
2) I would add the possibility of using wildcards to the 'exports' (I
think David has also commented about it)
3) I would also use the syntax that Stephen talks about, but to
restrict completely (both in compile time and in runtime) the "secret"
packages, like the JDK internal classes.

So I would organize my packages this way:

- Packages to be exported (the "API", available at runtime and
compile time):
- com.foo.myproject.package1
- com.foo.myproject.package2

- Internal packages (only available at runtime):
- internal.com.foo.myproject.package1
- internal.com.foo.myproject.package2

- Hidden packages (not available neither at compile time nor at runtime):
- hidden.com.foo.myproject.package2

In the module-info file I would write:

module com.foo.myproject {
.. (requires, uses, etc.)
exports com.foo.myproject.*;
restricts hidden.*;
..
}

With this convention and the wildcard, the problem of forgetting to
export a package or to restrict a package is reduced (of course it can
happen that I forget to put the export line, but as nothing would be
exported the build tool could emit a warning). At least, once written
the line and following the convention of the packages it would be more
difficult to leave a package without export unintentionally. The
convention is not enforced by the system, nothing prevents to use
non-wildcard 'exports' or 'restricts' or to put the packages in other
places.

This mixed proposal is based on the idea that exporting at runtime
makes no harm unless otherwise specified (with 'restricts'), so I think
that in this context the 'exports static' wouldn't make sense. As the
default is a 'exports dynamic' implicitly, it wouldn't be necessary to
have it as an explicit statement.

The qualified exports and qualified restricts would work as in the
other proposals.

So as a summary of the export visibility:

exports => compile time=yes, runtime=yes
(default) => compile time=no, runtime=yes
restricts=> compile time=no, runtime=no

I'm sure this solution has "holes", I'm not a Jigsaw expert, but I
hope that reading it can help the JSR experts to find a good proposal.

Xavi
Post by Remi Forax
----- Mail original -----
Envoyé: Mercredi 27 Juillet 2016 14:39:05
Objet: Re: Exporting - the wrong default?
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at http://youtu.be/-fC975HLhyc
for some less anecdotal thoughts on the business value of slightly more
secure software.
It even touches briefly on the utility of modules in JDK 9.
Interesting talk !
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
The default can not be (3) because it's a corner case, it can not be (4) because in that case we lost the 'strong encapsulation' that a module should provide by default, so the default can be either (1), either (2) or to force the user to choose between (1) and (2) when declaring a module.
- 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.
Stephen Colebourne
2016-07-27 15:37:31 UTC
Permalink
While the JDK cannot afford to compromise on security, many real-world
systems can and do. Software is mostly a trade-off between security,
quality, features, delivery date, design, resources... etc. As such,
this discussion cannot and should not be shut down solely on the basis
of security.

Stephen
Post by Stephen Colebourne
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for Secure
Languages?" from the recent Curry On conference, of which a recording is
available at http://youtu.be/-fC975HLhyc for some less
anecdotal thoughts on the business value of slightly more secure software.
It even touches briefly on the utility of modules in JDK 9.
cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
dalibor topic
2016-07-28 12:33:15 UTC
Permalink
Post by Stephen Colebourne
While the JDK cannot afford to compromise on security, many real-world
systems can and do. Software is mostly a trade-off between security,
quality, features, delivery date, design, resources... etc. As such,
this discussion cannot and should not be shut down solely on the basis
of security.
For an entirely hypothetical straw man example, imagine the expert
authors of a third party component A making a deliberate security trade
off in one class. For the sake of brevity, let's call that class 'Gun'.

Let's also imagine a different set of expert authors of a different
third party component B making a different deliberate security trade off
in another class. Let's call that class 'Bullet'.

Assembling a software system H which, by simply using both component A
and component B, provides both a Gun and a Bullet, could lead to some
pretty bad headaches down the road.

In the "exported by default" world view, the assembler is responsible
for restricting all such headache inducing interactions between these
classes, originating in different components with different trade offs.

Let's hope for their sake they are really awesome experts at that sort
of thing, and especially good at handling the potentially exponential
complexities that can arise from adding new components with further
third party provided Guns and Bullets to their software system.

In the "failsafe by default" world view, they are responsible for
enabling "just" the non-headache inducing interactions between those
classes, of which there in most cases may very well be none.

That's (potentially) a substantial difference in effort necessary to
accurately make such trade offs, in particular over the maintenance life
cycle of a software system.

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Stephen Colebourne
2016-07-28 13:09:38 UTC
Permalink
This artificial description/analogy seems to bear no relation to real
world development or the proposal in this thread,

To get any module to work with the basic jigsaw design, it has to
somehow expose a set of packages. As I have shown, in most libraries,
90%+ of the packages need to be exposed - hiding packages is the
minority/specialist use case (the JDK is unusual in the packages it
wants to hide).

This proposal simply alters how that set of packages is calculated
when processing module-info. It asks the module writer to deliberately
hide something, rather than to slavishy create a super long list of
exposed packages. But the binary format could still list the exported
packages rather than the restrictions.

No more packages would be exposed than with the current proposal. No
more headache inducing problems would be created.

Stephen
In the "exported by default" world view, the assembler is responsible for
restricting all such headache inducing interactions between these classes,
originating in different components with different trade offs.
Let's hope for their sake they are really awesome experts at that sort of
thing, and especially good at handling the potentially exponential
complexities that can arise from adding new components with further third
party provided Guns and Bullets to their software system.
In the "failsafe by default" world view, they are responsible for enabling
"just" the non-headache inducing interactions between those classes, of
which there in most cases may very well be none.
That's (potentially) a substantial difference in effort necessary to
accurately make such trade offs, in particular over the maintenance life
cycle of a software system.
Andrew Dinn
2016-07-28 14:24:46 UTC
Permalink
Post by Stephen Colebourne
No more packages would be exposed than with the current proposal. No
more headache inducing problems would be created.
I think you must have misunderstood Dalibor to come to that second
conclusion. A headache inducing problem that he clearly (to me at least)
identified was the one where someone adds a package but omits to
restrict it from being exported.

The need for analgesic relief stems from this default being risky in a
way that the opposing default is not. Forgetting to export a new package
cannot compromise the security of the deployment (even though it might
indeed compromise its functionality). Forgetting to restrict access can
pass unnoticed whilst granting access to clients wiht larcenous intent.

Now, you might wish to eschew (decline to chew) the aspirin and pooh
pooh Dalibor's assessment that there is a /significant/ risk involved
here. Suggesting that there is zero to balance against your suggested
gains doesn't really stand up.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Stephen Colebourne
2016-07-28 14:58:43 UTC
Permalink
Post by Andrew Dinn
Post by Stephen Colebourne
No more packages would be exposed than with the current proposal. No
more headache inducing problems would be created.
The need for analgesic relief stems from this default being risky in a
way that the opposing default is not. Forgetting to export a new package
cannot compromise the security of the deployment (even though it might
indeed compromise its functionality). Forgetting to restrict access can
pass unnoticed whilst granting access to clients wiht larcenous intent.
Sure, I understand the point. I just can't see it being particularly
relevant when most modules need to export everything.

Whereas I can see that forgetting to export a package would be fairly
common and really annoying, as it would require a new release to solve
(given that it would only be when someone tries to use the package
that you get told about the stupid mistake of not exporting it.)

Stephen
dalibor topic
2016-07-29 09:32:41 UTC
Permalink
Post by Andrew Dinn
Now, you might wish to eschew (decline to chew) the aspirin and pooh
pooh Dalibor's assessment that there is a /significant/ risk involved
here.
"An analysis of 25,000 scans reveals that 6.8% of components
being used in applications contained at least one known security
vulnerability. This finding demonstrates that defective components are
making their way across the entire software supply chain -- from initial
sourcing to use in finished goods."

"However, because a single component may contain multiple
vulnerabilities, it's important to understand that an average
application consisting of 106 components -- of which 6.8% are
known bad -- could contain numerous unique vulnerabilities" [0]

Relevant background reading:
https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities

cheers,
dalibor topic

[0]
http://www.sonatype.com/hubfs/SSC/2016_State_of_the_Software_Supply_Chain_Report.pdf
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Russell Gold
2016-07-28 14:47:27 UTC
Permalink
Post by Stephen Colebourne
As I have shown, in most libraries,
90%+ of the packages need to be exposed - hiding packages is the
minority/specialist use case (the JDK is unusual in the packages it
wants to hide).
Did you show this in an article we can access? I’ve done some open-source libraries, in which fewer than half of the packages really needed to be exported. Maybe it depends on how they are written? After all, without this capability, many developers might not have felt motivated to organize their code to minimize package visibility.
Stephen Colebourne
2016-07-28 14:54:15 UTC
Permalink
Post by Russell Gold
Did you show this in an article we can access?
On this list:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008823.html

Stephen
Jason Greene
2016-07-28 20:40:30 UTC
Permalink
Post by Stephen Colebourne
As I have shown, in most libraries,
90%+ of the packages need to be exposed - hiding packages is the
minority/specialist use case (the JDK is unusual in the packages it
wants to hide).
FWIW with jboss modules we ended up with an export everything local by default behavior because for already existing code (it’s a typical use-case to retrofit code), this is your starting point.

In cases where your project fits the Java package accessibility model well, then I agree this is also what you want for even a new project. However, it’s not uncommon for a project to break up functionality into factory/delegation patterns with packages that are intended to be private, but the accessibility model just doesn’t support a way other than making the package public. Theres also another common approach, which you see frequently in standards, where you have an API jar and a impl jar. In such a scenario you want to hide all of the packages in impl. Finally a weaker, yet interesting, case worth mentioning, is that I have seen some projects with a very large number of classes break them up into packages for organizational purposes, and this tends to introduce a great deal of “hidden" packages.

So I think an opt-in model makes sense, but, unsurprisingly, I like David’s proposal where you can expand the Java package model to allow for essentially friend package-protection.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
David M. Lloyd
2016-07-28 14:59:00 UTC
Permalink
Post by dalibor topic
Post by Stephen Colebourne
While the JDK cannot afford to compromise on security, many real-world
systems can and do. Software is mostly a trade-off between security,
quality, features, delivery date, design, resources... etc. As such,
this discussion cannot and should not be shut down solely on the basis
of security.
For an entirely hypothetical straw man example, imagine the expert
authors of a third party component A making a deliberate security trade
off in one class. For the sake of brevity, let's call that class 'Gun'.
Let's also imagine a different set of expert authors of a different
third party component B making a different deliberate security trade off
in another class. Let's call that class 'Bullet'.
Assembling a software system H which, by simply using both component A
and component B, provides both a Gun and a Bullet, could lead to some
pretty bad headaches down the road.
In the "exported by default" world view, the assembler is responsible
for restricting all such headache inducing interactions between these
classes, originating in different components with different trade offs.
Let's hope for their sake they are really awesome experts at that sort
of thing, and especially good at handling the potentially exponential
complexities that can arise from adding new components with further
third party provided Guns and Bullets to their software system.
In the "failsafe by default" world view, they are responsible for
enabling "just" the non-headache inducing interactions between those
classes, of which there in most cases may very well be none.
That's (potentially) a substantial difference in effort necessary to
accurately make such trade offs, in particular over the maintenance life
cycle of a software system.
My proposal gives the best of both worlds: all public types of all
packages are always accessible, and only the secret/non-public types
need to be explicitly privately exported. You don't have to add new
public packages to the exported list, because exporting all by default
is a safe/sane default as well as being intuitive. On the other hand,
you have to go out of your way to provide additional access to new
private packages, which is also intuitive.
--
- DML
dalibor topic
2016-07-29 14:20:59 UTC
Permalink
Post by David M. Lloyd
You don't have to add new
public packages to the exported list, because exporting all by default
is a safe/sane default as well as being intuitive.
Is it safe to assume that all potentially headache inducing Guns and
Bullets are always kept under lock in non-public classes?

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
David M. Lloyd
2016-07-29 14:55:25 UTC
Permalink
Post by dalibor topic
Post by David M. Lloyd
You don't have to add new
public packages to the exported list, because exporting all by default
is a safe/sane default as well as being intuitive.
Is it safe to assume that all potentially headache inducing Guns and
Bullets are always kept under lock in non-public classes?
Of course, that's why we had non-public classes in the first place. The
only reason users use public for this kind of thing (despite the
availability of less permissive access modes) is because the language
gives no useful way to share these classes outside their packages; this
is why I proposed this exact behavior as an alternative. This is better
than the alternative suggestion: just export everything to everybody,
defeating the point of the security measure in the first place. Also, I
propose that this is much closer to the original spirit of the Java
language than the complex knot we have on the table before us now.

At some point you must have *some* kind of faith in the user. If you
can trust the user to know to put the right packages in the module
descriptor - a task that at best can be described as "side-channel" -
then surely you can trust the user to know which classes are "safe" to
be made public and which are not (which, I might add, is something that
any regular Java user already knows how to do).
--
- DML
Alan Bateman
2016-07-29 15:14:25 UTC
Permalink
This is better than the alternative suggestion: just export everything
to everybody, defeating the point of the security measure in the first
place.
Just to check. Do you mean `exports dynamic *` or some variant of? If so
then it would mean that all public types in the module would be
accessible to code outside of the module. Non-public types would not be
accessible (ignoring wormholes when Lookup objects leak out,
setAccessible, ... for this discussion).

-Alan.
David M. Lloyd
2016-07-29 16:47:21 UTC
Permalink
Post by Alan Bateman
This is better than the alternative suggestion: just export everything
to everybody, defeating the point of the security measure in the first
place.
Just to check. Do you mean `exports dynamic *` or some variant of? If so
then it would mean that all public types in the module would be
accessible to code outside of the module. Non-public types would not be
accessible (ignoring wormholes when Lookup objects leak out,
setAccessible, ... for this discussion).
Right, I'm referring to "exports dynamic *".
--
- DML
dalibor topic
2016-08-01 10:40:39 UTC
Permalink
Post by David M. Lloyd
Post by dalibor topic
Is it safe to assume that all potentially headache inducing Guns and
Bullets are always kept under lock in non-public classes?
Of course, that's why we had non-public classes in the first place.
OK, let's assume that's correct for the deliberate headache instrument
hiding decisions made by all Java developers for the sake of the argument.

To balance that assumption out, please grant me an assumption as well:
Let's assume for the sake of the argument that not all Java developers
are experts all the time, and therefore some of them might sometimes
produce classes that could be abused as headache inducing Slings and
Stones.

Is it safe to assume that all such involuntarily headache inducing
Slings and Stones are also kept under lock in non-public classes?

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
David M. Lloyd
2016-08-01 14:04:03 UTC
Permalink
Post by dalibor topic
Post by David M. Lloyd
Post by dalibor topic
Is it safe to assume that all potentially headache inducing Guns and
Bullets are always kept under lock in non-public classes?
Of course, that's why we had non-public classes in the first place.
OK, let's assume that's correct for the deliberate headache instrument
hiding decisions made by all Java developers for the sake of the argument.
Let's assume for the sake of the argument that not all Java developers
are experts all the time, and therefore some of them might sometimes
produce classes that could be abused as headache inducing Slings and
Stones.
Is it safe to assume that all such involuntarily headache inducing
Slings and Stones are also kept under lock in non-public classes?
Of course not, no more than it is safe to assume that such will be kept
hidden in non-exported packages under the existing regime. At some
point the user has to make the decision to make something public or not
public; nothing can change that. But what we can do is to make it easy
for users: a public class is public, otherwise it is secret and has to
be explicitly shared. Contrast with the current system, where whole
packages must have their definition of "public" defined to mean either
selectively shared or fully public, which is less intuitive and more
confusing. The more confused the user is, the more likely they are to
make a mistake about security. With my proposal, if there are any
doubts about a class, you make it non-public (regardless of what package
it is in), which is a very simple criterion. In addition, you make the
public/non-public choice on a per-class basis, not a per-package basis,
which is also useful as well as intuitive.
--
- DML
Paul Benedict
2016-08-01 15:38:53 UTC
Permalink
To echo David, there is a complaint by me in these archives how I still
find it difficult to remember that "public" is no longer being public. I
feel the same way today still. The word "public" means "for everyone" so
it's always jarring to have it no longer mean what it should mean in normal
English. Also, I find it less than appealing to do double-duty to make my
classes public. I now have to remind myself to export my package but it's
still something I forget. I find this step to be a nuisance. That's my real
world feedback.

Cheers,
Paul
Post by David M. Lloyd
Post by dalibor topic
Post by David M. Lloyd
Post by dalibor topic
Is it safe to assume that all potentially headache inducing Guns and
Bullets are always kept under lock in non-public classes?
Of course, that's why we had non-public classes in the first place.
OK, let's assume that's correct for the deliberate headache instrument
hiding decisions made by all Java developers for the sake of the argument.
Let's assume for the sake of the argument that not all Java developers
are experts all the time, and therefore some of them might sometimes
produce classes that could be abused as headache inducing Slings and
Stones.
Is it safe to assume that all such involuntarily headache inducing
Slings and Stones are also kept under lock in non-public classes?
Of course not, no more than it is safe to assume that such will be kept
hidden in non-exported packages under the existing regime. At some point
the user has to make the decision to make something public or not public;
a public class is public, otherwise it is secret and has to be explicitly
shared. Contrast with the current system, where whole packages must have
their definition of "public" defined to mean either selectively shared or
fully public, which is less intuitive and more confusing. The more
confused the user is, the more likely they are to make a mistake about
security. With my proposal, if there are any doubts about a class, you
make it non-public (regardless of what package it is in), which is a very
simple criterion. In addition, you make the public/non-public choice on a
per-class basis, not a per-package basis, which is also useful as well as
intuitive.
--
- DML
Stephane Epardaud
2016-08-01 15:58:48 UTC
Permalink
I don't think public ever meant "public to the world". In Java 1->8 it
means "visible to those who can see the containing scope". If you
declare a public inner class in a private (or package-private) class,
then those who cannot access the outer type also cannot access the
public inner class.

So no, "public" never meant "visible to everyone", it was always about
scope.

On the other hand, for toplevel types, the scope had always been the
package, and packages were public by default. Now that default changes
to private, but notice that even here, a package is only private outside
its scope (the module). Other packages in the same scope (module) will
be able to access it.

So for me it's always been about exporting from the current scope.
Post by Paul Benedict
To echo David, there is a complaint by me in these archives how I still
find it difficult to remember that "public" is no longer being public. I
feel the same way today still. The word "public" means "for everyone" so
it's always jarring to have it no longer mean what it should mean in normal
English. Also, I find it less than appealing to do double-duty to make my
classes public. I now have to remind myself to export my package but it's
still something I forget. I find this step to be a nuisance. That's my real
world feedback.
Paul Benedict
2016-08-01 16:04:13 UTC
Permalink
Stephane, please take my words within context. I wasn't being too
technical; just merely using "public to the world" with regards to
exporting packages. However, I appreciate your technical eye to get the
details right. Thanks for the broader explanation.

Cheers,
Paul
Post by Stephane Epardaud
I don't think public ever meant "public to the world". In Java 1->8 it
means "visible to those who can see the containing scope". If you declare a
public inner class in a private (or package-private) class, then those who
cannot access the outer type also cannot access the public inner class.
So no, "public" never meant "visible to everyone", it was always about
scope.
On the other hand, for toplevel types, the scope had always been the
package, and packages were public by default. Now that default changes to
private, but notice that even here, a package is only private outside its
scope (the module). Other packages in the same scope (module) will be able
to access it.
So for me it's always been about exporting from the current scope.
Post by Paul Benedict
To echo David, there is a complaint by me in these archives how I still
find it difficult to remember that "public" is no longer being public. I
feel the same way today still. The word "public" means "for everyone" so
it's always jarring to have it no longer mean what it should mean in normal
English. Also, I find it less than appealing to do double-duty to make my
classes public. I now have to remind myself to export my package but it's
still something I forget. I find this step to be a nuisance. That's my real
world feedback.
David Holmes
2016-08-02 01:26:09 UTC
Permalink
Post by Stephane Epardaud
I don't think public ever meant "public to the world". In Java 1->8 it
means "visible to those who can see the containing scope". If you
declare a public inner class in a private (or package-private) class,
then those who cannot access the outer type also cannot access the
public inner class.
So no, "public" never meant "visible to everyone", it was always about
scope.
On the other hand, for toplevel types, the scope had always been the
package, and packages were public by default. Now that default changes
to private, but notice that even here, a package is only private outside
its scope (the module). Other packages in the same scope (module) will
be able to access it.
So for me it's always been about exporting from the current scope.
That is my take on this exactly. Modules introduce a new scoping layer.
If you want packages to now appear to users of a module, you have to
export them.

David H.
Post by Stephane Epardaud
Post by Paul Benedict
To echo David, there is a complaint by me in these archives how I still
find it difficult to remember that "public" is no longer being public. I
feel the same way today still. The word "public" means "for everyone" so
it's always jarring to have it no longer mean what it should mean in normal
English. Also, I find it less than appealing to do double-duty to make my
classes public. I now have to remind myself to export my package but it's
still something I forget. I find this step to be a nuisance. That's my real
world feedback.
dalibor topic
2016-08-02 09:48:06 UTC
Permalink
Post by David M. Lloyd
With my proposal, if there are any
doubts about a class, you make it non-public (regardless of what package
it is in), which is a very simple criterion. In addition, you make the
public/non-public choice on a per-class basis, not a per-package basis,
which is also useful as well as intuitive.
How do I make a single class non-public in a third party component?

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
dalibor topic
2016-08-02 11:49:01 UTC
Permalink
Post by David M. Lloyd
Post by dalibor topic
Is it safe to assume that all such involuntarily headache inducing
Slings and Stones are also kept under lock in non-public classes?
Of course not, no more than it is safe to assume that such will be kept
hidden in non-exported packages under the existing regime.
Great - I think we can agree that some inadvertently headache inducing
classes might be public and some might be not.

Let's now consider two different scenarios, in which Sling and Stone are
either public, or not, and denote the variants with a P or N prefix -
PSling is a public Sling, while NStone is a non-public Stone, for example.

Let's also consider two defaults: permissive (i.e. all packages are
exported) and fail safe (i.e. no packages are exported).

Permissive:
PSling + PStone can induce a headache, while the other three cases
fortunately can not. So a mere 25% opportunity for a headache.

Fail safe:
none of the four cases induce a headache.

Let's now add reflection & setAccessible to the mix.

To make the example more plastic, let's hypothetically assume that the
Sling is some kind of a universal reflector utility class, which has a
method that kindly performs a reflective operation upon polite request,
using setAccessible if necessary to access otherwise inaccessible
members, while violating SEC05-J [0]. Let's also assume that the Stone
has some other potentially headache inducing problem.

Again, no headache occurs in the Failsafe case, because no packages are
exported, while at the same time in the Permissive case, both the
PSling+PStone and PSling+NStone cases now can induce a headache.

Fortunately, the other two cases still do not, so that's a mere 50%
opportunity for headache.

A coin toss, in other words.

Now let's consider the Fail safe default with developers optionally
exporting packages containing Sling and Stone. Let's mark classes
contained in an exported package with an X prefix, while those that
aren't get an O.

The headache inducing cases are

XPSling+XPStone and XPSling+XNStone

while the other 14 cases are not.

While headaches can no longer be excluded, that's quite a bit better
than a coin toss, or even just the initial permissive scenario without
use of reflection & setAccessible in the Sling.

Of course, you can get to the same cases starting with a Permissive
default and then restricting exports of the packages in question.

Yet, there is an interesting difference between the two scenarios:

a) in the fail safe default case you start at no risk of headache
inducing combinations of Slings and Stones, and then can increase your
risk of a headache occurring to a certain level by adding exports, while
in the permissive case you start at a coin toss level of headache risk
and have to remove exports to decrease it to the same level, and

b) regardless of how many Slings and Stones there are in the mix, you
always start at no risk of headache inducing combinations of Stones and
Slings in the fail safe default case, while adding further Slings and
Stones to the mix makes your initial headache risk significantly greater
than a coin toss in the permissive case.

cheers,
dalibor topic

[0]
https://www.securecoding.cert.org/confluence/display/java/SEC05-J.+Do+not+use+reflection+to+increase+accessibility+of+classes,+methods,+or+fields
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Stephen Colebourne
2016-08-02 12:47:34 UTC
Permalink
Post by dalibor topic
Let's now consider two different scenarios, in which Sling and Stone are
either public, or not, and denote the variants with a P or N prefix - PSling
is a public Sling, while NStone is a non-public Stone, for example.
Let's also consider two defaults: permissive (i.e. all packages are
exported) and fail safe (i.e. no packages are exported).
PSling + PStone can induce a headache, while the other three cases
fortunately can not. So a mere 25% opportunity for a headache.
none of the four cases induce a headache.
Er, now no-one can use the library.

The purpose of a library is to provide public types for applications
to use. That these have bugs and/or security issues is a fact of life
in software. Developers are not going to suddenly stop using external
OSS libraries.
Post by dalibor topic
Let's now add reflection & setAccessible to the mix.
...
Again, no headache occurs in the Failsafe case, because no packages are
exported,
Er, now no-one can use the library because it can't operate without
reflection+setAccessible.

I again draw attention to the fact that many many OSS libraries use
reflection+setAccessible, and that the ecosystem relies on it pretty
much everywhere [1], at least in part because beans+properties has
never been addressed.
Post by dalibor topic
Of course, you can get to the same cases starting with a Permissive default
and then restricting exports of the packages in question.
a) in the fail safe default case you start at no risk of headache inducing
combinations of Slings and Stones, and then can increase your risk of a
headache occurring to a certain level by adding exports, while in the
permissive case you start at a coin toss level of headache risk and have to
remove exports to decrease it to the same level, and
b) regardless of how many Slings and Stones there are in the mix, you always
start at no risk of headache inducing combinations of Stones and Slings in
the fail safe default case, while adding further Slings and Stones to the
mix makes your initial headache risk significantly greater than a coin toss
in the permissive case.
Er, but this is such a straw man. There is no "initial headache risk".
The packages have to be exported to actually use the library, and are
today. The vast majority of libraries porting to Java 9 will have to
export all packages because nothing else will work. In virtually no
cases, is the end-user developer going to be changing the exported
packages of the libraries they depend on.

To get any benefit from the new modular scope, existing OSS projects
will require significant backward-incompatible reworking - to take
existing public classes and methods and move them to different
packages. This is major work, and far less likely than just exporting
everything (how many years has it taken to do this in the JDK?).

What I want from jigsaw is a *new* ability, not alteration of the
status quo. ie. to allow developers to *opt-in* to selectively hide
things at the module level *going forward*. Ideally I also want to
hide individual classes, methods and fields, because packages are far
too coarse grained for this.

IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple. Get this wrong, and we'll all just carry on using the
classpath, and the last 5+ years of effort in the JDK will have little
value.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008855.html
Eric Johnson
2016-08-02 17:43:45 UTC
Permalink
There's so much to tackle on this thread...
Post by Stephen Colebourne
IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple. Get this wrong, and we'll all just carry on using the
classpath, and the last 5+ years of effort in the JDK will have little
value.
Indeed. Commercial vendors will have the same problem. And to the extent
that we use open source libraries, we may need to fork said libraries.
In working with OSGi, my company has had enormous issues with getting
the metadata right for libraries - nothing obviously wrong with the
code, but the metadata is a royal pain. It doesn't appear to transfer
between platforms seamlessly. Potentially a huge cost with JDK 9
modularization.

At the same time, I work on security issues. I want security by default.
So I want both sides of this question to get the answer they want. Nasty
conundrum we've found ourselves in.

One part of the split is simple - modules are a (presumably) useful
compile time constraint. Giving Java the ability to hide public classes
simply because the author didn't really want to expose them, but the
language constraints didn't give them a choice, that seems like an
improvement. This is not a security problem, just a language problem.

Bring module enforcement into the runtime, and it is now a security
problem. All security problems are trade-offs. For one step, (as I've
mentioned before) I'd really like someone to point at some security
analysis document that goes through the threat model analysis (or its
equivalent), so we can have a deeper discussion than "default to secure"
as the only answer. Off the top of my head, I cannot think of any
threats to something like Eclipse, which has already embraced the OSGi
form of modularization. How will Jigsaw modularization enforcement at
runtime can actually make Eclipse safer? I don't think it will. On the
server side - much different question.

On the server side, without deep analysis, I suspect the default to
enforce module boundaries makes sense. However, we also know, up front,
that such a step will break things. To fix that breakage, will mean lots
of changes to code, made by a lot of people, not all with lots of
experience, across a lot of libraries. In other words, an opportunity to
accidentally introduce new security bugs while trying to work within a
new security framework. Again, wanting a threat model analysis, because
helping those developers cross the chasm should be part of the threat
equation that we're trying to solve.

So we really want a place where people can start using modules at
compile time, and choose to opt into module boundary enforcement at
runtime. I suspect it is probably an OK starting position if the JRE
itself always benefits from boundary enforcement. But everything else -
not sure that's a good idea, as it will blow-up the Java ecosystem.

Two possibilities - either a flag for the Java runtime to enforce module
boundaries (default off?), or let individual modules choose whether they
opt-in. Actually, both might be useful.

With the opt-in on a module basis, the open source project that needs to
produce a module can produce one quickly, and opt-out of boundary
enforcement. No source code changes besides module declarations, so
minimal risk. That way, those developers can avoid all the hacking on
code and changes that might be necessary by flipping to strict
enforcement immediately. Over time, downstream users of those open
source projects will be able to test those libraries by flipping a
switch, and enforcing module boundaries for a given module, then testing
to see if that caused problems. They can then go back to the open source
project with definitive information, gleaned from actual use, about what
is necessary to opt-in to full enforcement.

As for flags on the runtime, it might be good to have a flag which
defaults to off. Other settings would be "warn", and "strict". SELinux,
which seems closely analogous to this problem, has a similar model of
"warn" vs. "enforce". So perhaps a good pattern to follow?

Eric
dalibor topic
2016-08-04 13:05:44 UTC
Permalink
Post by Eric Johnson
So we really want a place where people can start using modules at
compile time, and choose to opt into module boundary enforcement at
runtime.
I think that Alex goes a bit into all that in the unnamed and automatic
module sections in his JVM Language Summit talk:
. For some interesting usage
of layers to generate dynamic modules, for example, please see the
Nashorn talk from the same event:
.

A more detailed exploration of different migration approaches to fully
modular applications is available in the Advanced Modular Development
talk at
.
Post by Eric Johnson
But everything else -
not sure that's a good idea, as it will blow-up the Java ecosystem.
As exciting [2] as predictions of impending doomsday often seem, they
don't turn out to be very likely in practice. [0] [1]

cheers,
dalibor topic

[0] "Comet May Kill All Earth Life Says Scientist," The San Francisco
Call (San Francisco, CA), February 8, 1910, Page 1, Image 1, col. 2.
http://chroniclingamerica.loc.gov/lccn/sn85066387/1910-02-08/ed-1/seq-1/#words=Halley's+Cyanogen+cyanogen+Flammarion+Yerkes+comet

[1]
http://sunsite.uakom.sk/sunworldonline/swol-08-1998/swol-08-torvalds.html
[2] http://tvtropes.org/pmwiki/pmwiki.php/Main/TheEndOfTheWorldAsWeKnowIt
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
dalibor topic
2016-08-03 12:52:22 UTC
Permalink
Post by Stephen Colebourne
today. The vast majority of libraries porting to Java 9 will have to
export all packages because nothing else will work. In virtually no
cases, is the end-user developer going to be changing the exported
packages of the libraries they depend on.
OK, let's adjust the "reflection under failsafe defaults" example to
take the "vast majority" effect into account.

Let's say that a component author is n times more likely to export the
packages containing Sling and Stone than not, for example by just
exporting all packages.

In that case, the headache inducing XPSling+XPStone and XPSling+XNStone
cases give us 2*(n*n) combinations that might cause a headache (i.e. 2n^2).

They are balanced out by XNSling+XPStone and XNSling+XNStone cases,
which give us another 2n^2 combinations that can't cause a headache.

In addition, there are 8n + 4 other combinations that can't cause a
headache, such as XNSling+OPStone, etc.

From this example, I think two things are quite obvious:

a) Regardless of how high n is, the ratio of headache inducing
combinations vs. the total is always going to be less than a half - i.e.
the fail safe default always provides less risk than the coin toss of
the permissive default, regardless of how widespread a practice of just
exporting all packages to everyone would be.

c) Looking at
https://www.wolframalpha.com/input/?i=(2n%5E2)%2F(4n%5E2%2B8n%2B4) ,
even assuming that n is as extreme as 15, you get a roughly 44% ratio of
headache inducing cases - which would still be quite an improvement over
the coin toss of the permissive case.

If we look at your survey in
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008823.html,
you found about 20 components that export all packages to everyone vs.
about 5 that don't. That suggests n may be closer to 4 for some types of
components.

In that case the ratio of headache inducing combinations ends up being a
mere 32% compared to the coin toss probability of the permissive default.

I think that's quite a substantial difference.
Post by Stephen Colebourne
To get any benefit from the new modular scope, existing OSS projects
will require significant backward-incompatible reworking - to take
existing public classes and methods and move them to different
packages. This is major work, and far less likely than just exporting
everything (how many years has it taken to do this in the JDK?).
I'm not sure that the JDK with its millions of lines of code developed
over decades in hundreds of packages is a perfect example to guide
expectations of effort necessary to benefit from modules for most
components in the Java ecosystem.

For example, assuming for the sake of argument that the effort to
determine and untangle dependencies and exports between packages is
roughly quadratic in the number of packages, a multi-year effort for the
JDK would translate to much smaller efforts for components with a much
smaller number of packages to consider.

As a real world example, in your survey above around half of the
components have 5 packages or less.
Post by Stephen Colebourne
IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple.
Yes, a general migratory movement would be great! Of course, many
component developers may want to continue to support JDK 8, so for
example http://openjdk.java.net/jeps/238 is important in this context,
as well.

Outside of individual organizations, it might be quite hard for everyone
everywhere to migrate at the same time though, so ways for modularized
and non-modularized components to safely coexist are important in order
to allow such migrations to take place at the pace their users and
developers are comfortable with.

For some of the ways the proposed module system design works hard behind
the scenes to support that approach, please see
http://openjdk.java.net/projects/jigsaw/spec/sotms/#compatibility--migration
.

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Alan Bateman
2016-07-27 16:26:38 UTC
Permalink
Post by Stephen Colebourne
I think a key problem is that those working on the JDK have a warped
sense of what a typical Java project is like. In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*. The current default to force developers to list all
exports is simply going to slow developers down for no perceived
benefit.
One thing that I like with the current design is that there is one
authoritative source file that describes the module. It's nice to edit
one source file when you want to examine or change the set of packages
in the API, the dependences, and of course the services used and
provided. Also declaring the set of the API packages that are exported
shouldn't be a big surprise. There are many module systems built on top
of the platform where you will see similar.

I do see your point about it being a potential chore when starting out,
esp. when a new module is in development and the API packages are in
flux. However I would expect that in time that the IDEs, the refactoring
support in particular, will help. Also once the API has settled a bit,
and other modules start depending on your module, then the number of
changes to the exports list will reduce.

-Alan
Andrew Dinn
2016-07-28 08:47:50 UTC
Permalink
Post by Alan Bateman
I do see your point about it being a potential chore when starting out,
esp. when a new module is in development and the API packages are in
flux. However I would expect that in time that the IDEs, the refactoring
support in particular, will help. Also once the API has settled a bit,
and other modules start depending on your module, then the number of
changes to the exports list will reduce.
I believe you are missing an important point here -- one of scale. Large
middleware suites like containers currently comprise many hundreds of
component jars, many of them released independently by a proportionately
large number of 3rd party developers. That means something is always in
flux between one release and the next of the middleware suite. Your
pretty picture of Jigsaw imposing a nice clean mechanism to control
dependencies at the level of each individual released component does not
scale to this sort of circumstance.

A descriptor (module-info.class) baked into a 3rd party jar at release
cannot be altered without getting the 3rd party to update and re-release
the jar -- at which point other components then also need to change and
be re-released in consequence. Meanwhile further components will have
had to change to patch bugs or security issues and the whole cycle
starts all over again.

By contrast a descriptor (or suite of descriptors) independent from the
described components can be updated without having to get multiple 3rd
parties to be involved in re-creating the described components. This
latter route has indeed been followed by those who have had to build
systems at this scale for exactly this reason.

What you present as an advantage - having the linkage descriptor tightly
coupled with the linked component -- is, in fact, already known to
present significant problems. I find it bizarre that you seem to think
that your assumptions about the benefits offered by Jigsaw's mode of
operation can be blithely retained - not even allowing that they might
have some drawbacks -- in the face of repeated warnings from those who
have experience in these matters.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Alan Bateman
2016-07-28 09:20:54 UTC
Permalink
Post by Andrew Dinn
I believe you are missing an important point here -- one of scale. Large
middleware suites like containers currently comprise many hundreds of
component jars, many of them released independently by a proportionately
large number of 3rd party developers. That means something is always in
flux between one release and the next of the middleware suite. Your
pretty picture of Jigsaw imposing a nice clean mechanism to control
dependencies at the level of each individual released component does not
scale to this sort of circumstance.
A descriptor (module-info.class) baked into a 3rd party jar at release
cannot be altered without getting the 3rd party to update and re-release
the jar -- at which point other components then also need to change and
be re-released in consequence. Meanwhile further components will have
had to change to patch bugs or security issues and the whole cycle
starts all over again.
By contrast a descriptor (or suite of descriptors) independent from the
described components can be updated without having to get multiple 3rd
parties to be involved in re-creating the described components. This
latter route has indeed been followed by those who have had to build
systems at this scale for exactly this reason.
What you present as an advantage - having the linkage descriptor tightly
coupled with the linked component -- is, in fact, already known to
present significant problems. I find it bizarre that you seem to think
that your assumptions about the benefits offered by Jigsaw's mode of
operation can be blithely retained - not even allowing that they might
have some drawbacks -- in the face of repeated warnings from those who
have experience in these matters.
There is nothing in the module system that forces anyone to package a
module as a modular JAR. Also nothing that requires the compiled form of
the module declaration to be in the same artifact as the module
contents. Maybe it would better to start another thread on your
concerns, it otherwise feels like we are hijacking Stephen's thread.

-Alan.
Andrew Dinn
2016-07-28 09:42:34 UTC
Permalink
Post by Alan Bateman
There is nothing in the module system that forces anyone to package a
module as a modular JAR. ...
No, of course not. But designing a module system which is not going to
be useful to EE developers looks like fiddling when Rome is burning.
Post by Alan Bateman
... Also nothing that requires the compiled form of
the module declaration to be in the same artifact as the module
contents. Maybe it would better to start another thread on your
concerns, it otherwise feels like we are hijacking Stephen's thread.
Well, that is a complete surprise to me. I have not seen this explained
or documented anywhere.

Could you point me at the relevant documentation so I can understand
how I need to configure such a split deployment or at least provide me
with more details?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Alan Bateman
2016-07-28 11:12:07 UTC
Permalink
Post by Andrew Dinn
Well, that is a complete surprise to me. I have not seen this explained
or documented anywhere.
Could you point me at the relevant documentation so I can understand
how I need to configure such a split deployment or at least provide me
with more details?
(I've changed the subject line).

OOTB, the JDK supports modular JARs and exploded modules at compile-time
and run-time. There is also a niche format called JMOD for packaging
modules that are only consumed at link time, interesting when creating
custom run-time images with jlink, probably not interesting in this thread.

If you want to use alternative packaging, or store the module
declarations separate to the module contents, then you will need to
develop your own ModuleFinder. There are are a number of classes in the
API that need to be implemented but it shouldn't be too difficult. One
method to point out is ModuleDescriptor.read to read the binary form and
combine it with the set of packages in the module. All the docs are
online [1]. This all assumes you are doing dynamic configuration and
creating your own layer of modules of course, there is nothing that
allows using custom packaging formats during startup (chicken 'an egg
issue of course). I don't have a suggestion for compile-time but from
your other mail then it sounds more like patching, no mention of
recompiling modules.

BTW: One thing that would be useful is to provide one or two examples.
If my module `exports foo.math` and `exports foo.math.function` for
example, then it's hard to see why you would be changing it, at least
not if you aren't shading it. Ditto for `uses` and `provides`. So I
think/assume you are mostly thinking about `requires`.

-Alan

[1] http://download.java.net/java/jigsaw/docs/api/index.html
Andrew Dinn
2016-07-28 12:17:05 UTC
Permalink
Post by Alan Bateman
OOTB, the JDK supports modular JARs and exploded modules at compile-time
and run-time. There is also a niche format called JMOD for packaging
modules that are only consumed at link time, interesting when creating
custom run-time images with jlink, probably not interesting in this thread.
If you want to use alternative packaging, or store the module
declarations separate to the module contents, then you will need to
develop your own ModuleFinder. There are are a number of classes in the
API that need to be implemented but it shouldn't be too difficult. One
method to point out is ModuleDescriptor.read to read the binary form and
combine it with the set of packages in the module. All the docs are
online [1]. This all assumes you are doing dynamic configuration and
creating your own layer of modules of course, there is nothing that
allows using custom packaging formats during startup (chicken 'an egg
issue of course). I don't have a suggestion for compile-time but from
your other mail then it sounds more like patching, no mention of
recompiling modules.
Ok, so when you say that there is

"nothing that requires the compiled form of the module declaration to
be in the same artifact as the module contents."

what you are seem to be saying is that there is nothing short of:

a protocol defining a standard format for storing a module descriptor
separate from its implementation classes

standard tooling for packaging module contents separate from their
declarations in said putative format

a standard library capable of re-uniting a module descriptor with the
associated module contents at module load time should they be packaged
in said putative format

So, this seems to be very much a theoretical rather than an actual
option we are discussing here.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Alex Buckley
2016-07-28 22:05:52 UTC
Permalink
Post by Andrew Dinn
A descriptor (module-info.class) baked into a 3rd party jar at release
cannot be altered without getting the 3rd party to update and re-release
the jar -- at which point other components then also need to change and
be re-released in consequence. Meanwhile further components will have
had to change to patch bugs or security issues and the whole cycle
starts all over again.
By contrast a descriptor (or suite of descriptors) independent from the
described components can be updated without having to get multiple 3rd
parties to be involved in re-creating the described components. This
latter route has indeed been followed by those who have had to build
systems at this scale for exactly this reason.
Down-thread, Alan asked for examples of the changes you've made to a 3rd
party's descriptor, but I think you're raising "descriptor baked into a
3rd party jar" as a concern for modules delivered in the future rather
than for JAR files you have on hand today. I think this because Sanne
Grinovero spoke on 7/12 of CREATING descriptors from scratch:

"In fact in my team we also have experience "packaging" lots of these
OSS Java libraries into JBoss Modules, and have always appreciated that
- as an assembler - with JBoss Modules I can define the dependencies via
external metadata, without having to recompile or have to reassemble the
jar. As you [meaning John Rose] suggest, it is indeed useful to be able
to override the intent of the library authors, especially as different
libraries are developed by independent teams / communities / companies."

I assume the "intent of the library authors" is found in the POM, and he
translate it to module.xml [1] with occasional tweaks to add, remove,
and optionalize dependencies.

Am I on track?

Alex

[1] https://docs.jboss.org/author/display/MODULES/Module+descriptors
Andrew Dinn
2016-07-29 11:24:44 UTC
Permalink
Post by Alex Buckley
Down-thread, Alan asked for examples of the changes you've made to a 3rd
party's descriptor, but I think you're raising "descriptor baked into a
3rd party jar" as a concern for modules delivered in the future rather
than for JAR files you have on hand today. I think this because Sanne
"In fact in my team we also have experience "packaging" lots of these
OSS Java libraries into JBoss Modules, and have always appreciated that
- as an assembler - with JBoss Modules I can define the dependencies via
external metadata, without having to recompile or have to reassemble the
jar. As you [meaning John Rose] suggest, it is indeed useful to be able
to override the intent of the library authors, especially as different
libraries are developed by independent teams / communities / companies."
I assume the "intent of the library authors" is found in the POM, and he
translate it to module.xml [1] with occasional tweaks to add, remove,
and optionalize dependencies.
Am I on track?
Yes, you are on track. The problem I was referring to relates to the
future possibility of having to integrate Jigsaw-enabled components into
middleware tools like containers, specifically to whatever management
problems this may cause. The potential for complexity is twofold. A
container like EAP may be faced with having some of the component jars
it relies on being Jigsaw-modularized. It may also need to deploy
Jigsaw-modularized application jars which need to access the
functionality it manages. In both cases the specific problem I was
concerned with was the need to add, remove or optimize dependencies that
Sanne refers to.

Sanne is probably far better able than I am to communicate what might be
problematic as regards configuratation in the sort of scenario I
referred to since he has far greater experience of using JBoss Modules
and the containers built on top of it than I have (albeit that I have
probably looked as deep or deeper into the code which implements JBoss
Modules itself). However, I am not sure that this issue stands in
complete isolation from other issues identified by David Lloyd (JBoss
Modules author and author of the page you cited describing the
moudle.xml file). David may well be in a better position to comment on that.

Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Alex Buckley
2016-07-29 20:13:49 UTC
Permalink
Post by Andrew Dinn
Post by Alex Buckley
Down-thread, Alan asked for examples of the changes you've made to a 3rd
party's descriptor, but I think you're raising "descriptor baked into a
3rd party jar" as a concern for modules delivered in the future rather
than for JAR files you have on hand today. I think this because Sanne
"In fact in my team we also have experience "packaging" lots of these
OSS Java libraries into JBoss Modules, and have always appreciated that
- as an assembler - with JBoss Modules I can define the dependencies via
external metadata, without having to recompile or have to reassemble the
jar. As you [meaning John Rose] suggest, it is indeed useful to be able
to override the intent of the library authors, especially as different
libraries are developed by independent teams / communities / companies."
I assume the "intent of the library authors" is found in the POM, and he
translate it to module.xml [1] with occasional tweaks to add, remove,
and optionalize dependencies.
Am I on track?
Yes, you are on track. The problem I was referring to relates to the
future possibility of having to integrate Jigsaw-enabled components into
middleware tools like containers, specifically to whatever management
problems this may cause. The potential for complexity is twofold. A
container like EAP may be faced with having some of the component jars
it relies on being Jigsaw-modularized. It may also need to deploy
Jigsaw-modularized application jars which need to access the
functionality it manages. In both cases the specific problem I was
concerned with was the need to add, remove or optimize dependencies that
Sanne refers to.
Mark already discussed with Jason how a container can rewrite
descriptors as modules are being spun up [1] so I'm struggling to see
the problem unless there is some burning desire to rewrite the
descriptor by hand prior to run time. I can understand that if Sanne
takes third party JARs containing no descriptors, and manually creates
descriptors by spying on the POMs, then sure it's nice to keep the
descriptors external and the JARs unchanged ... but a Jigsaw modular JAR
already contains a descriptor that we assume is authoritative unless a
container is rewriting at run time.

Alex

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008637.html
Andrew Dinn
2016-08-01 11:36:34 UTC
Permalink
Post by Alex Buckley
Mark already discussed with Jason how a container can rewrite
descriptors as modules are being spun up [1] so I'm struggling to see
the problem unless there is some burning desire to rewrite the
descriptor by hand prior to run time. I can understand that if Sanne
takes third party JARs containing no descriptors, and manually creates
descriptors by spying on the POMs, then sure it's nice to keep the
descriptors external and the JARs unchanged ... but a Jigsaw modular JAR
already contains a descriptor that we assume is authoritative unless a
container is rewriting at run time.
Yes, I had already read that discussion and I am hoping it can continue
to a point where it reaches a more definitive and actionable conclusion.

Firstly, I'll note that it was merely that -- a discussion. It was not a
conclusive investigation (let alone resolution) of the all the problems
that might be involved in providing the functionality required to manage
exports in the way Mark suggested. So, the suggestion that Jigsaw
provides all the functionality that is needed would not (yet) seem to me
to be warranted.

Secondly, the ability to rewrite import export relations at runtime when
constructing module Layers does not of itself remove any of the
complexity resulting from baking module descriptors into deployments. It
merely removes the stopper from the fly bottle -- the fly still needs to
work out how to locate and attain the exit. Now, if the fly was never
led into the fly-bottle in the first place ...

Thirdly, I think there are still outstanding issues on the table which
may invalidate this proposed solution (#CyclicDependences,
#MutableConfigurations). Indeed, Jason's response to Mark referred to
the latter issue (albeit not by name) and I don't think the response
really took into account the potential for problems in this area. In
particular, in a runtime where stopping and restarting of services along
with all their dependents may happen repeatedly and regularly issue
#MutableConfigurations may well transmute into issue
#LazyConfigurationAndInstantiation. Jigsaw really is not built to
support the removal and reinstallation of modules. Whether or not its
Layer concept is adequate to the needs of containers for which this is a
critical capability appears to me still to be an open question.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Peter Levart
2016-08-01 14:37:45 UTC
Permalink
Hi,
Post by Stephen Colebourne
If the default does not change, then I assume the tools will
effectively work around it. ie. that Maven will have an option to
export all packages not explicitly hidden. Anything else would be far
too annoying for development.
Stephen
PS, I would accept a design where developers could choose to use
exports or restricts (but not both) in module-info.java.
What about adding support for automatic modules to javac ?

Currently if there is a directory in the -modulesourcepath that contains
sources but no module-info.java file, it is not treated as a module. If
it was treated as an automatic module (meaning that it would export all
packages and require all other modules), the development process could
be more easily bootstrapped. At some point in time when clear API of the
module is formed, the developer would just add the module-info.java to
it to describe the module in full...

Regards, Peter
Gregg Wonderly
2016-07-26 12:05:10 UTC
Permalink
But the question really comes down to, "will 80% of developers be interested in this level of restriction, or is this functionality which only 20% of all software needs?

The defaults fails to support open, shared access to facilitate reuse. Instead it supposes that we are all creating secured, limited environments which will demand very limited exposures.

I don't see this as the reality that exists today or might exist in any coming future. I see all matters of environmental security issues as being solved by container standards and/or SecurityManager implementations.

It would be awesome to have standards for how modules could be deployed to any container. It feels like we are instead focused on how to further reduce reuse and sharing in general.

Gregg

Sent from my iPhone
Post by Stephen Colebourne
This does not appear to change the underlying model of modules
(reliable configuration and strong encapsulation), but would make it
much more practical to use.
It wouldn't be as robust in face of change, as it would require consciously tracking new packages being added to a module and explicitly marking them as internal, or living with design mistakes (or other problems) because someone forgot to immediately restrict access to something that was supposed to be internal.
For a much longer explanation, see "Fail-safe defaults" in https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Continue reading on narkive:
Loading...