Bug 209780 - @NamedServiceDefinition
@NamedServiceDefinition
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Lookup
7.2
All All
: P3 (vote)
: 7.2
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks: 200636
  Show dependency treegraph
 
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
:


Attachments
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
http://hg.netbeans.org/ergonomics/rev/f9ebf6d55b55
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:

ant.grammar/build/classes/META-INF/namedservices/Plugins/XML/GrammarQueryManagers/org.netbeans.modules.xml.api.model.GrammarQueryManager
autoupdate.pluginimporter/build/classes/META-INF/namedservices/WarmUp/java.lang.Runnable
core.ui/build/classes/META-INF/namedservices/WarmUp/java.lang.Runnable
hudson.maven/build/classes/META-INF/namedservices/Plugins/XML/UserCatalogs/org.netbeans.modules.xml.catalog.spi.CatalogReader
hudson.tasklist/build/classes/META-INF/namedservices/TaskList/Scanners/org.netbeans.spi.tasklist.PushTaskScanner
java.editor/build/classes/META-INF/namedservices/WarmUp/java.lang.Runnable

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 http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c78ef1210520
User: Jaroslav Tulach <jtulach@netbeans.org>
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 http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ec301ca4a477
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #209780: Remind (well currently enforce) people to use @Retention and @Target


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo