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-9722) [FB] Package org.apache.ofbiz.base.util.test
Date Fri, 08 Dec 2017 21:04:00 GMT

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

Michael Brohl reassigned OFBIZ-9722:
------------------------------------

    Assignee: Michael Brohl

> [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
>            Assignee: Michael Brohl
>            Priority: Minor
>         Attachments: OFBIZ-9722_org.apache.ofbiz.base.util.test_bugfixes.patch
>
>
> 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