ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Brohl (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (OFBIZ-9576) [FB] Package org.apache.ofbiz.base.util.cache.test
Date Sat, 07 Oct 2017 12:10:00 GMT

     [ https://issues.apache.org/jira/browse/OFBIZ-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Brohl reassigned OFBIZ-9576:
------------------------------------

    Assignee: Michael Brohl

> [FB] Package org.apache.ofbiz.base.util.cache.test
> --------------------------------------------------
>
>                 Key: OFBIZ-9576
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9576
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: base
>    Affects Versions: Trunk
>            Reporter: Dennis Balkir
>            Assignee: Michael Brohl
>            Priority: Minor
>         Attachments: OFBIZ-9576_org.apache.ofbiz.base.util.cache.test_bugfixes.patch
>
>
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Addition is final but
declares protected field org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Addition.newValue
> 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.
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Removal is final but declares
protected field org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Removal.oldValue
> 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.
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update is final but declares
protected field org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update.newValue
> 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.
> - UtilCacheTests.java:-1, CI_CONFUSED_INHERITANCE
> CI: Class org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update is final but declares
protected field org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Update.oldValue
> 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.
> - UtilCacheTests.java:39, SE_NO_SUITABLE_CONSTRUCTOR
> Se: org.apache.ofbiz.base.util.cache.test.UtilCacheTests is Serializable but its superclass
doesn't define an accessible void constructor
> This class implements the Serializable interface and its superclass does not. When such
an object is deserialized, the fields of the superclass need to be initialized by invoking
the void constructor of the superclass. Since the superclass does not have one, serialization
and deserialization will fail at runtime.
> - UtilCacheTests.java:39, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.base.util.cache.test.UtilCacheTests 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.
> - UtilCacheTests.java:148, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Listener 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
>   }
> - UtilCacheTests.java:148, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Listener.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.
> - UtilCacheTests.java:148, BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS
> BC: Equals method for org.apache.ofbiz.base.util.cache.test.UtilCacheTests$Listener assumes
the argument is of type UtilCacheTests$Listener
> The equals(Object o) method shouldn't make any assumptions about the type of o. It should
simply return false if o is not the same type as this.
> - UtilCacheTests.java:345, DM_STRING_CTOR
> Dm: org.apache.ofbiz.base.util.cache.test.UtilCacheTests.testPutIfAbsentAndGet() invokes
inefficient new String(String) constructor
> Using the java.lang.String(String) constructor wastes memory because the object so constructed
will be functionally indistinguishable from the String passed as a parameter.  Just use the
argument String directly.
> - UtilCacheTests.java:350, ES_COMPARING_STRINGS_WITH_EQ
> ES: Comparison of String objects using == or != in org.apache.ofbiz.base.util.cache.test.UtilCacheTests.testPutIfAbsentAndGet()
> This code compares java.lang.String objects for reference equality using the == or !=
operators. Unless both strings are either constants in a source file, or have been interned
using the String.intern() method, the same string value may be represented by two different
String objects. Consider using the equals(Object) method instead.
> - UtilCacheTests.java:365, DM_STRING_CTOR
> Dm: org.apache.ofbiz.base.util.cache.test.UtilCacheTests.testChangeMemSize() invokes
inefficient new String(String) constructor
> Using the java.lang.String(String) constructor wastes memory because the object so constructed
will be functionally indistinguishable from the String passed as a parameter.  Just use the
argument String directly.
> - UtilCacheTests.java:396, DM_STRING_CTOR
> Dm: org.apache.ofbiz.base.util.cache.test.UtilCacheTests.expireTest(UtilCache, int, long)
invokes inefficient new String(String) constructor
> Using the java.lang.String(String) constructor wastes memory because the object so constructed
will be functionally indistinguishable from the String passed as a parameter.  Just use the
argument String directly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message