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.

Bug 209780 - @NamedServiceDefinition
Summary: @NamedServiceDefinition
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Tulach
Depends on:
Blocks: 200636
  Show dependency tree
Reported: 2012-03-20 10:00 UTC by Jaroslav Tulach
Modified: 2012-04-04 10:09 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

API, test and usage (33.58 KB, patch)
2012-03-20 10:00 UTC, Jaroslav Tulach
Details | Diff
Accepting most of the comments (43.75 KB, patch)
2012-03-24 00:02 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2012-03-20 10:00:42 UTC
Created attachment 116909 [details]
API, test and usage

JG04 from bug 200636 suggest making AbstractServiceProviderProcessor public. It functionality is indeed needed, but rather than opening up such infrastructure class, I want to expose a declarative way to use its functionality.

The attached patch defines the new meta annotation and shows how it simplifies creation of "named services" annotation on the example of @URLStreamHandlerRegistration.

@NamedServiceDefinition annotation will be used in @ModuleStart & co to be defined by bug 200636.
Comment 1 Jaroslav Tulach 2012-03-20 10:01:36 UTC
Y01 wrong issue number, should be 209780
Comment 2 Jesse Glick 2012-03-20 19:45:52 UTC
[JG01] searchAnnotations, findPath, etc. seem much too magical. While this issue is an interesting idea, I would recommend just exposing something like AbstractServiceProviderProcessor as an SPI, permitting subclasses to interpret various annotation attributes (and perform domain-specific validation) however they like, just as we do for LayerGeneratingProcessor. Other comments follow under the assumption you will reject this advice and choose the more complicated and less flexible approach.

[JG02] Javadoc for ServiceProvider.path should recommend the new API as a replacement.

[JG03] Javadoc is unclear whether @location or @location() is used.

[JG04] Javadoc is unclear how a String[] in the path is substituted (all variants registered?), or what a non-singleton Class[] for the serviceType would mean (disjunction?).

[JG05] AbstractServiceProviderProcessor should be moved into a (truly) private package, in which case the subclass checks are unnecessary.

[JG06] Stray System.err.println.

[JG07] Default value for position() attr may be unfriendly to Javadoc etc. Just use "-" for example (it cannot be an identifier). Or simply make "" be the default; I think it is no burden to specify position="position" if you have such an attribute and want to use it.

[JG08] Do not throw ISE from a processor. Use Messager.

[JG09] Do not use e.getAnnotation(c) & nsd.serviceType() as the types involved might not be loadable from the processing environment. 269 has more general APIs for inspecting Class-valued annotation members.
Comment 3 Jaroslav Tulach 2012-03-24 00:02:28 UTC
Created attachment 117186 [details]
Accepting most of the comments

Re. JG01 - yes, I'd rather prefer declarative approach to Turing completeness.

Implemented: JG02, JG03, JG04, JG06, JG07. As for the JG08, I've added more checks during processing of @NamedServiceDeclaration usage and I report errors using messager. If the same errors occur later during processing of the annotated annotations, I consider that (internal) error and still throw ISE.

Re. JG05 - that would be an incompatible change for openide.util. People might face it when using new version of openide.util.lookup and old openide.util. I'd rather keep the class where it is at least for one version.

Re. JG09 - I know there is AnnotationMirror, but I am not sure why it would be beneficial to use it in this case. If you can show me a sample that fails and requires advanced usage of annotations, I'll use them.
Comment 4 Jaroslav Tulach 2012-03-25 02:58:22 UTC
I'd like to integrate tomorrow.
Comment 5 Jaroslav Tulach 2012-03-26 11:11:24 UTC
Comment 6 Jesse Glick 2012-03-26 18:49:16 UTC
JG09 - not sure if it could cause a compilation failure, but might cause problems with in-IDE annotation processing. jlahoda would be able to tell you more precisely.

FWIW, known places where @SP.path is currently used but @NSD could be used instead:


Not clear whether bug #200636 will cover the WarmUp/java.lang.Runnable cases.

GrammarQueryManagers, UserCatalogs, and TaskList/Scanners are odd cases because there is no apparent reason why these are not just in Lookup.getDefault (i.e. null path); probably for historical reasons.
Comment 7 Quality Engineering 2012-03-27 17:00:36 UTC
Integrated into 'main-golden', will be available in build *201203271056* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #209780: Initial implementation including comments JG02, JG03, JG04, JG06, JG07
Comment 8 Quality Engineering 2012-04-04 10:09:53 UTC
Integrated into 'main-golden', will be available in build *201204040400* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #209780: Remind (well currently enforce) people to use @Retention and @Target