XMLWordPrintableJSON

Details

    • Sub-task
    • Status: Closed
    • Minor
    • Resolution: Implemented
    • Trunk
    • 17.12.01
    • base
    • None

    Description

      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.

      Attachments

        Activity

          People

            mbrohl Michael Brohl
            jleichert Julian Leichert
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: