[
https://issues.apache.org/jira/browse/OFBIZ-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-10056:
-------------------------------------
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.order.order
> -----------------------------------------
>
> Key: OFBIZ-10056
> URL: https://issues.apache.org/jira/browse/OFBIZ-10056
> Project: OFBiz
> Issue Type: Sub-task
> Components: order
> Affects Versions: Trunk
> Reporter: Julian Leichert
> Assignee: Michael Brohl
> Priority: Minor
> Attachments: OFBIZ-No_org.apache.ofbiz.order.order_bugfixes.patch
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
