No cycle is a property checked at compile time not at runtime. Having cycles at runtime is not a big deal, when have cyclic class dependencies since a long time now, At compile time, it's problematic because it means that you have to compile both modules at the same time defeating the idea that a module is a sigle compilation unit.
Rémi ----- Mail original ----- > De: "Stephane Epardaud" <[email protected]> > À: [email protected] > Envoyé: Mardi 8 Décembre 2015 15:59:26 > Objet: Re: Is there really a jdk.proxy1 module? > > Actually no, I've found that insted of accessing the proxy class > directly I should just access the proxied annotation class and it works. > > Thanks anyway. > > Except now I have to add a read to scan annotations of another module, > which naturally introduces a cycle. This can't be right. Suppose I've a > Framework module "F" and an app "A" which reads "F" (since it works for > that framework). Now when that framework scans annotations in "A" it > can't use reflection to access them because it doesn't read "A"? > > Funny thing is I can add the read and it doesn't complain about cycles, > not sure why. >
