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 207671 - Arch-api-questions.xml should be updated with a new exec-static-blocks
Summary: Arch-api-questions.xml should be updated with a new exec-static-blocks
Status: RESOLVED INVALID
Alias: None
Product: apisupport
Classification: Unclassified
Component: API docs (show other bugs)
Version: 7.2
Hardware: PC All
: P3 normal (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-24 10:12 UTC by emi
Modified: 2012-01-24 12:37 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emi 2012-01-24 10:12:38 UTC
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
Comment 1 Jesse Glick 2012-01-24 12:15:31 UTC
(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.
Comment 2 emi 2012-01-24 12:20:54 UTC
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.
Comment 3 Jesse Glick 2012-01-24 12:28:35 UTC
(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.
Comment 4 emi 2012-01-24 12:30:59 UTC
Why bother with Arch-api-questions.xml at all then?
Comment 5 Jesse Glick 2012-01-24 12:37:55 UTC
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.