[jira] [Updated] (OFBIZ-9714) [FB] Package org.apache.ofbiz.service.rmi.socket.ssl

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9714:
-
Attachment: 
OFBIZ-9714_org.apache.ofbiz.service.rmi.socket.ssl_bugfixes.patch

class SSLClientSocketFactory:
- Line 38: it’s not necessary for the class to implement serialVerisonUID

class SSLServerSocketFactory:
- Line 43: it’s not necessary for the class to implement serialVerisonUID
- Line 74 and following: changed the declaration of the FileInputStream
- Line 117: changed the code to reduce the possibility of errors


> [FB] Package org.apache.ofbiz.service.rmi.socket.ssl
> 
>
> Key: OFBIZ-9714
> URL: https://issues.apache.org/jira/browse/OFBIZ-9714
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: 
> OFBIZ-9714_org.apache.ofbiz.service.rmi.socket.ssl_bugfixes.patch
>
>
> - SSLClientSocketFactory.java:37, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory 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.
> - SSLServerSocketFactory.java:43, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory 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.
> - SSLServerSocketFactory.java:76, OS_OPEN_STREAM
> OS: 
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
>  may fail to close stream
> The method creates an IO stream object, does not assign it to any fields, 
> pass it to other methods that might close it, or return it, and does not 
> appear to close the stream on all paths out of the method.  This may result 
> in a file descriptor leak.  It is generally a good idea to use a finally 
> block to ensure that streams are closed.
> - SSLServerSocketFactory.java:76, OBL_UNSATISFIED_OBLIGATION
> OBL: 
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
>  may fail to clean up java.io.InputStream
> This method may fail to clean up (close, dispose of) a stream, database 
> object, or other resource requiring an explicit cleanup operation.
> In general, if a method opens a stream or other resource, the method should 
> use a try/finally block to ensure that the stream or resource is cleaned up 
> before the method returns.
> This bug pattern is essentially the same as the OS_OPEN_STREAM and 
> ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and 
> hopefully better) static analysis technique. We are interested is getting 
> feedback about the usefulness of this bug pattern. To send feedback, either:
> send email to findb...@cs.umd.edu
> file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
> In particular, the false-positive suppression heuristics for this bug pattern 
> have not been extensively tuned, so reports about false positives are helpful 
> to us.
> See Weimer and Necula, Finding and Preventing Run-Time Error Handling 
> Mistakes, for a description of the analysis technique.
> - SSLServerSocketFactory.java:111, BC_UNCONFIRMED_CAST_OF_RETURN_VALUE
> BC: Unchecked/unconfirmed cast from java.net.ServerSocket to 
> javax.net.ssl.SSLServerSocket of return value in 
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
> This code performs an unchecked cast of the return value of a method. The 
> code might be calling the method in such a way 

[jira] [Created] (OFBIZ-9714) [FB] Package org.apache.ofbiz.service.rmi.socket.ssl

2017-09-13 Thread Dennis Balkir (JIRA)
Dennis Balkir created OFBIZ-9714:


 Summary: [FB] Package org.apache.ofbiz.service.rmi.socket.ssl
 Key: OFBIZ-9714
 URL: https://issues.apache.org/jira/browse/OFBIZ-9714
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Dennis Balkir
Priority: Minor


- SSLClientSocketFactory.java:37, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory 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.

- SSLServerSocketFactory.java:43, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory 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.

- SSLServerSocketFactory.java:76, OS_OPEN_STREAM
OS: 
org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
 may fail to close stream

The method creates an IO stream object, does not assign it to any fields, pass 
it to other methods that might close it, or return it, and does not appear to 
close the stream on all paths out of the method.  This may result in a file 
descriptor leak.  It is generally a good idea to use a finally block to ensure 
that streams are closed.

- SSLServerSocketFactory.java:76, OBL_UNSATISFIED_OBLIGATION
OBL: 
org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
 may fail to clean up java.io.InputStream

This method may fail to clean up (close, dispose of) a stream, database object, 
or other resource requiring an explicit cleanup operation.

In general, if a method opens a stream or other resource, the method should use 
a try/finally block to ensure that the stream or resource is cleaned up before 
the method returns.

This bug pattern is essentially the same as the OS_OPEN_STREAM and 
ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and 
hopefully better) static analysis technique. We are interested is getting 
feedback about the usefulness of this bug pattern. To send feedback, either:

send email to findb...@cs.umd.edu
file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
In particular, the false-positive suppression heuristics for this bug pattern 
have not been extensively tuned, so reports about false positives are helpful 
to us.

See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, 
for a description of the analysis technique.

- SSLServerSocketFactory.java:111, BC_UNCONFIRMED_CAST_OF_RETURN_VALUE
BC: Unchecked/unconfirmed cast from java.net.ServerSocket to 
javax.net.ssl.SSLServerSocket of return value in 
org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)

This code performs an unchecked cast of the return value of a method. The code 
might be calling the method in such a way that the cast is guaranteed to be 
safe, but FindBugs is unable to verify that the cast is safe. Check that your 
program logic ensures that this cast will not fail.



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


[jira] [Updated] (OFBIZ-9713) [FB] Package org.apache.ofbiz.entity.condition

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9713:
-
Attachment: OFBIZ-9713_org.apache.ofbiz.entity.condition_bugfixes.patch

- Diamond Operators fixed

class EntityClause:
- Line 142: removed {{interFieldOperation.getCode() == null ? "null" :}} since 
the method {{getCode()}} cannot produce null as a result, it can return the 
String „null“ though, which this method would have set, if {{getCode()}} would 
have returned null
- Line 144: removed {{getValue().toString() == null ? "null" :}} because 
{{toString()}} cannot return null

class EntityConditionBase:
- Line 104 & 109: very unusual implementation of {{equals}} and {{hashCode}}; 
maybe this is because, these methods should never have been used, and when they 
are, something must be wrong?

class EntityConditionBuilder:
- removed unnecessary else
- Line 43: it’s not necessary for the class to implement serialVerisonUID
- Line 91: added a default Locale to {{toLowerCase}}
- Line 107: added a default Locale to {{toLowerCase}}

class EntityConditionFunction:
- removed unnecessary else
- Line 40: it’s not necessary for the class to implement serialVerisonUID
- Line 90: changed the {{==}} operator to {{equals()}}

class EntityConditionList:
- Line 31: it’s not necessary for the class to implement serialVerisonUID

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

class EntityConditionSubSelect:
- Line 39: it’s not necessary for the class to implement serialVerisonUID

class EntityConditionValue:
- Line 43: it’s not necessary for the class to implement serialVerisonUID

class EntityDateFilterCondition:
- Line 39, 40: made the parameters private
- Line 42: it’s not necessary for the class to implement serialVerisonUID

class EntityExpr:
- Line 44: it’s not necessary for the class to implement serialVerisonUID
- Line 144: added a default Locale to {{toUpperCase}}
- Line 226 & 252: {{valueType}} treated like {{type}} before, now it cannot be 
null at these points

class EntityFieldMap:
- Line 37: made the parameter private
- Line 40: it’s not necessary for the class to implement serialVerisonUID

class EntityFieldValue:
- Line 42: it’s not necessary for the class to implement serialVerisonUID
- removed unnecessary else

class EntityFunction:
- removed unnecessary else
- Line 68: made the parameter final
- Line 68: it’s not necessary for the class to implement serialVerisonUID
- Line 82 made the parameter final
- Line 82: it’s not necessary for the class to implement serialVerisonUID
- Line 96: made the parameter final
- Line 96: it’s not necessary for the class to implement serialVerisonUID
- Line 97: added a default Locale to {{toUpperCase}}
- Line 110: made the parameter final
- Line 110: it’s not necessary for the class to implement serialVerisonUID
- Line 111: added a default Locale to {{toLowerCase}}
- Line 159 & 161: NACHFRAGEN

class EntityJoinOperator:
- Line 40: it’s not necessary for the class to implement serialVerisonUID

class EntityOperator:
- removed unnecessary else
- Line 64: added a default Locale to {{toLowerCase}}
- Line 65: added a default Locale to {{toUpperCase}}
- Line 303: was intended this way, since no equals method was implemented

class EnitityWhereString:
- Line 45: made the parameter private
- Line 47: it’s not necessary for the class to implement serialVerisonUID

