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