Bug: The method name MsmPlanDAOTest.TestViewMsmPlanList() doesn’t start with a lower case letter Pattern id: NM_METHOD_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
Bug: Confusing to have methods xxx.SellerBrandServiceImpl.getAllGrantSellerBrandsByBrandId(long) and xxx.DefaultSellerBrandManager.getALLGrantSellerBrandsByBrandId(long) Pattern id: NM_CONFUSING, type: Nm, category: BAD_PRACTICE
The referenced methods have names that differ only by capitalization.
解釋：
同一個包兩個類中有一模一樣的兩個方法（包括參數）
解決方法：
最好可以修改為不一樣的方法名稱
MF_CLASS_MASKS_FIELD
Bug: Field PDHSubCardInstanceDialogCommand.m_instance masks field in superclass ViewNEProperity Pattern id: MF_CLASS_MASKS_FIELD, type: MF, category: CORRECTNESS
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.
解釋：
這是什麼意思呢？想要字段也能夠具有多态性嗎？太迷惑了。
當你想要更新一個m_instance時，你要更新哪個？你用到它時，你知道哪個又被更新了？
解決方法：
要麼去掉其中一個字段，要麼重新命名。
NM_CLASS_NAMING_CONVENTION
Bug: The class name crossConnectIndexCollecter doesn’t start with an upper case letter
Bug: Ambiguous invocation of either an outer or inherited method JExtendDialog.onOK() Pattern id: IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD, type: IA, category: STYLE
Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.
Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or the valueOf() method when creating instances of Double and Float.
Bug: WindowHandlerManager M y S i n g l e S e l e c t i o n M o d e l i s S e r i a l i z a b l e ; c o n s i d e r d e c l a r i n g a s e r i a l V e r s i o n U I D P a t t e r n i d : S E N O S E R I A L V E R S I O N I D , t y p e : S n V I , c a t e g o r y : B A D P R A C T I C E T h i s c l a s s i m p l e m e n t s t h e S e r i a l i z a b l e i n t e r f a c e , b u t d o e s n o t d e f i n e a s e r i a l V e r s i o n U I D f i e l d . A c h a n g e a s s i m p l e a s a d d i n g a r e f e r e n c e t o a . c l a s s o b j e c t w i l l a d d s y n t h e t i c f i e l d s t o t h e c l a s s , w h i c h w i l l u n f o r t u n a t e l y c h a n g e t h e i m p l i c i t s e r i a l V e r s i o n U I D ( e . g . , a d d i n g a r e f e r e n c e t o S t r i n g . c l a s s w i l l g e n e r a t e a s t a t i c f i e l d c l a s s MySingleSelectionModel is Serializable; consider declaring a serialVersionUID Pattern id: SE_NO_SERIALVERSIONID, type: SnVI, category: BAD_PRACTICE This class implements the Serializable interface, but does not define a serialVersionUID 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 serialVersionUID (e.g., adding a reference to String.class will generate a static field class MySingleSelectionModelisSerializable;considerdeclaringaserialVersionUIDPatternid:SENOSERIALVERSIONID,type:SnVI,category:BADPRACTICEThisclassimplementstheSerializableinterface,butdoesnotdefineaserialVersionUIDfield.Achangeassimpleasaddingareferencetoa.classobjectwilladdsyntheticfieldstotheclass,whichwillunfortunatelychangetheimplicitserialVersionUID(e.g.,addingareferencetoString.classwillgenerateastaticfieldclassjava l a n g lang langString). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure interoperability of Serializable across versions, consider adding an explicit serialVersionUID.
Bug: com.taobao.sellerservice.core.test.BaseTestJunit.autoSetBean() invokes reflect.Field.setAccessible(boolean), which should be invoked from within a doPrivileged block Pattern id: DP_DO_INSIDE_DO_PRIVILEGED, type: DP, category: BAD_PRACTICE
This code invokes a method that requires a security permission check. If this code will be granted security permissions, but might be invoked by code that does not have security permissions, then the invocation needs to occur inside a doPrivileged block.
Bug: The field name TopoControlPaneII.SyncSelection doesn’t start with a lower case letter Pattern id: NM_FIELD_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
解釋：
為神馬字段是大寫開頭的？喂神馬？喂神馬啊？
解決方法：
建議按照sun規定的命名方式
Bug: Field only ever set to null: RaisecomStatus.infoURL Pattern id: UWF_NULL_FIELD, type: UwF, category: CORRECTNESS
Bug: Possible null pointer dereference of busCatId Pattern id: NP_NULL_ON_SOME_PATH, type: NP, category: CORRECTNESS
There is a branch of statement that, if executed, guarantees that a null value will be dereferenced, which would generate a NullPointerException when the code is executed. Of course, the problem might be that the branch or statement is infeasible and that the null pointer exception can’t ever be executed; deciding that is beyond the ability of FindBugs.
解釋：
方法中存在空指針
解決方法：
增加字段busCatId為空的判斷
NP_NULL_ON_SOME_PATH
Bug:.HierarchicalManagerImpl.isExistByName(String, long) forgets to throw new exception.HierarchicalServiceException(String, Throwable) Pattern id: RV_EXCEPTION_NOT_THROWN, type: RV, category: CORRECTNESS
This code creates an exception (or error) object, but doesn’t do anything with it. For example, something like
if (x < 0)
new IllegalArgumentException(“x must be nonnegative”);
It was probably the intent of the programmer to throw the created exception:
if (x < 0)
throw new IllegalArgumentException(“x must be nonnegative”);
解釋：
此代碼建立了一個異常（或錯誤）的對象，但并不做任何事情。
可能作者是想繼續抛出異常資訊吧，可是卻産生了一個對象，啥也不幹。
解決方法：
抛出這個錯誤
FI_FINALIZER_NULLS_FIELDS
Bug: CustomerResTreeDialog.java:[line 67] is set to null inside finalize method Pattern id: FI_FINALIZER_NULLS_FIELDS, type: FI, category: BAD_PRACTICE
Bug: Inconsistent synchronization of URLAlarmMonitor.m_Counter; locked 50% of time Pattern id: IS2_INCONSISTENT_SYNC, type: IS, category: MT_CORRECTNESS
Bug: Method JTAMainFrame.initView(JFrame) makes inefficient use of keySet iterator instead of entrySet iterator Pattern id: WMI_WRONG_MAP_ITERATOR, type: WMI, category: PERFORMANCE
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
List eachCompanyBlackItems = tempEntiy.getValue();
BC_VACUOUS_INSTANCEOF
Bug: instanceof will always return true, since all TopoTreeNode are instances of TopoTreeNode Pattern id: BC_VACUOUS_INSTANCEOF, type: BC, category: STYLE
Bug: Load of known null value Pattern id: NP_LOAD_OF_KNOWN_NULL_VALUE, type: NP, category: STYLE
The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was nonnull).
Bug: SingleNePollConfigDialog.collectValues(Hashtable) may expose internal representation by storing an externally mutable object into SingleNePollConfigDialog.values Pattern id: EI_EXPOSE_REP2, type: EI2, category: MALICIOUS_CODE
This code stores a reference to an externally mutable object into the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.
Bug: Method InitDBPoolParaTask.execute() concatenates strings using + in a loop Pattern id: SBSC_USE_STRINGBUFFER_CONCATENATION, type: SBSC, category: PERFORMANCE
The method seems 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 quadratic 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.
[Bx] Method invokes inefficient Number constructor; use static valueOf instead [DM_NUMBER_CTOR]
Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.
public static Integer valueOf(int i) { final int offset = 128; if (i >= -128 && i <= 127) { // must cache return IntegerCache.cache[i + offset]; } return new Integer(i); } private static class IntegerCache { private IntegerCache(){} static final Integer cache[] = new Integer[-(-128) + 127 + 1]; static { for(int i = 0; i < cache.length; i++) cache = new Integer(i - 128); } }
public static void main(String []args) { Integer a = 100; Integer b = 100; System.out.println(ab); Integer c = new Integer(100); Integer d = new Integer(100); System.out.println(cd); }
結果是：
true false
因為：java在編譯的時候 Integer a = 100; 被翻譯成-> Integer a = Integer.valueOf(100);，是以a和b得到都是一個Cache對象，并且是同一個！而c和d是新建立的兩個不同的對象，是以c自然不等于d。
再看看這段代碼：
public static void main(String args[]) throws Exception{ Integer a = 100; Integer b = a; a = a + 1; //或者a++; System.out.println(a==b); }