class OrderByItem:
- Line 31: this is not a problem in the Ofbiz-api
- Line 82: added a default Locale to {{toUpperCase()}}
- Line 90: added a default Locale to {{toUpperCase()}}
- Line 121: added a defsult Locale to {{toUpperCase()}}
- Line 200: implemented the method {{hashCode()}} because {{equals()}} was 
implemented

class OrderByList:
- Line 31: this is not a problem in the Ofbiz-api
- Line 107: implemented the method {{hashCode()}} because {{equals()}} was 
implemented

> [FB] Package org.apache.ofbiz.entity.condition
> --
>
> Key: OFBIZ-9713
> URL: https://issues.apache.org/jira/browse/OFBIZ-9713
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: 
> OFBIZ-9713_org.apache.ofbiz.entity.condition_bugfixes.patch
>
>
> - EntityClause.java:142, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of 
> org.apache.ofbiz.entity.condition.EntityOperator.getCode(), which is known to 
> be non-null in org.apache.ofbiz.entity.condition.EntityClause.toString()
> This method contains a redundant check of a known non-null value against the 
> constant null.
> - EntityClause.java:144, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of Object.toString(), which is known to be non-null 
> in 

[jira] [Created] (OFBIZ-9713) [FB] Package org.apache.ofbiz.entity.condition

2017-09-13 Thread Dennis Balkir (JIRA)
Dennis Balkir created OFBIZ-9713:


 Summary: [FB] Package org.apache.ofbiz.entity.condition
 Key: OFBIZ-9713
 URL: https://issues.apache.org/jira/browse/OFBIZ-9713
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Dennis Balkir
Priority: Minor


- EntityClause.java:142, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
RCN: Redundant nullcheck of 
org.apache.ofbiz.entity.condition.EntityOperator.getCode(), which is known to 
be non-null in org.apache.ofbiz.entity.condition.EntityClause.toString()

This method contains a redundant check of a known non-null value against the 
constant null.

- EntityClause.java:144, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
RCN: Redundant nullcheck of Object.toString(), which is known to be non-null in 
org.apache.ofbiz.entity.condition.EntityClause.toString()

This method contains a redundant check of a known non-null value against the 
constant null.

- EntityConditionBase.java:104, EQ_UNUSUAL
Eq: org.apache.ofbiz.entity.condition.EntityConditionBase.equals(Object) is 
unusual

This class doesn't do any of the patterns we recognize for checking that the 
type of the argument is compatible with the type of the this object. There 
might not be anything wrong with this code, but it is worth reviewing.

- EntityConditionBuilder.java:43, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.condition.EntityConditionBuilder$ConditionHolder 
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.

- EntityConditionBuilder.java:90, DM_CONVERT_CASE
Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in 
org.apache.ofbiz.entity.condition.EntityConditionBuilder.createNode(Object)

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.

- EntityConditionBuilder.java:106, DM_CONVERT_CASE
Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in 
org.apache.ofbiz.entity.condition.EntityConditionBuilder.createNode(Object, Map)

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.

- EntityConditionFunction.java:40, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.condition.EntityConditionFunction$NOT 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.

- EntityConditionFunction.java:91, RC_REF_COMPARISON
RC: Suspicious comparison of Integer references in 
org.apache.ofbiz.entity.condition.EntityConditionFunction.equals(Object)

This method compares two reference values using the == or != operator, where 
the correct way to compare instances of this type is generally with the 
equals() method. It is possible to create distinct instances that are equal but 
do not compare as == since they are different objects. Examples of classes 
which should generally not be compared by reference are java.lang.Integer, 
java.lang.Float, etc.

- EntityConditionList.java:31, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.condition.EntityConditionList 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 

[jira] [Updated] (OFBIZ-9712) [FB] Package org.apache.ofbiz.entity.finder

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9712:
-
Attachment: OFBIZ-9712_org.apache.ofbiz.entity.finder_bugfixes.patch

- Diamond Operators fixed

class ByAndFinder:
- Line 37: it’s not necessary for the class to implement serialVerisonUID

class ByConditionFinder:
- Line 39: it’s not necessary for the class to implement serialVerisonUID

