[
https://issues.apache.org/jira/browse/OFBIZ-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reopened OFBIZ-9700:
------------------------------------
I reopen because OFBIZ-10058, please check
> [FB] Package org.apache.ofbiz.base.util.string
> ----------------------------------------------
>
> Key: OFBIZ-9700
> URL: https://issues.apache.org/jira/browse/OFBIZ-9700
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
> Affects Versions: Trunk
> Reporter: Julian Leichert
> Assignee: Michael Brohl
> Priority: Minor
> Fix For: Upcoming Release
>
> Attachments:
> OFBIZ-9700_org.apache.ofbiz.base.util.string_bugfixes.patch,
> OFBIZ-9700_org.apache.ofbiz.base.util.string_bugfixes.patch
>
>
> FlexibleStringExpander.java:245, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> - NP:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$Key.equals(Object)
> does not check for null argument
> This implementation of equals(Object) violates the contract defined by
> java.lang.Object.equals() because it does not check for null being passed as
> the argument. All equals() methods should return false if passed a null value.
> FlexibleStringExpander.java:444, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.FlexibleStringExpander.expandString(Map,
> TimeZone, Locale)
> 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 ...
> }
> FlexibleStringExpander.java:540, SE_NO_SERIALVERSIONID
> - SnVI:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$ConstSimpleElem 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.
> FlexibleStringExpander.java:567, SE_NO_SERIALVERSIONID
> - SnVI:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$ConstOffsetElem 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.
> FlexibleStringExpander.java:587, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.FlexibleStringExpander$CurrElem 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.
> FlexibleStringExpander.java:619, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.FlexibleStringExpander$Elements 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.
> FlexibleStringExpander.java:642, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.FlexibleStringExpander$ScriptElem
> 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.
> FlexibleStringExpander.java:674, SE_NO_SERIALVERSIONID
> - SnVI:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$NestedVarElem 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.
> FlexibleStringExpander.java:708, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.FlexibleStringExpander$VarElem 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.
> JuelConnector.java:81, DE_MIGHT_IGNORE
> - DE:
> org.apache.ofbiz.base.util.string.JuelConnector$ExtendedAstBracket.setValue(Bindings,
> ELContext, Object) might ignore java.lang.Exception
> This method might ignore an exception. In general, exceptions should be
> handled or reported in some way, or they should be thrown out of the method.
> JuelConnector.java:115, DE_MIGHT_IGNORE
> - DE:
> org.apache.ofbiz.base.util.string.JuelConnector$ExtendedAstDot.setValue(Bindings,
> ELContext, Object) might ignore java.lang.Exception
> This method might ignore an exception. In general, exceptions should be
> handled or reported in some way, or they should be thrown out of the method.
> JuelConnector.java:177, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.JuelConnector$ExtendedBuilder 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.
> UelFunctions.java:261, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in new
> org.apache.ofbiz.base.util.string.UelFunctions$Functions()
> 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 ...
> }
> UelFunctions.java:403, DM_CONVERT_CASE
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in
> org.apache.ofbiz.base.util.string.UelFunctions.toLowerCase(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.
> UelFunctions.java:410, DM_CONVERT_CASE
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in
> org.apache.ofbiz.base.util.string.UelFunctions.toUpperCase(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.
> UelFunctions.java:442, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.UelFunctions.urlExists(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 ...
> }
> UelFunctions.java:458, REC_CATCH_EXCEPTION, Priorität: Niedrig
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.UelFunctions.readHtmlDocument(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 ...
> }
> UelFunctions.java:475, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.UelFunctions.readXmlDocument(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 ...
> }
> UelFunctions.java:485, OS_OPEN_STREAM_EXCEPTION_PATH
> - OS: org.apache.ofbiz.base.util.string.UelFunctions.writeXmlDocument(String,
> Node, String, boolean, boolean, int) 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.
> UelFunctions.java:492, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.UelFunctions.writeXmlDocument(String, Node,
> String, boolean, boolean, int)
> 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 ...
> }
> UelFunctions.java:517, DM_DEFAULT_ENCODING
> - Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.util.string.UelFunctions.toHtmlString(Node, String,
> 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.
> UelFunctions.java:522, DM_DEFAULT_ENCODING
> - Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.util.string.UelFunctions.toHtmlString(Node, String,
> boolean, int): java.io.ByteArrayOutputStream.toString()
> 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.
> UelFunctions.java:523, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.UelFunctions.toHtmlString(Node, String,
> boolean, int)
> 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 ...
> }
> UelFunctions.java:534, DM_DEFAULT_ENCODING
> - Dm: Found reliance on default encoding in
> org.apache.ofbiz.base.util.string.UelFunctions.toXmlString(Node, String,
> boolean, boolean, int): java.io.ByteArrayOutputStream.toString()
> 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.
> UelFunctions.java:535, REC_CATCH_EXCEPTION, Priorität: Niedrig
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.UelFunctions.toXmlString(Node, String,
> boolean, boolean, int)
> 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 ...
> }
> UelUtil.java:-1, CI_CONFUSED_INHERITANCE
> - CI: Class org.apache.ofbiz.base.util.string.UelUtil is final but declares
> protected field org.apache.ofbiz.base.util.string.UelUtil.module
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> UelUtil.java:-1, SE_BAD_FIELD
> - Se: Class org.apache.ofbiz.base.util.string.UelUtil$BasicValueExpression
> defines non-transient non-serializable instance field elContext
> This Serializable class defines a non-primitive instance field which is
> neither transient, Serializable, or java.lang.Object, and does not appear to
> implement the Externalizable interface or the readObject() and writeObject()
> methods. Objects of this class will not be deserialized correctly if a
> non-Serializable object is stored in this field.
> UelUtil.java:212, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.UelUtil$ReadOnlyExpression 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.
> UelUtil.java:245, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> - NP:
> org.apache.ofbiz.base.util.string.UelUtil$ReadOnlyExpression.equals(Object)
> does not check for null argument
> This implementation of equals(Object) violates the contract defined by
> java.lang.Object.equals() because it does not check for null being passed as
> the argument. All equals() methods should return false if passed a null value.
> UelUtil.java:273, SE_NO_SERIALVERSIONID, Priorität: Niedrig
> - SnVI: org.apache.ofbiz.base.util.string.UelUtil$BasicValueExpression 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.
> UelUtil.java:282, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> - NP:
> org.apache.ofbiz.base.util.string.UelUtil$BasicValueExpression.equals(Object)
> does not check for null argument
> This implementation of equals(Object) violates the contract defined by
> java.lang.Object.equals() because it does not check for null being passed as
> the argument. All equals() methods should return false if passed a null value.
> UelUtil.java:339, NP_LOAD_OF_KNOWN_NULL_VALUE
> - NP: Load of known null value in
> org.apache.ofbiz.base.util.string.UelUtil$ExtendedCompositeResolver.setValue(ELContext,
> Object, Object, 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).
> UelUtil.java:429, NP_LOAD_OF_KNOWN_NULL_VALUE
> - NP: Load of known null value in
> org.apache.ofbiz.base.util.string.UelUtil$ExtendedMapResolver.getValue(ELContext,
> Object, 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).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
