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.
| Summary: | @MIMEResolver.Registration and related should specify @Target(ElementType.PACKAGE) | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jesse Glick <jglick> |
| Component: | Filesystems | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | apireviews |
| Priority: | P2 | Keywords: | API_REVIEW |
| Version: | 7.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 207960, 191777 | ||
|
Description
Jesse Glick
2012-01-31 16:31:45 UTC
I see no reason for this restriction other than consistency. And that is a weak reason. All other aspects - usability, co-location to @DataObject.Registration, no need for @Registrations, @NamespaceRegistrations and @ExtensionRegistrations - speak in favor of flexible target. Btw. is not it a bit too late for a TCR? That might have come as a result of comment #12. What I am supposed to do with a TCR I don't agree with now? Call a meeting, revert all the code!? Moreover I am not going to go through all the NetBeans sources and rewrite them again to place the annotations to package-info.java. I'd be willing to do it after comment #10, but not later. (In reply to comment #1) > no reason for this restriction other than consistency. And that is a weak > reason. I think consistency is a rather strong reason. The other reason, and the reason all other annotations which are not bound to a Java object (e.g. @OptionsPanelController.ContainerRegistration) specify @Target(PACKAGE), is that it is misleading to have an annotation on an element which is not actually related to the handling of that annotation. > is not it a bit too late for a TCR? That might have come as a result of > comment #12. Sorry, but reviews are there so changes can be reviewed. There are a lot of API reviews going on at once and there is barely time to read them all before feature freeze. > What I am supposed to do with a TCR I don't agree with now? Call a > meeting, revert all the code!? No need to revert all the code, just fix it; or assign to me to fix it; or find some other opinions; or call a meeting to discuss. > I am not going to go through all the NetBeans sources and rewrite them > again to place the annotations to package-info.java. Then assign to me to do so. Let's do it like this: bug 191777 is finished. This is new review, you are proposing a change, I am a reviewer. I vote no. I'll try to find next three reviewers to express a vote. Need three reviewers... Related to bug #207219 comment #15 (JG11): registration processors should be written to reject annotations on non-PACKAGE targets when the Element is not being used by the layer entry except perhaps as a source of an arbitrary name. In other words, all registering annotation usages should be classifiable as one of 1. Purely static data, on a package-info.java. 2. An object assignable to an API supertype - on a concrete class with a no-arg ctor, or a static @NonNull no-arg method, or (if supported by XMLFileSystem) a static final @NonNull field. 3. A non-package element meeting processor-specific structural constraints, such as @ProjectServiceProvider, or context-sensitive @ActionRegistration. where #2 should be favored over #3 in general. No other opinions gathered, no action on part of assignee before feature freeze, so I guess we are stuck with the inconsistent/confused design. |