Suggestion: allow accessible reflection on protected methods of exported types.

[Remi Forax]

What jigsaw downgrade is the reflection API, deep reflection now requires a module (or a package) to be open, that's true.
Reflection is not the only way to do monkey patching, agents can still do whatever they want and jigsaw also introduce new ways to do monkey patching with the Layer API.
By example, doing things like replacing a class by another is now far easier with jigsaw because you don't have to mess with class loading anymore.

and for JVM languages, being able to use jlink or jaotc worth the tradeoff in my opinion.

cheers,
Rémi

----- Mail original -----
> De: "Alessio Stalla" <alessiostalla at gmail.com>
> À: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Lundi 9 Janvier 2017 10:53:50
> Objet: Re: Suggestion: allow accessible reflection on protected methods of	exported types.

> Jochen, what you say resonates with me a lot too. And though I don't want
> to hijack the thread to a pointless Java-is-dying flame, I have to say one
> thing:
> Java won because of its (imperfect, but surprisingly usable and versatile)
> balance between static and dynamic. And lots of marketing, of course ;)
> Jigsaw is significantly altering that balance, and that has not been
> explicitly discussed. Everyone talks about security and encapsulation but
> nobody talks about loss of dynamicity - because, hey, Java is static, the
> more static the better, dynamic is bad, monkey patching is for monkey
> coders, boo! But, folks, reality check: there IS a significant slice of the
> community which thrives on the more dynamic sides of the JVM, and it is
> being completely ignored. You have the right to ignore it, but please say
> so explicitly: "we prefer to make the JVM a more static place and we do not
> care if we lose a part of the ecosystem. Please go doing your nasty dynamic
> stuff elsewhere."
> 
> Cheers,
> Alessio
> 
> On 3 January 2017 at 20:54, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> On 03/01/2017 18:13, Jochen Theodorou wrote:
>>
>>
>>> You sound as if there are equal good alternative solutions to all these
>>> cases. For example changing the environment for a subprocess after its
>>> creation.... No, there is no clean solution. The only solution that does
>>> not require an opens is to do it by custom native code.
>>>
>> Is this the issue with the rubygrapefruit library that there was a brief
>> discussion here about a few months ago, I think with Cedric Champeau? I was
>> hoping that this would be brought to core-libs-dev for discussion and
>> explore whether it would make sense for Process/ProcessBuilder to support.
>>
>> -Alan