Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Jochen Theodorou]

On 16.07.2016 00:03, Alex Buckley wrote:

On 7/15/2016 6:21 AM, Jochen Theodorou wrote:

I will give you an analysis of my situation so far:

assuming the whole Groovy runtime is a module, and assuming I have other
modules as well, and then I want to use a Groovy script at runtime, to
access those modules. And let us assume those modules do not know of
Groovy. Let us further assume the Groovy runtime will be in a loader
that delegates to a loader knowing the classes of those modules, or is
in the same loader.

So first problem is ... can I use the unnamed module for the scripts?
They read every (named) module, thus they can access the types.
Next are 4 types of method invocations to consider for the case of  an
invocation from script in the unnamed module to named module:
reflective, indy, direct, generated bytecode for callsites (I name this
one csgen in short). The method itself is looked up by reflection

* for indy it is only a question of the lookup object, which will be
provided by the script and can do the call
* direct calls will work
* reflection would be done from the groovy runtime, thus the runtime
need to have a read on the named module. That´s the first time I will
need Java9 special code in this scenario
* csgen is more unclear. Let us assume it is in the unnamed package as
well, in a loader that delegates to the script loader. Basically it
becomes a direct call and works.

Next step is for my Groovy runtime having to call a method from the
script. Since everything is exported there is no problem on this side.
* indy will work after adding the read
* reflection - same
* direct call - same
* cs gen... the call to the csgen method will be done by an
interface/class of the Groovy runtime, and since the csgen class is in
the unnamed package, it has no problem calling the script methods.


With one exception, everything above is correct. (Exception: reflection
from the Groovy module to a named module, performed on behalf of the
script, does NOT need Java 9 code, because reflection gets readability
for free. Also, you mean that csgen code is in the unnamed MODULE; its
package is not so important.)


yes, my mistake, looks like I did not see it even the second or third 
time I did read through my post. Anyway, thanks for adding the part 
about reflection being able to read everything. I did forget that. This 
simplifies matters for the reflection part.



Key point: Just because a framework is delivered as a module, does not
mean the framework has to change its class loading behavior or require
that its plugins/scripts/introspectees be delivered as modules. Groovy
can continue to load scripts (or classes derived therefrom) into
user-defined loaders. The scripts can continue to access each other
(assuming suitable loader delegation) and Java platform APIs and Groovy
runtime APIs (assuming the Groovy module exports some packages).


Well, that is exactly what I am wondering about. Should we even go the 
module route or not? I did for example not attempt to make the runtime 
scripts modules, as I did not found need for actually doing that so far. 
And those runtime scripts are what you are talking about mostly. But 
people are supposed to be able to use precompiled Groovy as much as Java 
as possible. Not being able to make a module for Groovy code would be 
bad then. And if you have Java code, that depends on a library written 
in Groovy, do you really want to be blocked from making this a module, 
just because of that library being in Groovy? That will be bad for 
Groovy and the library.


Groovy is not like many JVM languages, in which you basically switch 
over into a new universe and have to do conversions and special things 
to go back to Java or use something of that language in Java. With the 
effect of staying in one universe as much as possible. Instead we target 
full integration. It is very common for us to switch between Groovy and 
Java all the time in the same program. That´s why a library written in 
Groovy is supposed to be usable from Java without quirks... and that 
includes the module system.


[...]

For creating named modules at run time, see the javadoc for
java.lang.reflect.Layer and all the linked javadoc down to
java.lang.module.ModuleDescriptor.Builder.


What if I have to make anamed module at runtime to realize a call that 
involves sibling layers? I do not see an answer to that in the javadoc. 
Not that I know if I would need that... but that is also information I 
do not have in the javadoc



You're right about indy calls and direct calls following readability, so
you can either have the script's module require another named module in
the Configuration that you pass to the Layer, or you can have the
script's own code add readability as you describe.


so far the named module version looks much more complicated...


Now for a pivot. All the issues you raise in the rest of this email,
about how named modules containing bytecode-derived-from-Groovy-source
interact with na

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[John Rose]

On Jul 14, 2016, at 3:25 PM, Jason Greene  wrote:
> 
> Not to sound like a broken record, but not all systems want the module to 
> control its own security. They want an intermediary.
> 
> And that's a perfectly fine and reasonable security model.


I agree, as long as the intermediary is highly predictable and accountable
in its violations of standard access rules.

And that's in the middle ground I'm talking about, where a module (or class)
is deemed (without direct delegation on its part) to extend trusted access to 
some
intermediary, which is generally trusted to do things on behalf of a broad 
range of
such modules (or classes).  It's middle ground (not the extreme of setA) because
(a) the intermediary would be more clearly marked as trusted (not just contain
a setA call somewhere in its guts), and (b) the task entrusted to the 
intermediary
would not require trusted access to all classes, but some well-defined "slice"
across a well-defined set of classes.

To reason about setA you have to predict the actions of a Turing machine,
as it assembles Class and String constants to pick out any API point whatever,
and then make a skeleton key for it.

A good framework makes those actions predictable, based on rules which
allow predictions based on the form of a program rather than the steps it
takes during execution.

Personally, I prefer the MethodHandles.Lookup API to setA (when I have
a choice between the two) because Lookup respects the existing access
control boundaries, while allowing delegation.  I think the data flow of
capabilities is easier to reason about than the data flow of random String
and Class values, followed by an unpredictable setA call.  But a Lookup
(today) must be created by the principal that owns the access rights,
which is what I think Jason is objecting to.

If we were to make some sort of middle ground between setA and Lookup,
it would look like a kind of Lookup that was obtained with upgraded access
(relative to publicLookup), but without direct creation by the target class.

In exchange for that power, there would be rules for limiting and configuring
the effect of such a Lookup.  For example, it might work only for API points
carrying a particular annotation.

You can build this sort of thing on top of setA of course, since setA is
basically root privileges.  My point is not that access rules should be
inviolate, but that exceptions to the rules should be as predictable and
even configurable as possible.

A final point:  Predictability and configurability leads to alternative
implementations, such as AOP-like injection of code at AOT time.
That's one of the promises of jlink.

HTH
— John

Re: It's not too late for access control

[Claes Redestad]

On 2016-07-16 01:16, Eric Johnson wrote:

Hmmm

On 7/15/16 1:10 PM, Claes Redestad wrote:

It's still perfectly possible to break through to non-exported
packages: it will simply require use of either new flags
(addExports/addReads, upgraded modules etc) or use of the newly added
extensions to the reflection API. And as has been stated again and
again elsewhere: setAccessible and friends are not going anywhere soon.

Let me play out an analogy: City upgrades the building codes. You as a
home owner are not required to upgrade to conform, unless:

  * house undergoes a significant, externally visible change
  * buy/sell transaction

(In other words, when the owner clearly demonstrates they likely have
the financial resources to conform.)

With JDK 9, however, we all know that JDK 8 will fall out of support.
Which means that changes in JDK 9 /must/ be accommodated by any project
/ product that wishes to maintain viability past the support window for
JDK 8. Except, given the maturity of the Java ecosystem, in most cases
most projects don't want to change, or fundamentally don't need to change.

