Minor Description
OrderChangeHelper.java:75, 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.
We are trying to reduce the false positives as much as possible, but in some cases this warning might be wrong. Common false-positive cases include:
- The method is designed to be overridden and produce a side effect in other 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 @CheckReturnValue annotation to instruct FindBugs that ignoring the return value of this method is acceptable.
OrderChangeHelper.java:99, 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.
We are trying to reduce the false positives as much as possible, but in some cases this warning might be wrong. Common false-positive cases include:
- The method is designed to be overridden and produce a side effect in other 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 @CheckReturnValue annotation to instruct FindBugs that ignoring the return value of this method is acceptable.
OrderChangeHelper.java:137, 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.
We are trying to reduce the false positives as much as possible, but in some cases this warning might be wrong. Common false-positive cases include:
- The method is designed to be overridden and produce a side effect in other 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 @CheckReturnValue annotation to instruct FindBugs that ignoring the return value of this method is acceptable.
OrderChangeHelper.java:214, NP_LOAD_OF_KNOWN_NULL_VALUE
- NP: Load of known null value in org.apache.ofbiz.order.order.OrderChangeHelper.orderStatusChanges(LocalDispatcher, GenericValue, String, String, String, String, String)
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).
OrderContentWrapper.java:103, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of OrderContentWrapper.orderContentCache at line 115 of value previously dereferenced in org.apache.ofbiz.order.order.OrderContentWrapper.getOrderContentAsText(GenericValue, String, Locale, String, Delegator, LocalDispatcher, String)
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer 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 dereference is erroneous.
OrderContentWrapper.java:112, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
- RCN: Redundant nullcheck of outString, which is known to be non-null in org.apache.ofbiz.order.order.OrderContentWrapper.getOrderContentAsText(GenericValue, String, Locale, String, Delegator, LocalDispatcher, String)
This method contains a redundant check of a known non-null value against the constant null.
OrderEvents.java:112, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to resultMap in org.apache.ofbiz.order.order.OrderEvents.cancelSelectedOrderItems(HttpServletRequest, HttpServletResponse)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderListState.java:60, SE_NO_SERIALVERSIONID
- SnVI: org.apache.ofbiz.order.order.OrderListState 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.
OrderLookupServices.java:127, RpC_REPEATED_CONDITIONAL_TEST
- RpC: Repeated conditional test in org.apache.ofbiz.order.order.OrderLookupServices.findOrders(DispatchContext, Map)
The code contains a conditional test is performed twice, one right after the other (e.g., x == 0 || x == 0). Perhaps the second occurrence is intended to be something else (e.g., x == 0 || y == 0).
OrderLookupServices.java:406, NP_NULL_ON_SOME_PATH_EXCEPTION
- NP: Possible null pointer dereference of varLookup in org.apache.ofbiz.order.order.OrderLookupServices.findOrders(DispatchContext, Map) on exception path
A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.
Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.
OrderReadHelper.java:2417, DE_MIGHT_IGNORE
- DE: org.apache.ofbiz.order.order.OrderReadHelper.getOrderItemSubTotal(GenericValue, List, boolean, boolean) might ignore org.apache.ofbiz.entity.GenericEntityException
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.
OrderReadHelper.java:2426, NP_NULL_PARAM_DEREF
- NP: Null passed for nonnull parameter of getWorkEffortRentalQuantity(GenericValue) in org.apache.ofbiz.order.order.OrderReadHelper.getOrderItemSubTotal(GenericValue, List, boolean, boolean)
This method call passes a null value for a non-null method parameter. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.
OrderReadHelper.java:2706, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
- RCN: Redundant nullcheck of orderHeaderAdjustments, which is known to be non-null in org.apache.ofbiz.order.order.OrderReadHelper.getAvailableOrderHeaderAdjustments()
This method contains a redundant check of a known non-null value against the constant null.
OrderReturnServices.java:212, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to returnAdjustments in org.apache.ofbiz.order.order.OrderReturnServices.sendReturnNotificationScreen(DispatchContext, Map, String)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderReturnServices.java:544, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of item at line 544 of value previously dereferenced in org.apache.ofbiz.order.order.OrderReturnServices.getReturnableItems(DispatchContext, Map)
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer 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 dereference is erroneous.
OrderReturnServices.java:686, NP_NULL_ON_SOME_PATH
- NP: Possible null pointer dereference of returnHeader in org.apache.ofbiz.order.order.OrderReturnServices.checkReturnComplete(DispatchContext, Map)
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.
OrderReturnServices.java:765, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to billingAccounts in org.apache.ofbiz.order.order.OrderReturnServices.processCreditReturn(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderReturnServices.java:1089, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to orderPayPrefs in org.apache.ofbiz.order.order.OrderReturnServices.processRefundReturnForReplacement(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderReturnServices.java:1101, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to returnItemResponses in org.apache.ofbiz.order.order.OrderReturnServices.processRefundReturnForReplacement(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderReturnServices.java:1317, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to otherPaymentMethodTypes in org.apache.ofbiz.order.order.OrderReturnServices.processRefundReturn(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderReturnServices.java:1692, NP_NULL_ON_SOME_PATH
- NP: Possible null pointer dereference of returnHeader in org.apache.ofbiz.order.order.OrderReturnServices.processReplacementReturn(DispatchContext, Map)
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.
OrderReturnServices.java:1692, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of returnHeader at line 1692 of value previously dereferenced in org.apache.ofbiz.order.order.OrderReturnServices.processReplacementReturn(DispatchContext, Map)
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer 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 dereference is erroneous.
OrderReturnServices.java:1769, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of orderItem at line 1769 of value previously dereferenced in org.apache.ofbiz.order.order.OrderReturnServices.processReplacementReturn(DispatchContext, Map)
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer 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 dereference is erroneous.
OrderReturnServices.java:2250, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderReturnServices.groupReturnItemsByOrder(List, Map, Map, Delegator, String, String) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderReturnServices.java:2318, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderReturnServices.checkPaymentAmountForRefund(DispatchContext, Map) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderServices.java:97, MS_SHOULD_BE_FINAL
- MS: org.apache.ofbiz.order.order.OrderServices.salesAttributeRoleMap isn't final but should be
This static field public but not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
OrderServices.java:98, MS_SHOULD_BE_FINAL
- MS: org.apache.ofbiz.order.order.OrderServices.purchaseAttributeRoleMap isn't final but should be
This static field public but not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.
OrderServices.java:201, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to partyId in org.apache.ofbiz.order.order.OrderServices.createOrder(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderServices.java:300, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderServices.createOrder(DispatchContext, Map) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderServices.java:566, NP_NULL_ON_SOME_PATH
- NP: Possible null pointer dereference of userLogin in org.apache.ofbiz.order.order.OrderServices.createOrder(DispatchContext, Map)
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.
OrderServices.java:1261, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
- RCN: Redundant nullcheck of product, which is known to be non-null in org.apache.ofbiz.order.order.OrderServices.reserveInventory(Delegator, LocalDispatcher, GenericValue, Locale, List, List, Map, String, String, List)
This method contains a redundant check of a known non-null value against the constant null.
OrderServices.java:2377, 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.
We are trying to reduce the false positives as much as possible, but in some cases this warning might be wrong. Common false-positive cases include:
- The method is designed to be overridden and produce a side effect in other 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 @CheckReturnValue annotation to instruct FindBugs that ignoring the return value of this method is acceptable.
OrderServices.java:2381, 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.
We are trying to reduce the false positives as much as possible, but in some cases this warning might be wrong. Common false-positive cases include:
- The method is designed to be overridden and produce a side effect in other 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 @CheckReturnValue annotation to instruct FindBugs that ignoring the return value of this method is acceptable.
OrderServices.java:2466, 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.
We are trying to reduce the false positives as much as possible, but in some cases this warning might be wrong. Common false-positive cases include:
- The method is designed to be overridden and produce a side effect in other 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 @CheckReturnValue annotation to instruct FindBugs that ignoring the return value of this method is acceptable.
OrderServices.java:2624, RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE
- RCN: Redundant nullcheck of locale which is known to be null in org.apache.ofbiz.order.order.OrderServices.sendOrderNotificationScreen(DispatchContext, Map, String)
This method contains a redundant check of a known null value against the constant null.
OrderServices.java:2624, NP_LOAD_OF_KNOWN_NULL_VALUE
- NP: Load of known null value in org.apache.ofbiz.order.order.OrderServices.sendOrderNotificationScreen(DispatchContext, Map, String)
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).
OrderServices.java:2712, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of workEffort at line 2712 of value previously dereferenced in org.apache.ofbiz.order.order.OrderServices.sendProcessNotification(DispatchContext, Map)
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer 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 dereference is erroneous.
OrderServices.java:3495, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to amount in org.apache.ofbiz.order.order.OrderServices.addItemToApprovedOrder(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderServices.java:3521, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
- RCN: Redundant nullcheck of cart, which is known to be non-null in org.apache.ofbiz.order.order.OrderServices.addItemToApprovedOrder(DispatchContext, Map)
This method contains a redundant check of a known non-null value against the constant null.
OrderServices.java:3661, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
- RCN: Redundant nullcheck of cart, which is known to be non-null in org.apache.ofbiz.order.order.OrderServices.updateApprovedOrderItems(DispatchContext, Map)
This method contains a redundant check of a known non-null value against the constant null.
OrderServices.java:3669, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderServices.updateApprovedOrderItems(DispatchContext, Map) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderServices.java:4818, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderServices.massPickOrders(DispatchContext, Map) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderServices.java:5015, REC_CATCH_EXCEPTION
- REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.order.order.OrderServices.checkCreateDropShipPurchaseOrders(DispatchContext, Map)
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 ... }OrderServices.java:5048, NP_LOAD_OF_KNOWN_NULL_VALUE
- NP: Load of known null value in org.apache.ofbiz.order.order.OrderServices.updateOrderPaymentPreference(DispatchContext, Map)
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).
OrderServices.java:5136, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderServices.generateReqsFromCancelledPOItems(DispatchContext, Map) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderServices.java:5257, WMI_WRONG_MAP_ITERATOR
- WMI: org.apache.ofbiz.order.order.OrderServices.createSimpleNonProductSalesOrder(DispatchContext, Map) makes inefficient use of keySet iterator instead of entrySet iterator
This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
OrderServices.java:5392, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to orderItemTotalValue in org.apache.ofbiz.order.order.OrderServices.getOrderItemInvoicedAmountAndQuantity(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderServices.java:5590, DM_BOXED_PRIMITIVE_FOR_PARSING
- Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.order.order.OrderServices.runSubscriptionAutoReorders(DispatchContext, Map)
A boxed primitive is created from a String, just to extract the unboxed primitive value. It is more efficient to just call the static parseXXX method.
OrderServices.java:5623, NP_NULL_ON_SOME_PATH
- NP: Possible null pointer dereference of createResp in org.apache.ofbiz.order.order.OrderServices.runSubscriptionAutoReorders(DispatchContext, Map)
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.
OrderServices.java:5685, DLS_DEAD_LOCAL_STORE
- DLS: Dead store to result in org.apache.ofbiz.order.order.OrderServices.addOrderItemShipGroup(DispatchContext, Map)
This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
OrderServices.java:5918, DM_NUMBER_CTOR
- Bx: org.apache.ofbiz.order.order.OrderServices.updateOrderItemShipGroupAssoc(DispatchContext, Map) invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) 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.
OrderServices.java:5945, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
- RCN: Nullcheck of rowNumber at line 5961 of value previously dereferenced in org.apache.ofbiz.order.order.OrderServices.updateOrderItemShipGroupAssoc(DispatchContext, Map)
A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer 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 dereference is erroneous.
OrderServices.java:6350, NP_LOAD_OF_KNOWN_NULL_VALUE
- NP: Load of known null value in org.apache.ofbiz.order.order.OrderServices.updateShipGroupShipInfo(DispatchContext, Map)
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).