This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Everybody talks about the need of using Annotations instead of our current layers and lookup, etc. So it seems that the future is clear - NetBeans will be using annotations. The question of course is when and how to get there? I am known to prefer incremental improvements, and that is why I have a proposal to make lookup annotation ready. That way people will be able to use annotation on services and other elements registered in lookups and use such information to additional processing.
Created attachment 39609 [details] Changes in openide/util
Lookup.Item implements AnnotatedElement. By default it takes values from the class it returns - e.g. the values are going to be reasonably valid for MetainfServices lookup and other existing lookups. If the change is acceptable then I'd like to enhance FolderLookup to take the annotations for methodvalue defined objects from the annotations of the defining method. Also contrib/index-annotation on branch canthisworkwithlookup see http://www.netbeans.org/source/browse/contrib/indexed-annotations/?only_with_tag=canthisworkwithlookup should take advantage of Lookup.Item being AnnotatedElement. As 6.0 is first release that will support JDK 1.5, I believe it is the right time to make Lookup.Item implement AnnotatedElement, as this should not result in any compatiblity issues - the AnnotatedElement did not exist prior to 1.5 and as such there should be no clashes on binary level as each of the method has a type that could not be created when running on plain 1.4.
I don't see any background explaining what the goal of this change is. What do you expect people to use it for? I think a basic change in Lookup like this deserves a written proposal - what we have now, what we want to have, what steps we will take to get there.
#1 - This proposal is not yet ready for commit-I wanted to get early feedback #2 - As far the API usage goes I'd like this feature be used for example in URLStreamHandlerFactory: @interface URLProto{ String proto() } for (Item<USHF> i : Lookup.gD().lookupResult(USHF.class).allItems()) { URLProto p = i.getAnnotation(URLProto.class); if (p != null && !myProto.equals(p.proto()) { continue } // delegate as usual here } #3 - As the registration goes, I'd like the FolderLookup to understand: <file name="x.instance"><attr name="instanceCreate" methodvalue="x.m"/></file> class X { @URLProto("nbfs") public static USHF m() { ... } } #4 - future projects like contrib/indexed-annotation could provide even more efficient loading of annotations and create Lookup.Item without loading any class into VM
I think this is an interesting experiment but it would just add confusion to an already confusing mix if it were in trunk now. Would rather see a real proposal for what will happen to Lookup and the system filesystem, and a significant set of concrete use cases which will use any new techniques and be committed in the same IDE release.
Obsolete milestone, please reevaluate
We have gone a different direction (domain-specific annotation processors); I think this is obsolete.
I still like to see this done, but you are right, there is no tempting need right now.