So, based on what you're saying about the act of "simply require" a
small amount of new configuration, or a few code tweaks - JDK 9 is sort
of like having the building codes change, and being given a very short
window to conform - or be forced to move out.

I think that's where the "tea party" analogy that Gregg came up with
comes out. It feels like government usurpation. Maybe it is done with
the best of intentions - just like an upgrade to building codes might be
- but /forcing/ everyone to change is counterproductive.


Running with that analogy: most applications can opt out of "going
modular" and stick with putting everything on the classpath. Many
applications we run internally run just fine on JDK 9 without any 
modifications, and can likely continue to do so through many major 
releases to come. Sooner or later the opportunity cost of not upgrading

to a modular approach might grow too large, but I think most will
experience a more gentler pressure to upgrade than you're suggesting.

The obvious exception is of course those applications which ignored all
the warnings and use non-public internals - I guess the home owner
analogy equivalent would be someone hooking up to the power grid in
some unordained or illegal way: Should the government be blocked from
doing much-needed upgrades to the power grid for everyone since some
use unlicenced equipment? Would it be OK if they did so with some due
warning (major release)? Or should they be free to do whatever,
whenever (minor, patch or security release)?

/Claes

Re: It's not too late for access control

[Claes Redestad]

Jason,

On 2016-07-15 22:25, Jason T. Greene wrote:


Claes,

I ask that you take a look at the extensive arguments I have presented on the 
topic of reflection. The assumption you seem to make is that the use case of 
reflective access to internal packages  is wrong, poor programming practice, or 
an error.

That couldn't be further from the truth.


I'm refraining from such generalization - although I do take the view
that most reflective *and* static uses of JDK internals comes at a cost
and that replacing such uses with public - or at least officially
supported - APIs should be the preferred long term solution, since
it'll give the internals more leeway to change and improve.

I hope that you can somewhat agree with that, and that a platform which 
is able to evolve - be it by adding, changing or even removing code -

will live a healthier life in the long term.


The use cases are widely adopted by the industry, and they enable rich and 
powerful programming models that developers depend on.


I assume you're referring to some specific concern here, which I hope
can be discussed more in-depth either in a new thread or where it's
already been brought up.



I was personally hoping to be able to promote the jigsaw model to developers, 
but the technology as it is currently defined is insufficient to meet the 
demands of today, let alone tomorrow. I am still holding out hope this will be 
addressed,l.


There are surely open questions, and I too hope they can be addressed
in a manner satisfactory to most, if not all.

/Claes




On Jul 15, 2016, at 3:11 PM, Claes Redestad  wrote:




On 2016-07-15 20:24, Gregg Wonderly wrote:


On Jul 14, 2016, at 6:23 PM, Eric Johnson  wrote:

At least someone replied to my question.

On 7/14/16 5:44 AM, Russell Gold wrote:

On Jul 12, 2016, at 1:31 PM, Eric Johnson  wrote:

What infuriates me is that in all this discussion, I don't see anyone talking about a 
threat analysis. What are we trying to protect, from whom, and why? I see comments about 
how implementation details of the JRE (such as "com.sun" packages) must be 
hidden, but without reference to the threats that cause a problem.

It’s primarily a maintenance issue, IMO. It is common that we provide classes 
and methods that are intended to be used from elsewhere inside a product, but 
which we do not want users to see. That is, it is much the same as the reason 
you use “private” for class internals - if everything is publicly accessible, 
people use it, and you cannot refactor your code without breaking theirs.

If the entire aim is just a maintenance issue, then I assert that compiler 
changes should be sufficient. At that point, anyone who fires up runtime 
reflection to work around the compiler gets the benefits and the costs that 
they deserve. Benefits include the ability to leverage code in the guts of any 
library or the JRE that the authors decided they didn't want to publish. And 
they embrace the likelihood that it will break in the future.


More rigorous versioning could help mediate this so that when my introspecting 
code which works on JDK7 is deployed on JDK8, it would not run if I declared a 
version dependency on JDK7.  We currently have versioning that works with newer 
JDKs by default, without the ability to declare that only one JDK works.


http://openjdk.java.net/jeps/238 allows graceful transition from
introspecting code and other hacks to supported APIs in 9, 10 etc.



Believe me, I understand how ugly many people in the JDK development team feel 
it is for all this reflection to be done, and how responsible they seem to 
feel, given the direction JigSaw is going, to try and keep people from 
“breaking” their own software.  But practically, they are taking that risk.  
Leave them in the dust by ignoring their dependencies.  But, don’t shut the 
door on long term solutions evolving from that experimentation/introspection 
which allows the platform to become better because they help you understand 
that an API change is actually in order because there is a use case that was 
missed in the original JDK design.

What will happen if JigSaw is deployed as it is today, is that people will 
elect to use something else.  They literally will run as fast as they can to a 
“place” where participation is in their control, not some outside party.

Think of the Boston Tea Party.  From Hamilton lyrics, “Why should some tiny 
island on the other side of the world set the price of tea?”  Making the JDK 
seem like a King of overlord with all kinds of limits applied will make people 
really mad.  Also from Hamilton, “I’ll kill your family to remind you of my 
love” is sort of how people look at this kind of “control” and “overreach” of 
responsibility in software.   It’s like JDK-9 shuts down all kinds of 
responsibilities and totally disrupts interactions that used to feel friendly 
and inviting and instead makes them feel like a teach standing over you with a 
ruler, smacking your hand every time you

Re: It's not too late for access control

[dalibor topic]

On 15.07.2016 15:39, Jochen Theodorou wrote:

On 15.07.2016 14:55, dalibor topic wrote:
[...]
And if adopting the more correct practices requires them to make a huge
breaking change? Maybe even getting rid of base principles?


Commitment bias to accumulated technical debt is completely 
understandable. Unfortunately, it's also a bad guiding principle, as the 
nice picture of "shoveling forward" in 
http://ferd.ca/on-technical-debt-shoveling-forward.html illustrates.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +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

 Oracle is committed to developing
practices and products that help protect the environment

Re: It's not too late for access control

[Gregg Wonderly]

> On Jul 15, 2016, at 3:10 PM, Claes Redestad  wrote:
> 
> 
> 
> On 2016-07-15 20:24, Gregg Wonderly wrote:
>> 
>>> On Jul 14, 2016, at 6:23 PM, Eric Johnson  wrote:
>>> 
>>> At least someone replied to my question.
>>> 
>>> On 7/14/16 5:44 AM, Russell Gold wrote:
> On Jul 12, 2016, at 1:31 PM, Eric Johnson  wrote:
> 
> What infuriates me is that in all this discussion, I don't see anyone 
> talking about a threat analysis. What are we trying to protect, from 
> whom, and why? I see comments about how implementation details of the JRE 
> (such as "com.sun" packages) must be hidden, but without reference to the 
> threats that cause a problem.
 It’s primarily a maintenance issue, IMO. It is common that we provide 
 classes and methods that are intended to be used from elsewhere inside a 
 product, but which we do not want users to see. That is, it is much the 
 same as the reason you use “private” for class internals - if everything 
 is publicly accessible, people use it, and you cannot refactor your code 
 without breaking theirs.
