ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Leichert (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OFBIZ-9700) [FB] Package org.apache.ofbiz.base.util.string
Date Wed, 13 Dec 2017 10:00:03 GMT

     [ https://issues.apache.org/jira/browse/OFBIZ-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julian Leichert updated OFBIZ-9700:
-----------------------------------
    Attachment: OFBIZ-9700_org.apache.ofbiz.base.util.string_bugfixes.patch

Attached a fixed Patch. There was an wrong check of base in UelUtil.setValue() .



> [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)

Mime
View raw message