[
https://issues.apache.org/jira/browse/OFBIZ-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-9709.
--------------------------------
Resolution: Implemented
Fix Version/s: Upcoming Release
Thanks Dennis,
your patch is in trunk r1812916.
> [FB] Package org.apache.ofbiz.service.job
> -----------------------------------------
>
> Key: OFBIZ-9709
> URL: https://issues.apache.org/jira/browse/OFBIZ-9709
> 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-9709_org.apache.ofbiz.service.job_bugfixes.patch
>
>
> - AbstractJob.java:116, EI_EXPOSE_REP
> EI: org.apache.ofbiz.service.job.AbstractJob.getStartTime() may expose
> internal representation by returning AbstractJob.startTime
> 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.
> - GenericServiceJob.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED
> Se: The field org.apache.ofbiz.service.job.GenericServiceJob.dctx is
> transient but isn't set by deserialization
> This class contains a field that is updated at multiple places in the class,
> thus it seems to be part of the state of the class. However, since the field
> is marked as transient and not set in readObject or readResolve, it will
> contain the default value in any deserialized instance of the class.
> - GenericServiceJob.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED
> Se: The field org.apache.ofbiz.service.job.GenericServiceJob.requester is
> transient but isn't set by deserialization
> This class contains a field that is updated at multiple places in the class,
> thus it seems to be part of the state of the class. However, since the field
> is marked as transient and not set in readObject or readResolve, it will
> contain the default value in any deserialized instance of the class.
> - GenericServiceJob.java:37, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.job.GenericServiceJob 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.
> - GenericServiceJob.java:37, SE_NO_SUITABLE_CONSTRUCTOR
> Se: org.apache.ofbiz.service.job.GenericServiceJob is Serializable but its
> superclass doesn't define an accessible void constructor
> This class implements the Serializable interface and its superclass does not.
> When such an object is deserialized, the fields of the superclass need to be
> initialized by invoking the void constructor of the superclass. Since the
> superclass does not have one, serialization and deserialization will fail at
> runtime.
> - JobManager.java:564, DM_NUMBER_CTOR
> Bx: org.apache.ofbiz.service.job.JobManager.schedule(String, String, String,
> String, long, int, int, int, long, int) invokes inefficient new Long(long)
> constructor; use Long.valueOf(long) instead
> Using new Integer(int) is guaranteed to always result in a new object whereas
> Integer.valueOf(int) allows caching of values to be done by the compiler,
> class library, or JVM. Using of cached values avoids object allocation and
> the code will be faster.
> Values between -128 and 127 are guaranteed to have corresponding cached
> instances and using valueOf is approximately 3.5 times faster than using
> constructor. For values outside the constant range the performance of both
> styles is the same.
> Unless the class must be compatible with JVMs predating Java 1.5, use either
> autoboxing or the valueOf() method when creating instances of Long, Integer,
> Short, Character, and Byte.
> - PersistedServiceJob.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED
> Se: The field org.apache.ofbiz.service.job.PersistedServiceJob.delegator is
> transient but isn't set by deserialization
> This class contains a field that is updated at multiple places in the class,
> thus it seems to be part of the state of the class. However, since the field
> is marked as transient and not set in readObject or readResolve, it will
> contain the default value in any deserialized instance of the class.
> - PersistedServiceJob.java:62, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.job.PersistedServiceJob 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.
> - PersistedServiceJob.java:206, DM_NUMBER_CTOR
> Bx: org.apache.ofbiz.service.job.PersistedServiceJob.createRecurrence(long,
> boolean) invokes inefficient new Long(long) constructor; use
> Long.valueOf(long) instead
> Using new Integer(int) is guaranteed to always result in a new object whereas
> Integer.valueOf(int) allows caching of values to be done by the compiler,
> class library, or JVM. Using of cached values avoids object allocation and
> the code will be faster.
> Values between -128 and 127 are guaranteed to have corresponding cached
> instances and using valueOf is approximately 3.5 times faster than using
> constructor. For values outside the constant range the performance of both
> styles is the same.
> Unless the class must be compatible with JVMs predating Java 1.5, use either
> autoboxing or the valueOf() method when creating instances of Long, Integer,
> Short, Character, and Byte.
> - PurgeJob.java:34, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.job.PurgeJob 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.
> - PurgeJob.java:34, SE_NO_SUITABLE_CONSTRUCTOR
> Se: org.apache.ofbiz.service.job.PurgeJob is Serializable but its superclass
> doesn't define an accessible void constructor
> This class implements the Serializable interface and its superclass does not.
> When such an object is deserialized, the fields of the superclass need to be
> initialized by invoking the void constructor of the superclass. Since the
> superclass does not have one, serialization and deserialization will fail at
> runtime.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