>>> If the entire aim is just a maintenance issue, then I assert that compiler 
>>> changes should be sufficient. At that point, anyone who fires up runtime 
>>> reflection to work around the compiler gets the benefits and the costs that 
>>> they deserve. Benefits include the ability to leverage code in the guts of 
>>> any library or the JRE that the authors decided they didn't want to 
>>> publish. And they embrace the likelihood that it will break in the future.
>> 
>> More rigorous versioning could help mediate this so that when my 
>> introspecting code which works on JDK7 is deployed on JDK8, it would not run 
>> if I declared a version dependency on JDK7.  We currently have versioning 
>> that works with newer JDKs by default, without the ability to declare that 
>> only one JDK works.
> 
> http://openjdk.java.net/jeps/238  allows 
> graceful transition from
> introspecting code and other hacks to supported APIs in 9, 10 etc.
> 
>> 
>> Believe me, I understand how ugly many people in the JDK development team 
>> feel it is for all this reflection to be done, and how responsible they seem 
>> to feel, given the direction JigSaw is going, to try and keep people from 
>> “breaking” their own software.  But practically, they are taking that risk.  
>> Leave them in the dust by ignoring their dependencies.  But, don’t shut the 
>> door on long term solutions evolving from that experimentation/introspection 
>> which allows the platform to become better because they help you understand 
>> that an API change is actually in order because there is a use case that was 
>> missed in the original JDK design.
>> 
>> What will happen if JigSaw is deployed as it is today, is that people will 
>> elect to use something else.  They literally will run as fast as they can to 
>> a “place” where participation is in their control, not some outside party.
>> 
>> Think of the Boston Tea Party.  From Hamilton lyrics, “Why should some tiny 
>> island on the other side of the world set the price of tea?”  Making the JDK 
>> seem like a King of overlord with all kinds of limits applied will make 
>> people really mad.  Also from Hamilton, “I’ll kill your family to remind you 
>> of my love” is sort of how people look at this kind of “control” and 
>> “overreach” of responsibility in software.   It’s like JDK-9 shuts down all 
>> kinds of responsibilities and totally disrupts interactions that used to 
>> feel friendly and inviting and instead makes them feel like a teach standing 
>> over you with a ruler, smacking your hand every time you try and touch 
>> something they don’t want you to.
> 
> Sorry if this sounds rude, but it seems like you're all arguing some straw 
> man idea of jigsaw rather than the actual implementation,
> in addition to going slightly off-topic.
> 
> It's still perfectly possible to break through to non-exported
> packages: it will simply require use of either new flags
> (addExports/addReads, upgraded modules etc) or use of the newly added
> extensions to the reflection API. And as has been stated again and again 
> elsewhere: setAccessible and friends are not going anywhere soon.
> 
> Rather than an unfriendly or even despotic attempt to wrest control
> from free developer souls, I find it quite agreeable to give
> module/library/JDK authors a stronger way of saying "this is
> internal, please keep out". Unless there is a security manager
> prohibiting you, but hey, no change there.
> 
> What will break is the ability for libraries to go ahead and do this
> without explicit approval from the "deployer", application owner, user.

But, it’s impossible for this ability to be removed.  People will decompile 
modules, alter their declarations and make things accessible if they need 
access.  There is no hope that JigSaw mechanisms can keep people out of your 
code.  Once you release it, e

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Alex Buckley]

On 7/15/2016 6:21 AM, Jochen Theodorou wrote:

I will give you an analysis of my situation so far:

assuming the whole Groovy runtime is a module, and assuming I have other
modules as well, and then I want to use a Groovy script at runtime, to
access those modules. And let us assume those modules do not know of
Groovy. Let us further assume the Groovy runtime will be in a loader
that delegates to a loader knowing the classes of those modules, or is
in the same loader.

So first problem is ... can I use the unnamed module for the scripts?
They read every (named) module, thus they can access the types.
Next are 4 types of method invocations to consider for the case of  an
invocation from script in the unnamed module to named module:
reflective, indy, direct, generated bytecode for callsites (I name this
one csgen in short). The method itself is looked up by reflection

* for indy it is only a question of the lookup object, which will be
provided by the script and can do the call
* direct calls will work
* reflection would be done from the groovy runtime, thus the runtime
need to have a read on the named module. That´s the first time I will
need Java9 special code in this scenario
* csgen is more unclear. Let us assume it is in the unnamed package as
well, in a loader that delegates to the script loader. Basically it
becomes a direct call and works.

Next step is for my Groovy runtime having to call a method from the
script. Since everything is exported there is no problem on this side.
* indy will work after adding the read
* reflection - same
* direct call - same
* cs gen... the call to the csgen method will be done by an
interface/class of the Groovy runtime, and since the csgen class is in
the unnamed package, it has no problem calling the script methods.


With one exception, everything above is correct. (Exception: reflection 
from the Groovy module to a named module, performed on behalf of the 
script, does NOT need Java 9 code, because reflection gets readability 
for free. Also, you mean that csgen code is in the unnamed MODULE; its 
package is not so important.)


Key point: Just because a framework is delivered as a module, does not 
mean the framework has to change its class loading behavior or require 
that its plugins/scripts/introspectees be delivered as modules. Groovy 
can continue to load scripts (or classes derived therefrom) into 
user-defined loaders. The scripts can continue to access each other 
(assuming suitable loader delegation) and Java platform APIs and Groovy 
runtime APIs (assuming the Groovy module exports some packages).



Let us look at the same scenario with a named module for scripts. I will
use that as a step in between to think about actual compile time modules
written in Groovy. So for simplicity I assume I can create such a module
at runtime and it will export everything. How to do that? I have not the
slightest idea. Anyway, that means now I have calls from named script
module to named module:

* indy will work after the script module added a read to the target
module. This will require in the script, with a direct call to addReads,
because of caller sensitivity. Which means instead of just having JDK9
specific code in my runtime, I will now need JDK9 specific code to my
bytecode as well. And this needs to happen before any normal method
invocation can take place, thus static initializer, first thing... which
means completely new code for the compiler, that will work only on JDK9.
This means the compiler will then have to at least know if he compiles
for JDK9 or not...
* direct call - same
* reflection - the call is effectively done from the Groovy runtime, so
the Groovy runtime will have to add the read.
* csgen in the unnamed module means.. since the call is gated by an
interface/class from the runtime I assume I do not need a read edge from
the script module to the unnamed module csgen is in. The csgen class
then will be able to read the exported class of the target module, thus
has no problem.

Calls from the groovy runtime to the script are not different to before.


For creating named modules at run time, see the javadoc for 
java.lang.reflect.Layer and all the linked javadoc down to 
java.lang.module.ModuleDescriptor.Builder.


You're right about indy calls and direct calls following readability, so 
you can either have the script's module require another named module in 
the Configuration that you pass to the Layer, or you can have the 
script's own code add readability as you describe.


(For reflection, note again that the Groovy runtime does NOT have to add 
a read from its module to another named module.)