class EntityFinderUtil:
- removed unnecessary else
- Line 166: it’s not necessary for the class to implement serialVerisonUID
- Line 212: changed the String {{„|“}} to {{‚|‘}} because it is more efficient
- Line 214: changed the String {{„,“}} to {{‚,‘}} because it is more efficient
- Line 262: it’s not necessary for the class to implement serialVerisonUID
- Line 314: it’s not necessary for the class to implement serialVerisonUID
- Line 337: it’s not necessary for the class to implement serialVerisonUID
- Line 399: it’s not necessary for the class to implement serialVerisonUID
- Line 459: it’s not necessary for the class to implement serialVerisonUID
- Line 473: it’s not necessary for the class to implement serialVerisonUID

class PrimaryKeyFinder:
- Line 47: it’s not necessary for the class to implement serialVerisonUID

> [FB] Package org.apache.ofbiz.entity.finder
> ---
>
> Key: OFBIZ-9712
> URL: https://issues.apache.org/jira/browse/OFBIZ-9712
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-9712_org.apache.ofbiz.entity.finder_bugfixes.patch
>
>
> - ByAndFinder.java:37, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.entity.finder.ByAndFinder 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.
> - ByConditionFinder.java:39, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.entity.finder.ByConditionFinder 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.
> - EntityFinderUtil.java:166, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.entity.finder.EntityFinderUtil$ConditionExpr 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.
> - EntityFinderUtil.java:265, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.entity.finder.EntityFinderUtil$ConditionList 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 

[jira] [Updated] (OFBIZ-9712) [FB] Package org.apache.ofbiz.entity.finder

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9712:
-
Description: 
- ByAndFinder.java:37, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.finder.ByAndFinder 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.

- ByConditionFinder.java:39, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.finder.ByConditionFinder 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.

- EntityFinderUtil.java:166, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.finder.EntityFinderUtil$ConditionExpr 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.

- EntityFinderUtil.java:265, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.finder.EntityFinderUtil$ConditionList 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.

- EntityFinderUtil.java:317, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.finder.EntityFinderUtil$ConditionObject 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.

- EntityFinderUtil.java:340, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.entity.finder.EntityFinderUtil$LimitRange 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 

[jira] [Updated] (OFBIZ-9712) [FB] Package org.apache.ofbiz.entity.finder

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9712:
-
Summary: [FB] Package org.apache.ofbiz.entity.finder  (was: [FB] Package 
org.apache.ofbiz.service.rmi.socket.ssl)

> [FB] Package org.apache.ofbiz.entity.finder
> ---
>
> Key: OFBIZ-9712
> URL: https://issues.apache.org/jira/browse/OFBIZ-9712
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
>
> - SSLClientSocketFactory.java:37, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory 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.
> - SSLServerSocketFactory.java:43, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory 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.
> - SSLServerSocketFactory.java:76, OS_OPEN_STREAM
> OS: 
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
>  may fail to close stream
> The method creates an IO stream object, does not assign it to any fields, 
> pass it to other methods that might close it, or return it, and does not 
> appear to close the stream on all paths out of the method.  This may result 
> in a file descriptor leak.  It is generally a good idea to use a finally 
> block to ensure that streams are closed.
> - SSLServerSocketFactory.java:76, OBL_UNSATISFIED_OBLIGATION
> OBL: 
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
>  may fail to clean up java.io.InputStream
> This method may fail to clean up (close, dispose of) a stream, database 
> object, or other resource requiring an explicit cleanup operation.
> In general, if a method opens a stream or other resource, the method should 
> use a try/finally block to ensure that the stream or resource is cleaned up 
> before the method returns.
> This bug pattern is essentially the same as the OS_OPEN_STREAM and 
> ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and 
> hopefully better) static analysis technique. We are interested is getting 
> feedback about the usefulness of this bug pattern. To send feedback, either:
> send email to findb...@cs.umd.edu
> file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
> In particular, the false-positive suppression heuristics for this bug pattern 
> have not been extensively tuned, so reports about false positives are helpful 
> to us.
> See Weimer and Necula, Finding and Preventing Run-Time Error Handling 
> Mistakes, for a description of the analysis technique.
> - SSLServerSocketFactory.java:111, BC_UNCONFIRMED_CAST_OF_RETURN_VALUE
> BC: Unchecked/unconfirmed cast from java.net.ServerSocket to 
> javax.net.ssl.SSLServerSocket of return value in 
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
> This code performs an unchecked cast of the return value of a method. The 
> code might be calling the method in such a way that the cast is guaranteed to 
> be safe, but FindBugs is unable to verify that the cast is safe. Check that 
> your program logic ensures that this cast will not fail.



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


