Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[Andrew Dinn]

On 27/09/16 10:27, dalibor topic wrote:
> On 26.09.2016 18:37, Andrew Dinn wrote:

[snip]

>> I think those involved in this discussion already know all that you have
>> stated here regarding /what/ this project is doing. The present question
>> is /why/ is something that it is doing needed.
> 
> Paraphrasing, your question seems to be
> 
> "If A is true, why does B need to be true?"
> 
> whereas Alan's answer seems to be
> 
> "A is not universally true."

I'm not sure a truth-theoretic analysis quite captures the argument
correctly but ... it's nice to actually see someone begin to address the
original poster's question.

> So it appears that he answered this specific question by providing two
> counter examples:
> 
>   1. "no security manager at runtime", and
>   2. "no equivalent at compile time"
> 
> when A (i.e. being able to constrain access control using a security
> manager) can not be true.

You seem to be saying that Alan's argument (one that I am sorry I failed
to spot) is we can may already have a belt (security manager) but we can
also do with braces (jigsaw access restrictions) because you might
choose not to wear a belt and the braces would serve instead to cover
your modesty. That is indeed an argument and might be all that is needed
if choice of belt and/or braces were all one. Unfortunately, the
question of their efficacy and their potential for collateral hindrance
(as opposed to vertical benefit) that was at the heart of the original
question is still left unaddressed. Yes we could use braces instead of a
belt, but why do we /need/ braces when we can already wear a belt?

Stressing the optionality of wearing a belt does not really answer the
question as to whether the braces proffered as alternative improve on
our current options. Your argument could equally be used to deprecate
Jigsaw's (symmetrically optional) access restrictions as 'legacy' and,
instead, promote use of security managers. It certainly doesn't address
the clearly expressed feeling that Jigsaw might make important things
worse and, clearly, there is a strong feeling amongst some posters here
that it does make some things very much worse. Equally, it doesn't
present what makes Jigsaw better. As an example of the former, let's
note that although use of Jigsaw is also optional -- in that no one has
to package code as a module -- compared with the security manager model
the choice is no longer quite so flexible since it is not left in the
hands of the end user (i.e. a library jar published as a module leaves
no room for a consumer of that jar to redefine the accessibility without
rebuilding from a tweaked source). I am not saying that this difference
is a good or bad thing (after the changes made to support agent access I
no longer have a dog in this fight). Also, I'm not going to provide a
positive example to promote Jigsaw (I can think of several) because I
think it is really up to members of the Jigsaw project to do that and no
doubt they can do it more effectively than I can. The real point here is
that I don't think Alan's answer (as you present it above) is
satisfactory when such aspects of the original question have not been
addressed.

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