ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Balkir (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OFBIZ-9691) [FB] Package org.apache.ofbiz.service.calendar
Date Fri, 08 Sep 2017 11:22:01 GMT

     [ https://issues.apache.org/jira/browse/OFBIZ-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Balkir updated OFBIZ-9691:
---------------------------------
    Description: 
- ExpressionUiHelper.java:42, MS_PKGPROTECT
MS: org.apache.ofbiz.service.calendar.ExpressionUiHelper.Occurrence should be package protected

A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability.

- RecurrenceInfo.java:-1, SE_BAD_FIELD
Se: Class org.apache.ofbiz.service.calendar.RecurrenceInfo$RecurrenceWrapper defines non-transient non-serializable instance field info

This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods.  Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field.

- RecurrenceInfo.java:117, EI_EXPOSE_REP
EI: org.apache.ofbiz.service.calendar.RecurrenceInfo.getStartDate() may expose internal representation by returning RecurrenceInfo.startDate

Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object.  If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.

- RecurrenceInfo.java:349, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.RecurrenceInfo$RecurrenceWrapper 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.

- RecurrenceRule.java:197, DM_CONVERT_CASE
Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.calendar.RecurrenceRule.getFrequencyName()

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )
versions instead.

- RecurrenceRule.java:321, SF_SWITCH_NO_DEFAULT
SF: Switch statement found in org.apache.ofbiz.service.calendar.RecurrenceRule.validCurrent(long, long, long) where default case is missing

This method contains a switch statement where default case is missing. Usually you need to provide a default case.

Because the analysis only looks at the generated bytecode, this warning can be incorrect triggered if the default case is at the end of the switch statement and the switch statement doesn't contain break statements for other cases.

- RecurrenceRule.java:335, SF_SWITCH_FALLTHROUGH
SF: Switch statement found in org.apache.ofbiz.service.calendar.RecurrenceRule.validCurrent(long, long, long) where one case falls through to the next case

This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.

- RecurrenceRule.java:724, NP_NULL_ON_SOME_PATH
NP: Possible null pointer dereference of day in org.apache.ofbiz.service.calendar.RecurrenceRule.getCalendarDay(String)

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.

- TemporalExpression.java:47, EQ_COMPARETO_USE_OBJECT_EQUALS
Eq: org.apache.ofbiz.service.calendar.TemporalExpression defines compareTo(TemporalExpression) and uses Object.equals()

This class defines a compareTo(...) method but inherits its equals() method from java.lang.Object. Generally, the value of compareTo should return zero if and only if equals returns true. If this is violated, weird and unpredictable failures will occur in classes such as PriorityQueue. In Java 5 the PriorityQueue.remove method uses the compareTo method, while in Java 6 it uses the equals method.

>From the JavaDoc for the compareTo method in the Comparable interface:

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."

- TemporalExpression.java:81, DLS_DEAD_LOCAL_STORE
DLS: Dead store to last in org.apache.ofbiz.service.calendar.TemporalExpression.getRange(DateRange, Calendar)

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.

- TemporalExpression.java:139, SIC_INNER_SHOULD_BE_STATIC
SIC: Should org.apache.ofbiz.service.calendar.TemporalExpression$ExpressionContext be a _static_ inner class?

This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made static.

- TemporalExpression.java:142, URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD
UrF: Unread public/protected field: org.apache.ofbiz.service.calendar.TemporalExpression$ExpressionContext.monthBumped

This field is never read.  The field is public or protected, so perhaps it is intended to be used with classes not seen as part of the analysis. If not, consider removing it from the class.

- TemporalExpressionWorker.java:166, MS_EXPOSE_REP
MS: Public static org.apache.ofbiz.service.calendar.TemporalExpressionWorker.getExpressionTypeList() may expose internal representation by returning TemporalExpressionWorker.ExpressionTypeList

A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. One fix is to return a copy of the array.

- TemporalExpressions.java:36, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions 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.

- TemporalExpressions.java:63, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DateRange 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.

- TemporalExpressions.java:81, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DateRange defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:81, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DateRange.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:133, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DayInMonth 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.

- TemporalExpressions.java:179, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DayInMonth.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:179, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DayInMonth defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:268, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfMonthRange 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.