[jira] [Created] (OFBIZ-9712) [FB] Package org.apache.ofbiz.service.rmi.socket.ssl

2017-09-13 Thread Dennis Balkir (JIRA)
Dennis Balkir created OFBIZ-9712:


 Summary: [FB] Package org.apache.ofbiz.service.rmi.socket.ssl
 Key: OFBIZ-9712
 URL: https://issues.apache.org/jira/browse/OFBIZ-9712
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Dennis Balkir
Priority: Minor


- SSLClientSocketFactory.java:37, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory 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.

- SSLServerSocketFactory.java:43, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory 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.

- SSLServerSocketFactory.java:76, OS_OPEN_STREAM
OS: 
org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
 may fail to close stream

The method creates an IO stream object, does not assign it to any fields, pass 
it to other methods that might close it, or return it, and does not appear to 
close the stream on all paths out of the method.  This may result in a file 
descriptor leak.  It is generally a good idea to use a finally block to ensure 
that streams are closed.

- SSLServerSocketFactory.java:76, OBL_UNSATISFIED_OBLIGATION
OBL: 
org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
 may fail to clean up java.io.InputStream

This method may fail to clean up (close, dispose of) a stream, database object, 
or other resource requiring an explicit cleanup operation.

In general, if a method opens a stream or other resource, the method should use 
a try/finally block to ensure that the stream or resource is cleaned up before 
the method returns.

This bug pattern is essentially the same as the OS_OPEN_STREAM and 
ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and 
hopefully better) static analysis technique. We are interested is getting 
feedback about the usefulness of this bug pattern. To send feedback, either:

send email to findb...@cs.umd.edu
file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
In particular, the false-positive suppression heuristics for this bug pattern 
have not been extensively tuned, so reports about false positives are helpful 
to us.

See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, 
for a description of the analysis technique.

- SSLServerSocketFactory.java:111, BC_UNCONFIRMED_CAST_OF_RETURN_VALUE
BC: Unchecked/unconfirmed cast from java.net.ServerSocket to 
javax.net.ssl.SSLServerSocket of return value in 
org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)

This code performs an unchecked cast of the return value of a method. The code 
might be calling the method in such a way that the cast is guaranteed to be 
safe, but FindBugs is unable to verify that the cast is safe. Check that your 
program logic ensures that this cast will not fail.



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


[jira] [Updated] (OFBIZ-9711) [FB] Package org.apache.ofbiz.entity.cache

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9711:
-
Attachment: OFBIZ-9711_org.apache.ofbiz.entity.cache_bugfixes.patch

- Diamond Operators fixed

- Line 68: removed the unnecessary if, {{model}} cannot be null at this point
- Line 167: not used if phase removed
- Line 181: not used if phrase removed

> [FB] Package org.apache.ofbiz.entity.cache
> --
>
> Key: OFBIZ-9711
> URL: https://issues.apache.org/jira/browse/OFBIZ-9711
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-9711_org.apache.ofbiz.entity.cache_bugfixes.patch
>
>
> - AbstractEntityConditionCache.java:68, 
> RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> RCN: Redundant nullcheck of model, which is known to be non-null in 
> org.apache.ofbiz.entity.cache.AbstractEntityConditionCache.remove(GenericEntity)
> This method contains a redundant check of a known non-null value against the 
> constant null.
> - AbstractEntityConditionCache.java:169, UCF_USELESS_CONTROL_FLOW
> UCF: Useless control flow in 
> org.apache.ofbiz.entity.cache.AbstractEntityConditionCache.storeHook(boolean, 
> GenericEntity, GenericEntity)
> This method contains a useless control flow statement, where control flow 
> continues onto the same place regardless of whether or not the branch is 
> taken. For example, this is caused by having an empty statement block for an 
> if statement:
> if (argv.length == 0) {
> // TODO: handle this case
> }
> - AbstractEntityConditionCache.java:183, UCF_USELESS_CONTROL_FLOW
> UCF: Useless control flow in 
> org.apache.ofbiz.entity.cache.AbstractEntityConditionCache.storeHook(String, 
> boolean, List, List)
> This method contains a useless control flow statement, where control flow 
> continues onto the same place regardless of whether or not the branch is 
> taken. For example, this is caused by having an empty statement block for an 
> if statement:
> if (argv.length == 0) {
> // TODO: handle this case
> }



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


