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

[Andrew Dinn]

On 09/01/17 09:53, Alessio Stalla wrote:
> 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."

If you carefully review discussion on the subject of this (slightly
false) dichotomy between static and dynamic capabilities I think you
will find that there has been a lot of explicit discussion. In my view,
your summary of the status quo is at best out of date and at worst
misrepresents the goals of the Jigsaw project and the wider goals of the
OpenJDK project as a whole.

There is indeed a desire to limit opportunities for programs to rely on
reflection. That desire is linked to the motivation for implementing
Jigsaw. Reflection as it was provided in JDK8- does not really fit well
with /the/ main goal of modularization i.e. ensuring that module
internals -- in particular, JDK runtime internals -- can be guaranteed
to remain private to client code. The concern is wider than simply
meeting this Jigsaw requirement. That guarantee is critical to ensuring
that module implementations, most especially JDK runtime modules
implementations, can be maintained, extended and optimized without
breaking backward compatibility. Some breakage now is being traded off
against breakage later.

This change to reflective accessibility is not simply a wholesale
removal of capability. It is being balanced by a mix of completed and
in-progress changes which i) allow suitably privileged code (such as
agents or containers) to enable reflective access where they see fit and
ii) provide an alternative mechanism to achieve the same end result as
reflection but instead based on method handles. The latter alternative
is especially important as it will ensure more precisely controlled and
recorded access and, as one very important consequence, enable better
performance from the compiler(s).

There have also been many other changes made to ensure that Jigsaw
supports other important aspects of dynamic programs. the Layer API in
particular has been extended significantly to allow greater control over
loading and linking of dynamically deployed modules, including support
for undeploying and redeploying modular code (as required by e.g. EE
containers). You might want to look over the archives of discussions on
the JSR expert group, observers and comments mail lists to review all
these proposed changes in full or maybe even sign up to the last of
these lists in order to monitor progress on work that still remains to
be completed.

  http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
  http://mail.openjdk.java.net/pipermail/jpms-spec-observers/
  http://mail.openjdk.java.net/pipermail/jpms-spec-comments/


regards,


Andrew Dinn
-----------