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] [Assigned] (OFBIZ-9709) [FB] Package org.apache.ofbiz.service.job
Date Fri, 13 Oct 2017 21:02:01 GMT

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

Michael Brohl reassigned OFBIZ-9709:
------------------------------------

    Assignee: Michael Brohl

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

Mime
View raw message