> On Jul 14, 2016, at 6:51 AM, Andrew Haley <a...@redhat.com> wrote: > > On 14/07/16 11:28, Alan Bateman wrote: >>>> Yes, indeed, and that is potentially a significant problem. My >>>> comment stands: there is a serious possibility that his will make it >>>> impossible to use (non-exported) Jigsaw modules for some kinds of >>>> programming. This is exactly the kind of decision that needs all >>>> stakeholders to be consulted. >>>> >>>> It ought to be possible to have some kind of conditional export which >>>> only allows such access by (e.g.) suitably privileged frameworks or >>>> tools. But I have no desire to get involved in such design issues: I >>>> am only going to say that this is an issue which requires wider >>>> consultation. >>>> >> This is #ReflectiveAccessToNonExportedTypes on the JSR 376 issues list. >> The problem is reasonably well understood and there are several >> proposals and approaches being discussed and considered. > > Forgive me if I've missed something, but > #ReflectiveAccessToNonExportedTypes does not deal with the need to > make fields or methods accessible to the framework. That's what > setAccessible is used for. It would certainly be nice for a > framework to be able to say "make it accessible, but only to me.”
That is the question though. Why does it seem like a good idea to limit accessibility when there are so many other ways that the software can be exploited without this single limit being able to control all the others? Do you think that people would not decide to decompile your module definition and change all the details for visibility so that they can then do with it exactly as they need? In this day and age, and especially in the public software realm, control of anything does not exist in practicality. No matter what you believe might limit any aspect of your software, there is no way to categorically enforce that. Only on closed systems with all kinds of access control limits could you start to have some ability to limit what happens with/for the software use. Gregg