Now for a pivot. All the issues you raise in the rest of this email, 
about how named modules containing bytecode-derived-from-Groovy-source 
interact with named modules of the Groovy runtime or otherwise, are 
familiar. Why? Because Nashorn faced exactly the same issues. There will 
be a presentation at the JVM Language Summit (jvmlangsummit.com) on h

Re: It's not too late for access control

[Jason T. Greene]

Claes,

I ask that you take a look at the extensive arguments I have presented on the 
topic of reflection. The assumption you seem to make is that the use case of 
reflective access to internal packages  is wrong, poor programming practice, or 
an error.

That couldn't be further from the truth. The use cases are widely adopted by 
the industry, and they enable rich and powerful programming models that 
developers depend on. 

I was personally hoping to be able to promote the jigsaw model to developers, 
but the technology as it is currently defined is insufficient to meet the 
demands of today, let alone tomorrow. I am still holding out hope this will be 
addressed,l.

> On Jul 15, 2016, at 3:11 PM, Claes Redestad  wrote:
> 
> 
> 
>> On 2016-07-15 20:24, Gregg Wonderly wrote:
>> 
>>> On Jul 14, 2016, at 6:23 PM, Eric Johnson  wrote:
>>> 
>>> At least someone replied to my question.
>>> 
>>> On 7/14/16 5:44 AM, Russell Gold wrote:
> On Jul 12, 2016, at 1:31 PM, Eric Johnson  wrote:
> 
> What infuriates me is that in all this discussion, I don't see anyone 
> talking about a threat analysis. What are we trying to protect, from 
> whom, and why? I see comments about how implementation details of the JRE 
> (such as "com.sun" packages) must be hidden, but without reference to the 
> threats that cause a problem.
 It’s primarily a maintenance issue, IMO. It is common that we provide 
 classes and methods that are intended to be used from elsewhere inside a 
 product, but which we do not want users to see. That is, it is much the 
 same as the reason you use “private” for class internals - if everything 
 is publicly accessible, people use it, and you cannot refactor your code 
 without breaking theirs.
>>> If the entire aim is just a maintenance issue, then I assert that compiler 
>>> changes should be sufficient. At that point, anyone who fires up runtime 
>>> reflection to work around the compiler gets the benefits and the costs that 
>>> they deserve. Benefits include the ability to leverage code in the guts of 
>>> any library or the JRE that the authors decided they didn't want to 
>>> publish. And they embrace the likelihood that it will break in the future.
>> 
>> More rigorous versioning could help mediate this so that when my 
>> introspecting code which works on JDK7 is deployed on JDK8, it would not run 
>> if I declared a version dependency on JDK7.  We currently have versioning 
>> that works with newer JDKs by default, without the ability to declare that 
>> only one JDK works.
> 
> http://openjdk.java.net/jeps/238 allows graceful transition from
> introspecting code and other hacks to supported APIs in 9, 10 etc.
> 
>> 
>> Believe me, I understand how ugly many people in the JDK development team 
>> feel it is for all this reflection to be done, and how responsible they seem 
>> to feel, given the direction JigSaw is going, to try and keep people from 
>> “breaking” their own software.  But practically, they are taking that risk.  
>> Leave them in the dust by ignoring their dependencies.  But, don’t shut the 
>> door on long term solutions evolving from that experimentation/introspection 
>> which allows the platform to become better because they help you understand 
>> that an API change is actually in order because there is a use case that was 
>> missed in the original JDK design.
>> 
>> What will happen if JigSaw is deployed as it is today, is that people will 
>> elect to use something else.  They literally will run as fast as they can to 
>> a “place” where participation is in their control, not some outside party.
>> 
>> Think of the Boston Tea Party.  From Hamilton lyrics, “Why should some tiny 
>> island on the other side of the world set the price of tea?”  Making the JDK 
>> seem like a King of overlord with all kinds of limits applied will make 
>> people really mad.  Also from Hamilton, “I’ll kill your family to remind you 
>> of my love” is sort of how people look at this kind of “control” and 
>> “overreach” of responsibility in software.   It’s like JDK-9 shuts down all 
>> kinds of responsibilities and totally disrupts interactions that used to 
>> feel friendly and inviting and instead makes them feel like a teach standing 
>> over you with a ruler, smacking your hand every time you try and touch 
>> something they don’t want you to.
> 
> Sorry if this sounds rude, but it seems like you're all arguing some straw 
> man idea of jigsaw rather than the actual implementation,
> in addition to going slightly off-topic.
> 
> It's still perfectly possible to break through to non-exported
> packages: it will simply require use of either new flags
> (addExports/addReads, upgraded modules etc) or use of the newly added
> extensions to the reflection API. And as has been stated again and again 
> elsewhere: setAccessible and friends are not going anywhere soon.
> 
> Rather than an unfriendly or even despotic attempt to wrest control
>

Re: It's not too late for access control

[Claes Redestad]

On 2016-07-15 20:24, Gregg Wonderly wrote:



On Jul 14, 2016, at 6:23 PM, Eric Johnson  wrote:

At least someone replied to my question.

On 7/14/16 5:44 AM, Russell Gold wrote:

On Jul 12, 2016, at 1:31 PM, Eric Johnson  wrote:

What infuriates me is that in all this discussion, I don't see anyone talking about a 
threat analysis. What are we trying to protect, from whom, and why? I see comments about 
how implementation details of the JRE (such as "com.sun" packages) must be 
hidden, but without reference to the threats that cause a problem.

It’s primarily a maintenance issue, IMO. It is common that we provide classes 
and methods that are intended to be used from elsewhere inside a product, but 
which we do not want users to see. That is, it is much the same as the reason 
you use “private” for class internals - if everything is publicly accessible, 
people use it, and you cannot refactor your code without breaking theirs.

If the entire aim is just a maintenance issue, then I assert that compiler 
changes should be sufficient. At that point, anyone who fires up runtime 
reflection to work around the compiler gets the benefits and the costs that 
they deserve. Benefits include the ability to leverage code in the guts of any 
library or the JRE that the authors decided they didn't want to publish. And 
they embrace the likelihood that it will break in the future.


More rigorous versioning could help mediate this so that when my introspecting 
code which works on JDK7 is deployed on JDK8, it would not run if I declared a 
version dependency on JDK7.  We currently have versioning that works with newer 
JDKs by default, without the ability to declare that only one JDK works.


http://openjdk.java.net/jeps/238 allows graceful transition from
introspecting code and other hacks to supported APIs in 9, 10 etc.



Believe me, I understand how ugly many people in the JDK development team feel 
it is for all this reflection to be done, and how responsible they seem to 
feel, given the direction JigSaw is going, to try and keep people from 
“breaking” their own software.  But practically, they are taking that risk.  
Leave them in the dust by ignoring their dependencies.  But, don’t shut the 
door on long term solutions evolving from that experimentation/introspection 
which allows the platform to become better because they help you understand 
that an API change is actually in order because there is a use case that was 
missed in the original JDK design.

What will happen if JigSaw is deployed as it is today, is that people will 
elect to use something else.  They literally will run as fast as they can to a 
“place” where participation is in their control, not some outside party.

