[OFBIZ-9807] [FB] Package org.apache.ofbiz.product.product

• Type: Sub-task
• Status: Closed
• Priority: Minor
• Resolution: Implemented
• Affects Version/s: Trunk
• Fix Version/s: 17.12.01
• Component/s: product
• Assignee: Michael Brohl
• Reporter: Julian Leichert
• Created: 05/Oct/17 08:30
• Updated: 09/Dec/17 18:08
• Resolved: 09/Dec/17 18:08

Description

KeywordIndex.java:76, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of delegator, which is known to be non-null in org.apache.ofbiz.product.product.KeywordIndex.indexKeywords(GenericValue, boolean)

This method contains a redundant check of a known non-null value against the constant null.

KeywordIndex.java:95, DM_CONVERT_CASE

• Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.product.product.KeywordIndex.indexKeywords(GenericValue, boolean)

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )

versions instead.

KeywordIndex.java:230, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to delegator in org.apache.ofbiz.product.product.KeywordIndex.addWeightedKeywordSourceString(GenericValue, String, List)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductContentWrapper.java:114, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE

• RCN: Nullcheck of ProductContentWrapper.productContentCache at line 127 of value previously dereferenced in org.apache.ofbiz.product.product.ProductContentWrapper.getProductContentAsText(GenericValue, String, Locale, String, String, String, Delegator, LocalDispatcher, String)

A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.

ProductEvents.java:358, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to productAssoc in org.apache.ofbiz.product.product.ProductEvents.updateProductAssoc(HttpServletRequest, HttpServletResponse)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductEvents.java:672, RpC_REPEATED_CONDITIONAL_TEST

• RpC: Repeated conditional test in org.apache.ofbiz.product.product.ProductEvents.checkUpdateFeatureApplByDescription(String, GenericValue, String, String, GenericValue, String, Timestamp, Delegator, Set, Set)

The code contains a conditional test is performed twice, one right after the other (e.g., x == 0 || x == 0). Perhaps the second occurrence is intended to be something else (e.g., x == 0 || y == 0).

ProductEvents.java:672, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of descriptionsToRemove, which is known to be non-null in org.apache.ofbiz.product.product.ProductEvents.checkUpdateFeatureApplByDescription(String, GenericValue, String, String, GenericValue, String, Timestamp, Delegator, Set, Set)

This method contains a redundant check of a known non-null value against the constant null.

ProductEvents.java:709, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of productFeatureAndAppl, which is known to be non-null in org.apache.ofbiz.product.product.ProductEvents.checkUpdateFeatureApplByDescription(String, GenericValue, String, String, GenericValue, String, Timestamp, Delegator, Set, Set)

This method contains a redundant check of a known non-null value against the constant null.

ProductPromoContentWrapper.java:119, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE

• RCN: Nullcheck of ProductPromoContentWrapper.productPromoContentCache at line 132 of value previously dereferenced in org.apache.ofbiz.product.product.ProductPromoContentWrapper.getProductPromoContentAsText(GenericValue, String, Locale, String, String, String, Delegator, LocalDispatcher, String)

A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.

ProductSearch.java:835, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$CatalogConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:884, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$CatalogConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:884, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$CatalogConstraint assumes the argument is of type ProductSearch$CatalogConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:917, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$CategoryConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:977, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$CategoryConstraint assumes the argument is of type ProductSearch$CategoryConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:977, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$CategoryConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1011, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$FeatureConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1062, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$FeatureConstraint assumes the argument is of type ProductSearch$FeatureConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1062, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$FeatureConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1094, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$FeatureCategoryConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1144, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$FeatureCategoryConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1144, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$FeatureCategoryConstraint assumes the argument is of type ProductSearch$FeatureCategoryConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1175, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$FeatureGroupConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1224, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$FeatureGroupConstraint assumes the argument is of type ProductSearch$FeatureGroupConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1224, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$FeatureGroupConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1256, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$FeatureSetConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1319, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$FeatureSetConstraint assumes the argument is of type ProductSearch$FeatureSetConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1319, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$FeatureSetConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1347, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$KeywordConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1428, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$KeywordConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1428, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$KeywordConstraint assumes the argument is of type ProductSearch$KeywordConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1465, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$LastUpdatedRangeConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1466, EI_EXPOSE_REP2

