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

Andrew Dinn adinn at redhat.com
Thu Jul 14 08:59:57 UTC 2016


On 13/07/16 17:00, Alan Bateman wrote:
> On 13/07/2016 12:47, David M. Lloyd wrote:
>> Isn't that what this entire thread is about?  And also, what the whole
>> #ReflectiveAccessToNonExportedTypes issue is about? 
> I think that's a good question, esp as some frameworks allow for
> annotations or configuration on non-public types or members. The
> `exports dynamic` proposal on the #ReflectiveAccessToNonExportedTypes
> thread exports the package at runtime and so allows the slimy
> setAccessible(true) to break in. In the very long term then
> setAccessible needs to go away of course but I do think non-public types
> in non-exported packages is part of the discussion too.

Alan, you previously described setAccessible as a 'sledge hammer that
breaks down the door' and now resort to calling it 'slimy'. Clearly, you
don't think much of this API. However, I'll put aside the
appropriateness of such descriptions in order to challenge the assertion
that it 'needs to go away'.

Does it? Why and on whose say so? This is a pretty significant change to
the nature of the runtime that you are talking about. It removes a
capability that is critical to certain important types of program
operation and which has been used by many tools and libraries in
previous JDK releases. If removing this API is an agreed long term goal
of Jigsaw then where is the discussion to justify that goal? Have you
established that Java users actually want a JDK which does not provide
this means of privileged access? I don't see any such agreement in the
EG archive, for example.

My agent has very good reason to want to do precisely what you wish to
eject from the runtime. I have many users who rely on this ability to be
able to test, monitor and debug their applications. Without this API a
great deal of testing becomes very difficult or even impossible,
Likewise, without it the job of many of Red Hat's support staff and
consultants will be severely compromised.

If this aspect of how Java currently works is to be removed then I
believe it needs to be done so on the basis of a publicly established
consensus, preferably under the aegis of the JSR EG. It certainly does
not seem right to me that  such a goal should be adopted by an
implementation team without such consultation.

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


More information about the jigsaw-dev mailing list