Think of the Boston Tea Party.  From Hamilton lyrics, “Why should some tiny 
island on the other side of the world set the price of tea?”  Making the JDK 
seem like a King of overlord with all kinds of limits applied will make people 
really mad.  Also from Hamilton, “I’ll kill your family to remind you of my 
love” is sort of how people look at this kind of “control” and “overreach” of 
responsibility in software.   It’s like JDK-9 shuts down all kinds of 
responsibilities and totally disrupts interactions that used to feel friendly 
and inviting and instead makes them feel like a teach standing over you with a 
ruler, smacking your hand every time you try and touch something they don’t 
want you to.


Sorry if this sounds rude, but it seems like you're all arguing some 
straw man idea of jigsaw rather than the actual implementation,

in addition to going slightly off-topic.

It's still perfectly possible to break through to non-exported
packages: it will simply require use of either new flags
(addExports/addReads, upgraded modules etc) or use of the newly added
extensions to the reflection API. And as has been stated again and again 
elsewhere: setAccessible and friends are not going anywhere soon.


Rather than an unfriendly or even despotic attempt to wrest control
from free developer souls, I find it quite agreeable to give
module/library/JDK authors a stronger way of saying "this is
internal, please keep out". Unless there is a security manager
prohibiting you, but hey, no change there.

What will break is the ability for libraries to go ahead and do this
without explicit approval from the "deployer", application owner, user.

Currently plenty of libraries take these freedoms on the behalf of that
guy or gal, who might not even be aware of the library authors decision
to cut corners. Some of these people might not think it's worth the
cost or risk of breaking future compatibility for some convenience, a
few points on a benchmark or whatever other reason.

As we're being emotional: I feel good about the way jigsaw brings
control back to the application owner to do more informed decisions and
to library authors to be more confident about evolving their code, and
hope that someday you will feel that there's actually a big deal o

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Gregg Wonderly]

> On Jul 14, 2016, at 6:51 AM, Andrew Haley  wrote:
> 
> On 14/07/16 11:28, Alan Bateman wrote:
 Yes, indeed, and that is potentially a significant problem.  My
 comment stands: there is a serious possibility that his will make it
 impossible to use (non-exported) Jigsaw modules for some kinds of
 programming.  This is exactly the kind of decision that needs all
 stakeholders to be consulted.
 
 It ought to be possible to have some kind of conditional export which
 only allows such access by (e.g.)  suitably privileged frameworks or
 tools.  But I have no desire to get involved in such design issues: I
 am only going to say that this is an issue which requires wider
 consultation.
 
>> This is #ReflectiveAccessToNonExportedTypes on the JSR 376 issues list. 
>> The problem is reasonably well understood and there are several 
>> proposals and approaches being discussed and considered.
> 
> Forgive me if I've missed something, but
> #ReflectiveAccessToNonExportedTypes does not deal with the need to
> make fields or methods accessible to the framework.  That's what
> setAccessible is used for.  It would certainly be nice for a
> framework to be able to say "make it accessible, but only to me.”

That is the question though.  Why does it seem like a good idea to limit 
accessibility when there are so many other ways that the software can be 
exploited without this single limit being able to control all the others?  Do 
you think that people would not decide to decompile your module definition and 
change all the details for visibility so that they can then do with it exactly 
as they need?  In this day and age, and especially in the public software 
realm, control of anything does not exist in practicality.  No matter what you 
believe might limit any aspect of your software, there is no way to 
categorically enforce that.

Only on closed systems with all kinds of access control limits could you start 
to have some ability to limit what happens with/for the software use.

Gregg 

Re: It's not too late for access control

[Gregg Wonderly]

> On Jul 14, 2016, at 6:23 PM, Eric Johnson  wrote:
> 
> At least someone replied to my question.
> 
> On 7/14/16 5:44 AM, Russell Gold wrote:
>>> On Jul 12, 2016, at 1:31 PM, Eric Johnson  wrote:
>>> 
>>> What infuriates me is that in all this discussion, I don't see anyone 
>>> talking about a threat analysis. What are we trying to protect, from whom, 
>>> and why? I see comments about how implementation details of the JRE (such 
>>> as "com.sun" packages) must be hidden, but without reference to the threats 
>>> that cause a problem.
>> It’s primarily a maintenance issue, IMO. It is common that we provide 
>> classes and methods that are intended to be used from elsewhere inside a 
>> product, but which we do not want users to see. That is, it is much the same 
>> as the reason you use “private” for class internals - if everything is 
>> publicly accessible, people use it, and you cannot refactor your code 
>> without breaking theirs.
> If the entire aim is just a maintenance issue, then I assert that compiler 
> changes should be sufficient. At that point, anyone who fires up runtime 
> reflection to work around the compiler gets the benefits and the costs that 
> they deserve. Benefits include the ability to leverage code in the guts of 
> any library or the JRE that the authors decided they didn't want to publish. 
> And they embrace the likelihood that it will break in the future.

More rigorous versioning could help mediate this so that when my introspecting 
code which works on JDK7 is deployed on JDK8, it would not run if I declared a 
version dependency on JDK7.  We currently have versioning that works with newer 
JDKs by default, without the ability to declare that only one JDK works.

Believe me, I understand how ugly many people in the JDK development team feel 
it is for all this reflection to be done, and how responsible they seem to 
feel, given the direction JigSaw is going, to try and keep people from 
“breaking” their own software.  But practically, they are taking that risk.  
Leave them in the dust by ignoring their dependencies.  But, don’t shut the 
door on long term solutions evolving from that experimentation/introspection 
which allows the platform to become better because they help you understand 
that an API change is actually in order because there is a use case that was 
missed in the original JDK design.

What will happen if JigSaw is deployed as it is today, is that people will 
elect to use something else.  They literally will run as fast as they can to a 
“place” where participation is in their control, not some outside party.

Think of the Boston Tea Party.  From Hamilton lyrics, “Why should some tiny 
island on the other side of the world set the price of tea?”  Making the JDK 
seem like a King of overlord with all kinds of limits applied will make people 
really mad.  Also from Hamilton, “I’ll kill your family to remind you of my 
love” is sort of how people look at this kind of “control” and “overreach” of 
responsibility in software.   It’s like JDK-9 shuts down all kinds of 
responsibilities and totally disrupts interactions that used to feel friendly 
and inviting and instead makes them feel like a teach standing over you with a 
ruler, smacking your hand every time you try and touch something they don’t 
want you to.

Gregg

Re: It's not too late for access control

[Sanne Grinovero]

