Julian Leichert created OFBIZ-9774:
--------------------------------------
Summary: [FB] Package org.apache.ofbiz.product.config
Key: OFBIZ-9774
URL: https://issues.apache.org/jira/browse/OFBIZ-9774
Project: OFBiz
Issue Type: Sub-task
Components: product
Affects Versions: Trunk
Reporter: Julian Leichert
Priority: Minor
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
}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
