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 150804 - Source code annotations to simplify module development
Summary: Source code annotations to simplify module development
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jesse Glick
Depends on: 147393 149136 150447 153093
  Show dependency tree
Reported: 2008-10-21 05:48 UTC by Jesse Glick
Modified: 2009-05-26 20:00 UTC (History)
10 users (show)

See Also:
Exception Reporter:

Outstanding changesets (22.04 KB, application/octet-stream)
2008-10-21 05:57 UTC, Jesse Glick
New outstanding changesets (27.02 KB, application/octet-stream)
2008-10-22 23:14 UTC, Jesse Glick
New outstanding changesets (134.82 KB, application/octet-stream)
2008-10-24 21:44 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-10-21 05:48:23 UTC
I am filing this as an umbrella issue for the review of a proposed feature to use Java annotations to simplify the
registration of global objects in NetBeans modules. Very generally, with these changes you will be able to register
various kinds of objects in the platform without using any specialized GUI or editing any files other than plain Java
sources. This is all built on JSR-269 and happens mostly at build time, with minor effects on the runtime.

Specific changes to review include:

issue #147393 - modification of harness to support annotation processors (requires bundling JDK 7 javac to support
building on JDK 5)
issue #149136 - infrastructure for APs which generate XML layer fragments
issue #150447 - annotation to generate META-INF/services/* entries

Not yet included in running patch:
- specific layer-generating APs (though an example is available for illustration)
- apichanges
- tools to convert old modules to use annotations where possible
- conversion of modules in this way

Given how visible a change like this would be, I don't think fast-track review is appropriate (though everything should
be compatible), so it would be great if we could schedule a formal review meeting. Yarda could you please take care of
setting up a meeting, as I expect most people attending to be in Prague?
Comment 1 Jesse Glick 2008-10-21 05:57:01 UTC
Created attachment 72339 [details]
Outstanding changesets
Comment 2 Jesse Glick 2008-10-21 19:48:47 UTC
I have written up a detailed discussion of the problem, proposed solution, and other issues in the referenced wiki page.
Comment 3 tomwheeler 2008-10-22 02:28:23 UTC
I appreciate any effort which aims to simplify module development.

As noted in the Wiki describing the proposal, there are already two methods of registering services, but it was not
clear to me from (and I admit I have so far just read it quickly) whether the new annotation-based method was going to
be the preferred approach for new code. It's already somewhat confusing to module developers now when to choose the
META-INF/services versus doing registration in layer files.   My concern is that adding an additional method of
registering services without clarifying when to use each one will wind up confusing rather than helping developers.

It was also not clear to me what, if any, precedence will be used to resolve conflicts among these different methods.
For example, what happens if a module declares a service via annotations and another module hides it via the layer file?
 Will it be available? What happens in the opposite case?  I guess this scenario is possible even now with
META-INF/services and layer registration, but I'd think it would be more likely to happen in the future based on what I
see in the proposal.

Overall, I like what I read and plan to comment more after I have had time to consider it more.
Comment 4 Jesse Glick 2008-10-22 16:04:13 UTC
Use of annotations would be encouraged for all new code in all situations where annotations were available. I agree that
there is a risk that new developers might become confused by their options, especially if they have been perusing a mix
of old and new documentation.

The proposed system is purely a build-time convenience, so it does not change runtime semantics or precedence rules.
M-I/s registrations can be hidden by other M-I/s files (using #- syntax, also supported directly from @Service), and
layer registrations can be hidden by other layers (using _hidden files).
Comment 5 Jesse Glick 2008-10-22 23:14:54 UTC
Created attachment 72499 [details]
New outstanding changesets
Comment 6 Jaroslav Tulach 2008-10-23 15:00:49 UTC
The conf call review is going to happen on Thursday Oct 30, around 18.30-19.30CET (exact time to be specified on 
Wednesday). Everyone who wants to join the conf call, please write me an email. I'll send to dial in info. Prague 
meets in Olympia. Voting reviewers include me, Jan Lahoda and we need two more - any volunteers?
Comment 7 Jesse Glick 2008-10-24 21:44:18 UTC
Created attachment 72634 [details]
New outstanding changesets
Comment 8 Jesse Glick 2008-11-01 16:50:54 UTC
Infrastructure merged in core-main #78103b644dfc.
Comment 9 Quality Engineering 2008-11-04 16:29:06 UTC
Integrated into 'main-golden', will be available in build *200811041401* on (upload may still be in progress)
User: Jesse Glick <>
Log: #150804: infrastructure for annotation processors.
Comment 10 Jesse Glick 2009-05-26 20:00:25 UTC
Consider implemented in 6.7 at least for some cases.