Hi, Putting my user's hat on, I'm interested in a solution which a) fulfils my desire to hide types internal to my implementation as much as possible (that's why I'm using a module system after all) and b) still is easy to use.
Looking at the proposal, I feel adding *un-qualified* dynamic exports goes against a) - every other module can access my internal types reflectively. b) is only partly addressed, too - I need to list all my internal packages (there may be many of them). Adding *qualified* dynamic exports addresses a) (only selected modules may access my internal types), but makes things worse for b) as I now need to list all my internal packages *and* the modules meant to access them. Tooling for generating the exports may help, but I feel that's dealing with symptoms rather than addressing the cause (1). Making internal types available to reflection by default as suggested before in this thread does address a) not at all, but b) very much. Personally, I find none of these solutions very compelling. A solution that'd address a) and b) would be a way for allowing me as a user to whitelist "trust-worthy modules" in one single spot. I.e. a global descriptor of sorts where I can say "export foo.internal.* to hibernate". I know Hibernate needs to use reflection, I'm ok with it doing this, but I want to express that fact only once in a single place, and using something like wildcards, for the sake of b). As the export is qualified, and if needed also could be given on a more fine-grained level, a) is addressed, too. Such descriptor should live on the application (not module) level for the sake of b) but also in order to allow for alignments with the specific runtime environment. E.g. a third party module might have been compiled with EclipseLink, while in my application I might want to use it with Hibernate. In container environments (Java EE), the container may create that descriptor to address all the requirements of all the modules a specific deployment is using to further simplify the user's life. I think such approach would help with exposing internal types as less as possible while still keeping things manageable for the user. --Gunnar (1) Btw. qualified exports with several targets (export foo to a, b) may be tough to deal with when it comes to different tools involved. E.g. two annotation processors, each aware of one such target requiring the export. If that could be given in two distinct export statements, that'd help as each tool than simply can add its entry rather than potentially updating an existing one. 2016-07-08 11:16 GMT+02:00 Alan Bateman <alan.bate...@oracle.com>: > > > On 08/07/2016 09:39, Sander Mak wrote: > >> That is, define your module-info's, possibly containing dynamic exports >> if your framework of choice does its magic through reflection. >> >> Right and there is nothing in this proposal that is specific to core > reflection either. The framework that I am using might be spinning bytecode > or maybe it switches to using method handles when there is a waning gibbous > moon - that's implementation detail that the user of the framework should > be oblivious too. > > -Alan >