On Fri, Jul 15, 2016 at 3:30 PM, Alan Bateman  wrote:
> On 15/07/2016 12:55, Sanne Grinovero wrote:
>
>> :
>> Hi Alan, you're spot-on about JEP-220: myself and my colleagues have
>> sent patches to numerous projects to which I normally don't contribute
>> to, just to fix our dependencies, such as Maven.
>
> Good to hear this.
>
>>
>> But please be aware of how many of the OSS projects in the Java
>> community are organised: some will have integration tests running in
>> modular environments, like WildFly which is based on David Lloyd's
>> JBoss Modules, or for OSGi tests it seems popular to use Apache Karaf.
>> Many others don't have any "modular" or "container" integration tests
>> and are not aware of what's coming.. since in my team we package some
>> of these for usage in modular environments, I'm painfully aware of
>> problems coming but it's no easy task to convince them for the need to
>> test now.
>
> I understand, we've found it hard in the past to get projects to test too.
> However, for JDK 9 then I see a lot more projects engaged and actively
> testing. As we've been saying at conferences for several years now, the
> changes in JDK 9 have a huge impact on the eco system, this update is not a
> JDK-only update.
>
>>
>> When I get in touch to try convey a sense of urgent need to test
>> Jigsaw, and sometimes successfully, then people realise that their
>> whole toolchain, not least the testing environment, blows up with
>> errors which are often too complex or simply too unrelated to the
>> project itself.
>
> There are folks working on several Oracle's products trying out JDK 9 builds
> too. A lot of issues that I hear about tend to be somewhat mundane but they
> are some complicated issues too - particularly around deploying upgraded
> versions of the components that overlap with what is the JDK (the EE modules
> and CORBA mostly).
>
>> So what happens is that such projects go to communities like WildFly
>> and OSGi for advice, where the typical answer is among the lines "I
>> know, we're discussing such things on the jigsaw-dev list, watch
>> thread XY, or watch #MyIssueCategory on Mark's blogs".
>>
>> In short, please be aware that David Lloyd isn't making such
>> suggestions just for WildFly itself, but is pre-processing and
>> summarising feedback from hundreds of projects there. The ones who
>> care are lurking on this list hoping to see answers for issues which
>> have been raised already, but not many feel competent enough to join
>> the conversation directly (and this might be a good thing!).
>
> Do you know if these hundreds of projects are really trying out modules?

The only one I know of is Hibernate Validator, Gunnar Morling has been
trying it:
 - http://in.relation.to/2016/06/17/bean-validation-and-the-jigsaw-liaison/

I'm not sure about all those other projects though, I personally deal
with only a fraction of them: we interact across projects on a need-be
case. (While Gunnar is on my same team).

My point was just that many of those developers - including often
myself - would reach out to David first rather than to this list, when
needing advice about modularity and classloading issues.

Thanks,
Sanne

>
> -Alan

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Remi Forax]

The problem of addRead being CallerSensitive can be solve by adding a way to 
add a read edge from a Lookup object ?

Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: "jigsaw-dev@openjdk.java.net >> jigsaw-dev" 
> Envoyé: Vendredi 15 Juillet 2016 15:21:01
> Objet: Re: Should setAccessible be part of Java or not? (was Re: It's not 
> too late for access control)
> 
> On 14.07.2016 23:24, Alan Bateman wrote:
> >
> >
> > On 14/07/2016 21:20, Jochen Theodorou wrote:
> >>
> >> What I would wish for at this moment is a document explaining the
> >> runtime aspects of the module system, including limitations reflection
> >> and normal method calls, as well as things like layers / runtime
> >> generated modules - as well as the methods to be used to create and
> >> change these. I don´t anything JLS ready here and just the behaviour
> >> of the one of the latest releases is also good. I cannot give feedback
> >> on a design I do not know. Because maybe some frameworks are content
> >> with the compile time side of this, I am not.
> >>
> > Jochen - have you worked through the documents, slides and recordings
> > that are linked from the main Project Jigsaw page [1]?
> >
> > I know in other threads we we alluded to slides on how
> > Nashorn/Javascript has been updated to work with modules (and spin
> > modules at runtime). I realize Groovy is different but I think we should
> > do this as it may be useful to other language implementers too.
> >
> > [1] http://openjdk.java.net/projects/jigsaw/
> 
> Well, I was hoping for a document, videos do not work well for me and
> slides are better, but often useless without the actual talk... depends
> of course
> 
> The problem is that this is a lot of material that barely scratches the
> points I am wondering about.
> 
> Example http://openjdk.java.net/projects/jigsaw/talks/
> 
> Javaone 2015
> Prepare for JDK 9 -> for me useless
> Introduction to Modular Development -> for runtime aspects useless
> Advanced Modular Development -> mentions addReads on slide 36 and is
> done with the runtime aspect with that basically.
> Project Jigsaw: Under the Hood -> is more interesting from slide 34 on,
> but does not answer my questions enough.
> Project Jigsaw Hack Session -> the whole thing as video
> 
> Devoxx BE 2015 is only video
> 
> I will give you an analysis of my situation so far:
> 
> assuming the whole Groovy runtime is a module, and assuming I have other
> modules as well, and then I want to use a Groovy script at runtime, to
> access those modules. And let us assume those modules do not know of
> Groovy. Let us further assume the Groovy runtime will be in a loader
> that delegates to a loader knowing the classes of those modules, or is
> in the same loader.
> 
> So first problem is ... can I use the unnamed module for the scripts?
> They read every (named) module, thus they can access the types.
> Next are 4 types of method invocations to consider for the case of  an
> invocation from script in the unnamed module to named module:
> reflective, indy, direct, generated bytecode for callsites (I name this
> one csgen in short). The method itself is looked up by reflection
> 
> * for indy it is only a question of the lookup object, which will be
> provided by the script and can do the call
> * direct calls will work
> * reflection would be done from the groovy runtime, thus the runtime
> need to have a read on the named module. That´s the first time I will
> need Java9 special code in this scenario
> * csgen is more unclear. Let us assume it is in the unnamed package as
> well, in a loader that delegates to the script loader. Basically it
> becomes a direct call and works.
> 
> Next step is for my Groovy runtime having to call a method from the
> script. Since everything is exported there is no problem on this side.
> * indy will work after adding the read
> * reflection - same
> * direct call - same
> * cs gen... the call to the csgen method will be done by an
> interface/class of the Groovy runtime, and since the csgen class is in
> the unnamed package, it has no problem calling the script methods.
> 
> Let us look at the same scenario with a named module for scripts. I will
> use that as a step in between to think about actual compile time modules
> written in Groovy. So for simplicity I assume I can create such a module
> at runtime and it will export everything. How to do that? I have not the
> slightest idea. Anyway, that means now I have calls from named script
> module to named module:
> 
> * indy will work after the script module added a read to the target
> module. This will require in the script, with a direct call to addReads,
> because of caller sensitivity. Which means instead of just having JDK9
> specific code in my runtime, I will now need JDK9 specific code to my
> bytecode as well. And this needs to happen before any normal method
> invocation can take place, thus static initializer, first thing... which
> means completely new code for the co

Re: It's not too late for access control

[Alan Bateman]

On 15/07/2016 12:55, Sanne Grinovero wrote:


:
Hi Alan, you're spot-on about JEP-220: myself and my colleagues have
sent patches to numerous projects to which I normally don't contribute
to, just to fix our dependencies, such as Maven.

Good to hear this.



