Minor Description
ProductConfigItemContentWrapper.java:125, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of ProductConfigItemContentWrapper.configItemContentCache at line 137 of value previously dereferenced in org.apache.ofbiz.product.config.ProductConfigItemContentWrapper.getProductConfigItemContentAsText(GenericValue, String, Locale, 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.
ProductConfigWorker.java:397, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
- RCN: Redundant nullcheck of configWrapper, which is known to be non-null in org.apache.ofbiz.product.config.ProductConfigWorker.loadProductConfigWrapper(Delegator, LocalDispatcher, String, String, String, String, String, String, Locale, GenericValue)
This method contains a redundant check of a known non-null value against the constant null.
ProductConfigWrapper.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED
- Se: The field org.apache.ofbiz.product.config.ProductConfigWrapper.dispatcher is transient but isn't set by deserialization
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
ProductConfigWrapper.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED
- Se: The field org.apache.ofbiz.product.config.ProductConfigWrapper.delegator is transient but isn't set by deserialization
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
ProductConfigWrapper.java:-1, SE_BAD_FIELD
- Se: Class org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigItem defines non-transient non-serializable instance field content
This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods. Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field.
ProductConfigWrapper.java:50, SE_NO_SERIALVERSIONID
- SnVI: org.apache.ofbiz.product.config.ProductConfigWrapper 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.
ProductConfigWrapper.java:226, HE_EQUALS_USE_HASHCODE
- HE: org.apache.ofbiz.product.config.ProductConfigWrapper 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 }ProductConfigWrapper.java:388, SE_NO_SERIALVERSIONID
- SnVI: org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigItem 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.
ProductConfigWrapper.java:388, SE_INNER_CLASS
- Se: org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigItem is serializable and an inner class
This Serializable class is an inner class. Any attempt to serialize it will also serialize the associated outer instance. The outer instance is serializable, so this won't fail, but it might serialize a lot more data than intended. If possible, making the inner class a static inner class (also known as a nested class) should solve the problem.
ProductConfigWrapper.java:517, HE_EQUALS_USE_HASHCODE
- HE: org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigItem 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 }ProductConfigWrapper.java:544, SE_NO_SERIALVERSIONID
- SnVI: org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigOption 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.
ProductConfigWrapper.java:544, SE_INNER_CLASS
- Se: org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigOption is serializable and an inner class
This Serializable class is an inner class. Any attempt to serialize it will also serialize the associated outer instance. The outer instance is serializable, so this won't fail, but it might serialize a lot more data than intended. If possible, making the inner class a static inner class (also known as a nested class) should solve the problem.
ProductConfigWrapper.java:681, NM_CONFUSING
- Nm: Confusing to have methods org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigOption.getId() and org.apache.ofbiz.service.calendar.RecurrenceInfo.getID()
The referenced methods have names that differ only by capitalization.
ProductConfigWrapper.java:778, HE_EQUALS_USE_HASHCODE
- HE: org.apache.ofbiz.product.config.ProductConfigWrapper$ConfigOption 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 }Attachments
Attachments
Issue Links
- breaks
-
OFBIZ-10741 Blank page is displayed on ecommerce
-
- Closed
-