You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Kyra Pritzel-Hentley (JIRA)" <ji...@apache.org> on 2017/08/03 09:31:00 UTC

[jira] [Created] (OFBIZ-9548) [FB] Package org.apache.ofbiz.accounting.thirdparty.worldpay

Kyra Pritzel-Hentley created OFBIZ-9548:
-------------------------------------------

             Summary: [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
            Priority: Minor


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)