[ https://issues.apache.org/jira/browse/OFBIZ-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Brohl closed OFBIZ-9774. -------------------------------- Resolution: Implemented Fix Version/s: Upcoming Release Thanks Julian, your patch is in trunk r1817618. > [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: Upcoming Release > > 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 (v6.4.14#64029)