FindBugs Bug Descriptions This document lists the standard bug patterns reported by version 0.8.5. Summary
Descriptions AM: Creates an empty jar file entry The code calls putNextEntry(), immediately followed by a call to cloEntry(). This results in an empty JarFile entry. The contents of the entry should be written to the JarFile between the calls to putNextEntry() and cloEntry(). AM: Creates an empty zip file entry The code calls putNextEntry(), immediately followed by a call to cloEntry(). This results in an empty ZipFile entry. The contents of the entry should be written to the ZipFile between the calls to putNextEntry() and cloEntry(). BIT: Incompatible bit masks This method compares an expression of the form (a & C) to D, which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo. BIT: Incompatible bit masks This method compares an expression of the form (a & 0) to 0, which will always compare equal. This may indicate a logic error or typo. BIT: Incompatible bit masks This method compares an expression of the form (a | C) to D. which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo. Typically, this bug occurs becau the code wants to perform a membership test in a bit t, but us the bitwi OR operator ("|") instead of bitwi AND ("&"). BOA: Class overrides a method implemented in super class Adapter wrongly This method overrides a method found in a parent class, where that class is an Adapter that implements a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not get called when the event occurs. BRSA: Method attempts to access a result t field with index 0 A call to getXXX or updateXXX methods of a result t was made where the field index is 0. As ResultSet fields start at index 1, this is always a mistake. CN: Class implements Cloneable but does not define or u clone method Class implements Cloneable but does not define or u the clone method. CN: clone method does not call super.clone() This class defines a clone() method that does not call super.clone(), and is not final. If this class ("A") is extended by a subclass ("B"), and the subclass B calls super.clone(), then it is likely that B's clone() method will return an object of type A, which violates the standard contract for clone(). If all clone() methods call super.clone(), then they are guaranteed to u Object.clone(), which always returns an object of the correct type. Co: Covariant compareTo() method defined This class defines a covariant version of compareTo(). To correctly override the compareTo() method in the Comparable interface, the parameter of compareTo() must have type java.lang.Object. DE: Method might drop exception This method might drop an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method. DE: Method might ignore exception This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method. Dm: Method it(...) it shuts down the entire Java virtual machine. This should only been done when it is appropriate. Such calls make it hard or impossible for your code to be invoked by other code. Consider throwing a RuntimeException instead. EC: Call to equals() with null argument This method calls equals(Object), passing a null value as the argument. According to the contract of the equals() method, this call should always return fal. EC: Call to equals() comparing different interface types This method calls equals(Object) on two references of unrelated interface types (neither is a subtype of the other). According to the contract of equals(), objects of different class should always compare as unequal. Note that it is possible that the program contains class that implement both interfaces, so the comparison may be valid. However, it is worth inspecting cloly. EC: Call to equals() comparing different types This method calls equals(Object) on two references of different types. According to the contract of equals(), objects of different class should always compare as unequal; therefore, it is likely that the result of this comparision will always be fal at runtime. ES: Comparison of String objects using == or != This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be reprented by two different String objects. Consider using the equals(Object) method instead. Eq: Covariant equals() method defined This class defines a covariant version of equals(). To correctly override the equals() method in java.lang.Object, the parameter of equals() must have type java.lang.Object. Eq: Covariant equals() method defined, Object.equals(Object) inherited This class defines a covariant version of the equals() method, but calls the normal equals(Object) method defined in the ba java.lang.Object class. The class should probably define a non-covariant version of equals(). (I.e., a method with the signature boolean equals(java.lang.Object). FI: Explicit invocation of finalizer This method contains an explicit invocation of the finalize() method on an object. Becau finalizer methods are suppod to be executed once, and only by the VM, this is a bad idea. FI: Finalizer does not call superclass finalizer This finalize() method does not make a call to its superclass's finalize() method. So, any finalizer actions defined for the superclass will not be performed. Add a call to super.finalize(). FI: Finalizer nullifies superclass finalizer This empty finalize() method explicitly negates the effect of any finalizer defined by its superclass. Any finalizer actions defined for the superclass will not be performed. Unless this is intended, delete this method. HE: Class defines equals() but not hashCode() This class overrides equals(Object), but does not override hashCode(). Therefore, the class may violate the invariant that equal objects must have equal hashcodes. HE: Class defines equals() and us Object.hashCode() This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes. If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException. HE: Class defines hashCode() but not equals() This class defines a hashCode() method but not an equals() method. Therefore, the class may violate the invariant that equal objects must have equal hashcodes. HE: Class defines hashCode() and us Object.equals() This class defines a hashCode() method but inherits its equals() method from java.lang.Object (which defines equality by comparing object references). Although this will probably satisfy the contract that equal objects must have equal hashcodes, it is probably not what was intended by overriding the hashCode() method. (Overriding hashCode() implies that the object's identity is bad on criteria more complicated than simple reference equality.) HE: Class inherits equals() and us Object.hashCode() 暑假亲子游This class inherits equals(Object) from an abstract superclass, and hashCode() from from java.lang.Object北回归线是什么意思 (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes. If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException. IC: Initialization circularity A circularity was detected in the static initializers of the two class referenced by the bug instance. Many kinds of unexpected behavior may ari from such circularity. IJU: TestCa implements tUp but doesn't call super.tUp() Class is a JUnit TestCa and implements the tUp method. The tUp method should call super.tUp(), but doesn't. IMSE: Dubious catching of IllegalMonitorStateException IllegalMonitorStateException is generally only thrown in ca of a design flaw in your code (calling wait or notify on an object you do not hold a lock on). It: Iterator next() method can't throw NoSuchElement exception This class implements the java.util.Iterator interface. However, its next() method is not capable of throwing java.util.NoSuchElementException. The next() method should be changed so it throws NoSuchElementException if is called when there are no more elements to return. MF: Class defines field that obscures a superclass field This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other. MF: Method defines a variable that obscures a field This method defines a local variable with the same name as a field in this class or a superclass. This may cau the method to read an uninitialized value from the field, leave the field uninitialized, or both. MWN: Mismatched notify() This method ify() ifyAll() without obviously holding a lock on the object. Calling notify() or notifyAll() without a lock held will result in an IllegalMonitorStateException being thrown. MWN: Mismatched wait() This method calls Object.wait() without obviously holding a lock on the object. Calling wait() without a lock held will result in an IllegalMonitorStateException being thrown. NP: Null pointer dereference in method A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed. NP: Null pointer dereference in method on exception path A pointer which is null on an exception path is dereferenced here. This will lead to a NullPointerException when the code is executed. Note that becau FindBugs currently does not prune infeasible exception paths, this may be a fal warning. Also note that FindBugs considers the default ca of a switch statement to be an exception path, since the default ca is often infeasible. NP: Possible null pointer dereference in method A reference value dereferenced here might be null at runtime. This may lead to a NullPointerException when the code is executed. NP: Possible null pointer dereference in method on exception path A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. Note that becau FindBugs currently does not prune infeasible exception paths, this may be a fal warning. Also note that FindBugs considers the default ca of a switch statement to be an exception path, since the default ca is often infeasible. NS: Questionable u of non-short-circuit logic This code ems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). Non-short-circuit logic caus both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cas when evaluating the right-hand side can generate an error. Nm: Class defines equal(); should it be equals()? This class defines a method equal(Object). This method does not override the equals(Object) method in java.lang.Object, which is probably what was intended. Nm: Confusing method names The referenced methods have names that differ only by capitalization. Nm: Confusing method name This method has the same name as the superclass of the class it is defined in. Nm: Class defines hashcode(); should it be hashCode()? This class defines a method called hashcode(). This method does not override the hashCode() method in java.lang.Object, which is probably what was intended. Nm: Class defines tostring(); should it be toString()? This class defines a method called tostring(). This method does not override the toString() method in java.lang.Object, which is probably what was intended. Nm: Very confusing method names The referenced methods have names that differ only by capitalization. ODR: Method may fail to clo databa resource The method creates a databa resource (such as a databa connection or row t), does not assign it to any fields, pass it to other methods, or return it, and does not appear to clo the object on all paths out of the method. Failure to clo databa resources on all paths out of a method may result in poor performance, and could cau the application to have problems communicating with the databa. ODR: Method may fail to clo databa resource on exception The method creates a databa resource (such as a databa connection or row t), does not assign it to any fields, pass it to other methods, or return it, and does not appear to clo the object on all exception paths out of the method. Failure to clo databa resources on all paths out of a method may result in poor performance, and could cau the application to have problems communicating with the databa. OS: Method may fail to clo stream The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to clo the stream on all paths out of the method. This may result in a file descriptor leak. It is generally a good idea to u a finally block to ensure that streams are clod. OS: Method may fail to clo stream on exception The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to clo it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to u a finally block to ensure that streams are clod. PZLA: Consider returning a zero length array rather than null It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method. On the otherhand, using null to indicate "there is no answer to this question", then it is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory. RC: Suspicious reference comparison This method compares two reference values using the == or != operator, where the correct way to compare instances of this type is generally with the equals() method. Examples of class which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc. RCN: Redundant comparision to null of previously checked value This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported: ∙ Both values compared are definitely null ∙ One value is definitely null and the other is definitely not null This particular warning generally indicates that a value known not to be null was checked against null. While the check is not necessary, it may simply be a ca of defensive programming. RCN: Redundant comparison to null This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported: ∙ Both values compared are definitely null ∙ One value is definitely null and the other is definitely not null This particular warning reprents two specific kinds of redundant comparisions: 1. A value was dereferenced, and later explicitly compared to null: this often indicates an error in the method 2. A literal null value was explicitly compared to null: this may indicate that the method was modified without complete understanding of the invariants of the method RR: Method ignores results ad() This method ignores the return value of one of the variants of java.ad() which can return multiple bytes. If the return value is not checked, the caller will not be able to correctly handle the ca where fewer bytes were read than the caller requested. This is a particularly insidious kind of bug, becau in many programs, reads from input streams usually do read the full amount of data requested, causing the program to fail only sporadically. RR: Method ignores results of InputStream.skip() This method ignores the return value of java.io.InputStream.skip() which can skip multiple bytes. If the return value is not checked, the caller will not be able to correctly handle the ca where fewer bytes were skipped than the caller requested. This is a particularly insidious kind of bug, becau in many programs, skips from input streams usually do skip the full amount of data requested, causing the program to fail only sporadically. With Buffered streams, however, skip() will only skip data in the buffer, and will routinely fail to skip the requested number of bytes. RV: Method ignores return value The return value of this method should be checked. SA: Self assignment of field This method contains a lf assignment of a field; e.g. int x; public void foo() { x = x; } Such assignments are uless, and may indicate a logic error or typo. SI: Static initializer for class creates instance before all static final fields assigned The class's static initializer creates an instance of the class before all of the static final fields are assigned. SIO: Unnecessary type check done using instanceof operator Type check performed using the instanceof operator where it can be statically determined whether the object is of the type requested. SW: Certain swing methods should only be invoked from the Swing event thread (From JDC Tech Tip): The Swing methods show(), tVisible(), and pack() will create the associated peer for the frame. With the creation of the peer, the system creates the event dispatch thread. This makes things problematic becau the event dispatch thread could be notifying listeners while pack and validate are still processing. This situation could result in two threads going through the Swing component-bad GUI -- it's a rious flaw that could result in deadlocks or other related threading issues. A pack call caus components to be realized. As they are being realized (that is, not necessarily visible), they could trigger listener notification on the event dispatch thread. Se: Non-transient non-rializable instance field in rializable class This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods. Objects of this class will not be derialized correctly if a non-Serializable object is stored in this field. Se: rialVersionUID isn't final This class defines a rialVersionUID field that is not final. The field should be made final if it is intended to specify the version UID for purpos of rialization. Se: rialVersionUID isn't long This class defines a rialVersionUID field that is not long. The field should be made long if it is intended to specify the version UID for purpos of rialization. Se: rialVersionUID isn't static This class defines a rialVersionUID field that is not static. The field should be made static if it is intended to specify the version UID for purpos of rialization. Se: Class is Serializable but its superclass doesn't define a void constructor This class implements the Serializable interface and its superclass does not. When such an object is derialized, the fields of the superclass need to be initialized by invoking the void constructor of the superclass. Since the superclass does not have one, rialization and derialization will fail at runtime. Se: Class is Externalizable but doesn't define a void constructor This class implements the Externalizable interface, but does not define a void constructor. When Externalizable objects are derialized, they first need to be constructed by invoking the void constructor. Since this class does not have one, rialization and derialization will fail at runtime. SnVI: Class is Serializable, but doesn't define rialVersionUID This class implements the Serializable interface, but does not define a rialVersionUID field. A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit rialVersionUID (e.g., adding a reference to String.class宝宝奶粉 will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may u different naming conventions for synthetic variables generated for references to class objects or inner class. To ensure interoperability of Serializable across versions, consider adding an explicit rialVersionUID. UCF: Uless control flow in method This method contains a uless control flow statement. Often, this is caud by inadvertently using an empty statement as the body of an if statement, e.g.: if (argv.length == 1); System.out.println("Hello, " + argv[0]); UI: Usage of GetResource may be unsafe if class is extended Calling Class().getResource(...) could give results other than expected if this class is extended by a class in another package. UR: Uninitialized read of field in constructor This constructor reads a field which has not yet been assigned a value. This is often caud when the programmer mistakenly us the field instead of one of the constructor's parameters. UwF: Unwritten field This field is never written. All reads of it will return the default value. Check for errors (should it have been initialized?), or remove it if it is uless. EI: Method may expo internal reprentation by returning reference to mutable object Returning a reference to a mutable object value stored in one of the object's fields expos the internal reprentation of the object. If instances are accesd by untrusted code, and unchecked changes to the mutable object would compromi curity or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations. FI: Finalizer should be protected, not public A class's finalize() method should have protected access, not public. MS: Method may expo internal static state by storing a mutable object into a static field This code stores a reference to an externally mutable object into a static field. If unchecked changes to the mutable object would compromi curity or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations. MS: Field isn't final and can't be protected from malicious code A mutable static field could be changed by malicious code or by accident from another package. Unfortunately, the way the field is ud doesn't allow any easy fix to this problem. MS: Public static method may expo internal reprentation by returning array A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. One fix is to return a copy of the array. MS: Field should be both final and package protected A mutable static field could be changed by malicious code or by accident from another package. The field could be made package protected and/or made final to avoid this vulnerability. MS: Field is a mutable array A final static field references an array and can be accesd by malicious code or by accident from another package. This code can freely modify the contents of the array. MS: Field is a mutable Hashtable A final static field references a Hashtable and can be accesd by malicious code or by accident from another package. This code can freely modify the contents of the Hashtable. MS: Field should be moved out of an interface and made package protected A final static field that is defined in an interface references a mutable object such as an array or hashtable. This mutable object could be changed by malicious code or by accident from another package. To solve this, the field needs to be moved to a class and made package protected to avoid this vulnerability. MS: Field should be package protected A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability. MS: Field isn't final but should be A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability. 2LW: Wait with two locks held Waiting on a monitor while two locks are held may cau deadlock. Performing a wait only releas the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining cloly. DC: Possible double check of field This method may contain an instance of double-checked locking. This idiom is not correct according to the mantics of the Java memory model. For more information, e the web page www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html. IS2: Inconsistent synchronization The fields of this class appear to be accesd inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that 1. The class contains a mix of locked and unlocked access, 2. At least one locked access was performed by one of the class's own methods, and 3. The number of unsynchronized field access (reads and writes) was no more than one third of all access, with writes being weighed twice as high as reads A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe. You can lect the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accesd without synchronization. Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held. Also, even when the detector is accurate in distinguishing locked vs. unlocked access, the code in question may still be correct. This description refers to the "IS2" version of the pattern detector, which has more accurate ways of detecting locked vs. unlocked access than the older "IS" detector. LI: Incorrect lazy initialization of static field This method contains an unsynchronized lazy initialization of a non-volatile static field. Becau the compiler or processor may reorder instructions, threads are not guaranteed to e a completely initialized object, if the method can be called by multiple threads. You can make the field volatile to correct the problem. For more information, e the Java Memory Model web site. ML: Method synchronizes on an updated field This method synchronizes on an object references from a mutable field. This is unlikely to have uful mantics, since different threads may be synchronizing on different objects. NN: Naked notify in method A call to notify() or notifyAll() was made without any (apparent) accompanying modification to mutable object state. In general, calling a notify method on a monitor is done becau some condition another thread is waiting for has become true. However, for the condition to be meaningful, it must involve a heap object that is visible to both threads. This bug does not necessarily indicate an error, since the change to mutable object state may have taken place in a method which then called the method containing the notification. No: Using notify() rather than notifyAll() in method 3月文案This method calls notify() rather than notifyAll(). Java monitors are often ud for multiple conditions. Calling notify() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied. RS: Class's readObject() method is synchronized This rializable class defines a readObject() which is synchronized. By definition, an object created by derialization is only reachable by one thread, and thus there is no need for readObject() to be synchronized. If the readObject() method itlf is causing the object to become visible to another thread, that is an example of very dubious coding style. Ru: Invokes run on a thread (did you mean to start it instead?) This method explicitly invokes run() on an object. In general, class implement the Runnable interface becau they are going to have their run() method invoked in a new thread, in which ca Thread.start() is the right method to call. SC: Constructor invokes Thread.start() The constructor starts a thread. This is likely to be wrong if the class is ever extended/subclasd, since the thread will be started before the subclass constructor is started. SP: Method spins on field This method spins in a loop which reads a field. The compiler may legally hoist the read out of the loop, turning the code into an infinite loop. The class should be changed so it us proper synchronization (including wait and notify calls). UG: Unsynchronized get method, synchronized t method This class contains similarly-named get and t methods where the t method is synchronized and the get method is not. This may result in incorrect behavior at runtime, as callers of the get method will not necessarily e a consistent state for the object. The get method should be made synchronized. UW: Unconditional wait in method This method contains a call to java.lang.Object.wait() which is not guarded by conditional control flow. If the condition that the method intends to wait for has already happened, the thread could wait indefinitely. VO: A volatile reference to an array doesn't treat the array elements as volatile This declares a volatile reference to an array, which might not be what you want. With a volatile reference to an array, reads and writes of the reference to the array are treated as volatile, but the array elements are non-volatile. To get volatile array elements, you will need to u one of the atomic array class in urrent (provided in Java 5.0). WS: Class's writeObject() method is synchronized but nothing el is This class has a writeObject() method which is synchronized; however, no other method of the class is synchronized. Wa: Wait not in loop in method This method contains a call to java.lang.Object.wait() which is not in a loop. If the monitor is ud for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred. Dm: Method invokes dubious Boolean constructor; u Boolean.valueOf(...) instead Creating new instances of java.lang.Boolean wastes memory, since Boolean objects are immutable and there are only two uful values of this type. U the Boolean.valueOf() method to create Boolean objects instead. Dm: Explicit garbage collection; extremely dubious except in benchmarking code Code explicitly invokes garbage collection. Except for specific u in benchmarking, this is very dubious. In the past, situations where people have explicitly invoked the garbage collector in routines such as clo or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl. Dm: Method invokes dubious new String(String) constructor; just u the argument 笔记本怎么重启Using the java.lang.String(String) constructor wastes memory becau the object so constructed will be functionally indistinguishable from the String pasd as a parameter. Just u the argument String directly. Dm: Method invokes dubious String.equals(""); u String.length() == 0 instead An object is compared to the empty String object using the equals() method here. Checking that the String object's length is zero may be faster, and removes String constants from the class file. Dm: Method invokes toString() method on a String; just u the String Calling String() is just a redundant operation. Just u the String. Dm: Method invokes dubious new String() constructor; just u "" Creating a new java.lang.String object using the no-argument constructor wastes memory becau the object so created will be functionally indistinguishable from the empty string constant "". Java guarantees that identical string constants will be reprented by the same String object. Therefore, you should just u the empty string constant directly. FI: Empty finalizer should be deleted Empty finalize() methods are uless, so they should be deleted. FI: Finalizer does nothing but call superclass finalizer The only thing this finalize() method does is call the superclass's finalize() method, making it redundant. Delete it. ITA: Method us toArray() with zero-length array argument This method us the toArray() method of a collection derived class, and pass in a zero-length prototype array argument. It is more efficient to u Array(new Foo[myCollection.size()]) If the array pasd in is big enough to store all of the elements of the collection, then it is populated and returned directly. This avoids the need to create a cond array (by reflection) to return as the result. SBSC: Method concatenates strings using + in a loop The method ems to be building a String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadractic in the number of iterations, as the growing string is recopied in each iteration. Better performance can be obtained by using a StringBuffer (or StringBuilder in Java 1.5) explicitly. For example: // This is bad String s = ""; for (int i = 0; i < field.length; ++i) { s = s + field[i]; } // This is better StringBuffer buf = new StringBuffer(); for (int i = 0; i < field.length; ++i) { buf.append(field[i]); 吴季刚 } String s = String(); SIC: Should be a static inner class This class is an inner class, but does not u its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class. SIC: Could be refactored into a named static inner class This class is an inner class, but does not u its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class. Since anonymous inner class cannot be marked as static, doing this will requiring refactoring the inner class so that it is a named inner class. SIC: Could be refactored into a static inner class This class is an inner class, but does not u its embedded reference to the object which created it except during construction of the inner object. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class. Since the reference to the outer object is required during construction of the inner instance, the inner class will need to be refactored so as to pass a reference to the outer instance to the constructor for the inner class. SS: Unread field: should this field be static? This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static. UPM: Private method is never called This private method is never called. Although it is possible that the method will be invoked through reflection, it is more likely that the method is never ud, and should be removed. UrF: Unread field This field is never read. Consider removing it from the class. UuF: Unud field This field is never ud. Consider removing it from the class. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
本文发布于:2023-07-12 23:28:27，感谢您对本站的认可！
本文链接：https://www.wtabcd.cn/fanwen/fan/82/1093332.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
