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.bate...@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