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.
I see static initialization blocks as something to watch for (see email the triggered this[1]) because they hide assumptions and rely on an unknown execution order based on the classloading order when multiple classes are involved. Thus I suggest a new question for Arch-api-questions.xml called exec-static-blocks which should be something like this: "Does your code have multiple static initialization blocks? Does the execution of your code assume a classloading order for the static initialization blocks?" 1. http://netbeans.org/projects/www/lists/nbdev/archive/2012-01/message/53
(In reply to comment #0) > I see static initialization blocks as something to watch for > [...] rely on an unknown > execution order based on the classloading order when multiple classes are > involved. Only if the code is buggy, in which case the problem should be fixed, not documented.
Well, answering "YES" to exec-static-blocks would mean special attention must be given to justify it. Using Arch-api-questions.xml is an active way to look for this kind of issues, just as you look for classloader usage and other things. Unless you suggest some Hudson or post-commit task to check for this, doing nothing doesn't seem to best choice.
(In reply to comment #2) > Unless you suggest some Hudson or post-commit task to check for this I do not know of static analysis that would catch this kind of coding error. > doing nothing doesn't seem to best choice. Fixing any problems that are reported seems to be the best choice. You found one, you filed it, and I hope it will get fixed. There is no reason to duplicate the function of Bugzilla.
Why bother with Arch-api-questions.xml at all then?
That would be a question for jtulach, who invented it. But various sections of arch.xml can be used to document aspects of a module's design (if the developer bothers to keep it up to date, and the user thinks to look there). Adding sections corresponding to known and easily fixable bugs would make no sense.