Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Paul Benedict]

The argument I'm making is not just someone really wants to do this, but
that many people won't settle without it. Reflection has always been the
tool to dynamically achieve what the Java language can't always express
statically. IoC is built on the notion that language boundaries can and
should be broken to achieve magic-like behavior like injecting. Look all
over the EE spec and see how injection doesn't care what visibility
modifier you use... private methods and private fields are just as readable
and writable like public counterparts. Nothing wrong here, nothing broken
either.

The whole notion that people would turn to Containers to jailbreak a
feature smells of a poor design. I'd say it's analogous to how many
developers abandoned EJB 2 for Spring until EJB 3 spec leads finally
acknowledged what developers really wanted. I think the reaction to this
restriction is, in my opinion, going to lead to similar behavior of a mass
hunt and development for a better solution.

I really don't want to turn to Containers to escape this restriction. I
prefer the JDK correctly solve it using the Security Manager to prevent an
incongruous solution with the past. To be congruent should be about how the
Security Manager can be finely turned to restrict reflection on
non-exported types. Oracle can use it to protect JDK internals (if Oracle
wants to), but the world can go on doing the reflection it depends on now
without more (module) configuration.... I prefer less configuration, and
more convention, unless I have a security reason not to.

And what about non-EE containers using injection? I suppose they will need
a custom framework to make everything reflectable -- maybe Spring will help
out here to universalize a solution? I don't know. But I do know I don't
like controlling how reflection acts through a module descriptor. That's
clearly a responsibility of the Security Manager and this kind of external
control should continue to be built upon.

On Jul 9, 2016 3:01 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:

On 08/07/2016 22:42, Paul Benedict wrote:

:
>
>
> 2) Allow layers to control if non-exported types can be reflected. Perhaps
> the JDK sets its own layers to "false", but Containers and what they deploy
> can be separately configured, each.
>
>
> A container or anything else doing dynamic configuration today provides
the module finders and so gets an opportunity to re-write module
descriptors if it really wants to. So if someone really wants every module
in the configuration to export every package then it is possible. It's a
bit of effort of course but it seems better than introducting
inconsistencies into how core reflection does access checks vs. the VM and
method handles.

-Alan