[jira] [Created] (OFBIZ-9711) [FB] Package org.apache.ofbiz.entity.cache

2017-09-13 Thread Dennis Balkir (JIRA)
Dennis Balkir created OFBIZ-9711:


 Summary: [FB] Package org.apache.ofbiz.entity.cache
 Key: OFBIZ-9711
 URL: https://issues.apache.org/jira/browse/OFBIZ-9711
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Dennis Balkir
Priority: Minor


- AbstractEntityConditionCache.java:68, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
RCN: Redundant nullcheck of model, which is known to be non-null in 
org.apache.ofbiz.entity.cache.AbstractEntityConditionCache.remove(GenericEntity)

This method contains a redundant check of a known non-null value against the 
constant null.

- AbstractEntityConditionCache.java:169, UCF_USELESS_CONTROL_FLOW
UCF: Useless control flow in 
org.apache.ofbiz.entity.cache.AbstractEntityConditionCache.storeHook(boolean, 
GenericEntity, GenericEntity)

This method contains a useless control flow statement, where control flow 
continues onto the same place regardless of whether or not the branch is taken. 
For example, this is caused by having an empty statement block for an if 
statement:

if (argv.length == 0) {
// TODO: handle this case
}

- AbstractEntityConditionCache.java:183, UCF_USELESS_CONTROL_FLOW
UCF: Useless control flow in 
org.apache.ofbiz.entity.cache.AbstractEntityConditionCache.storeHook(String, 
boolean, List, List)

This method contains a useless control flow statement, where control flow 
continues onto the same place regardless of whether or not the branch is taken. 
For example, this is caused by having an empty statement block for an if 
statement:

if (argv.length == 0) {
// TODO: handle this case
}



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


[jira] [Updated] (OFBIZ-9710) [FB] Package org.apache.ofbiz.widget.model

2017-09-13 Thread Dennis Balkir (JIRA)

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

Dennis Balkir updated OFBIZ-9710:
-
Attachment: OFBIZ-9710_org.apache.ofbiz.widget.model_bugfixes.patch

- Diamond Operators fixed

class AbstractModelAction:
- Line 83: this is intended this way
- Line 191: this was intended this way
- Line 225: this was intended this way
- Line 259: this was intended this way
- Line 298: it’s not necessary for the class to implement serialVerisonUID
- Line 381: it’s not necessary for the class to implement serialVerisonUID
- Line 445: it’s not necessary for the class to implement serialVerisonUID
- Line 523: it’s not necessary for the class to implement serialVerisonUID
- Line 607: it’s not necessary for the class to implement serialVerisonUID
- Line 657: this was intended this way
- Line 746: it’s not necessary for the class to implement serialVerisonUID

class AbstractModelCondition:
- removed unnecessary else
- Line 118: it’s not necessary for the class to implement serialVerisonUID
- Line 225: it’s not necessary for the class to implement serialVerisonUID
- Line 300: it’s not necessary for the class to implement serialVerisonUID
- Line 376: this was intended this way
- Line 406: this cannot happen in the Ofbiz-api
- Line 409: it’s not necessary for the class to implement serialVerisonUID
- Line 438: it’s not necessary for the class to implement serialVerisonUID
- Line 490: it’s not necessary for the class to implement serialVerisonUID
- Line 550: it’s not necessary for the class to implement serialVerisonUID
- Line 598: removed if phrase, because {{permService}} cannot be null at this 
point
- Line 652: it’s not necessary for the class to implement serialVerisonUID
- Line 732: it’s not necessary for the class to implement serialVerisonUID
- Line 761: it’s not necessary for the class to implement serialVerisonUID
- Line 795: it’s not necessary for the class to implement serialVerisonUID