• EI2: new org.apache.ofbiz.product.product.ProductSearch$LastUpdatedRangeConstraint(Timestamp, Timestamp) may expose internal representation by storing an externally mutable object into ProductSearch$LastUpdatedRangeConstraint.fromDate

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.

ProductSearch.java:1467, EI_EXPOSE_REP2

• EI2: new org.apache.ofbiz.product.product.ProductSearch$LastUpdatedRangeConstraint(Timestamp, Timestamp) may expose internal representation by storing an externally mutable object into ProductSearch$LastUpdatedRangeConstraint.thruDate

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.

ProductSearch.java:1484, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$LastUpdatedRangeConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1484, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$LastUpdatedRangeConstraint assumes the argument is of type ProductSearch$LastUpdatedRangeConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1519, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$StoreGroupPriceConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1560, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$StoreGroupPriceConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1579, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$ListPriceRangeConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1651, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$ListPriceRangeConstraint assumes the argument is of type ProductSearch$ListPriceRangeConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1651, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$ListPriceRangeConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1684, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$SupplierConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1711, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$SupplierConstraint assumes the argument is of type ProductSearch$SupplierConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1711, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$SupplierConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1734, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$ExcludeVariantsConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1753, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$ExcludeVariantsConstraint assumes the argument is of type ProductSearch$ExcludeVariantsConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1753, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$ExcludeVariantsConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1766, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$AvailabilityDateConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1785, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$AvailabilityDateConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1785, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$AvailabilityDateConstraint assumes the argument is of type ProductSearch$AvailabilityDateConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1801, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$GoodIdentificationConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1821, RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN

• RC: Suspicious comparison of Boolean references in org.apache.ofbiz.product.product.ProductSearch$GoodIdentificationConstraint.addConstraint(ProductSearch$ProductSearchContext)

This method compares two Boolean values using the == or != operator. Normally, there are only two Boolean values (Boolean.TRUE and Boolean.FALSE), but it is possible to create other Boolean objects using the new Boolean(b) constructor. It is best to avoid such objects, but if they do exist, then checking Boolean objects for equality using == or != will give results than are different than you would get using .equals(...)

ProductSearch.java:1854, RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN

• RC: Suspicious comparison of Boolean references in org.apache.ofbiz.product.product.ProductSearch$GoodIdentificationConstraint.prettyPrintConstraint(Delegator, boolean, Locale)

This method compares two Boolean values using the == or != operator. Normally, there are only two Boolean values (Boolean.TRUE and Boolean.FALSE), but it is possible to create other Boolean objects using the new Boolean(b) constructor. It is best to avoid such objects, but if they do exist, then checking Boolean objects for equality using == or != will give results than are different than you would get using .equals(...)

ProductSearch.java:1879, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$GoodIdentificationConstraint assumes the argument is of type ProductSearch$GoodIdentificationConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1879, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$GoodIdentificationConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1894, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$ProductFieldConstraint is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1913, HE_EQUALS_USE_HASHCODE

• HE: org.apache.ofbiz.product.product.ProductSearch$ProductFieldConstraint defines equals and uses 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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode()

{ assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

ProductSearch.java:1913, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS

• BC: Equals method for org.apache.ofbiz.product.product.ProductSearch$ProductFieldConstraint assumes the argument is of type ProductSearch$ProductFieldConstraint

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

ProductSearch.java:1949, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$SortKeywordRelevancy is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:1993, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$SortProductField is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:2045, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$SortProductPrice is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearch.java:2130, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearch$SortProductFeature is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearchSession.java:78, SE_NO_SERIALVERSIONID

• SnVI: org.apache.ofbiz.product.product.ProductSearchSession$ProductSearchOptions is Serializable; consider declaring a serialVersionUID

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$java$lang$String). 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.

ProductSearchSession.java:393, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of keywordSet, which is known to be non-null in org.apache.ofbiz.product.product.ProductSearchSession.checkDoKeywordOverride(HttpServletRequest, HttpServletResponse)

