[
https://issues.apache.org/jira/browse/OFBIZ-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741227#comment-16741227
]
Michael Brohl commented on OFBIZ-9774:
--------------------------------------
I'll work on it to fix the error.
> [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
> Assignee: Michael Brohl
> Priority: Minor
> Fix For: 17.12.01
>
> Attachments: OFBIZ-9774_org.apache.ofbiz.product.config_bugfixes.patch
>
>
> 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
(v7.6.3#76005)
