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 <eric at tibco.com> 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 <eric at tibco.com> 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 of
common sense invested into jigsaw.

Now, can we go back to arguing about public vs package private?

/Claes