- TemporalExpressions.java:297, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfMonthRange.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:297, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfMonthRange defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:371, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfWeekRange 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.

- TemporalExpressions.java:402, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfWeekRange defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:402, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfWeekRange.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:497, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Difference 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.

- TemporalExpressions.java:524, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Difference.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:524, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Difference defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:595, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency 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.

- TemporalExpressions.java:605, EI_EXPOSE_REP2
EI2: new org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency(Date, int, int) may expose internal representation by storing an externally mutable object into TemporalExpressions$Frequency.start

This code stores a reference to an externally mutable object into the internal representation of the object.  If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

- TemporalExpressions.java:624, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:624, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:738, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$HourRange 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.

- TemporalExpressions.java:767, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$HourRange defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:767, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$HourRange.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:874, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Intersection 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.

- TemporalExpressions.java:915, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Intersection.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:915, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Intersection defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:995, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$MinuteRange 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.

- TemporalExpressions.java:1024, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$MinuteRange.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:1024, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$MinuteRange defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:1129, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$MonthRange 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.

- TemporalExpressions.java:1160, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$MonthRange defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:1160, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$MonthRange.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:1244, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Null 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.

- TemporalExpressions.java:1273, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Substitution 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.

- TemporalExpressions.java:1307, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Substitution defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:1307, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Substitution.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

- TemporalExpressions.java:1380, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Union 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.

- TemporalExpressions.java:1414, HE_EQUALS_USE_HASHCODE
HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Union defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do
  }
  
- TemporalExpressions.java:1414, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Union.equals(Object) does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

  was:
- JavaMailContainer.java:127, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
RCN: Redundant nullcheck of store, which is known to be non-null in org.apache.ofbiz.service.mail.JavaMailContainer.start()

This method contains a redundant check of a known non-null value against the constant null.

- JavaMailContainer.java:167, DM_CONVERT_CASE
Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.mail.JavaMailContainer.makeSession(ContainerConfig$Configuration$Property)

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )
versions instead.

- JavaMailContainer.java:245, DM_BOXED_PRIMITIVE_FOR_PARSING
Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.service.mail.JavaMailContainer.updateUrlName(URLName, Properties)

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.

- JavaMailContainer.java:269, SIC_INNER_SHOULD_BE_STATIC
SIC: Should org.apache.ofbiz.service.mail.JavaMailContainer$LoggingStoreListener be a _static_ inner class?

This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made static.

- JavaMailContainer.java:274, SF_SWITCH_NO_DEFAULT
SF: Switch statement found in org.apache.ofbiz.service.mail.JavaMailContainer$LoggingStoreListener.notification(StoreEvent) where default case is missing

This method contains a switch statement where default case is missing. Usually you need to provide a default case.

Because the analysis only looks at the generated bytecode, this warning can be incorrect triggered if the default case is at the end of the switch statement and the switch statement doesn't contain break statements for other cases.

- MimeMessageWrapper.java:50, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.mail.MimeMessageWrapper 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.

- MimeMessageWrapper.java:68, IS2_INCONSISTENT_SYNC
IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.session; locked 75% of time

The fields of this class appear to be accessed inconsistently with respect to synchronization.  This bug report indicates that the bug pattern detector judged that

The class contains a mix of locked and unlocked accesses,
The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads
A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held.  Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

- MimeMessageWrapper.java:69, IS2_INCONSISTENT_SYNC
IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.mailProperties; locked 50% of time

The fields of this class appear to be accessed inconsistently with respect to synchronization.  This bug report indicates that the bug pattern detector judged that

The class contains a mix of locked and unlocked accesses,
The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads
A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held.  Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

- MimeMessageWrapper.java:82, IS2_INCONSISTENT_SYNC
IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.message; locked 75% of time

The fields of this class appear to be accessed inconsistently with respect to synchronization.  This bug report indicates that the bug pattern detector judged that

The class contains a mix of locked and unlocked accesses,
The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads
A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held.  Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

- MimeMessageWrapper.java:87, IS2_INCONSISTENT_SYNC
IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.serializedBytes; locked 66% of time

The fields of this class appear to be accessed inconsistently with respect to synchronization.  This bug report indicates that the bug pattern detector judged that

