On 08/12/15 16:47, Peter Levart wrote: > I have a scanner that can scan annotations of type X (by name) and >> member Y (by name) so it must use reflection to load the annotation and >> member. > > You can do that without readability of the target module. Apparently not, see my exception. > >> I got that when accessing the annotation's member Method: > > Ok, for invoking the method on annotation interface, you need > readability of the target module. That's it, yes. Well yes, if I don't invoke that annotation method I can't read its member values.
> Right, this is controversial. Some would say that when you have two > modules that depend on each other, none of them can exist without the > other, so why the split? At least one direction of the bi-directional > dependency should be "optional" then. I don't see it as controversial at all, and I also don't see cyclic modules as controversial at all, for the same reasons as class cycles are not controversial. They help maintainability by splitting classes and packages by functionality and possibly owners. We split interdependent classes and packages the same way. For example java.lang classes depend on java.util collections, which depend back on java.lang classes. If we can accept it for classes and packages, why not admit that it's the same with modules?