class CommonWidgetModels:
- Line 104: removed unnecessary if phrase, because {{fieldsIter}} cannot not be 
null at this point
- Line 127: removed {{boolean includeNonPk;}} because it is never used
- Line 127: removed {{boolean includePk;}} because it is never used

class HtmlWidget:
- Line 60: this was intended this way
- Line 63: made the parameter final
- Line 205: this was intended this way
- Line 230: this was intended this way
- Line 285: it’s not necessary for the class to implement serialVerisonUID

class IterateSectionWidget:
- Line 58: it’s not necessary for the class to implement serialVerisonUID
- Line 59: made the parameter final
- Line 60: made the parameter final
- Line 115: changed the name of the parameter from {{viewSize}} to 
{{locViewSize}}, as in local view size, to reduce confusion with the class 
parameter {{viewSize}} and to solve this findbugs error
- Line 155: added a catch for RuntimeException

class ModelForm:
- removed unnecessary else
- Line 86, 87, 88, 89, 90, 91, 92, 93, 94, 96, 97, 98: made the parameter final 
to prevent violation from other classes
- Line 210: changed the method use from {{valueOf()}} to {{parseInt()}} because 
it is more efficient
- Line 607: removed the local variable {{rowCountExdr}} because it is never used
- Line 800: removed the unnecessary null-check, because {{modelEntity}} cannot 
be null at this point, since {{getModelEntity}} cannot produce null as a result
- Line 1448: changed the method use from {{valueOf()}} to {{parseInt()}} 
because it is more efficient
- Line 1472: changed the method use from {{valueOf()}} to {{parseInt()}} 
because it is more efficient
- Line 1536: this was intended this way
- Line 1605: made the field from line 129 protected, because this will cause a 
more efficient use in line 1605
- Line 1623: made the field from line 133 protected, because this will cause a 
more efficient use in line 1623, this solves the problem in line 1624 too
- Line 1628: made the field from line 143 protected, because this will cause a 
more efficient use in line 1628
- Line 1658: added a {{Debug.logInfo}} to at least not completely ignore the 
thrown exception

class ModelFormAction:
- Line 78: it’s not necessary for the class to implement serialVerisonUID
- Line 137: this was intended this way
- Line 141: removed {{= FlexibleStringExpander.getInstance(„“)}} because the 
variable {{resultMapListNameExdr}} gets declared multi times after this before 
it is read

class ModelFormField:
- removed unnecessary else
- Line 975: this is intended this way; when this method is used, the returned 
value is stored in a {{Boolean}} which cannot result in a 
{{NullPointerException}}
- Line 1312: made the field from line 115 protected, because this will cause a 
more efficient use in line 1312
- Line 1320: made the field from line 120 protected, because this will cause a 
more efficient use in line 1320
- Line 1773: made the field from line 129 protected, because this will 

[jira] [Created] (OFBIZ-9710) [FB] Package org.apache.ofbiz.widget.model

2017-09-13 Thread Dennis Balkir (JIRA)
Dennis Balkir created OFBIZ-9710:


 Summary: [FB] Package org.apache.ofbiz.widget.model
 Key: OFBIZ-9710
 URL: https://issues.apache.org/jira/browse/OFBIZ-9710
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Dennis Balkir
Priority: Minor


- AbstractModelAction.java:191, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.widget.model.AbstractModelAction$EntityAnd 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.

- AbstractModelAction.java:225, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.widget.model.AbstractModelAction$EntityCondition 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.

- AbstractModelAction.java:259, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.widget.model.AbstractModelAction$EntityOne 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.

- AbstractModelAction.java:298, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.widget.model.AbstractModelAction$GetRelated 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.

- AbstractModelAction.java:381, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.widget.model.AbstractModelAction$GetRelatedOne 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.

- AbstractModelAction.java:445, SE_NO_SERIALVERSIONID
SnVI: org.apache.ofbiz.widget.model.AbstractModelAction$PropertyMap 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 

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

2017-09-13 Thread Dennis Balkir (JIRA)

 [ 
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 

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

2017-09-13 Thread Dennis Balkir (JIRA)
Dennis Balkir created OFBIZ-9709:


 Summary: [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


- 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