The class contains a mix of locked and unlocked accesses,
The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads
A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held.  Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

- MimeMessageWrapper.java:142, PZLA_PREFER_ZERO_LENGTH_ARRAYS
PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getHeader(String) return a zero length array rather than null?

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

- MimeMessageWrapper.java:152, PZLA_PREFER_ZERO_LENGTH_ARRAYS
PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getFrom() return a zero length array rather than null?

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

- MimeMessageWrapper.java:162, PZLA_PREFER_ZERO_LENGTH_ARRAYS
PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getTo() return a zero length array rather than null?

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

- MimeMessageWrapper.java:172, PZLA_PREFER_ZERO_LENGTH_ARRAYS
PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getCc() return a zero length array rather than null?

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

- MimeMessageWrapper.java:182, PZLA_PREFER_ZERO_LENGTH_ARRAYS
PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getBcc() return a zero length array rather than null?

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

- MimeMessageWrapper.java:294, DM_CONVERT_CASE
Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.mail.MimeMessageWrapper.getMessageBody()

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )
versions instead.

- MimeMessageWrapper.java:315, DM_CONVERT_CASE
Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.mail.MimeMessageWrapper.getMessageBodyContentType()

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )
versions instead.

- MimeMessageWrapper.java:526, DM_DEFAULT_ENCODING
Dm: Found reliance on default encoding in org.apache.ofbiz.service.mail.MimeMessageWrapper.getTextFromStream(InputStream): new String(byte[], int, int)

Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.

- ServiceMcaAction.java:36, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.mail.ServiceMcaAction 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.

- ServiceMcaCondition.java:44, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.mail.ServiceMcaCondition 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.

- ServiceMcaCondition.java:56, SF_SWITCH_NO_DEFAULT
SF: Switch statement found in new org.apache.ofbiz.service.mail.ServiceMcaCondition(Element, int) where default case is missing

This method contains a switch statement where default case is missing. Usually you need to provide a default case.

Because the analysis only looks at the generated bytecode, this warning can be incorrect triggered if the default case is at the end of the switch statement and the switch statement doesn't contain break statements for other cases.

- ServiceMcaRule.java:35, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.mail.ServiceMcaRule 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.


