[
https://issues.apache.org/jira/browse/OFBIZ-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-9590.
--------------------------------
Resolution: Implemented
Fix Version/s: Upcoming Release
Thanks Dennis,
your patch is in trunk r1811685.
> [FB] Package org.apache.ofbiz.base.util.collections
> ---------------------------------------------------
>
> Key: OFBIZ-9590
> URL: https://issues.apache.org/jira/browse/OFBIZ-9590
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
> Affects Versions: Trunk
> Reporter: Dennis Balkir
> Assignee: Michael Brohl
> Priority: Minor
> Fix For: Upcoming Release
>
> Attachments:
> OFBIZ-9590_org.apache.ofbiz.base.util.collections_bugfixes.patch
>
>
> FlexibleMapAccessor.java:44, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.collections.FlexibleMapAccessor 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.
> - FlexibleServletAccessor.java:47, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.collections.FlexibleServletAccessor 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.
> - FlexibleServletAccessor.java:181,
> EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS
> Eq:
> org.apache.ofbiz.base.util.collections.FlexibleServletAccessor.equals(Object)
> checks for operand being a String
> This equals method is checking to see if the argument is some incompatible
> type (i.e., a class that is neither a supertype nor subtype of the class that
> defines the equals method). For example, the Foo class might have an equals
> method that looks like:
> public boolean equals(Object o) {
> if (o instanceof Foo)
> return name.equals(((Foo)o).name);
> else if (o instanceof String)
> return name.equals(o);
> else return false;
> This is considered bad practice, as it makes it very hard to implement an
> equals method that is symmetric and transitive. Without those properties,
> very unexpected behavoirs are possible.
> - FlexibleServletAccessor.java:208, SE_NO_SERIALVERSIONID
> SnVI:
> org.apache.ofbiz.base.util.collections.FlexibleServletAccessor$AttributeAccessor
> 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.
> - GenericMap.java:68, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.base.util.collections.GenericMap 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
> }
> - GenericMapValues.java:45, EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS
> Eq: org.apache.ofbiz.base.util.collections.GenericMapValues.equals(Object)
> checks for operand being a java.util.List
> This equals method is checking to see if the argument is some incompatible
> type (i.e., a class that is neither a supertype nor subtype of the class that
> defines the equals method). For example, the Foo class might have an equals
> method that looks like:
> public boolean equals(Object o) {
> if (o instanceof Foo)
> return name.equals(((Foo)o).name);
> else if (o instanceof String)
> return name.equals(o);
> else return false;
> This is considered bad practice, as it makes it very hard to implement an
> equals method that is symmetric and transitive. Without those properties,
> very unexpected behavoirs are possible.
> - GenericMapValues.java:45, EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS
> Eq: org.apache.ofbiz.base.util.collections.GenericMapValues.equals(Object)
> checks for operand being a java.util.Set
> This equals method is checking to see if the argument is some incompatible
> type (i.e., a class that is neither a supertype nor subtype of the class that
> defines the equals method). For example, the Foo class might have an equals
> method that looks like:
> public boolean equals(Object o) {
> if (o instanceof Foo)
> return name.equals(((Foo)o).name);
> else if (o instanceof String)
> return name.equals(o);
> else return false;
> This is considered bad practice, as it makes it very hard to implement an
> equals method that is symmetric and transitive. Without those properties,
> very unexpected behavoirs are possible.
> - LRUMap.java:33, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.collections.LRUMap 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.
> - LifoSet.java:35, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.collections.LifoSet 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.
> - MapComparator.java:32, SE_COMPARATOR_SHOULD_BE_SERIALIZABLE
> Se: org.apache.ofbiz.base.util.collections.MapComparator implements
> Comparator but not Serializable
> This class implements the Comparator interface. You should consider whether
> or not it should also implement the Serializable interface. If a comparator
> is used to construct an ordered collection such as a TreeMap, then the
> TreeMap will be serializable only if the comparator is also serializable. As
> most comparators have little or no state, making them serializable is
> generally easy and good defensive programming.
> - MapComparator.java:51, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.base.util.collections.MapComparator.equals(Object) does
> not check for null argument
> This implementation of equals(Object) violates the contract defined by
> java.lang.Object.equals() because it does not check for null being passed as
> the argument. All equals() methods should return false if passed a null value.
> - MapComparator.java:51, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.base.util.collections.MapComparator 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
> }
> - MapContext.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.collections.MapContext$ListSet is final
> but declares protected field
> org.apache.ofbiz.base.util.collections.MapContext$ListSet.listImpl
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> - MapContext.java:345, RI_REDUNDANT_INTERFACES
> RI: Class org.apache.ofbiz.base.util.collections.MapContext$ListSet
> implements same interface as superclass
> This class declares that it implements an interface that is also implemented
> by a superclass. This is redundant because once a superclass implements an
> interface, all subclasses by default also implement this interface. It may
> point out that the inheritance hierarchy has changed since this class was
> created, and consideration should be given to the ownership of the
> interface's implementation.
> - ResourceBundleMapWrapper.java:-1, SE_BAD_FIELD
> Se: Class org.apache.ofbiz.base.util.collections.ResourceBundleMapWrapper
> defines non-transient non-serializable instance field initialResourceBundle
> 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.
> - ResourceBundleMapWrapper.java:-1, SE_BAD_FIELD
> Se: Class org.apache.ofbiz.base.util.collections.ResourceBundleMapWrapper
> defines non-transient non-serializable instance field rbmwStack
> 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.
> - ResourceBundleMapWrapper.java:-1, SE_BAD_FIELD
> Se: Class
> org.apache.ofbiz.base.util.collections.ResourceBundleMapWrapper$InternalRbmWrapper
> defines non-transient non-serializable instance field resourceBundle
> 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.
> - ResourceBundleMapWrapper.java:36, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.collections.ResourceBundleMapWrapper 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.
> - ResourceBundleMapWrapper.java:153, SE_NO_SERIALVERSIONID
> SnVI:
> org.apache.ofbiz.base.util.collections.ResourceBundleMapWrapper$InternalRbmWrapper
> 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.
> - ResourceBundleMapWrapper.java:223, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of java.util.ResourceBundle.getObject(String), which
> is known to be non-null in
> org.apache.ofbiz.base.util.collections.ResourceBundleMapWrapper$InternalRbmWrapper.containsKey(Object)
> This method contains a redundant check of a known non-null value against the
> constant null.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
