changes.html

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

					<li>Enabled StaticCalendarDetector
					</li>
					<li>Reworked GUI2 to use standard FindBugs filters
					</li>
					<ul>
					<li>Allow a suppression filter to be stored in a project and persisted to the XML representation of a project.
					</li>
					</ul>
					
					<li>Move away from old GUI2 save format (a directory containing an xml file and another file containing serialized filters).
					</li>
					<li>Support/recommend use of two new file extensions/formats:
					<dl><dt>.fba - FindBugs Analysis File</dt>
					<dd>Exactly the same as an existing bug collection file stored in XML format, but using a distinct file extension
					to make it easier to figure out which xml files contain FindBugs results.</dd>
					<dt>.fbp - FindBugs Project File</dt><dd>Contains just the information needed to run FindBugs and display the results (e.g., the files to be analyzed, the auxiliary class path and the location of source files)</dl></li>
					</ul>
					<p> Changes since version 1.1.3</p>
					<ul>
					<li>Added -xml:withAbridgedMessages option to generate xml containing shorter messages.
					    The messages will be shorted by doing things like eliding package names, and leaving off
					    the source line from the LongMessage.
					    These messages are appropriate if being used in a context where 
					    the non-message components of the bug annotations will be used to provide more information
					    (e.g., clicking on the message for a MethodAnnotation will display the source for the method).
					<ul><li>FindBugsDisplayFeatures.setAbridgedMessages(true) can be used to generate abridged messages
					    when FindBugs is being accessed directly (not via generated XML) from a GUI or IDE.
					    </li>
					    </ul>
					<li>In null pointer analysis, try to be better about always showing two locations: where it is known null and
					where it is dereferenced.
					<li>Interprocedural analysis of which methods return nonnull values
					<li>Use method calls to select order in which classes are analyzed, and order in which methods
					are analyzed, to improve interprocedural analysis results.
					<li>Significant improvements in memory footprint, memory allocation and CPU utilization 
					    (20-30% reduction in all three) 
					<li>Added a project name, to provide better descriptions in the HTML output.
					<li>Added new bug pattern: Casting to char, or bit masking with nonnegative value, and then checking to see
						if the result is negative.
					<li>Stopped reporting transient fields
					of classes not marked as serializable. Transient is used by other persistence frameworks.
					<li>Improvements to detector for SQL injection (Thanks to <a href="http://www.clock.org/~matt">Matt Hargett</a> for
					his contributions
					<li>Changed open/save options in GUI2 to not distinguish between FindBugs projects
					and saved FindBugs analysis results.
					<li>Improvements to detection of serious non-short-circuit evaluation.
					<li>Updated Japanese localization (thanks to Ruimo Uno)
					
					<li>Eclipse plugin changes:
					<ul>
					<li>Created Bug User Annotations and Bug Tree Views
					<li>Use different icons for different bug priorities
					<li>Provide more information in Bug Details view
					</ul>
					</ul>
					
					<p>
						Changes since version 1.1.2:
					</p>
					<ul>
					<li>Fixed broken Ant task
					<li>Added running ant task to smoke test
					<li>Added validating xml and html output to smoke test
					<li>Fixed some  (but not all) issues with html output validation
					<li>Added check for x.equals(x) and x.compareTo(x)
					<li>Various bug fixes
					</ul>
					<p>
						Changes since version 1.1.1:
					</p>
					<ul>
						<li>
							Added check for infinite iterative loops
						</li>
						<li>
							Added check for use of incompatible types in a collection (e.g.,
							checking to see if a Set&lt;String&gt; contains a StringBuffer).
						</li>
						<li>
							Added check for invocations of equals or hashCode on a URL,
							which,
							<a
								href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">surprising
								many people</a>, requires DNS resolution.
						</li>
						<li>
							Added check for classes that define compareTo but not equals;
							such classes can exhibit some anomalous behavior (e.g., they are
							treated differently by PriorityQueues in Java 5 and Java 6).
						</li>
						<li>
							Added a check for useless self operations (e.g., x &lt; x or x ^ x).
						</li>
						<li>
							Fixed a data race that could cause the GUI to fail on startup
						</li>
						<li>
							Partial internationalization of the new GUI
						</li>
						<li>
							Fix bug in "Redo analysis" option of new GUI
						</li>
						<li>
							Tuning to reduce false positives
						</li>
						<li>
							Fixed a bug in null pointer analysis that was generating false
							positive null pointer warnings on exception paths. Fixing this
							bug eliminates about 1/4 of the warnings on null pointer
							exceptions on exception paths.
						</li>
						<li>
							Fixed a bug in the processing of phi nodes for fields in the null
							pointer analysis
						</li>
						<li>
							Applied contributed patch that provides more quick fixes in
							Eclipse plugin.
						</li>
						<li>
						Fixed a number of bugs in the Eclipse auto update sites, and in the way
						date qualifiers were being used in the Eclipse plugin. You may need to manually
						disable your existing version of the plugin and download the 1.1.2 from the update 
						site to get the automatic update function working correctly.
						The Eclipse update sites are described at <a href="http://findbugs.cs.umd.edu/eclipse/">http://findbugs.cs.umd.edu/eclipse/</a>.
						
						</li>
						<li>
							Fixed progress bar in Eclipse plugin
						</li>
						<li>
							A number of other bug fixes.
						</li>
					</ul>

					<p>
						Changes since version 1.1.0:
					</p>
					<ul>
						<li>
							less scanning of classes not on the analysis path (This was
							causing some performance problems.)
						</li>
						<li>
							no unread field warnings for fields annotated with
							javax.persistent or javax.ejb3
						</li>
						<li>
							Eclipse plugin
							<ul>
								<li>
									bug annotation info displayed in Bug Details tab
								</li>
								<li>
									.fbwarnings data file now stored in .metadata (not in the
									project itself)
								</li>
							</ul>
						</li>
						<li>
							new SE_BAD_FIELD_INNER_CLASS pattern
						</li>
						<li>
							updates to Japanese translation (ruimo)
						</li>
						<li>
							fix some internal slashed/dotted path confusion
						</li>
						<li>
							other minor improvements
						</li>
					</ul>

					<p>
						Changes since version 1.0.0:
					</p>

					<ul>
						<li>
							Overall, the change from FindBugs 1.0.0 to FindBugs 1.1.0 has
							been a big change. We've done a lot of work in a lot of areas,
							and aren't even going to try to enumerate all the changes.
						</li>
						<li>
							We spent a lot of time reviewing the results generated by
							FindBugs for open source and commercial code bases, and made a
							number of changes, small and large, to minimize the number of
							false positives. Our primary focus for this was warnings reported
							as high and medium priority correctness warnings. Our internal
							evaluation is that we produce very few high/medium priority
							correctness warnings where the analysis is actually wrong, and
							that more than 75% of the high/medium priority correctness
							warnings correspond to real coding defects that need addressing
							in the source code. The remaining 25% are largely cases such as a
							branch or statement that if taken would lead to an error, but in
							fact is a dead branch or statement that can never be taken. Such
							coding is confusing and hard to maintain, so it should arguably
							be fixed, but it is unlikely to actually result in an error
							during execution. Thus, some might classify those warnings as
							false positives.

						</li>
						<li>
							We've substantially improved the analysis for errors that could
							result in null pointer dereferences. Overall, our experience has
							been that these changes have roughly doubled the number of null
							pointer errors we detect, without increasing the number of false
							positives (in fact, our false positive rate has gone down). The
							improvements are due to four factors:
							<ul>
								<li>
									By default, we now do some interprocedural analysis to
									determine methods that unconditionally dereference their
									parameters.
								</li>
								<li>
									FindBugs also comes with a model of which JDK methods
									unconditionally dereference their parameters.
								</li>
								<li>
									We do limited tracking of fields, so that we can detect null
									values stored in fields that lead to exceptions.
								</li>
								<li>
									We implemented a new analysis technique to find guaranteed
									dereferences. Consider the following example:

									<code>
										<pre>public int f(Object x, boolean b) {
  int result = 0;
  if (x == null) result++;
  else result--;
  // at this point, we know x is null on a simple path
  if (b) {
    // at this point, x is only null on a complex path
    // we don't know if the path in which x is null and b is true is feasible
    return result + x.hashCode();
    }
  else {
    // at this point, x is only null on a complex path
    // we don't know if the path in which x is null and b is false is feasible
    return result - x.hashCode();
    }
</pre>
									</code>

									<p>
										FindBugs 1.0 used forward dataflow analysis to determine
										whether each value is definitely null, null on a simple path,
										possible null on a complex path, or definitely nonnull. Thus,
										at the statement where
										<code>
											result
										</code>
										is decremented, we know that
										<code>
											x
										</code>
										is definitely null, and at the point before
										<code>
											if (b)
										</code>
										, we know that
										<code>
											x
										</code>
										is null on a simple path. If