> [FB] Package org.apache.ofbiz.service.calendar
> ----------------------------------------------
>
>                 Key: OFBIZ-9691
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9691
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Dennis Balkir
>            Priority: Minor
>
> - ExpressionUiHelper.java:42, MS_PKGPROTECT
> MS: org.apache.ofbiz.service.calendar.ExpressionUiHelper.Occurrence should be package protected
> A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability.
> - RecurrenceInfo.java:-1, SE_BAD_FIELD
> Se: Class org.apache.ofbiz.service.calendar.RecurrenceInfo$RecurrenceWrapper defines non-transient non-serializable instance field info
> This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods.  Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field.
> - RecurrenceInfo.java:117, EI_EXPOSE_REP
> EI: org.apache.ofbiz.service.calendar.RecurrenceInfo.getStartDate() may expose internal representation by returning RecurrenceInfo.startDate
> Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object.  If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.
> - RecurrenceInfo.java:349, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.RecurrenceInfo$RecurrenceWrapper 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.
> - RecurrenceRule.java:197, DM_CONVERT_CASE
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.calendar.RecurrenceRule.getFrequencyName()
> A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> - RecurrenceRule.java:321, SF_SWITCH_NO_DEFAULT
> SF: Switch statement found in org.apache.ofbiz.service.calendar.RecurrenceRule.validCurrent(long, long, long) where default case is missing
> This method contains a switch statement where default case is missing. Usually you need to provide a default case.
> Because the analysis only looks at the generated bytecode, this warning can be incorrect triggered if the default case is at the end of the switch statement and the switch statement doesn't contain break statements for other cases.
> - RecurrenceRule.java:335, SF_SWITCH_FALLTHROUGH
> SF: Switch statement found in org.apache.ofbiz.service.calendar.RecurrenceRule.validCurrent(long, long, long) where one case falls through to the next case
> This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.
> - RecurrenceRule.java:724, NP_NULL_ON_SOME_PATH
> NP: Possible null pointer dereference of day in org.apache.ofbiz.service.calendar.RecurrenceRule.getCalendarDay(String)
> 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.
> - TemporalExpression.java:47, EQ_COMPARETO_USE_OBJECT_EQUALS
> Eq: org.apache.ofbiz.service.calendar.TemporalExpression defines compareTo(TemporalExpression) and uses Object.equals()
> This class defines a compareTo(...) method but inherits its equals() method from java.lang.Object. Generally, the value of compareTo should return zero if and only if equals returns true. If this is violated, weird and unpredictable failures will occur in classes such as PriorityQueue. In Java 5 the PriorityQueue.remove method uses the compareTo method, while in Java 6 it uses the equals method.
> From the JavaDoc for the compareTo method in the Comparable interface:
> It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."
> - TemporalExpression.java:81, DLS_DEAD_LOCAL_STORE
> DLS: Dead store to last in org.apache.ofbiz.service.calendar.TemporalExpression.getRange(DateRange, Calendar)
> 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.
> - TemporalExpression.java:139, SIC_INNER_SHOULD_BE_STATIC
> SIC: Should org.apache.ofbiz.service.calendar.TemporalExpression$ExpressionContext be a _static_ inner class?
> This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made static.
> - TemporalExpression.java:142, URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD
> UrF: Unread public/protected field: org.apache.ofbiz.service.calendar.TemporalExpression$ExpressionContext.monthBumped
> This field is never read.  The field is public or protected, so perhaps it is intended to be used with classes not seen as part of the analysis. If not, consider removing it from the class.
> - TemporalExpressionWorker.java:166, MS_EXPOSE_REP
> MS: Public static org.apache.ofbiz.service.calendar.TemporalExpressionWorker.getExpressionTypeList() may expose internal representation by returning TemporalExpressionWorker.ExpressionTypeList
> A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. One fix is to return a copy of the array.
> - TemporalExpressions.java:36, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions 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.
> - TemporalExpressions.java:63, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DateRange 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.
> - TemporalExpressions.java:81, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DateRange defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:81, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DateRange.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:133, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DayInMonth 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.
> - TemporalExpressions.java:179, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DayInMonth.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:179, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DayInMonth defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:268, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfMonthRange 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.
> - TemporalExpressions.java:297, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfMonthRange.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:297, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfMonthRange defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:371, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfWeekRange 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.
> - TemporalExpressions.java:402, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfWeekRange defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:402, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$DayOfWeekRange.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:497, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Difference 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.
> - TemporalExpressions.java:524, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Difference.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:524, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Difference defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:595, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency 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.
> - TemporalExpressions.java:605, EI_EXPOSE_REP2
> EI2: new org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency(Date, int, int) may expose internal representation by storing an externally mutable object into TemporalExpressions$Frequency.start
> This code stores a reference to an externally mutable object into the internal representation of the object.  If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.
> - TemporalExpressions.java:624, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:624, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Frequency defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:738, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$HourRange 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.
> - TemporalExpressions.java:767, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$HourRange defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:767, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$HourRange.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:874, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Intersection 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.
> - TemporalExpressions.java:915, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Intersection.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:915, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Intersection defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:995, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$MinuteRange 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.
> - TemporalExpressions.java:1024, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$MinuteRange.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:1024, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$MinuteRange defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:1129, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$MonthRange 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.
> - TemporalExpressions.java:1160, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$MonthRange defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:1160, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$MonthRange.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:1244, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Null 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.
> - TemporalExpressions.java:1273, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Substitution 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.
> - TemporalExpressions.java:1307, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Substitution defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:1307, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Substitution.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.
> - TemporalExpressions.java:1380, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.calendar.TemporalExpressions$Union 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.
> - TemporalExpressions.java:1414, HE_EQUALS_USE_HASHCODE
> HE: org.apache.ofbiz.service.calendar.TemporalExpressions$Union defines equals and uses Object.hashCode()
> This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
> If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:
> public int hashCode() {
>   assert false : "hashCode not designed";
>   return 42; // any arbitrary constant will do
>   }
>   
> - TemporalExpressions.java:1414, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> NP: org.apache.ofbiz.service.calendar.TemporalExpressions$Union.equals(Object) does not check for null argument
> This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message