[
https://issues.apache.org/jira/browse/OFBIZ-9692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227817#comment-17227817
]
Jacques Le Roux commented on OFBIZ-9692:
----------------------------------------
Hi Michael, Julian,
Could you please explain the reason of this change in
HttpRequestFileUpload.java (just for me to understand)? TIA
{code:java}
@@ -187,5 +192,34 @@
- // write the current buffer, except the last 2 bytes;
- if (i > 1) {
- fos.write(line, 0, i - 2);
+ // write the current buffer, except the last 2
bytes;
+ if (i > 1) {
+ fos.write(line, 0, i - 2);
+ }
+
+ oneByteLine = (i == 1); // we need to track
on-byte lines differently
+
+ i = waitingReadLine(in, line, 0, BUFFER_SIZE,
requestLength);
+ requestLength -= i;
+
+ // the problem is the last line of the file content
+ // contains the new line character.
+
+ // if the line just read was the last line, we're
done.
+ // if not, we must write the last 2 bytes of the
previous buffer
+ // just assume that a one-byte line isn't the last
line
+
+ if (requestLength < 1) {
+ bail = true;
+ } else if (oneByteLine) {
+ fos.write(lastTwoBytes, 0, 1); // we only
saved one byte
+ } else {
+ fos.write(lastTwoBytes, 0, 2);
+ }
+
+ if (i > 1) {
+ // save the last 2 bytes of the buffer
+ lastTwoBytes[0] = line[i - 2];
+ lastTwoBytes[1] = line[i - 1];
+ } else {
+ lastTwoBytes[0] = line[0]; // only save one
byte
+ }
}
{code}
> [FB] Package org.apache.ofbiz.base.util
> ---------------------------------------
>
> Key: OFBIZ-9692
> URL: https://issues.apache.org/jira/browse/OFBIZ-9692
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
> Affects Versions: Trunk
> Reporter: Julian Leichert
> Assignee: Michael Brohl
> Priority: Minor
> Fix For: 17.12.01
>
> Attachments: OFBIZ-9692_org.apache.ofbiz.base.util.patch
>
>
> 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 [email protected]
> 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 [email protected]
> 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 [email protected]
> 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 [email protected]
> 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 [email protected]
> 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 [email protected]
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
