[
https://issues.apache.org/jira/browse/OFBIZ-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-9807.
--------------------------------
Resolution: Implemented
Fix Version/s: Upcoming Release
Thanks Julian,
your patch is in trunk r1817650.
> [FB] Package org.apache.ofbiz.product.product
> ---------------------------------------------
>
> Key: OFBIZ-9807
> URL: https://issues.apache.org/jira/browse/OFBIZ-9807
> Project: OFBiz
> Issue Type: Sub-task
> Components: product
> Affects Versions: Trunk
> Reporter: Julian Leichert
> Assignee: Michael Brohl
> Priority: Minor
> Fix For: Upcoming Release
>
> Attachments:
> OFBIZ-9807_org.apache.ofbiz.product.product_bugfixes.patch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
