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 <claes.redestad at oracle.com> wrote:
>>
>>
>>
>>> 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