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