Hi Am 16.04.2012 um 06:29 schrieb Mark Derricutt:
> +1 for RetentionPolicy.RUNTIME if that change was on the cards ( also > upstream OSGi spec change ). Retention will be CLASS not RUNTIME. And the OSGi spec is not doing RUNTIME, either. Because the OSGi spec is targeted at tooling and not runtime support. The reason for not using the annotations at runtime is performance: With annotations on class files we have to scan all class files for annotations .. not the best thing to do in terms of performance. > > The other day I was trying to integrate Guice IOC with some of our > classes which use @Reference's, if the annotation was runtime I would > have been sweet and could have attached them simply into Guice, but alas > no :( Well, the goal and use case of our annotations is support DS descriptor tooling. If you want to use it for GUICE integration you may fail in the future because you depend on something which does not have (and will probably never have) your use case in mind. Regards Felix > > > > > On 14/04/12 1:03 AM, Robert Munteanu wrote: >> Hi Caspar, >> >> Thanks for your reply. I've glanced over >> http://www.osgi.org/download/osgi-early-draft-2011-09.pdf and noticed that >> the annotations are defined with @Retention(value=RetentionPolicy.CLASS) . >> I've also found that the same will happen with the SCR annotations from >> Felix in the next release ( https://issues.apache.org/jira/browse/FELIX-3247 >> ) . >> >> That means that the annotations will not be available at runtime, so I will >> not be able to configure components by myself in unit tests. I assume that >> Felix annotations will follow the official ones, so it makes little sense to >> argue for making them available at runtime. >> >> Robert >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
