changes.html

来自「JSP页面代码排错」· HTML 代码 · 共 1,335 行 · 第 1/5 页

										<code>
											x
										</code>
										were to be dereferenced here, we would generate a warning,
										because if the else branch of the
										<code>
											if (x == null)
										</code>
										were ever taken, a null pointer exception would result.
									</p>

									<p>
										However, in both the then and else branches of the
										<code>
											if (b)
										</code>
										statement,
										<code>
											x
										</code>
										is only null on a complex path that may be infeasible. It
										might be that the program logic is such that if
										<code>
											x
										</code>
										is null, then
										<code>
											b
										</code>
										is never true, so generating a warning about the dereference
										in the then clause might be a false positive. We could try to
										analyze the program to determine whether it is possible for
										<code>
											x
										</code>
										to be null and
										<code>
											b
										</code>
										to be true, but that can be a hard analysis problem.
									</p>

									<p>
										However,
										<code>
											x
										</code>
										is dereferenced in both the then
										<em>and</em> else branches of the
										<code>
											if (b)
										</code>
										statement. So at the point immediately before
										<code>
											if (b)
										</code>
										, we know that
										<code>
											x
										</code>
										is null on a simple path
										<em>and</em> that
										<code>
											x
										</code>
										is guaranteed to be dereferenced on all paths from this point
										forward. FindBugs 1.1 performs a backwards data flow analysis
										to determine the values that are guaranteed to be
										dereferenced, and will generate a warning in this case.
									</p>
								</li>
							</ul>
							<p>
								The following screen shot of our new GUI shows an example of
								this analysis, as well as showing off our new GUI and points out
								a limitation of our current plugins for Eclipse and NetBeans.
								The screen shot shows a null pointer bug in HelpDisplay.java.
								The test for
								<code>
									href!=null
								</code>
								on line 78 suggests that
								<code>
									href
								</code>
								could be null. If it is, then
								<code>
									href
								</code>
								will be dereferenced on either line 87 or on line 90, generating
								a NPE. Note that our analysis here also understands that passing
								<code>
									href
								</code>
								to
								<code>
									URLEncoder.encode
								</code>
								will deference it, and thus treats line 87 as a dereference,
								even though
								<code>
									href
								</code>
								is not actually dereferenced at that line. Within our new GUI,
								all of these locations are highlighted and listed in the summary
								panel. In the original GUI (and in HTML output) we list all of
								the locations, but only the primary location is highlighted by
								the original GUI. In the Eclipse and NetBeans plugins, only the
								primary location is displayed; fixing this is on our todo list
								(contributions welcome).
							</p>
							<p>
								<img src="guaranteedDereference.png" alt="">


							</p>

						</li>
						<li>
							Preliminary support for detectors using the frameworks other than
							BCEL, such as the
							<a href="http://asm.objectweb.org/">ASM</a> bytecode framework.
							You may experiment with writing ASM-based detectors, but beware
							the API may still change (which could possibly also affect
							BCEL-based detectors). In general, we've started trying to move
							away from a deep dependence on BCEL, but that change is only
							partially complete. Probably best to just avoid this until we
							complete more work on this. This change is only visible to
							FindBugs plugin developers, and shouldn't be visible to FindBugs
							users.
						</li>
						<li>
							<p>
								Bug categories (CORRECTNESS, MT_CORRECTNESS, etc.) are no longer
								hard-coded, but rather defined in xml files associated with
								plugins, including the core plugin which defines the standard
								categories. Third-party plugins can define their own categories.
							</p>
						</li>
						<li>
							<p>
								Several bug patterns have been moved from CORRECTNESS and STYLE
								into a new category, BAD_PRACTICE. The English localization of
								STYLE has changed from "Style" to "Dodgy."
							</p>
							<p>
								In general, we've worked very hard to limit CORRECTNESS bugs to
								be real programming errors and sins of commission. We have
								reclassified as BAD_PRACTICE a number of bad design practices
								that result in overly fragile code, such as defining an equals
								method that doesn't accept null or defining class with a equals
								method that inherits hashCode from class Object.
							</p>
							<p>
								In general, our guidelines for deciding whether a bug should be
								classified as CORRECTNESS, BAD_PRACTICE or STYLE are:
							</p>
							<dl>
								<dt>
									CORRECTNESS
								</dt>
								<dd>
									A problem that we can recognize with high confidence and is an
									issue that we believe almost all developers would want to
									examine and address. We recommend that software teams review
									all high and medium priority warnings in their entire code
									base.
								</dd>
								<dt>
									BAD_PRACTICE
								</dt>
								<dd>
									A problem that we can recognize with high confidence and
									represents a clear violation of recommended and standard coding
									practice. We believe each software team should decide which bad
									practices identified by FindBugs it wants to prohibit in the
									team's coding standard, and take action to remedy violations of
									those coding standards.
								</dd>
								<dt>
									STYLE
								</dt>
								<dd>
									These are places where something strange or dodgy is going on,
									such as a dead store to a local variable. Typically, less than
									half of these represent actionable programming defects.
									Reviewing these warnings in any code under active development
									is probably a good idea, but reviewing all such warnings in
									your entire code base might be appropriate only in some
									situations. Individual or team programming styles can
									substantially influence the effectiveness of each of these
									warnings (e.g., you might have a coding practice or style in
									your group that confuses one of the detectors into generating a
									lot of STYLE warnings); you will likely want to selectively
									suppress or report the STYLE warnings that are effective for
									your group.
								</dd>
							</dl>
						</li>
						<li>
							Released a preliminary version of a new GUI (known internally as
							GUI2 -- not very creative, huh?)
						</li>
						<li>
							Provided standard ways to mark user designations of bug warnings
							(e.g., as NOT_A_BUG or SHOULD_FIX). The internal logic now
							records this, it is represented in the XML file, and GUI2 allows
							the designations to be applied (along with free-form user
							annotations about each warning). The user designations and
							annotations are not yet supported by the Eclipse plugin, but we
							clearly want to support it in Eclipse shortly.
						</li>
						<li>
							Added a check for a bad comparison with a signed byte with a
							value not in the range -128..127. For example:
							<code>
								<pre>boolean find200(byte b[]) {
  for(int i = 0; i &lt; b.length; i++) if (b[i] == 200) return i;
  return -1;
}
</pre>
							</code>
						</li>
						<li>
							Added a checking for testing if a value is equal to Double.NaN
							(no value is equal to NaN, not even NaN).
						</li>
						<li>
							Added a check for using a class with an equals method but no
							hashCode method in a hashed data structure.
						</li>
						<li>
							Added check for uncallable method of an anonymous inner class.
							For example, in the following code, it is impossible to invoke
							the initalValue method (because the name is misspelled and as a
							result is doesn't override a method in ThreadLocal).
							<code>
								<pre>private static ThreadLocal serialNum = new ThreadLocal() {
         protected synchronized Object initalValue() {
             return new Integer(nextSerialNum++);
         }
     };
</pre>
							</code>
						</li>
						<li>
							Added check for a dead local store caused by a switch statement
							fall through
						</li>
						<li>
							Added check for computing the absolute value of a random 32 bit
							integer or of a hashcode. This is broken because
							<code>
								Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE
							</code>
							, and thus result of calling Math.abs, which is expected to be
							nonnegative, will in fact be negative one time out of 2
							<sup>
								32
							</sup>
							, which will invariably be the time your boss is demoing the
							software to your customers.

						</li>
						<li>
							More careful resolution of inherited methods and fields. Some of
							the shortcuts we were taking in FindBugs 1.