changes.html

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

                            this will result in a NullPointerException.
					  </ul>
					<li>Changes to Existing Reports</li>
					<ul>
					  <li>RV_DONT_JUST_NULL_CHECK_READLINE: CORRECTNESS -&gt; STYLE</li>
					  <li>DMI_INVOKING_TOSTRING_ON_ARRAY: Long description mentions array name whenever possible</li>
					</ul>
					<li>Fixes:</li>
					<ul>
					<li>Updated manual to mention that Java 1.5 is now a requirement for running FindBugs
					<li>Applied patch 1840206 fixing issue "Ant task does not work when presetdef is used" - thanks to phejl 
					<li>Applied patch 1778690 fixing issue "Ant task: tolerate but complain about invalid auxClasspath" - thanks to David Schmidt
					<li>Applied patch 1852125 adding a Chinese-language GUI bundle props file - thanks to fifi
					<li>Applied patch 1845903 adding ability to load XML results with the Eclipse plugin - thanks to Alex Mont
					<li>Fixed issue 1844671 - "FP for "reversed" null check in catch for stream close"
					<li>Fixed issue 1836050 - "-onlyAnalyze broken"
					<li>Fixed issue 1853011 - "Typo: Field names should start with aN lower case letter"
					<li>Fixed issue 1844181 - "JNLP file does not contain all necessary JARs"
					<li>Fixed issue 1840245 - "xxxException class does not derive from Exception"
					<li>Fixed issue 1840277 - "[M D EC] Typo in bug documentation"
					<li>Fixed issue 1782447 - "OutOfMemoryError if i activate Findbugs on my project"
					<li>Fixed issue 1830576 - "[regression] keySet/entrySet false positive"
					</ul>
					<li>Other:</li>
					<ul>
					<li>New bug code: "IO" (for IO_APPENDING_TO_OBJECT_OUTPUT_STREAM)</li>
					<li>Added "-onlyMostRecent" option for computeBugHistory script/ant task
					<li>More explicit language in RV_RETURN_VALUE_IGNORED_BAD_PRACTICE messages
					<li>Modified ResourceValueAnalysis to correctly identify null == X or null != X as a null check (for issue 1844671)
					<li>Modified DMI_HARDCODED_ABSOLUTE_FILENAME logic in DumbMethodInvocations to ignore files from /etc or /dev and increase priority of files from /home
					<li>Better bug details for infinite loop warnings
					<li>Modified unread-fields detector to reduce false positives from reflective fields
					<li>build.xml "classes" target now builds all sources in one step
					</ul>
					</ul>

					<p> Changes since version 1.2.1</p>
					<ul>
					<li>New Detectors and Reports</li>
					<ul>
					  <li>SynchronizationOnSharedBuiltinConstant</li>
					  <ul>
					    <li>DL_SYNCHRONIZATION_ON_SHARED_CONSTANT:
					        The code synchronizes on a shared primitive
					        constant, such as an interned String.  Such
					        constants are interned and shared across all other
					        classes loaded by the JVM. Thus, this could be
					        locking on something that other code might also be
					        locking. This could result in very strange and hard
					        to diagnose blocking and deadlock behavior. See
					        <a href="http://www.javalobby.org/java/forums/t96352.html">http://www.javalobby.org/java/forums/t96352.html</a>
					        and
					        <a href="http://jira.codehaus.org/browse/JETTY-352">http://jira.codehaus.org/browse/JETTY-352</a>.
					  </ul>
					  <li>OverridingEqualsNotSymmetrical</li>
					  <ul>
					    <li>EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC:
					    Looks for equals methods that override equals
					    methods in a superclass where the equivalence
					    relationship might not be symmetrical.
					  </ul>
					  <li>CheckTypeQualifiers</li>
					  <ul>
					    <li>TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED:
					    A value specified as carrying a type qualifier
					    annotation is consumed in a location or locations
					    requiring that the value not carry that annotation.
					    More precisely, a value annotated with a type
					    qualifier specifying when=ALWAYS is guaranteed to reach
					    a use or uses where the same type qualifier specifies
					    when=NEVER.
					    </li>
					    <li>TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED:
					    A value specified as not carrying a type qualifier
					    annotation is guaranteed to be consumed in a location
					    or locations requiring that the value does carry that
					    annotation.  More precisely, a value annotated with a
					    type qualifier specifying when=NEVER is guaranteed to
					    reach a use or uses where the same type qualifier
					    specifies when=ALWAYS.
					    </li>
					    <li>TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK:
					    A value that might not carry a type qualifier
					    annotation reaches a use which requires that
					    annotation.
					    </li>
					    <li>TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK:
					    A value which might carry a type qualifier annotation
					    reaches a use which forbids values carrying that
					    annotation.
					    </li>
					  </ul>
					</ul>
					<li>New Reports (existing detectors)</li>
					<ul>
					  <li>FindHEmismatch</li>
					  <ul>
					    <li>EQ_DOESNT_OVERRIDE_EQUALS:
					    This class extends a class that defines an equals
					    method and adds fields, but doesn't define an equals
					    method itself. Thus, equality on instances of this
					    class will ignore the identity of the subclass and the
					    added fields. Be sure this is what is intended, and
					    that you don't need to override the equals method. Even
					    if you don't need to override the equals method,
					    consider overriding it anyway to document the fact that
					    the equals method for the subclass just return the
					    result of invoking super.equals(o).
					    </li>
					  </ul>
					  <li>Naming
					  <ul>
					    <li>NM_WRONG_PACKAGE, NM_WRONG_PACKAGE_INTENTIONAL:
					    The method in the subclass doesn't override a similar
					    method in a superclass because the type of a parameter
					    doesn't exactly match the type of the corresponding
					    parameter in the superclass.
					    </li>
					    <li>NM_SAME_SIMPLE_NAME_AS_SUPERCLASS:
					    This class has a simple name that is identical to that
					    of its superclass, except that its superclass is in a
					    different package (e.g., <code>alpha.Foo</code>
					    extends <code>beta.Foo</code>).  This can be
					    exceptionally confusing, create lots of situations in
					    which you have to look at import statements to resolve
					    references and creates many opportunities to
					    accidently define methods that do not override methods
					    in their superclasses.
					    </li>
					    <li>NM_SAME_SIMPLE_NAME_AS_INTERFACE:
					    This class/interface has a simple name that is
					    identical to that of an implemented/extended 
					    interface, except that the interface is in a different
					    package (e.g., <code>alpha.Foo</code> extends
					    <code>beta.Foo</code>).  This can be exceptionally
					    confusing, create lots of situations in which you have
					    to look at import statements to resolve references and
					    creates many opportunities to accidently define methods
					    that do not override methods in their superclasses.
					    </li>
					  </ul>
					  <li>FindRefComparison</li>
					  <ul>
					    <li>EC_UNRELATED_TYPES_USING_POINTER_EQUALITY:
					    This method uses using pointer equality to compare two
					    references that seem to be of different types.  The
					    result of this comparison will always be false at
					    runtime.
					    </li>
					  </ul>
					  <li>IncompatMask</li>
					  <ul>
					    <li>BIT_SIGNED_CHECK, BIT_SIGNED_CHECK_HIGH_BIT:
					    This method compares an expression such as
					    <tt>((event.detail &amp; SWT.SELECTED) &gt; 0)</tt>.  Using
					    bit arithmetic and then comparing with the greater than
					    operator can lead to unexpected results (of course
					    depending on the value of SWT.SELECTED). If
					    SWT.SELECTED is a negative number, this is a candidate
					    for a bug. Even when SWT.SELECTED is not negative, it
					    seems good practice to use '!= 0' instead of '&gt; 0'.
					    </li>
					  </ul>
					  <li>LazyInit</li>
					  <ul>
					    <li>LI_LAZY_INIT_UPDATE_STATIC:
					    This method contains an unsynchronized lazy
					    initialization of a static field.  After the field is
					    set, the object stored into that location is further
					    accessed.  The setting of the field is visible to other
					    threads as soon as it is set. If the further accesses in
					    the method that set the field serve to initialize the
					    object, then you have a <em>very serious</em>
					    multithreading bug, unless something else prevents any
					    other thread from accessing the stored object until it
					    is fully initialized.
					    </li>
					  </ul>
					  <li>FindDeadLocalStores</li>
					  <ul>
					    <li>DLS_DEAD_STORE_OF_CLASS_LITERAL:
					    This instruction assigns a class literal to a variable
					    and then never uses it.
					    <a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">The behavior of this differs in Java 1.4 and in Java 5.</a>
					    In Java 1.4 and earlier, a reference to
					    <code>Foo.class</code> would force the static
					    initializer for <code>Foo</code> to be executed, if it
					    has not been executed already.  In Java 5 and later, it
					    does not.  See Sun's
					    <a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">article on Java SE compatibility</a>
					    for more details and examples, and suggestions on how
					    to force class initialization in Java 5.
					    </li>
					  </ul>
					  <li>MethodReturnCheck</li>
					  <ul>
					    <li>RV_RETURN_VALUE_IGNORED_BAD_PRACTICE:
					    This method returns a value that is not checked. The
					    return value should be checked since it can indication
					    an unusual or unexpected function execution. For
					    example, the <code>File.delete()</code> method returns
					    false if the file could not be successfully deleted
					    (rather than throwing an Exception).  If you don't
					    check the result, you won't notice if the method
					    invocation signals unexpected behavior by returning an
					    atypical return value.
					    </li>
					    <li>RV_EXCEPTION_NOT_THROWN:
					    This code creates an exception (or error) object, but
					    doesn't do anything with it.
					    </li>
					  </ul>
					</ul>
					<li>Changes to Existing Reports</li>
					<ul>
					  <li>NS_NON_SHORT_CIRCUIT: BAD_PRACTICE -&gt; STYLE</li>
					  <li>NS_DANGEROUS_NON_SHORT_CIRCUIT: CORRECTNESS -&gt; STYLE</li>
					  <li>RC_REF_COMPARISON: CORRECTNESS -&gt; BAD_PRACTICE</li>
					</ul>
					<li>GUI Changes</li>
					<ul>
					  <li>Added importing and exporting of bug filters</li>
					  <li>Better handling of failed analysis runs</li>
					  <li>Added "-look" parameter for selecting look-and-feel</li>
					  <li>Fixed incorrect package filtering</li>
					  <li>Fixed issue where "synchronized" was not syntax-highlighted</li>
					</ul>
					<li>Ant-task Changes</li>
					<ul>
					  <li>Refactored common ant-task code to AbstractFindBugsTask</li>
					  <li>Added tasks for computeBugHistory, convertXmlToText, filterBugs, mineBugHistory, setBugDatabaseInfo</li>
					</ul>
					<li>Manual</li>
					<ul>
					  <li>Updates to GUI section, including new screenshots</li>
					  <li>Added description of rejarForAnalysis</li>
					  <li>Revamp of data-mining section</li>
					</ul>
					<li>Other Major</li>
					<ul>
					  <li>Internal restructuring for lower memory overhead</li>
					</ul>
					<li>Other Minor</li>
					<ul>
					  <li>Fixed typo: was STCAL_STATIC_SIMPLE_DATA_FORMAT_INSTANCE now STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE</li>
					  <li>-outputFile parameter became -output</li>
					  <li>More sensitivity and specificity inLazyInit detector</li>
					  <li>More sensitivity and specificity in Naming detector</li>
					  <li>More sensitivity and specificity in UnreadFields detector</li>
					  <li>More sensitivity in FindNullDeref detector</li>
					  <li>More sensitivity in FindBadCast2 detector</li>
					  <li>More specificity in FindReturnRef detector</li>
					  <li>Many other tweaks and bug fixes</li>
					</ul>
					</ul>

					<p> Changes since version 1.2.0</p>
					<ul>
					<li>Bug fixes:
					<ul>
					<li><a href="http://fisheye2.cenqua.com/changelog/findbugs/?cs=8219">Fix</a> <a href="http://sourceforge.net/tracker/index.php?func=detail&aid=1726946&group_id=96405&atid=614693">bug</a> with detectors that were requested to be disabled but were enabled due to requirements of other detectors.</li>
					<li>Fix bugs in incremental analysis within Eclipse plugin</li>
					<li>Fix some analysis errors</li>
					<li>Fix some threading bugs in GUI2</li>
					<li>Report version as version when it was compiled, not when it was run</li>
					<li>Copy analysis time stamp when filtering or transforming analysis files.</li>
					</ul>