But please be aware of how many of the OSS projects in the Java
community are organised: some will have integration tests running in
modular environments, like WildFly which is based on David Lloyd's
JBoss Modules, or for OSGi tests it seems popular to use Apache Karaf.
Many others don't have any "modular" or "container" integration tests
and are not aware of what's coming.. since in my team we package some
of these for usage in modular environments, I'm painfully aware of
problems coming but it's no easy task to convince them for the need to
test now.
I understand, we've found it hard in the past to get projects to test 
too. However, for JDK 9 then I see a lot more projects engaged and 
actively testing. As we've been saying at conferences for several years 
now, the changes in JDK 9 have a huge impact on the eco system, this 
update is not a JDK-only update.




When I get in touch to try convey a sense of urgent need to test
Jigsaw, and sometimes successfully, then people realise that their
whole toolchain, not least the testing environment, blows up with
errors which are often too complex or simply too unrelated to the
project itself.
There are folks working on several Oracle's products trying out JDK 9 
builds too. A lot of issues that I hear about tend to be somewhat 
mundane but they are some complicated issues too - particularly around 
deploying upgraded versions of the components that overlap with what is 
the JDK (the EE modules and CORBA mostly).


So what happens is that such projects go to communities like WildFly
and OSGi for advice, where the typical answer is among the lines "I
know, we're discussing such things on the jigsaw-dev list, watch
thread XY, or watch #MyIssueCategory on Mark's blogs".

In short, please be aware that David Lloyd isn't making such
suggestions just for WildFly itself, but is pre-processing and
summarising feedback from hundreds of projects there. The ones who
care are lurking on this list hoping to see answers for issues which
have been raised already, but not many feel competent enough to join
the conversation directly (and this might be a good thing!).

Do you know if these hundreds of projects are really trying out modules?

-Alan

Re: It's not too late for access control

[Alan Bateman]

On 15/07/2016 13:55, dalibor topic wrote:


:


I can't say what other OSGi frameworks are doing, but for example
testing Hibernate in OSGi requires Apache Karaf, which is stuck on
issues like:
 - https://issues.apache.org/jira/browse/KARAF-3518


Judging by http://markmail.org/message/6v3kiqabebwtuwpv they use the 
endorsed standards mechanism to override non-endorsed classes.
If I read this correctly then they are attempting to override 
java.lang.Exception for some reason. That "worked" because the legacy 
endorsed standard override mechanism was essentially -Xbootclasspath/p.


For debugging purposes then  way to override a class in a module is 
-Xpatch (or --patch-module with the new option). In this case, it would 
be `--patch-module java.base=myexception.jar` although I don't expect it 
will work (at either compile-time or run-time) because code in java.base 
can't link to code in java.xml.bind (JAXB). They will need 
`--add-modules java.xml.bind --add-reads java.base=java.xml.bind` and 
additionally -Xmodule:java.base at compile-time.


As regards the endorsed standard override mechanism then it has been 
removed in JDK 9. It was deprecated in a MR of JSR 337. Also 
-XX:+CheckEndorsedAndExtDirs is documented in the release notes for JDK 
8 updates as a quick way to have the VM fail at startup if you are 
(unknowing) using this or the legacy extension mechanism.


-Alan

Re: It's not too late for access control

[Jochen Theodorou]

On 15.07.2016 14:55, dalibor topic wrote:
[...]

A large part of what we do initially within the Quality Outreach effort
is to help open source projects understand problems with their own code
and practices that can adversely affect their ability to migrate to new
JDK (update) releases as they start testing against JDK 9 and discover
one or more issues with their code.


And if adopting the more correct practices requires them to make a huge 
breaking change? Maybe even getting rid of base principles?


bye Jochen

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Jochen Theodorou]

On 14.07.2016 23:24, Alan Bateman wrote:



On 14/07/2016 21:20, Jochen Theodorou wrote:


What I would wish for at this moment is a document explaining the
runtime aspects of the module system, including limitations reflection
and normal method calls, as well as things like layers / runtime
generated modules - as well as the methods to be used to create and
change these. I don´t anything JLS ready here and just the behaviour
of the one of the latest releases is also good. I cannot give feedback
on a design I do not know. Because maybe some frameworks are content
with the compile time side of this, I am not.


Jochen - have you worked through the documents, slides and recordings
that are linked from the main Project Jigsaw page [1]?

I know in other threads we we alluded to slides on how
Nashorn/Javascript has been updated to work with modules (and spin
modules at runtime). I realize Groovy is different but I think we should
do this as it may be useful to other language implementers too.

[1] http://openjdk.java.net/projects/jigsaw/


Well, I was hoping for a document, videos do not work well for me and 
slides are better, but often useless without the actual talk... depends 
of course


The problem is that this is a lot of material that barely scratches the 
points I am wondering about.


Example http://openjdk.java.net/projects/jigsaw/talks/

Javaone 2015
Prepare for JDK 9 -> for me useless
Introduction to Modular Development -> for runtime aspects useless
Advanced Modular Development -> mentions addReads on slide 36 and is 
done with the runtime aspect with that basically.
Project Jigsaw: Under the Hood -> is more interesting from slide 34 on, 
but does not answer my questions enough.

Project Jigsaw Hack Session -> the whole thing as video

Devoxx BE 2015 is only video

I will give you an analysis of my situation so far:

assuming the whole Groovy runtime is a module, and assuming I have other 
modules as well, and then I want to use a Groovy script at runtime, to 
access those modules. And let us assume those modules do not know of 
Groovy. Let us further assume the Groovy runtime will be in a loader 
that delegates to a loader knowing the classes of those modules, or is 
in the same loader.


So first problem is ... can I use the unnamed module for the scripts? 
They read every (named) module, thus they can access the types.
Next are 4 types of method invocations to consider for the case of  an 
invocation from script in the unnamed module to named module: 
reflective, indy, direct, generated bytecode for callsites (I name this 
one csgen in short). The method itself is looked up by reflection


* for indy it is only a question of the lookup object, which will be 
provided by the script and can do the call

* direct calls will work
* reflection would be done from the groovy runtime, thus the runtime 
need to have a read on the named module. That´s the first time I will 
need Java9 special code in this scenario
* csgen is more unclear. Let us assume it is in the unnamed package as 
well, in a loader that delegates to the script loader. Basically it 
becomes a direct call and works.


Next step is for my Groovy runtime having to call a method from the 
script. Since everything is exported there is no problem on this side.

* indy will work after adding the read
* reflection - same
* direct call - same
* cs gen... the call to the csgen method will be done by an 
interface/class of the Groovy runtime, and since the csgen class is in 
the unnamed package, it has no problem calling the script methods.


Let us look at the same scenario with a named module for scripts. I will 
use that as a step in between to think about actual compile time modules 
written in Groovy. So for simplicity I assume I can create such a module 
at runtime and it will export everything. How to do that? I have not the 
slightest idea. Anyway, that means now I have calls from named script 
module to named module:


* indy will work after the script module added a read to the target 
module. This will require in the script, with a direct call to addReads, 
because of caller sensitivity. Which means instead of just having JDK9 
specific code in my runtime, I will now need JDK9 specific code to my 
bytecode as well. And this needs to happen before any normal method 
invocation can take place, thus static initializer, first thing... which 
means completely new code for the compiler, that will work only on JDK9. 
This means the compiler will then have to at least know if he compiles 
for JDK9 or not...

