> From: [EMAIL PROTECTED] (Bill Pugh)
> Date: Mon, 18 Jun 2007 22:23:15 -0400
> Does anyone have suggestions for how to go about submitting patches
> for issues found via static analysis?
>
> One of the problems is that static analysis just points me at the
> source file, and it can often be exceptionally difficult for me as an
> outsider to figure out who the responsible engineer is, or if an
> appropriate OpenJDK project exists.
Yes. We already know that, in the long term, we need to document a
mapping from source file (or at least package) to responsible Group.
You might think we'd have done this ages ago for internal use, but we
just haven't needed to. It's kind of like the geographical expertise of
London cab drivers -- development and quality engineers in the JDK team
tend to develop "the knowledge" over time so that they pretty much know
without thinking too much how to route any particular bug.
This is just one of many things that we'll document as we continue our
transition to open development. Stay tuned ...
> For example, below is some code from FaultReason with an obvious bug:
> the line assert(texts == null) should be assert(texts != null). But I
> have no idea who to contact about fixing this bug.
>
> The code in NamingContextImpl below also has an obvious bug. The
> check (name != null || name.length > 0) should be (name != null &&
> name.length > 0); actually, just (name != null) is probably even better.
These two examples are good illustrations of the underlying complexity.
These code fragments are in the JDK but originate in the GlassFish
project -- we're effectively downstream from GlassFish for the XML and
CORBA technologies.
So the best way to get these two bugs fixed is to submit them to the
appropriate GlassFish subprojects. (Sorry, I know that's not much help.)
> I'd like to submit about 100 patches, so making this process as easy
> as possible is important.
We'd like to do what we can to make this easy.
Here are two ideas:
(1) Send a list of the files involved and we'll find someone to figure
out which Groups own them, and then you can send patches to the
appropriate Groups.
(2) Send all the patches to this list in one message, and we'll find
someone to divvy them up and send them on to the appropriate
Groups.
The advantage of (1) is that we can do that more quickly, so it's more
likely to lead to quick results. The advantage of (2) is that it's less
work for you. Take your pick.
(This offer is open only to authors of tools at least as useful as
FindBugs, void where prohibited by law, employees of Sun Microsystems
are not eligible, etc. etc.)
The real solution, of course, is for all of us who work on the JDK to run
FindBugs on a regular basis, so that patches like this aren't necessary.
We're working on a plan for that.
- Mark
