Security hardening? The security manager already stops .setAccessible() if you want it to, and if you don't stop that, you have no security anyway, so there's no point. I do not understand the argument of '... blocking .setAccessible() from letting you access members from non-exported packages is better for security' at all.
With some more depth: On Sun, Nov 15, 2015 at 7:14 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > - put all your modules in the classpath or remove all the module-info from > the modules in the module-path, > - create a jlink plugin that will crawle all modules (or the ones you > want) and change the module-info, > - at runtime to create a new layer that will bypass the application > classloader and change the module configuration on-the-fly. > And there are more exotic ways if you are able to change the bytecodes. > Exactly. Exotic ways. These options sounds sufficiently user hostile that it'll slow JDK9 adoption significantly. A lot of them also don't sound like something that team jigsaw would want. For example, if most java deployments start dumping all the modules on the CP to get around this issue, then... what was the point of the module system in the first place? I'm trying to make the point: This COULD lead to the community en masse establishing some hacky workaround as 'the new normal' because libraries simply do not have the tools to become JDK9 ready in time (or ever). That sounds like something to be avoided. I don't understand the security element at all. The only way to cause security issues if .setAccessible() would let you break through exports requirements, is if untrusted code is allowed to run, in-process, on your own JVM in the first place*. There is NO WAY to have such code (untrusted, running in-process) be in any way or form safe unless a security manager is involved, and the security manager is _already_ set up to allow you to deny .setAccessible. *) Technically, you could have code that calls .setAccessible(true) on an element that is found based on untrusted user input, but this sounds like a very exotic case, is already a security nightmare both in JDK8 and even in a fully modularized JDK9 world; if we take as written that accessing any element of a non-exported package is a huge security leak, how is accessing private members of exported packages perfectly fine? That makes no sense either. --Reinier Zwitserloot