* direct call - same
* reflection - the call is effectively done from the Groovy runtime, so 
the Groovy runtime will have to add the read.
* csgen in the unnamed module means.. since the call is gated by an 
interface/class from the runtime I assume I do not need a read edge from 
the script module to the unnamed module csgen is in. The csgen class 
then will be able to read the exported class of the target module, thus 
has no problem.

Re: It's not too late for access control

[dalibor topic]

On 15.07.2016 13:55, Sanne Grinovero wrote:

So what happens is that such projects go to communities like WildFly
and OSGi for advice, where the typical answer is among the lines "I
know, we're discussing such things on the jigsaw-dev list, watch
thread XY, or watch #MyIssueCategory on Mark's blogs".


Please also ask them to the Quality Outreach effort, as well and send 
them my or Rory's way.



summarising feedback from hundreds of projects there. The ones who
care are lurking on this list hoping to see answers for issues which
have been raised already, but not many feel competent enough to join
the conversation directly (and this might be a good thing!).


(Breaking the fourth wall)

If you're lurking on this list, are a lead developer on a popular open 
source project, and aren't listed on 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach yet, 
please get in touch with me to get listed there and start testing your 
project with JDK 9 Early Access builds, letting us know about things 
that don't work as they should.



interests of all such users. Not sure if you want us to organise a
storm of "+1" emails as I'm confident that reason will win over
spamming strategies and populism (or should I say "modern democracy").


I don't think that would be a productive use of anyone's resources.


I can't say what other OSGi frameworks are doing, but for example
testing Hibernate in OSGi requires Apache Karaf, which is stuck on
issues like:
 - https://issues.apache.org/jira/browse/KARAF-3518


Judging by http://markmail.org/message/6v3kiqabebwtuwpv they use the 
endorsed standards mechanism to override non-endorsed classes. That's 
not how the Java Endorsed Standards Override Mechanism
works - please see 
http://docs.oracle.com/javase/8/docs/technotes/guides/standards/ for 
details.


A large part of what we do initially within the Quality Outreach effort 
is to help open source projects understand problems with their own code 
and practices that can adversely affect their ability to migrate to new 
JDK (update) releases as they start testing against JDK 9 and discover 
one or more issues with their code.


cheers,
dalibor topic

--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +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

 Oracle is committed to developing
practices and products that help protect the environment

Re: It's not too late for access control

[Sanne Grinovero]

On Tue, Jul 12, 2016 at 9:25 PM, Alan Bateman  wrote:
> On 12/07/2016 18:31, Sanne Grinovero wrote:
>
>> :
>> As a maintainer and contributor to several popular Java open source
>> libraries my experience is that in practice very few existing
>> libraries will "just work" in Java 9 out of the box: people will have
>> to update their code. This is based on my experience, as some of these
>> projects have dozens of dependencies and it's taking a long time to
>> identify each problematic point, discuss patches, getting other
>> communities to release timely, an often there is need for "recursive
>> releases" and various iterations for each problem as they get
>> identified, for each dependency.
>
> Going off-topic slightly but when you do run into issues and if they aren't
> already listed as compatibility issues then please bring them up. So far
> then I think the vast majority of issues that we have heard about relate to
> the changes in JEP 220 (tools.jar going away etc), JEP 223 and the new
> version-string scheme, the class file version bump in jdk-9+119, and then
> all the issues that we have listed in JEP 261. Any help getting bugs
> submitted to projects would be appreciated too.
>
> The issue that `public` no longer implies accessible is listed in JEP 261
> (first item in the Risks and Assumption) but to be honest, has barely come
> up to date. That probably isn't too surprising as it's still early days for
> modules and many projects aren't trying out JDK 9 yet. Anyone trying out
> modules where a "module unaware" framework gets a reference to a public type
> in a non-exported package might run into it of course but I'm not aware of
> any reports yet.


Hi Alan, you're spot-on about JEP-220: myself and my colleagues have
sent patches to numerous projects to which I normally don't contribute
to, just to fix our dependencies, such as Maven.

But please be aware of how many of the OSS projects in the Java
community are organised: some will have integration tests running in
modular environments, like WildFly which is based on David Lloyd's
JBoss Modules, or for OSGi tests it seems popular to use Apache Karaf.
Many others don't have any "modular" or "container" integration tests
and are not aware of what's coming.. since in my team we package some
of these for usage in modular environments, I'm painfully aware of
problems coming but it's no easy task to convince them for the need to
test now.

When I get in touch to try convey a sense of urgent need to test
Jigsaw, and sometimes successfully, then people realise that their
whole toolchain, not least the testing environment, blows up with
errors which are often too complex or simply too unrelated to the
project itself.

So what happens is that such projects go to communities like WildFly
and OSGi for advice, where the typical answer is among the lines "I
know, we're discussing such things on the jigsaw-dev list, watch
thread XY, or watch #MyIssueCategory on Mark's blogs".

In short, please be aware that David Lloyd isn't making such
suggestions just for WildFly itself, but is pre-processing and
summarising feedback from hundreds of projects there. The ones who
care are lurking on this list hoping to see answers for issues which
have been raised already, but not many feel competent enough to join
the conversation directly (and this might be a good thing!).

Some other hundred of projects are relying on Andrew Dinn's project
Byteman for testing, they have also been concerned but didn't back
Dinn's proposals explicitly on this list as we feel he represents the
interests of all such users. Not sure if you want us to organise a
storm of "+1" emails as I'm confident that reason will win over
spamming strategies and populism (or should I say "modern democracy").

I can't say what other OSGi frameworks are doing, but for example
testing Hibernate in OSGi requires Apache Karaf, which is stuck on
issues like:
 - https://issues.apache.org/jira/browse/KARAF-3518

(I've talked again with some friends in the Karaf team last week and
they will try again now, but you get the point that people are waiting
rather than reporting here)

Clearly some projects are waiting for alternatives and answers to be
provided before proposing their own solutions. As an example,
personally I'm on the Hibernate team and we're very interested to see
how reflective access is going to work, but since Jason Greene
summarised our concerns very well already on a different thread, I'll
just let you know that we stand behind this and feel no need to add
further details.. I hope it's clear though that such things need to be
answered before we can decide how to test things further, and I
wouldn't expect large numbers of complaints from all other projects:
as these platforms are waiting for answers to very concrete issues,
there's a bottleneck and you probably won't see feedback on the
smaller issues either, as there's no much progress in testing until
Jigsaw brings some clarity and concrete solution

Re: It's not too late for access control

[dalibor topic]

On 14.07.2016 15:44, Robert Muir wrote:

So I just sense some trouble around this stuff for java 9: and some
users won't care if its jigsaw or a versioning change or whatever, it
just won't work for them.


Yeah, there is a lot more than just the changes within this Project that 
can affect code migrating to JDK 9.


I maintain a list of things to consider at 
https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach and would 
welcome suggestions for improving and expanding that list over on the 
adoption-discuss mailing list.


cheers,
dalibor topic


--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +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

 Oracle is committed to developing
practices and products that help protect the environment