ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Balkir (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OFBIZ-9691) [FB] Package org.apache.ofbiz.service.calendar
Date Fri, 08 Sep 2017 11:22:00 GMT

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

Dennis Balkir updated OFBIZ-9691:
---------------------------------
    Summary: [FB] Package org.apache.ofbiz.service.calendar  (was: [FB] Package org.apache.ofbiz.service.mail)

> [FB] Package org.apache.ofbiz.service.calendar
> ----------------------------------------------
>
>                 Key: OFBIZ-9691
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9691
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Dennis Balkir
>            Priority: Minor
>
> - JavaMailContainer.java:127, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of store, which is known to be non-null in org.apache.ofbiz.service.mail.JavaMailContainer.start()
> This method contains a redundant check of a known non-null value against the constant
null.
> - JavaMailContainer.java:167, DM_CONVERT_CASE
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.mail.JavaMailContainer.makeSession(ContainerConfig$Configuration$Property)
> A String is being converted to upper or lowercase, using the platform's default encoding.
This may result in improper conversions when used with international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> - JavaMailContainer.java:245, DM_BOXED_PRIMITIVE_FOR_PARSING
> Bx: Boxing/unboxing to parse a primitive org.apache.ofbiz.service.mail.JavaMailContainer.updateUrlName(URLName,
Properties)
> A boxed primitive is created from a String, just to extract the unboxed primitive value.
It is more efficient to just call the static parseXXX method.
> - JavaMailContainer.java:269, SIC_INNER_SHOULD_BE_STATIC
> SIC: Should org.apache.ofbiz.service.mail.JavaMailContainer$LoggingStoreListener be a
_static_ inner class?
> This class is an inner class, but does not use its embedded reference to the object which
created it.  This reference makes the instances of the class larger, and may keep the reference
to the creator object alive longer than necessary.  If possible, the class should be made
static.
> - JavaMailContainer.java:274, SF_SWITCH_NO_DEFAULT
> SF: Switch statement found in org.apache.ofbiz.service.mail.JavaMailContainer$LoggingStoreListener.notification(StoreEvent)
where default case is missing
> This method contains a switch statement where default case is missing. Usually you need
to provide a default case.
> Because the analysis only looks at the generated bytecode, this warning can be incorrect
triggered if the default case is at the end of the switch statement and the switch statement
doesn't contain break statements for other cases.
> - MimeMessageWrapper.java:50, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.mail.MimeMessageWrapper 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.
> - MimeMessageWrapper.java:68, IS2_INCONSISTENT_SYNC
> IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.session;
locked 75% of time
> The fields of this class appear to be accessed inconsistently with respect to synchronization.
 This bug report indicates that the bug pattern detector judged that
> The class contains a mix of locked and unlocked accesses,
> The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
> At least one locked access was performed by one of the class's own methods, and
> The number of unsynchronized field accesses (reads and writes) was no more than one third
of all accesses, with writes being weighed twice as high as reads
> A typical bug matching this bug pattern is forgetting to synchronize one of the methods
in a class that is intended to be thread-safe.
> You can select the nodes labeled "Unsynchronized access" to show the code locations where
the detector believed that a field was accessed without synchronization.
> Note that there are various sources of inaccuracy in this detector; for example, the
detector cannot statically detect all situations in which a lock is held.  Also, even when
the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question
may still be correct.
> - MimeMessageWrapper.java:69, IS2_INCONSISTENT_SYNC
> IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.mailProperties;
locked 50% of time
> The fields of this class appear to be accessed inconsistently with respect to synchronization.
 This bug report indicates that the bug pattern detector judged that
> The class contains a mix of locked and unlocked accesses,
> The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
> At least one locked access was performed by one of the class's own methods, and
> The number of unsynchronized field accesses (reads and writes) was no more than one third
of all accesses, with writes being weighed twice as high as reads
> A typical bug matching this bug pattern is forgetting to synchronize one of the methods
in a class that is intended to be thread-safe.
> You can select the nodes labeled "Unsynchronized access" to show the code locations where
the detector believed that a field was accessed without synchronization.
> Note that there are various sources of inaccuracy in this detector; for example, the
detector cannot statically detect all situations in which a lock is held.  Also, even when
the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question
may still be correct.
> - MimeMessageWrapper.java:82, IS2_INCONSISTENT_SYNC
> IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.message;
locked 75% of time
> The fields of this class appear to be accessed inconsistently with respect to synchronization.
 This bug report indicates that the bug pattern detector judged that
> The class contains a mix of locked and unlocked accesses,
> The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
> At least one locked access was performed by one of the class's own methods, and
> The number of unsynchronized field accesses (reads and writes) was no more than one third
of all accesses, with writes being weighed twice as high as reads
> A typical bug matching this bug pattern is forgetting to synchronize one of the methods
in a class that is intended to be thread-safe.
> You can select the nodes labeled "Unsynchronized access" to show the code locations where
the detector believed that a field was accessed without synchronization.
> Note that there are various sources of inaccuracy in this detector; for example, the
detector cannot statically detect all situations in which a lock is held.  Also, even when
the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question
may still be correct.
> - MimeMessageWrapper.java:87, IS2_INCONSISTENT_SYNC
> IS: Inconsistent synchronization of org.apache.ofbiz.service.mail.MimeMessageWrapper.serializedBytes;
locked 66% of time
> The fields of this class appear to be accessed inconsistently with respect to synchronization.
 This bug report indicates that the bug pattern detector judged that
