[ 
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)

Reply via email to