ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Brohl (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (OFBIZ-9691) [FB] Package org.apache.ofbiz.service.calendar
Date Thu, 12 Oct 2017 22:09:00 GMT

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

Michael Brohl closed OFBIZ-9691.
--------------------------------
       Resolution: Implemented
    Fix Version/s: Upcoming Release

Thanks Dennis,

your patch is in trunk r1812057.


> [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
>            Assignee: Michael Brohl
>            Priority: Minor
>             Fix For: Upcoming Release
>
>         Attachments: OFBIZ-9691_org.apache.ofbiz.service.calendar_bugfixes.patch
>
>
> - 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