It's not too late for access control

[Gregg Wonderly]

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

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