ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Leichert (JIRA)" <j...@apache.org>
Subject [jira] [Created] (OFBIZ-9722) [FB] Package org.apache.ofbiz.base.util.test
Date Thu, 14 Sep 2017 11:17:00 GMT
Julian Leichert created OFBIZ-9722:
--------------------------------------

             Summary: [FB] Package org.apache.ofbiz.base.util.test
                 Key: OFBIZ-9722
                 URL: https://issues.apache.org/jira/browse/OFBIZ-9722
             Project: OFBiz
          Issue Type: Sub-task
          Components: base
    Affects Versions: Trunk
            Reporter: Julian Leichert
            Priority: Minor


ObjectTypeTests.java:319, DM_FP_NUMBER_CTOR
-Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testDouble() invokes inefficient new
Double(String) constructor; use Double.valueOf(String) instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Double and Float.

ObjectTypeTests.java:334, DM_FP_NUMBER_CTOR
-Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testFloat() invokes inefficient new Float(String)
constructor; use Float.valueOf(String) instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Double and Float.

ObjectTypeTests.java:346, DM_FP_NUMBER_CTOR
- Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testLong() invokes inefficient new Double(String)
constructor; use Double.valueOf(String) instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Double and Float.

ObjectTypeTests.java:347, DM_FP_NUMBER_CTOR
- Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testLong() invokes inefficient new Float(String)
constructor; use Float.valueOf(String) instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Double and Float.

ObjectTypeTests.java:348, DM_NUMBER_CTOR
- Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testLong() invokes inefficient new Long(String)
constructor; use Long.valueOf(String) instead

Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Values between -128 and 127 are guaranteed to have corresponding cached instances and using
valueOf is approximately 3.5 times faster than using constructor. For values outside the constant
range the performance of both styles is the same.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Long, Integer, Short, Character, and Byte.

ObjectTypeTests.java:361, DM_FP_NUMBER_CTOR
- Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testInteger() invokes inefficient new
Double(String) constructor; use Double.valueOf(String) instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Double and Float.

ObjectTypeTests.java:362, DM_FP_NUMBER_CTOR
- Bx: org.apache.ofbiz.base.util.test.ObjectTypeTests.testInteger() invokes inefficient new
Float(String) constructor; use Float.valueOf(String) instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. Using of cached
values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or
the valueOf() method when creating instances of Double and Float.

ReferenceCleanerTests.java:61, DLS_DEAD_LOCAL_STORE_OF_NULL
- DLS: Dead store of null to obj in org.apache.ofbiz.base.util.test.ReferenceCleanerTests.testReferenceCleaner()

The code stores null into a local variable, and the stored value is not read. This store may
have been introduced to assist the garbage collector, but as of Java SE 6.0, this is no longer
needed or useful.

StringUtilTests.java:51, BC_VACUOUS_INSTANCEOF
- BC: instanceof will always return true for all nonnull values in org.apache.ofbiz.base.util.test.StringUtilTests.testStringUtil(),
since all org.apache.ofbiz.base.util.StringUtil are instances of org.apache.ofbiz.base.util.StringUtil

This instanceof test will always return true (unless the value being tested is null). Although
this is safe, make sure it isn't an indication of some misunderstanding or some other logic
error. If you really want to test the value for being null, perhaps it would be clearer to
do better to do a null test rather than an instanceof test.

StringUtilTests.java:56, DM_STRING_CTOR
- Dm: org.apache.ofbiz.base.util.test.StringUtilTests.testInternString() 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.

UtilObjectTests.java:142, RR_NOT_CHECKED
- RR: org.apache.ofbiz.base.util.test.UtilObjectTests.testErrorInjector() ignores result of
java.io.InputStream.read(byte[], int, int)

This method ignores the return value of one of the variants of java.io.InputStream.read()
which can return multiple bytes.  If the return value is not checked, the caller will not
be able to correctly handle the case where fewer bytes were read than the caller requested.
 This is a particularly insidious kind of bug, because in many programs, reads from input
streams usually do read the full amount of data requested, causing the program to fail only
sporadically.

UtilObjectTests.java:189, SE_NO_SERIALVERSIONID
- SnVI: org.apache.ofbiz.base.util.test.UtilObjectTests$SerializationInjector 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.

UtilPropertiesTests.java:33, SS_SHOULD_BE_STATIC
- SS: Unread field: org.apache.ofbiz.base.util.test.UtilPropertiesTests.country; should this
field be static?

This class contains an instance final field that is initialized to a compile-time static value.
Consider making the field static.

UtilPropertiesTests.java:34, SS_SHOULD_BE_STATIC
- SS: Unread field: org.apache.ofbiz.base.util.test.UtilPropertiesTests.language; should this
field be static?

This class contains an instance final field that is initialized to a compile-time static value.
Consider making the field static.

UtilPropertiesTests.java:78, DM_DEFAULT_ENCODING
- Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.test.UtilPropertiesTests.xmlToProperties(String):
String.getBytes()

Found a call to a method which will perform a byte to String (or String to byte) conversion,
and will assume that the default platform encoding is suitable. This will cause the application
behaviour to vary between platforms. Use an alternative API and specify a charset name or
Charset object explicitly.

UtilXmlTests.java:43, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to unsupportedObject in org.apache.ofbiz.base.util.test.UtilXmlTests.testUnsupportedClassConverter()

This instruction assigns a value to a local variable, but the value is not read or used in
any subsequent instruction. Often, this indicates an error, because the value computed is
never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because
FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

UtilXmlTests.java:45, DE_MIGHT_IGNORE
- DE: org.apache.ofbiz.base.util.test.UtilXmlTests.testUnsupportedClassConverter() might ignore
java.lang.Exception

This method might ignore an exception.  In general, exceptions should be handled or reported
in some way, or they should be thrown out of the method.



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

Mime
View raw message