Summary: | declare static initialization blocks and doc static initialization order | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Wes Isberg <wes> |
Component: | Compiler | Assignee: | Adrian Colyer <adrian.colyer> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | ||
Version: | 1.1.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Wes Isberg
2004-02-17 12:31:18 EST
I'm very reluctant to add this feature as I personally believe that static intertype field declarations are almost always a bad design style and don't see any good reasons to make them easier to use. Why would you want to use a static final ITD instead of just putting the static final field on the aspect? Static fields (final or not) declared in aspects are a feature of the language that programmers might like to use for whatever reasons they have. They might want to publish a public logger on each class; while the build depends on the aspect, the client classes do not do so directly. They may be under a requirement to make any static fields final (see, e.g., the EJB spec). It's also more convenient to have a block for initialization to be able to handle exceptions. The workaround for non-final fields and fields defined after other fields is after () returning : staticinitialization(Foo) { ... Foo.LOGGER = ...; } which of course gives you the block but not the finality. One hack for finality could be to define the static final in terms of another nonfinal static and hope that Java does the right thing. (Now there's bad style...) Let's see if any users actually want this. (If you are a user and need this, please explain why in the bug.) Re. the last comment on this enhancement request "Let's see if any users actually want this. (If you are a user and need this, please explain why in the bug.)" we've had no user votes for the feature, and Jim's vote against, so I'm proposing we close this off. |