Julian Leichert created OFBIZ-10056:
---------------------------------------
Summary: [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
Priority: Minor
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)
