From pugh at cs.umd.edu  Mon Jun 18 19:23:15 2007
From: pugh at cs.umd.edu (Bill Pugh)
Date: Mon, 18 Jun 2007 22:23:15 -0400
Subject: Submitting patches for problems found by static analysis
Message-ID: <8570037E-9D7C-4751-9A61-1AACF49835C6@cs.umd.edu>

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.

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.

I'd like to submit about 100 patches, so making this process as easy  
as possible is important.

Bill

--------------------------
package com.sun.xml.internal.ws.encoding.soap.message;
....

/**
  * SOAP 1.2 Fault Reason
  *  <soapenv:Reason>
  *      <soapenv:Text xml:lang="en">...</soapenv:Text>
  *  </soapenv:Reason>
  *
  * @author Vivek Pandey
  */
public class FaultReason {
     private List<FaultReasonText> texts;

     public FaultReason(FaultReasonText... texts) {
         assert(texts == null);
         this.texts = Arrays.asList(texts);
     }

--------------------------
package com.sun.corba.se.impl.naming.pcosnaming;

...

public class NamingContextImpl
     extends NamingContextExtPOA
     implements NamingContextDataStore, Serializable
{

...
    public static String nameToString(NameComponent[] name)
     {
         StringBuffer s = new StringBuffer("{");
         if (name != null || name.length > 0) {
           for (int i=0;i<name.length;i++) {


From mr at sun.com  Tue Jun 19 22:05:18 2007
From: mr at sun.com (Mark Reinhold)
Date: Tue, 19 Jun 2007 22:05:18 -0700
Subject: Submitting patches for problems found by static analysis 
In-Reply-To: pugh@cs.umd.edu; Mon, 18 Jun 2007 22:23:15 EDT;
	<8570037E-9D7C-4751-9A61-1AACF49835C6@cs.umd.edu> 
Message-ID: <20070620050518.0779C6432@callebaut.niobe.net>

> From: pugh at cs.umd.edu (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


From Martin.Buchholz at Sun.COM  Tue Jun 19 22:24:56 2007
From: Martin.Buchholz at Sun.COM (Martin Buchholz)
Date: Tue, 19 Jun 2007 22:24:56 -0700
Subject: Submitting patches for problems found by static analysis
In-Reply-To: <8570037E-9D7C-4751-9A61-1AACF49835C6@cs.umd.edu>
References: <8570037E-9D7C-4751-9A61-1AACF49835C6@cs.umd.edu>
Message-ID: <4678BA28.9000408@sun.com>



Bill Pugh wrote:
> 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.

With a project as large as the JDK, it is often difficult
even for JDK engineers to identify the maintainers of a file.
The JDK could come with a program to map file names to maintainers.

Martin