[jira] [Updated] (OFBIZ-9709) [FB] Package org.apache.ofbiz.service.job

["Dennis Balkir (JIRA)" <ji...@apache.org>]

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

Dennis Balkir updated OFBIZ-9709:
---------------------------------
    Attachment: OFBIZ-9709_org.apache.ofbiz.service.job_bugfixes.patch

- Diamond Operators fixed

class AbstractJob:
- Line 116: returned a clone instead of the actual object

class GenericServiceJob:
- Line 38: it’s not necessary for the class to implement serialVerisonUID
- Line 40, 41: won’t happen in Ofbiz-api

class JobManager:
- Line 495: changed the catches to a multicatch
- Line 564: changed the new operator to the more efficient {{Long.valueOf()}}

class PersistedServiceJob:
- Line 62: this was intended this way
- Line 64: won’t happen in Ofbiz-api
- Line 205, 207: changed the new operator to the more efficient {{Long.valueOf()}}
- removed unnecessary else

class PurgeJob:
- Line 34: it’s not necessary for the class to implement serialVerisonUID

> [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
>            Priority: Minor
>         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)