Mailing-List: contact notifications-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Date: Mon, 11 Sep 2017 09:31:00 +0000 (UTC)
From: "Julian Leichert (JIRA)" <jira@apache.org>
To: notifications@ofbiz.apache.org
Message-ID: <JIRA.13101196.1505118990000.76894.1505122260640@Atlassian.JIRA>
In-Reply-To: <JIRA.13101196.1505118990000@Atlassian.JIRA>
References: <JIRA.13101196.1505118990000@Atlassian.JIRA> <JIRA.13101196.1505118990618@jira-lw-us.apache.org>
Subject: [jira] [Updated] (OFBIZ-9702) [FB] Package
 org.apache.ofbiz.widget.renderer.macro
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 11 Sep 2017 09:31:07 -0000


     [ https://issues.apache.org/jira/browse/OFBIZ-9702?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Leichert updated OFBIZ-9702:
-----------------------------------
    Attachment:     (was: OFBIZ-9702_org.apache.ofbiz.widget.renderer.macro=
_bugfixes.patch)

> [FB] Package org.apache.ofbiz.widget.renderer.macro
> ---------------------------------------------------
>
>                 Key: OFBIZ-9702
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9702
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: ALL APPLICATIONS, ALL COMPONENTS
>    Affects Versions: Trunk
>            Reporter: Julian Leichert
>            Priority: Minor
>
> MacroFormRenderer.java:237, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> - RCN: Redundant nullcheck of fieldMap, which is known to be non-null in =
org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDisplayField=
(Appendable, Map, ModelFormField$DisplayField)
> This method contains a redundant check of a known non-null value against =
the constant null.
> MacroFormRenderer.java:246, SBSC_USE_STRINGBUFFER_CONCATENATION
> - SBSC: org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDi=
splayField(Appendable, Map, ModelFormField$DisplayField) concatenates strin=
gs using + in a loop
> The method seems to be building a String using concatenation in a loop. I=
n each iteration, the String is converted to a StringBuffer/StringBuilder, =
appended to, and converted back to a String. This can lead to a cost quadra=
tic in the number of iterations, as the growing string is recopied in each =
iteration.
> Better performance can be obtained by using a StringBuffer (or StringBuil=
der in Java 1.5) explicitly.
> For example:
>   // This is bad
>   String s =3D "";
>   for (int i =3D 0; i < field.length; ++i) {
>     s =3D s + field[i];
>   }
>   // This is better
>   StringBuffer buf =3D new StringBuffer();
>   for (int i =3D 0; i < field.length; ++i) {
>     buf.append(field[i]);
>   }
>   String s =3D buf.toString();
> MacroFormRenderer.java:538, DM_BOXED_PRIMITIVE_FOR_PARSING
> - Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.widget.render=
er.macro.MacroFormRenderer.renderDateTimeField(Appendable, Map, ModelFormFi=
eld$DateTimeField)
> A boxed primitive is created from a String, just to extract the unboxed p=
rimitive value. It is more efficient to just call the static parseXXX metho=
d.
> MacroFormRenderer.java:1000, RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT
> Return value of method without side effect is ignored
> This code calls a method and ignores the return value. However our analys=
is shows that the method (including its implementations in subclasses if an=
y) does not produce any effect other than return value. Thus this call can =
be removed.
> We are trying to reduce the false positives as much as possible, but in s=
ome cases this warning might be wrong. Common false-positive cases include:
> - The method is designed to be overridden and produce a side effect in ot=
her projects which are out of the scope of the analysis.
> - The method is called to trigger the class loading which may have a side=
 effect.
> - The method is called just to get some exception.
> If you feel that our assumption is incorrect, you can use a @CheckReturnV=
alue annotation to instruct FindBugs that ignoring the return value of this=
 method is acceptable.
> MacroFormRenderer.java:1062, RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT, Prio=
rit=C3=A4t: Normal
> Return value of method without side effect is ignored
> This code calls a method and ignores the return value. However our analys=
is shows that the method (including its implementations in subclasses if an=
y) does not produce any effect other than return value. Thus this call can =
be removed.
> We are trying to reduce the false positives as much as possible, but in s=
ome cases this warning might be wrong. Common false-positive cases include:
> - The method is designed to be overridden and produce a side effect in ot=
her projects which are out of the scope of the analysis.
> - The method is called to trigger the class loading which may have a side=
 effect.
> - The method is called just to get some exception.
> If you feel that our assumption is incorrect, you can use a @CheckReturnV=
alue annotation to instruct FindBugs that ignoring the return value of this=
 method is acceptable.
> MacroFormRenderer.java:1275, DM_CONVERT_CASE, Priorit=C3=A4t: Niedrig
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in =
org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderFieldTitle(A=
ppendable, Map, ModelFormField)
> A String is being converted to upper or lowercase, using the platform's d=
efault encoding. This may result in improper conversions when used with int=
ernational characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> MacroFormRenderer.java:1639, NP_NULL_ON_SOME_PATH
> - NP: Possible null pointer dereference of itemIndex in org.apache.ofbiz.=
widget.renderer.macro.MacroFormRenderer.renderFormatItemRowOpen(Appendable,=
 Map, ModelForm)
> There is a branch of statement that, if executed, guarantees that a null =
value will be dereferenced, which would generate a NullPointerException whe=
n the code is executed. Of course, the problem might be that the branch or =
statement is infeasible and that the null pointer exception can't ever be e=
xecuted; deciding that is beyond the ability of FindBugs.
> MacroFormRenderer.java:2339, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> - RCN: Redundant nullcheck of prepLinkText, which is known to be non-null=
 in org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderNextPrev=
(Appendable, Map, ModelForm)
> This method contains a redundant check of a known non-null value against =
the constant null.
> MacroFormRenderer.java:2979, SBSC_USE_STRINGBUFFER_CONCATENATION
> - SBSC: org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.createAj=
axParamsFromUpdateAreas(List, String, Map) concatenates strings using + in =
a loop
> The method seems to be building a String using concatenation in a loop. I=
n each iteration, the String is converted to a StringBuffer/StringBuilder, =
appended to, and converted back to a String. This can lead to a cost quadra=
tic in the number of iterations, as the growing string is recopied in each =
iteration.
> Better performance can be obtained by using a StringBuffer (or StringBuil=
der in Java 1.5) explicitly.
> For example:
>   // This is bad
>   String s =3D "";
>   for (int i =3D 0; i < field.length; ++i) {
>     s =3D s + field[i];
>   }
>   // This is better
>   StringBuffer buf =3D new StringBuffer();
>   for (int i =3D 0; i < field.length; ++i) {
>     buf.append(field[i]);
>   }
>   String s =3D buf.toString();
> MacroFormRenderer.java:3069, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NP=
E
> - RCN: Nullcheck of modelFormField at line 3083 of value previously deref=
erenced in org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.makeHyp=
erlinkByType(Appendable, String, String, String, String, Map, String, Strin=
g, String, ModelFormField, HttpServletRequest, HttpServletResponse, Map)
> A value is checked here to see whether it is null, but this value can't b=
e null because it was previously dereferenced and if it were null a null po=
inter 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 derefe=
rence is erroneous.
> MacroFormRenderer.java:3188, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of hiddenFormName, which is known to be non-null=
 in org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.makeHyperlinkS=
tring(Appendable, String, String, String, Map, String, String, ModelFormFie=
ld, HttpServletRequest, HttpServletResponse, Map, String)
> This method contains a redundant check of a known non-null value against =
the constant null.
> MacroFormRenderer.java:3240, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> - RCN: Redundant nullcheck of hiddenFormName, which is known to be non-nu=
ll in org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.makeHiddenFo=
rmLinkAnchor(Appendable, String, String, String, ModelFormField, HttpServle=
tRequest, HttpServletResponse, Map)
> This method contains a redundant check of a known non-null value against =
the constant null.
> MacroScreenRenderer.java:443, DM_CONVERT_CASE
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() i=
n org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderContentE=
nd(Appendable, Map, ModelScreenWidget$Content)
> A String is being converted to upper or lowercase, using the platform's d=
efault encoding. This may result in improper conversions when used with int=
ernational characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> MacroScreenRenderer.java:443, RV_CHECK_FOR_POSITIVE_INDEXOF
> - RV: org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderCo=
ntentEnd(Appendable, Map, ModelScreenWidget$Content) checks to see if resul=
t of String.indexOf is positive
> The method invokes String.indexOf and checks to see if the result is posi=
tive 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.
> MacroScreenRenderer.java:555, DM_CONVERT_CASE
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() i=
n org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderSubConte=
ntEnd(Appendable, Map, ModelScreenWidget$SubContent)
> A String is being converted to upper or lowercase, using the platform's d=
efault encoding. This may result in improper conversions when used with int=
ernational characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> MacroScreenRenderer.java:555, RV_CHECK_FOR_POSITIVE_INDEXOF
> - RV: org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderSu=
bContentEnd(Appendable, Map, ModelScreenWidget$SubContent) checks to see if=
 result of String.indexOf is positive
> The method invokes String.indexOf and checks to see if the result is posi=
tive 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.
> MacroScreenRenderer.java:726, DM_CONVERT_CASE
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() i=
n org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderScreenle=
tPaginateMenu(Appendable, Map, ModelScreenWidget$Form)
> A String is being converted to upper or lowercase, using the platform's d=
efault encoding. This may result in improper conversions when used with int=
ernational characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> MacroScreenRenderer.java:1022, NP_NULL_ON_SOME_PATH
> - NP: Possible null pointer dereference of modelScreen in org.apache.ofbi=
z.widget.renderer.macro.MacroScreenRenderer.renderPortalPagePortletBody(App=
endable, Map, ModelScreenWidget$PortalPage, GenericValue)
> There is a branch of statement that, if executed, guarantees that a null =
value will be dereferenced, which would generate a NullPointerException whe=
n the code is executed. Of course, the problem might be that the branch or =
statement is infeasible and that the null pointer exception can't ever be e=
xecuted; deciding that is beyond the ability of FindBugs.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)