This method contains a redundant check of a known non-null value against the constant null.

ProductSearchSession.java:475, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of resultSortOrder, which is known to be non-null in org.apache.ofbiz.product.product.ProductSearchSession.searchGetSortOrderString(boolean, HttpServletRequest)

This method contains a redundant check of a known non-null value against the constant null.

ProductSearchSession.java:638, WMI_WRONG_MAP_ITERATOR

• WMI: org.apache.ofbiz.product.product.ProductSearchSession.processSearchParameters(Map, HttpServletRequest) makes inefficient use of keySet iterator instead of entrySet iterator

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.

ProductSearchSession.java:897, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of paging, which is known to be non-null in org.apache.ofbiz.product.product.ProductSearchSession.getProductSearchResult(HttpServletRequest, Delegator, String)

This method contains a redundant check of a known non-null value against the constant null.

ProductSearchSession.java:919, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to addOnTopProductCategoryMembers in org.apache.ofbiz.product.product.ProductSearchSession.getProductSearchResult(HttpServletRequest, Delegator, String)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductSearchSession.java:1164, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

• RCN: Redundant nullcheck of resultSortOrder, which is known to be non-null in org.apache.ofbiz.product.product.ProductSearchSession.makeSearchParametersString(ProductSearchSession$ProductSearchOptions)

This method contains a redundant check of a known non-null value against the constant null.

ProductServices.java:423, BX_UNBOXING_IMMEDIATELY_REBOXED

• Bx: Boxed value is unboxed and then immediately reboxed in org.apache.ofbiz.product.product.ProductServices.prodFindAssociatedByType(DispatchContext, Map)

A boxed value is unboxed and then immediately reboxed.

ProductServices.java:601, WMI_WRONG_MAP_ITERATOR

• WMI: org.apache.ofbiz.product.product.ProductServices.makeGroup(Delegator, Map, List, List, int) makes inefficient use of keySet iterator instead of entrySet iterator

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.

ProductServices.java:969, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to fileExtension in org.apache.ofbiz.product.product.ProductServices.addAdditionalViewForProduct(DispatchContext, Map)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductServices.java:1000, RV_RETURN_VALUE_IGNORED_BAD_PRACTICE

• RV: Exceptional return value of java.io.File.delete() ignored in org.apache.ofbiz.product.product.ProductServices.addAdditionalViewForProduct(DispatchContext, Map)

This method returns a value that is not checked. The return value should be checked since it can indicate an unusual or unexpected function execution. For example, the File.delete() 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.

ProductServices.java:1068, DM_CONVERT_CASE

• Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.product.product.ProductServices.addAdditionalViewForProduct(DispatchContext, Map)

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )

versions instead.

ProductServices.java:1166, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to dataResourceResult in org.apache.ofbiz.product.product.ProductServices.addImageResource(LocalDispatcher, Delegator, Map, String, String)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductServices.java:1178, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to contentResult in org.apache.ofbiz.product.product.ProductServices.addImageResource(LocalDispatcher, Delegator, Map, String, String)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductServices.java:1268, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to fileExtension in org.apache.ofbiz.product.product.ProductServices.addImageForProductPromo(DispatchContext, Map)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductServices.java:1283, RV_RETURN_VALUE_IGNORED_BAD_PRACTICE

• RV: Exceptional return value of java.io.File.mkdirs() ignored in org.apache.ofbiz.product.product.ProductServices.addImageForProductPromo(DispatchContext, Map)

This method returns a value that is not checked. The return value should be checked since it can indicate an unusual or unexpected function execution. For example, the File.delete() 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.

ProductServices.java:1377, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to dataResourceResult in org.apache.ofbiz.product.product.ProductServices.addImageForProductPromo(DispatchContext, Map)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductServices.java:1389, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to contentResult in org.apache.ofbiz.product.product.ProductServices.addImageForProductPromo(DispatchContext, Map)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ProductWorker.java:1233, DLS_DEAD_LOCAL_STORE

• DLS: Dead store to resultOutput in org.apache.ofbiz.product.product.ProductWorker.filterOutOfStockProducts(List, LocalDispatcher, Delegator)

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.