XMLWordPrintableJSON

Details

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

    Description

      Base64.java:-1, NM_FIELD_NAMING_CONVENTION

      • Nm: The field name org.apache.ofbiz.base.util.Base64.Base64EncMap doesn't start with a lower case letter

      Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.

      Base64.java:-1, NM_FIELD_NAMING_CONVENTION

      • Nm: The field name org.apache.ofbiz.base.util.Base64.Base64DecMap doesn't start with a lower case letter

      Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.

      Base64.java:113, PZLA_PREFER_ZERO_LENGTH_ARRAYS

      • PZLA: Should org.apache.ofbiz.base.util.Base64.base64Decode(byte[]) return a zero length array rather than null?

      It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

      On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

      Base64.java:155, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.Base64.base64Decode(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.

      Base64.java:155, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.Base64.base64Decode(String): new String(byte[])

      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.

      Base64.java:167, PZLA_PREFER_ZERO_LENGTH_ARRAYS

      • PZLA: Should org.apache.ofbiz.base.util.Base64.base64Encode(byte[]) return a zero length array rather than null?

      It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

      On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

      Base64.java:208, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.Base64.base64Encode(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.

      Base64.java:208, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.Base64.base64Encode(String): new String(byte[])

      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.

      DateRange.java:30, SE_NO_SERIALVERSIONID

      • SnVI: org.apache.ofbiz.base.util.DateRange 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.

      DateRange.java:30, SE_NO_SUITABLE_CONSTRUCTOR

      • Se: org.apache.ofbiz.base.util.DateRange 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.

      Debug.java:89, DM_CONVERT_CASE

      • Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.util.Debug.getLevelFromString(String)

      A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

      String.toUpperCase( Locale l )
      String.toLowerCase( Locale l )
      versions instead.

      FileUtil.java:206, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.FileUtil.getBufferedWriter(String, String): new java.io.FileWriter(String)

      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.

      FileUtil.java:250, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.FileUtil.readTextFile(File, boolean): new java.io.FileReader(File)

      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.

      FileUtil.java:389, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.FileUtil.containsString(String, String): new java.io.FileReader(File)

      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.

      FileUtil.java:393, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

      • RCN: Redundant nullcheck of in, which is known to be non-null in org.apache.ofbiz.base.util.FileUtil.containsString(String, String)

      This method contains a redundant check of a known non-null value against the constant null.

      GroovyUtil.java:57, DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED

      • DP: org.apache.ofbiz.base.util.GroovyUtil.() creates a groovy.lang.GroovyClassLoader classloader, which should be performed within a doPrivileged block

      This code creates a classloader, which needs permission if a security manage is installed. If this code might be invoked by code that does not have security permissions, then the classloader creation needs to occur inside a doPrivileged block.

      GroovyUtil.java:171, REC_CATCH_EXCEPTION

      • REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.GroovyUtil.getScriptClassFromLocation(String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try

      { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      GroovyUtil.java:177, DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED, Priorität: Normal
      DP: org.apache.ofbiz.base.util.GroovyUtil.loadClass(String) creates a groovy.lang.GroovyClassLoader classloader, which should be performed within a doPrivileged block

      This code creates a classloader, which needs permission if a security manage is installed. If this code might be invoked by code that does not have security permissions, then the classloader creation needs to occur inside a doPrivileged block.

      GroovyUtil.java:184, DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED
      - DP: org.apache.ofbiz.base.util.GroovyUtil.parseClass(InputStream, String) creates a groovy.lang.GroovyClassLoader classloader, which should be performed within a doPrivileged block

      This code creates a classloader, which needs permission if a security manage is installed. If this code might be invoked by code that does not have security permissions, then the classloader creation needs to occur inside a doPrivileged block.

      GroovyUtil.java:194, DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED
      - DP: org.apache.ofbiz.base.util.GroovyUtil.parseClass(String) creates a groovy.lang.GroovyClassLoader classloader, which should be performed within a doPrivileged block

      This code creates a classloader, which needs permission if a security manage is installed. If this code might be invoked by code that does not have security permissions, then the classloader creation needs to occur inside a doPrivileged block.

      HttpClient.java:368, DM_CONVERT_CASE
      - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.util.HttpClient.sendHttpRequest(String)

      A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

      String.toUpperCase( Locale l )
      String.toLowerCase( Locale l )
      versions instead.

      HttpClient.java:381, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.HttpClient.sendHttpRequest(String): new java.io.InputStreamReader(InputStream)

      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.

      HttpClient.java:381, OS_OPEN_STREAM
      - OS: org.apache.ofbiz.base.util.HttpClient.sendHttpRequest(String) may fail to close stream

      The method creates an IO stream object, does not assign it to any fields, pass it to other methods that might close it, or return it, and does not appear to close the stream on all paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

      HttpClient.java:392, REC_CATCH_EXCEPTION,
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.HttpClient.sendHttpRequest(String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... }

      catch (Exception e)

      { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      HttpClient.java:479, OS_OPEN_STREAM_EXCEPTION_PATH
      - OS: org.apache.ofbiz.base.util.HttpClient.sendHttpRequestStream(String, boolean) may fail to close stream on exception

      The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

      HttpClient.java:504, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.HttpClient.sendHttpRequestStream(String, boolean)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something }

      as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try

      { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      HttpRequestFileUpload.java:59, NM_CONFUSING
      - Nm: Confusing to have methods org.apache.ofbiz.base.util.HttpRequestFileUpload.getFilename() and org.apache.ofbiz.minilang.SimpleMethod.getFileName()

      The referenced methods have names that differ only by capitalization.

      HttpRequestFileUpload.java:63, NM_CONFUSING
      - Nm: Confusing to have methods org.apache.ofbiz.base.util.HttpRequestFileUpload.getFilepath() and org.apache.ofbiz.webtools.labelmanager.LabelFile.getFilePath()

      The referenced methods have names that differ only by capitalization.

      HttpRequestFileUpload.java:118, DM_BOXED_PRIMITIVE_FOR_PARSING
      - Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest)

      A boxed primitive is created from a String, just to extract the unboxed primitive value. It is more efficient to just call the static parseXXX method.

      HttpRequestFileUpload.java:133, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest): new String(byte[], int, int)

      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.

      HttpRequestFileUpload.java:158, DLS_DEAD_LOCAL_STORE
      - DLS: Dead store to newLine in org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest)

      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.

      HttpRequestFileUpload.java:178, NP_NULL_PARAM_DEREF
      - NP: Null passed for nonnull parameter of new java.io.File(String) in org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest)

      This method call passes a null value for a non-null method parameter. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.

      HttpRequestFileUpload.java:178, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
      - RCN: Nullcheck of HttpRequestFileUpload.savePath at line 182 of value previously dereferenced in org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest)

      A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.

      HttpRequestFileUpload.java:180, RV_RETURN_VALUE_IGNORED_BAD_PRACTICE
      - RV: Exceptional return value of java.io.File.mkdirs() ignored in org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest)

      This method returns a value that is not checked. The return value should be checked since it can indicate an unusual or unexpected function execution. For example, the File.delete() method returns false if the file could not be successfully deleted (rather than throwing an Exception). If you don't check the result, you won't notice if the method invocation signals unexpected behavior by returning an atypical return value.

      HttpRequestFileUpload.java:182, OS_OPEN_STREAM_EXCEPTION_PATH
      - OS: org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest) may fail to close stream on exception

      The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

      HttpRequestFileUpload.java:182, OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE
      - OBL: org.apache.ofbiz.base.util.HttpRequestFileUpload.doUpload(HttpServletRequest) may fail to clean up java.io.OutputStream on checked exception

      This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.

      In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.

      This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:

      send email to findbugs@cs.umd.edu
      file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
      In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.

      See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.

      JNDIContextFactory.java:79, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of ic, which is known to be non-null in org.apache.ofbiz.base.util.JNDIContextFactory.getInitialContext(String)

      This method contains a redundant check of a known non-null value against the constant null.

      KeyStoreUtil.java:190, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.KeyStoreUtil.certToString(Certificate): new String(byte[])

      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.

      KeyStoreUtil.java:204, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.KeyStoreUtil.pemToCert(InputStream): new java.io.InputStreamReader(InputStream)

      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.

      KeyStoreUtil.java:213, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.KeyStoreUtil.pemToCert(Reader): new java.io.PrintStream(OutputStream)

      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.

      MessageString.java:36, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.MessageString 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.

      MultiTrustManager.java:115, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of issuers, which is known to be non-null in org.apache.ofbiz.base.util.MultiTrustManager.isTrusted(X509Certificate[])

      This method contains a redundant check of a known non-null value against the constant null.

      ObjectInputStream.java:35, NM_SAME_SIMPLE_NAME_AS_SUPERCLASS
      - Nm: The class name org.apache.ofbiz.base.util.ObjectInputStream shadows the simple name of the superclass java.io.ObjectInputStream

      This class has a simple name that is identical to that of its superclass, except that its superclass is in a different package (e.g., alpha.Foo extends beta.Foo). This can be exceptionally confusing, create lots of situations in which you have to look at import statements to resolve references and creates many opportunities to accidentally define methods that do not override methods in their superclasses.

      ObjectType.java:121, DM_CONVERT_CASE
      - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.util.ObjectType.loadClass(String, ClassLoader)

      A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

      String.toUpperCase( Locale l )
      String.toLowerCase( Locale l )
      versions instead.

      ObjectType.java:529, DE_MIGHT_IGNORE
      - DE: org.apache.ofbiz.base.util.ObjectType.simpleTypeConvert(Object, String, String, TimeZone, Locale, boolean) might ignore java.lang.ClassNotFoundException

      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.

      ObjectType.java:614, NP_BOOLEAN_RETURN_NULL
      - NP: org.apache.ofbiz.base.util.ObjectType.doRealCompare(Object, Object, String, String, String, List, Locale, ClassLoader, boolean) has Boolean return type and returns explicit null

      A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it returned a value of type boolean, and the compiler will insert automatic unboxing of the Boolean value. If a null value is returned, this will result in a NullPointerException.

      ObjectType.java:806, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.ObjectType$NullObject 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.

      RMIExtendedSocketFactory.java:69, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of octets, which is known to be non-null in new org.apache.ofbiz.base.util.RMIExtendedSocketFactory(String)

      This method contains a redundant check of a known non-null value against the constant null.

      SSLUtil.java:115, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of mgrs, which is known to be non-null in org.apache.ofbiz.base.util.SSLUtil.isClientTrusted(X509Certificate[], String)

      This method contains a redundant check of a known non-null value against the constant null.

      SSLUtil.java:138, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of newKeyManagers, which is known to be non-null in org.apache.ofbiz.base.util.SSLUtil.getKeyManagers(String)

      This method contains a redundant check of a known non-null value against the constant null.

      SSLUtil.java:269, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.SSLUtil$1.verify(String, SSLSession)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... }

      catch (RuntimeException e)

      { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      ScriptUtil.java:140, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.ScriptUtil.compileScriptFile(String): new java.io.InputStreamReader(InputStream)

      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.

      ScriptUtil.java:373, NP_LOAD_OF_KNOWN_NULL_VALUE
      - NP: Load of known null value in org.apache.ofbiz.base.util.ScriptUtil.executeScript(String, String, ScriptContext, Object[])

      The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was non-null).

      ScriptUtil.java:387, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.ScriptUtil.executeScript(String, String, ScriptContext, Object[]): new java.io.FileReader(File)

      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.

      ScriptUtil.java:387, OBL_UNSATISFIED_OBLIGATION
      - OBL: org.apache.ofbiz.base.util.ScriptUtil.executeScript(String, String, ScriptContext, Object[]) may fail to clean up java.io.Reader

      This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.

      In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.

      This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:

      send email to findbugs@cs.umd.edu
      file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
      In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.

      See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.

      StringUtil.java:238, NP_NULL_PARAM_DEREF
      - NP: Null passed for nonnull parameter of java.net.URLDecoder.decode(String, String) in org.apache.ofbiz.base.util.StringUtil.strToMap(String, String, boolean, String)

      This method call passes a null value for a non-null method parameter. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.

      StringUtil.java:238, NP_NULL_PARAM_DEREF
      - NP: Null passed for nonnull parameter of java.net.URLDecoder.decode(String, String) in org.apache.ofbiz.base.util.StringUtil.strToMap(String, String, boolean, String)

      This method call passes a null value for a non-null method parameter. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.

      TimeDuration.java:29, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.TimeDuration 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.

      TimeDuration.java:98, ICAST_INTEGER_MULTIPLY_CAST_TO_LONG, Priorität: Hoch
      - ICAST: Result of integer multiplication cast to long in new org.apache.ofbiz.base.util.TimeDuration(Calendar, Calendar)

      This code performs integer multiply and then converts the result to a long, as in:

      long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
      If the multiplication is done using long arithmetic, you can avoid the possibility that the result will overflow. For example, you could fix the above code to:

      long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
      or
      static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
      long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
      TimeDuration.java:99, ICAST_IDIV_CAST_TO_DOUBLE
      - ICAST: Integral division result cast to double or float in new org.apache.ofbiz.base.util.TimeDuration(Calendar, Calendar)

      This code casts the result of an integral division (e.g., int or long division) operation to double or float. Doing division on integers truncates the result to the integer value closest to zero. The fact that the result was cast to double suggests that this precision should have been retained. What was probably meant was to cast one or both of the operands to double before performing the division. Here is an example:

      int x = 2;
      int y = 5;
      // Wrong: yields result 0.0
      double value1 = x / y;

      // Right: yields result 0.4
      double value2 = x / (double) y;
      TimeDuration.java:174, HE_EQUALS_USE_HASHCODE
      HE: org.apache.ofbiz.base.util.TimeDuration 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 }
      TimeDuration.java:182, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.TimeDuration.equals(Object)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; }

      catch (Exception e)

      { ... deal with all non-runtime exceptions ... }
      TimeDuration.java:385, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.TimeDuration$NullDuration 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.

      URLConnector.java:60, WA_NOT_IN_LOOP
      - Wa: Wait not in loop in org.apache.ofbiz.base.util.URLConnector.openConnection(int)

      This method contains a call to java.lang.Object.wait() which is not in a loop. If the monitor is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

      URLConnector.java:144, NO_NOTIFY_NOT_NOTIFYALL
      - No: Using notify rather than notifyAll in org.apache.ofbiz.base.util.URLConnector$URLConnectorThread.run()

      This method calls notify() rather than notifyAll(). Java monitors are often used for multiple conditions. Calling notify() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied.

      UtilDateTime.java:117, DM_BOXED_PRIMITIVE_FOR_PARSING
      - Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.base.util.UtilDateTime.formatInterval(double, int, Locale)

      A boxed primitive is created from a String, just to extract the unboxed primitive value. It is more efficient to just call the static parseXXX method.

      UtilDateTime.java:566, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilDateTime.toDate(String, String, String, String, String, String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }

      UtilDateTime.java:686, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

      • RCN: Redundant nullcheck of dateString, which is known to be non-null in org.apache.ofbiz.base.util.UtilDateTime.toDateTimeString(Date)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilDateTime.java:686, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

      • RCN: Redundant nullcheck of timeString, which is known to be non-null in org.apache.ofbiz.base.util.UtilDateTime.toDateTimeString(Date)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilDateTime.java:1176, SE_NO_SERIALVERSIONID

      • SnVI: org.apache.ofbiz.base.util.UtilDateTime$ImmutableDate 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.

      UtilFormatOut.java:363, DM_DEFAULT_ENCODING

      • Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.UtilFormatOut.makeString(Object): new String(byte[])

      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.

      RMIExtendedSocketFactory.java:69, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

      • RCN: Redundant nullcheck of octets, which is known to be non-null in new org.apache.ofbiz.base.util.RMIExtendedSocketFactory(String)

      This method contains a redundant check of a known non-null value against the constant null.

      SSLUtil.java:115, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

      • RCN: Redundant nullcheck of mgrs, which is known to be non-null in org.apache.ofbiz.base.util.SSLUtil.isClientTrusted(X509Certificate[], String)

      This method contains a redundant check of a known non-null value against the constant null.

      SSLUtil.java:138, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

      • RCN: Redundant nullcheck of newKeyManagers, which is known to be non-null in org.apache.ofbiz.base.util.SSLUtil.getKeyManagers(String)

      This method contains a redundant check of a known non-null value against the constant null.

      SSLUtil.java:269, REC_CATCH_EXCEPTION

      • REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.SSLUtil$1.verify(String, SSLSession)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try

      { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      ScriptUtil.java:140, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.ScriptUtil.compileScriptFile(String): new java.io.InputStreamReader(InputStream)

      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.

      ScriptUtil.java:373, NP_LOAD_OF_KNOWN_NULL_VALUE
      - NP: Load of known null value in org.apache.ofbiz.base.util.ScriptUtil.executeScript(String, String, ScriptContext, Object[])

      The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was non-null).

      ScriptUtil.java:387, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.ScriptUtil.executeScript(String, String, ScriptContext, Object[]): new java.io.FileReader(File)

      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.

      ScriptUtil.java:387, OBL_UNSATISFIED_OBLIGATION
      - OBL: org.apache.ofbiz.base.util.ScriptUtil.executeScript(String, String, ScriptContext, Object[]) may fail to clean up java.io.Reader

      This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.

      In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.

      This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:

      send email to findbugs@cs.umd.edu
      file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
      In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.

      See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.

      StringUtil.java:238, NP_NULL_PARAM_DEREF
      - NP: Null passed for nonnull parameter of java.net.URLDecoder.decode(String, String) in org.apache.ofbiz.base.util.StringUtil.strToMap(String, String, boolean, String)

      This method call passes a null value for a non-null method parameter. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.

      StringUtil.java:238, NP_NULL_PARAM_DEREF
      - NP: Null passed for nonnull parameter of java.net.URLDecoder.decode(String, String) in org.apache.ofbiz.base.util.StringUtil.strToMap(String, String, boolean, String)

      This method call passes a null value for a non-null method parameter. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.

      TimeDuration.java:29, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.TimeDuration 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.

      TimeDuration.java:98, ICAST_INTEGER_MULTIPLY_CAST_TO_LONG, Priorität: Hoch
      - ICAST: Result of integer multiplication cast to long in new org.apache.ofbiz.base.util.TimeDuration(Calendar, Calendar)

      This code performs integer multiply and then converts the result to a long, as in:

      long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
      If the multiplication is done using long arithmetic, you can avoid the possibility that the result will overflow. For example, you could fix the above code to:

      long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
      or
      static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
      long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
      TimeDuration.java:99, ICAST_IDIV_CAST_TO_DOUBLE
      - ICAST: Integral division result cast to double or float in new org.apache.ofbiz.base.util.TimeDuration(Calendar, Calendar)

      This code casts the result of an integral division (e.g., int or long division) operation to double or float. Doing division on integers truncates the result to the integer value closest to zero. The fact that the result was cast to double suggests that this precision should have been retained. What was probably meant was to cast one or both of the operands to double before performing the division. Here is an example:

      int x = 2;
      int y = 5;
      // Wrong: yields result 0.0
      double value1 = x / y;

      // Right: yields result 0.4
      double value2 = x / (double) y;
      TimeDuration.java:174, HE_EQUALS_USE_HASHCODE
      HE: org.apache.ofbiz.base.util.TimeDuration 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 }
      TimeDuration.java:182, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.TimeDuration.equals(Object)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... }

      catch (Exception e)

      { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      TimeDuration.java:385, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.TimeDuration$NullDuration 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.

      URLConnector.java:60, WA_NOT_IN_LOOP
      - Wa: Wait not in loop in org.apache.ofbiz.base.util.URLConnector.openConnection(int)

      This method contains a call to java.lang.Object.wait() which is not in a loop. If the monitor is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

      URLConnector.java:144, NO_NOTIFY_NOT_NOTIFYALL
      - No: Using notify rather than notifyAll in org.apache.ofbiz.base.util.URLConnector$URLConnectorThread.run()

      This method calls notify() rather than notifyAll(). Java monitors are often used for multiple conditions. Calling notify() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied.

      UtilDateTime.java:117, DM_BOXED_PRIMITIVE_FOR_PARSING
      - Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.base.util.UtilDateTime.formatInterval(double, int, Locale)

      A boxed primitive is created from a String, just to extract the unboxed primitive value. It is more efficient to just call the static parseXXX method.

      UtilDateTime.java:566, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilDateTime.toDate(String, String, String, String, String, String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something }

      as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try

      { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      UtilDateTime.java:686, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of dateString, which is known to be non-null in org.apache.ofbiz.base.util.UtilDateTime.toDateTimeString(Date)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilDateTime.java:686, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of timeString, which is known to be non-null in org.apache.ofbiz.base.util.UtilDateTime.toDateTimeString(Date)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilDateTime.java:1176, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.UtilDateTime$ImmutableDate 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.

      UtilFormatOut.java:363, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.UtilFormatOut.makeString(Object): new String(byte[])

      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.
      UtilJavaParse.java:158, RV_RETURN_VALUE_IGNORED
      - RV: Return value of String.substring(int, int) ignored in org.apache.ofbiz.base.util.UtilJavaParse.findEndOfBlock(int, String)

      The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,

      String dateString = getHeaderField(name);
      dateString.trim();
      the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:

      String dateString = getHeaderField(name);
      dateString = dateString.trim();

      UtilHttp.java:178, DLS_DEAD_LOCAL_STORE
      - DLS: Dead store to name in org.apache.ofbiz.base.util.UtilHttp.getQueryStringOnlyParameterMap(String)

      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.

      UtilHttp.java:1086, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of bos, which is known to be non-null in org.apache.ofbiz.base.util.UtilHttp.streamContent(OutputStream, InputStream, int)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilHttp.java:1150, RV_CHECK_FOR_POSITIVE_INDEXOF
      - RV: org.apache.ofbiz.base.util.UtilHttp.parseMultiFormData(Map) checks to see if result of String.indexOf is positive

      The method invokes String.indexOf and checks to see if the result is positive or non-positive. It is much more typical to check to see if the result is negative or non-negative. It is positive only if the substring checked for occurs at some place other than at the beginning of the String.

      UtilHttp.java:1152, WMI_WRONG_MAP_ITERATOR
      - WMI: org.apache.ofbiz.base.util.UtilHttp.parseMultiFormData(Map) makes inefficient use of keySet iterator instead of entrySet iterator

      This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.

      UtilHttp.java:1463, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilHttp.getAllowAllHttpClient(String, String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... }

      catch (RuntimeException e)

      { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      UtilJavaParse.java:158, RV_RETURN_VALUE_IGNORED
      - RV: Return value of String.substring(int, int) ignored in org.apache.ofbiz.base.util.UtilJavaParse.findEndOfBlock(int, String)

      The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,

      String dateString = getHeaderField(name);
      dateString.trim();
      the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:

      String dateString = getHeaderField(name);
      dateString = dateString.trim();
      UtilMisc.java:82, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilMisc.compare(List, List)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; }

      catch (Exception e)

      { ... deal with all non-runtime exceptions ... }
      UtilMisc.java:389, DM_FP_NUMBER_CTOR
      - Bx: org.apache.ofbiz.base.util.UtilMisc.toDoubleObject(Object) invokes inefficient new Double(double) constructor; use Double.valueOf(double) 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.

      UtilMisc.java:453, DM_NUMBER_CTOR
      - Bx: org.apache.ofbiz.base.util.UtilMisc.toLongObject(Object) invokes inefficient new Long(long) constructor; use Long.valueOf(long) 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.

      UtilMisc.java:563, OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE
      - OBL: org.apache.ofbiz.base.util.UtilMisc.copyFile(File, File) may fail to clean up java.io.InputStream on checked exception

      This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.

      In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.

      This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:

      send email to findbugs@cs.umd.edu
      file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
      In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.

      See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.

      UtilMisc.java:563, OS_OPEN_STREAM_EXCEPTION_PATH
      - OS: org.apache.ofbiz.base.util.UtilMisc.copyFile(File, File) may fail to close stream on exception

      The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

      UtilMisc.java:564, OS_OPEN_STREAM_EXCEPTION_PATH
      - OS: org.apache.ofbiz.base.util.UtilMisc.copyFile(File, File) may fail to close stream on exception

      The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

      UtilMisc.java:564, OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE
      - OBL: org.apache.ofbiz.base.util.UtilMisc.copyFile(File, File) may fail to clean up java.io.OutputStream on checked exception

      This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.

      In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.

      This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:

      send email to findbugs@cs.umd.edu
      file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
      In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.

      See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.

      UtilNumber.java:30, MS_SHOULD_BE_FINAL
      - MS: org.apache.ofbiz.base.util.UtilNumber.module isn't final but should be

      This static field public but not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.

      UtilNumber.java:139, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of value, which is known to be non-null in org.apache.ofbiz.base.util.UtilNumber.getBigDecimalScale(String, String)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilProperties.java:68, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.UtilProperties 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.

      UtilProperties.java:88, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of value, which is known to be non-null in org.apache.ofbiz.base.util.UtilProperties.propertyValueEquals(String, String, String)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilProperties.java:101, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of value, which is known to be non-null in org.apache.ofbiz.base.util.UtilProperties.propertyValueEqualsIgnoreCase(String, String, String)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilProperties.java:123, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of str, which is known to be non-null in org.apache.ofbiz.base.util.UtilProperties.getPropertyNumber(String, String, double)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilProperties.java:497, OS_OPEN_STREAM_EXCEPTION_PATH
      - OS: org.apache.ofbiz.base.util.UtilProperties.setPropertyValue(String, String, String) may fail to close stream on exception

      The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

      UtilProperties.java:497, OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE
      - OBL: org.apache.ofbiz.base.util.UtilProperties.setPropertyValue(String, String, String) may fail to clean up java.io.OutputStream on checked exception

      This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.

      In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.

      This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:

      send email to findbugs@cs.umd.edu
      file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
      In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.

      See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.

      UtilProperties.java:598, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of value, which is known to be non-null in org.apache.ofbiz.base.util.UtilProperties.getMessage(String, String, Locale)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilProperties.java:1123, EQ_UNUSUAL
      - Eq: org.apache.ofbiz.base.util.UtilProperties$UtilResourceBundle.equals(Object) is unusual

      This class doesn't do any of the patterns we recognize for checking that the type of the argument is compatible with the type of the this object. There might not be anything wrong with this code, but it is worth reviewing.

      UtilProperties.java:1156, SE_NO_SERIALVERSIONID
      - SnVI: org.apache.ofbiz.base.util.UtilProperties$ExtendedProperties 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.

      UtilTimer.java:33, MS_SHOULD_BE_FINAL
      - MS: org.apache.ofbiz.base.util.UtilTimer.staticTimers isn't final but should be

      This static field public but not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.

      UtilURL.java:94, ISC_INSTANTIATE_STATIC_CLASS
      - ISC: org.apache.ofbiz.base.util.UtilURL.fromResource(String, ClassLoader) needlessly instantiates a class that only supplies static methods

      This class allocates an object that is based on a class that only supplies static methods. This object does not need to be created, just access the static methods directly using the class name as a qualifier.

      UtilValidate.java:136, MS_PKGPROTECT
      - MS: org.apache.ofbiz.base.util.UtilValidate.daysInMonth should be package protected

      A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability.

      UtilValidate.java:810, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilValidate.isDateAfterToday(String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }

      UtilValidate.java:852, REC_CATCH_EXCEPTION

      • REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilValidate.isDateBeforeToday(String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try

      { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try { ... } catch (RuntimeException e) { throw e; } catch (Exception e) { ... deal with all non-runtime exceptions ... }
      UtilValidate.java:1243, DM_CONVERT_CASE
      - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.util.UtilValidate.isNotPoBox(String)

      A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

      String.toUpperCase( Locale l )
      String.toLowerCase( Locale l )
      versions instead.

      UtilXml.java:210, DM_DEFAULT_ENCODING
      - Dm: Found reliance on default encoding in org.apache.ofbiz.base.util.UtilXml.createOutputTransformer(String, boolean, boolean, int): 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.

      UtilXml.java:472, UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR
      - UwF: UtilXml$1.locator not initialized in constructor and dereferenced in org.apache.ofbiz.base.util.UtilXml$1.setLineColumn(Node)

      This field is never initialized within any constructor, and is therefore could be null after the object is constructed. Elsewhere, it is loaded and dereferenced without a null check. This could be a either an error or a questionable design, since it means a null pointer exception will be generated if that field is dereferenced before being initialized.

      UtilXml.java:828, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
      - RCN: Redundant nullcheck of value, which is known to be non-null in org.apache.ofbiz.base.util.UtilXml.firstChildElement(Element, String, String, String)

      This method contains a redundant check of a known non-null value against the constant null.

      UtilXml.java:1015, REC_CATCH_EXCEPTION
      - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.base.util.UtilXml$LocalResolver.resolveEntity(String, String)

      This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... }

      catch (Exception e)

      { something }

      as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

      A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:

      try

      { ... }

      catch (RuntimeException e)

      { throw e; }

      catch (Exception e)

      { ... deal with all non-runtime exceptions ... }

      UtilXml.java:1076, DM_CONVERT_CASE

      • Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.base.util.UtilXml$LocalErrorHandler.error(SAXParseException)

      A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

      String.toUpperCase( Locale l )
      String.toLowerCase( Locale l )
      versions instead.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: