[
https://issues.apache.org/jira/browse/OFBIZ-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9548:
------------------------------------
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.accounting.thirdparty.worldpay
> ------------------------------------------------------------
>
> Key: OFBIZ-9548
> URL: https://issues.apache.org/jira/browse/OFBIZ-9548
> Project: OFBiz
> Issue Type: Sub-task
> Components: accounting
> Affects Versions: Trunk
> Reporter: Kyra Pritzel-Hentley
> Assignee: Michael Brohl
> Priority: Minor
> Attachments:
> OFBIZ-9548_org.apache.ofbiz.accounting.thirdparty.worldpay_bugfixes.patch
>
>
> FindBugs has found the following code bugs:
> WorldPayEvents.java:392, 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 analysis
> shows that the method (including its implementations in subclasses if any)
> does not produce any effect other than return value. Thus this call can be
> removed.
> WorldPayEvents.java:429, DM_NUMBER_CTOR
> * Bx:
> org.apache.ofbiz.accounting.thirdparty.worldpay.WorldPayEvents.setPaymentPreference(LocalDispatcher,
> GenericValue, GenericValue, HttpServletRequest) invokes inefficient new
> Long(String) constructor; use Long.valueOf(String) 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.
> WorldPayEvents.java:487, NP_NULL_ON_SOME_PATH
> * NP: Possible null pointer dereference of results in
> org.apache.ofbiz.accounting.thirdparty.worldpay.WorldPayEvents.setPaymentPreference(LocalDispatcher,
> GenericValue, GenericValue, HttpServletRequest)
> There is a branch of statement that, if executed, guarantees that a null
> value will be dereferenced, which would generate a NullPointerException when
> 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
> executed; deciding that is beyond the ability of FindBugs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