> The class contains a mix of locked and unlocked accesses,
> The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
> At least one locked access was performed by one of the class's own methods, and
> The number of unsynchronized field accesses (reads and writes) was no more than one third
of all accesses, with writes being weighed twice as high as reads
> A typical bug matching this bug pattern is forgetting to synchronize one of the methods
in a class that is intended to be thread-safe.
> You can select the nodes labeled "Unsynchronized access" to show the code locations where
the detector believed that a field was accessed without synchronization.
> Note that there are various sources of inaccuracy in this detector; for example, the
detector cannot statically detect all situations in which a lock is held.  Also, even when
the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question
may still be correct.
> - MimeMessageWrapper.java:142, PZLA_PREFER_ZERO_LENGTH_ARRAYS
> PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getHeader(String) return
a zero length array rather than null?
> It is often a better design to return a length zero array rather than a null reference
to indicate that there are no results (i.e., an empty list of results). This way, no explicit
check for null is needed by clients of the method.
> On the other hand, using null to indicate "there is no answer to this question" is probably
appropriate. For example, File.listFiles() returns an empty list if given a directory containing
no files, and returns null if the file is not a directory.
> - MimeMessageWrapper.java:152, PZLA_PREFER_ZERO_LENGTH_ARRAYS
> PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getFrom() return a zero
length array rather than null?
> It is often a better design to return a length zero array rather than a null reference
to indicate that there are no results (i.e., an empty list of results). This way, no explicit
check for null is needed by clients of the method.
> On the other hand, using null to indicate "there is no answer to this question" is probably
appropriate. For example, File.listFiles() returns an empty list if given a directory containing
no files, and returns null if the file is not a directory.
> - MimeMessageWrapper.java:162, PZLA_PREFER_ZERO_LENGTH_ARRAYS
> PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getTo() return a zero length
array rather than null?
> It is often a better design to return a length zero array rather than a null reference
to indicate that there are no results (i.e., an empty list of results). This way, no explicit
check for null is needed by clients of the method.
> On the other hand, using null to indicate "there is no answer to this question" is probably
appropriate. For example, File.listFiles() returns an empty list if given a directory containing
no files, and returns null if the file is not a directory.
> - MimeMessageWrapper.java:172, PZLA_PREFER_ZERO_LENGTH_ARRAYS
> PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getCc() return a zero length
array rather than null?
> It is often a better design to return a length zero array rather than a null reference
to indicate that there are no results (i.e., an empty list of results). This way, no explicit
check for null is needed by clients of the method.
> On the other hand, using null to indicate "there is no answer to this question" is probably
appropriate. For example, File.listFiles() returns an empty list if given a directory containing
no files, and returns null if the file is not a directory.
> - MimeMessageWrapper.java:182, PZLA_PREFER_ZERO_LENGTH_ARRAYS
> PZLA: Should org.apache.ofbiz.service.mail.MimeMessageWrapper.getBcc() return a zero
length array rather than null?
> It is often a better design to return a length zero array rather than a null reference
to indicate that there are no results (i.e., an empty list of results). This way, no explicit
check for null is needed by clients of the method.
> On the other hand, using null to indicate "there is no answer to this question" is probably
appropriate. For example, File.listFiles() returns an empty list if given a directory containing
no files, and returns null if the file is not a directory.
> - MimeMessageWrapper.java:294, DM_CONVERT_CASE
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.mail.MimeMessageWrapper.getMessageBody()
> A String is being converted to upper or lowercase, using the platform's default encoding.
This may result in improper conversions when used with international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> - MimeMessageWrapper.java:315, DM_CONVERT_CASE
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.service.mail.MimeMessageWrapper.getMessageBodyContentType()
> A String is being converted to upper or lowercase, using the platform's default encoding.
This may result in improper conversions when used with international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> - MimeMessageWrapper.java:526, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in org.apache.ofbiz.service.mail.MimeMessageWrapper.getTextFromStream(InputStream):
new String(byte[], int, int)
> Found a call to a method which will perform a byte to String (or String to byte) conversion,
and will assume that the default platform encoding is suitable. This will cause the application
behaviour to vary between platforms. Use an alternative API and specify a charset name or
Charset object explicitly.
> - ServiceMcaAction.java:36, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.mail.ServiceMcaAction 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.
> - ServiceMcaCondition.java:44, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.mail.ServiceMcaCondition 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.
> - ServiceMcaCondition.java:56, SF_SWITCH_NO_DEFAULT
> SF: Switch statement found in new org.apache.ofbiz.service.mail.ServiceMcaCondition(Element,
int) where default case is missing
> This method contains a switch statement where default case is missing. Usually you need
to provide a default case.
> Because the analysis only looks at the generated bytecode, this warning can be incorrect
triggered if the default case is at the end of the switch statement and the switch statement
doesn't contain break statements for other cases.
> - ServiceMcaRule.java:35, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.mail.ServiceMcaRule 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message