[jira] [Closed] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[ https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9567. -- Resolution: Fixed Fix Version/s: Release Branch 13.07 Release Branch 14.12 Release Branch 15.12 16.11.04 Thanks Dennis, Because of possible errors, I consider this a fix and not an improvement. Your patch is in trunk r1804656 R16.11 r1804657 R15.12, R14.12, R13.07 r1804658 > [FB] Package org.apache.ofbiz.base.metrics > -- > > Key: OFBIZ-9567 > URL: https://issues.apache.org/jira/browse/OFBIZ-9567 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 16.11.04, Release Branch 15.12, Release Branch 14.12, > Release Branch 13.07 > > Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch > > > - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE > ICAST: Integral division result cast to double or float in > org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int, > long) > This code casts the result of an integral division (e.g., int or long > division) operation to double or float. Doing division on integers truncates > the result to the integer value closest to zero. The fact that the result was > cast to double suggests that this precision should have been retained. What > was probably meant was to cast one or both of the operands to double before > performing the division. Here is an example: > int x = 2; > int y = 5; > // Wrong: yields result 0.0 > double value1 = x / y; > // Right: yields result 0.4 > double value2 = x / (double) y; -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[
https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121428#comment-16121428
]
Jacques Le Roux edited comment on OFBIZ-9567 at 8/10/17 10:26 AM:
--
Thanks Dennis,
I see your point. I think we already had a discussion and a consensus on that
because we follow
*[Java|http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#331]*
[Coding
Conventions|https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions].
So I'll not start a new discussion about that and will simply keep the
parentheses.
What makes things blurry to me is that APL's interpretation works like function
composition. So in APL you would have to write it
{{(10 * 2) + 50 * (1 - 0.5)}}.
Else; w/o 1st parentheses, you would get 270 instead of 45. And believe me
after 20 years of such habit it's hard to read it another way, it's also very
logical (function composition) :D
was (Author: jacques.le.roux):
Thanks Dennis,
I see your point. I think we already had a discussion and a consensus on that
because we follow
*[Java|http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#331]*
[Coding
Conventions|https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions].
So I'll not start a new discussion about that and will simply keep the
parentheses.
What makes things blurry to me is that APL's interpretation works like function
composition. So in APL you would have to write it
{{(10 * 2) + 50 * (1 - 0.5)}}.
Else; w/o 1st parentheses, you would get 270. And believe me after 20 years of
such habit it's hard to read it another way, it's also very logical (function
composition) :D
> [FB] Package org.apache.ofbiz.base.metrics
> --
>
> Key: OFBIZ-9567
> URL: https://issues.apache.org/jira/browse/OFBIZ-9567
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch
>
>
> - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE
> ICAST: Integral division result cast to double or float in
> org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int,
> long)
> This code casts the result of an integral division (e.g., int or long
> division) operation to double or float. Doing division on integers truncates
> the result to the integer value closest to zero. The fact that the result was
> cast to double suggests that this precision should have been retained. What
> was probably meant was to cast one or both of the operands to double before
> performing the division. Here is an example:
> int x = 2;
> int y = 5;
> // Wrong: yields result 0.0
> double value1 = x / y;
> // Right: yields result 0.4
> double value2 = x / (double) y;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[
https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121428#comment-16121428
]
Jacques Le Roux commented on OFBIZ-9567:
Thanks Dennis,
I see your point. I think we already had a discussion and a consensus on that
because we follow
*[Java|http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#331]*
[Coding
Conventions|https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions].
So I'll not start a new discussion about that and will simply keep the
parentheses.
What makes things blurry to me is that APL's interpretation works like function
composition. So in APL you would have to write it
{{(10 * 2) + 50 * (1 - 0.5)}}.
Else; w/o 1st parentheses, you would get 270. And believe me after 20 years of
such habit it's hard to read it another way, it's also very logical (function
composition) :D
> [FB] Package org.apache.ofbiz.base.metrics
> --
>
> Key: OFBIZ-9567
> URL: https://issues.apache.org/jira/browse/OFBIZ-9567
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch
>
>
> - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE
> ICAST: Integral division result cast to double or float in
> org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int,
> long)
> This code casts the result of an integral division (e.g., int or long
> division) operation to double or float. Doing division on integers truncates
> the result to the integer value closest to zero. The fact that the result was
> cast to double suggests that this precision should have been retained. What
> was probably meant was to cast one or both of the operands to double before
> performing the division. Here is an example:
> int x = 2;
> int y = 5;
> // Wrong: yields result 0.0
> double value1 = x / y;
> // Right: yields result 0.4
> double value2 = x / (double) y;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OFBIZ-9568) The deleteProductionRunRoutingTask service is used but not implemented
Jacques Le Roux created OFBIZ-9568:
--
Summary: The deleteProductionRunRoutingTask service is used but
not implemented
Key: OFBIZ-9568
URL: https://issues.apache.org/jira/browse/OFBIZ-9568
Project: OFBiz
Issue Type: Bug
Components: manufacturing
Affects Versions: Release Branch 16.11, Release Branch 15.12, Trunk,
Release Branch 14.12, Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
There is an old TODO from pre Apache era above its definition in
services_production_run.xml
bq. TODO: NOT STILL IMPLEMENTED ('deleteWorkEffort' is called directly)
Indeed deleteWorkEffort is called in controller (deleteProductionRunRoutingTask
request-map)
But since we anyway want to remove the deleteWorkEffort service I think we can
remove the deleteProductionRunRoutingTask. I though wonder if we should not
comment related code out rather than simply removing
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[ https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121361#comment-16121361 ] Dennis Balkir commented on OFBIZ-9567: -- Hi Jacques, I removed the parenthesis because I learned at Uni that they're logically not necessary. You can of course reimplement them, if you find it easier to read, I didn't want to change your style of programming, that's just the way I learned it and the way I'm doing it everytime :D > [FB] Package org.apache.ofbiz.base.metrics > -- > > Key: OFBIZ-9567 > URL: https://issues.apache.org/jira/browse/OFBIZ-9567 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch > > > - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE > ICAST: Integral division result cast to double or float in > org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int, > long) > This code casts the result of an integral division (e.g., int or long > division) operation to double or float. Doing division on integers truncates > the result to the integer value closest to zero. The fact that the result was > cast to double suggests that this precision should have been retained. What > was probably meant was to cast one or both of the operands to double before > performing the division. Here is an example: > int x = 2; > int y = 5; > // Wrong: yields result 0.0 > double value1 = x / y; > // Right: yields result 0.4 > double value2 = x / (double) y; -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[
https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121311#comment-16121311
]
Jacques Le Roux commented on OFBIZ-9567:
Hi Dennis,
Why did you decide to remove parenthesis in {{serviceRate = (rate * smoothing)
+ (serviceRate * (1.0 - smoothing));}} ?
I find it easier to read like that. Disclaimer, I have been mostly using the
[APL language|https://en.wikipedia.org/wiki/APL_(programming_language)] during
my 1st 20 years of preogramming. In APL there is no notion of precedence, all
expressions are evaluated from right to left (somehow like in Polish notation).
So I have always find uneasy to read complicated algebric expressions in other
languages ;)
> [FB] Package org.apache.ofbiz.base.metrics
> --
>
> Key: OFBIZ-9567
> URL: https://issues.apache.org/jira/browse/OFBIZ-9567
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch
>
>
> - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE
> ICAST: Integral division result cast to double or float in
> org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int,
> long)
> This code casts the result of an integral division (e.g., int or long
> division) operation to double or float. Doing division on integers truncates
> the result to the integer value closest to zero. The fact that the result was
> cast to double suggests that this precision should have been retained. What
> was probably meant was to cast one or both of the operands to double before
> performing the division. Here is an example:
> int x = 2;
> int y = 5;
> // Wrong: yields result 0.0
> double value1 = x / y;
> // Right: yields result 0.4
> double value2 = x / (double) y;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[ https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9567: -- Assignee: Jacques Le Roux > [FB] Package org.apache.ofbiz.base.metrics > -- > > Key: OFBIZ-9567 > URL: https://issues.apache.org/jira/browse/OFBIZ-9567 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch > > > - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE > ICAST: Integral division result cast to double or float in > org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int, > long) > This code casts the result of an integral division (e.g., int or long > division) operation to double or float. Doing division on integers truncates > the result to the integer value closest to zero. The fact that the result was > cast to double suggests that this precision should have been retained. What > was probably meant was to cast one or both of the operands to double before > performing the division. Here is an example: > int x = 2; > int y = 5; > // Wrong: yields result 0.0 > double value1 = x / y; > // Right: yields result 0.4 > double value2 = x / (double) y; -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[ https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121221#comment-16121221 ] Jacques Le Roux commented on OFBIZ-9567: Ouch, this is the kind of stuff that you easily not see when reviewing, thanks FB :) > [FB] Package org.apache.ofbiz.base.metrics > -- > > Key: OFBIZ-9567 > URL: https://issues.apache.org/jira/browse/OFBIZ-9567 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch > > > - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE > ICAST: Integral division result cast to double or float in > org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int, > long) > This code casts the result of an integral division (e.g., int or long > division) operation to double or float. Doing division on integers truncates > the result to the integer value closest to zero. The fact that the result was > cast to double suggests that this precision should have been retained. What > was probably meant was to cast one or both of the operands to double before > performing the division. Here is an example: > int x = 2; > int y = 5; > // Wrong: yields result 0.0 > double value1 = x / y; > // Right: yields result 0.4 > double value2 = x / (double) y; -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
[
https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-9567:
-
Attachment: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch
- changed a division with two {{long}} variables whose result was casted into a
{{double}}; now it performs a proper {{double}} division
> [FB] Package org.apache.ofbiz.base.metrics
> --
>
> Key: OFBIZ-9567
> URL: https://issues.apache.org/jira/browse/OFBIZ-9567
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch
>
>
> - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE
> ICAST: Integral division result cast to double or float in
> org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int,
> long)
> This code casts the result of an integral division (e.g., int or long
> division) operation to double or float. Doing division on integers truncates
> the result to the integer value closest to zero. The fact that the result was
> cast to double suggests that this precision should have been retained. What
> was probably meant was to cast one or both of the operands to double before
> performing the division. Here is an example:
> int x = 2;
> int y = 5;
> // Wrong: yields result 0.0
> double value1 = x / y;
> // Right: yields result 0.4
> double value2 = x / (double) y;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121214#comment-16121214
]
Jacques Le Roux commented on OFBIZ-9566:
Tobias, we crossed on wire. I think it's good to be said in Jira, but I did not
put in the comment since finally no action.
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Release
>
> Attachments: OFBIZ-9566.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
>
[jira] [Closed] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-9566.
--
Resolution: Implemented
Fix Version/s: Upcoming Release
Hi Tobias,
Your patch is in trunk at revision: 1804639.
Please consider giving more information about the proceeded changes when
possible (cf commit comment), thanks :)
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Release
>
> Attachments: OFBIZ-9566.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> }
[jira] [Created] (OFBIZ-9567) [FB] Package org.apache.ofbiz.base.metrics
Dennis Balkir created OFBIZ-9567: Summary: [FB] Package org.apache.ofbiz.base.metrics Key: OFBIZ-9567 URL: https://issues.apache.org/jira/browse/OFBIZ-9567 Project: OFBiz Issue Type: Sub-task Components: base Affects Versions: Trunk Reporter: Dennis Balkir Priority: Minor - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE ICAST: Integral division result cast to double or float in org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int, long) This code casts the result of an integral division (e.g., int or long division) operation to double or float. Doing division on integers truncates the result to the integer value closest to zero. The fact that the result was cast to double suggests that this precision should have been retained. What was probably meant was to cast one or both of the operands to double before performing the division. Here is an example: int x = 2; int y = 5; // Wrong: yields result 0.0 double value1 = x / y; // Right: yields result 0.4 double value2 = x / (double) y; -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121206#comment-16121206
]
Tobias Laufkötter commented on OFBIZ-9566:
--
{quote}please read http://markmail.org/message/x7r34bss3fwy2bn3
(backward){quote}
That's why I chose to ignore the FindBugs warning. Would it be better to just
leave it out of the report?
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-9566.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
>
[jira] [Commented] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121200#comment-16121200
]
Jacques Le Roux commented on OFBIZ-9566:
Tobias,
About
bq. I chose to catch the explicitly thrown exceptions for
ResourceLoader.java:159, REC_CATCH_EXCEPTION, because I share FindBug's
opinion. I would still like to have some input on this, in case it really was
intentional and needs to be this way.
I agree with FindBug's and your opinion. I guess most of the time it's only
lazyness or haste. It's much easier now with multi exceptions catch so should
not be an excuse.
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Priority: Minor
> Attachments: OFBIZ-9566.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are
[jira] [Assigned] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-9566:
--
Assignee: Jacques Le Roux
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-9566.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> UrlLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.UrlLoader is Serializable; consider
[jira] [Updated] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Laufkötter updated OFBIZ-9566:
-
Attachment: OFBIZ-9566.patch
Fixed the issue number in patch name.
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Priority: Minor
> Attachments: OFBIZ-9566.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> UrlLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.UrlLoader is Serializable; consider
[jira] [Commented] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121194#comment-16121194
]
Jacques Le Roux commented on OFBIZ-9566:
Hi Tobias,
About
bq. consider declaring a serialVersionUID
please read http://markmail.org/message/x7r34bss3fwy2bn3 (backward)
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Priority: Minor
> Attachments: OFBIZ-9450.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> UrlLoader.java:30,
[jira] [Updated] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Laufkötter updated OFBIZ-9566:
-
Attachment: (was: OFBIZ-9450.patch)
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Priority: Minor
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> UrlLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.UrlLoader is Serializable; consider
> declaring a serialVersionUID
> This class implements the
[jira] [Updated] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
[
https://issues.apache.org/jira/browse/OFBIZ-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Laufkötter updated OFBIZ-9566:
-
Attachment: OFBIZ-9450.patch
* {{serialVersionUID}} was ignored.
* The {{protected}} fields were set to {{private}} since the {{class}} is not
extended anywhere. If they need to be accessed in the future, getter that
return an unmodifiable version should be implemented
({{Collections.unmodifiableXXX}}).
* I chose to catch the explicitly thrown exceptions for
{{ResourceLoader.java:159, REC_CATCH_EXCEPTION}}, because I share FindBug's
opinion. I would still like to have some input on this, in case it really was
intentional and needs to be this way.
> [FB] Package org.apache.ofbiz.base.config
> -
>
> Key: OFBIZ-9566
> URL: https://issues.apache.org/jira/browse/OFBIZ-9566
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Tobias Laufkötter
>Priority: Minor
> Attachments: OFBIZ-9450.patch
>
>
> FileLoader.java:30, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.FileLoader 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.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.location
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
> CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
> declares protected field
> org.apache.ofbiz.base.config.MainResourceHandler.loaderName
> This class is declared to be final, but declares fields to be protected.
> Since the class is final, it can not be derived from, and the use of
> protected is confusing. The access modifier for the field should be changed
> to private or public to represent the true use for the field.
> MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
> SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
> ResourceLoader.java:159, REC_CATCH_EXCEPTION,
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
[jira] [Created] (OFBIZ-9566) [FB] Package org.apache.ofbiz.base.config
Tobias Laufkötter created OFBIZ-9566:
Summary: [FB] Package org.apache.ofbiz.base.config
Key: OFBIZ-9566
URL: https://issues.apache.org/jira/browse/OFBIZ-9566
Project: OFBiz
Issue Type: Sub-task
Components: base
Affects Versions: Trunk
Reporter: Tobias Laufkötter
Priority: Minor
FileLoader.java:30, SE_NO_SERIALVERSIONID,
SnVI: org.apache.ofbiz.base.config.FileLoader 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.
MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
declares protected field
org.apache.ofbiz.base.config.MainResourceHandler.xmlFilename
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
declares protected field
org.apache.ofbiz.base.config.MainResourceHandler.location
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
MainResourceHandler.java:-1, CI_CONFUSED_INHERITANCE,
CI: Class org.apache.ofbiz.base.config.MainResourceHandler is final but
declares protected field
org.apache.ofbiz.base.config.MainResourceHandler.loaderName
This class is declared to be final, but declares fields to be protected. Since
the class is final, it can not be derived from, and the use of protected is
confusing. The access modifier for the field should be changed to private or
public to represent the true use for the field.
MainResourceHandler.java:37, SE_NO_SERIALVERSIONID,
SnVI: org.apache.ofbiz.base.config.MainResourceHandler 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.
ResourceLoader.java:159, REC_CATCH_EXCEPTION,
REC: Exception is caught when Exception is not thrown in
org.apache.ofbiz.base.config.ResourceLoader.makeLoader(Element)
This method uses a try-catch block that catches Exception objects, but
Exception is not thrown within the try block, and RuntimeException is not
explicitly caught. It is a common bug pattern to say try { ... } catch
(Exception e) { something } as a shorthand for catching a number of types of
exception each of whose catch blocks is identical, but this construct also
accidentally catches RuntimeException as well, masking potential bugs.
A better approach is to either explicitly catch the specific exceptions that
are thrown, or to explicitly catch RuntimeException exception, rethrow it, and
then catch all non-Runtime Exceptions, as shown below:
try {
...
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
... deal with all non-runtime exceptions ...
}
UrlLoader.java:30, SE_NO_SERIALVERSIONID,
SnVI: org.apache.ofbiz.base.config.UrlLoader 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).
[jira] [Closed] (OFBIZ-9563) [FB] Package org.apache.ofbiz.base.container
[ https://issues.apache.org/jira/browse/OFBIZ-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9563. -- Resolution: Implemented Fix Version/s: Upcoming Release Thanks Dennis, Your patch is in trunk at revision: 1804636 > [FB] Package org.apache.ofbiz.base.container > > > Key: OFBIZ-9563 > URL: https://issues.apache.org/jira/browse/OFBIZ-9563 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-No_org.apache.ofbiz.base.container_bugfixes.patch > > > - ComponentContainer.java:140, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > RCN: Redundant nullcheck of componentLoadFile, which is known to be non-null > in > org.apache.ofbiz.base.container.ComponentContainer.loadComponentDirectory(String) > This method contains a redundant check of a known non-null value against the > constant null. > - ComponentContainer.java:165, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > RCN: Redundant nullcheck of componentsToLoad, which is known to be non-null > in > org.apache.ofbiz.base.container.ComponentContainer.loadComponentsInDirectoryUsingLoadFile(File, > File) > This method contains a redundant check of a known non-null value against the > constant null. > - ComponentContainer.java:187, NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE > NP: Possible null pointer dereference in > org.apache.ofbiz.base.container.ComponentContainer.loadComponentsInDirectory(File) > due to return value of called method > The return value from a method is dereferenced without a null check, and the > return value of that method is one that should generally be checked for null. > This may lead to a NullPointerException when the code is executed. > - ContainerConfig.java:102, DLS_DEAD_LOCAL_STORE > DLS: Dead store to num in > org.apache.ofbiz.base.container.ContainerConfig.getPropertyValue(ContainerConfig$Configuration, > String, int) > This instruction assigns a value to a local variable, but the value is not > read or used in any subsequent instruction. Often, this indicates an error, > because the value computed is never used. > Note that Sun's javac compiler often generates dead stores for final local > variables. Because FindBugs is a bytecode-based tool, there is no easy way to > eliminate these false positives. > - ContainerConfig.java:135, DLS_DEAD_LOCAL_STORE > DLS: Dead store to num in > org.apache.ofbiz.base.container.ContainerConfig.getPropertyValue(ContainerConfig$Configuration$Property, > String, int) > This instruction assigns a value to a local variable, but the value is not > read or used in any subsequent instruction. Often, this indicates an error, > because the value computed is never used. > Note that Sun's javac compiler often generates dead stores for final local > variables. Because FindBugs is a bytecode-based tool, there is no easy way to > eliminate these false positives. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9563) [FB] Package org.apache.ofbiz.base.container
[ https://issues.apache.org/jira/browse/OFBIZ-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9563: -- Assignee: Jacques Le Roux > [FB] Package org.apache.ofbiz.base.container > > > Key: OFBIZ-9563 > URL: https://issues.apache.org/jira/browse/OFBIZ-9563 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-No_org.apache.ofbiz.base.container_bugfixes.patch > > > - ComponentContainer.java:140, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > RCN: Redundant nullcheck of componentLoadFile, which is known to be non-null > in > org.apache.ofbiz.base.container.ComponentContainer.loadComponentDirectory(String) > This method contains a redundant check of a known non-null value against the > constant null. > - ComponentContainer.java:165, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE > RCN: Redundant nullcheck of componentsToLoad, which is known to be non-null > in > org.apache.ofbiz.base.container.ComponentContainer.loadComponentsInDirectoryUsingLoadFile(File, > File) > This method contains a redundant check of a known non-null value against the > constant null. > - ComponentContainer.java:187, NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE > NP: Possible null pointer dereference in > org.apache.ofbiz.base.container.ComponentContainer.loadComponentsInDirectory(File) > due to return value of called method > The return value from a method is dereferenced without a null check, and the > return value of that method is one that should generally be checked for null. > This may lead to a NullPointerException when the code is executed. > - ContainerConfig.java:102, DLS_DEAD_LOCAL_STORE > DLS: Dead store to num in > org.apache.ofbiz.base.container.ContainerConfig.getPropertyValue(ContainerConfig$Configuration, > String, int) > This instruction assigns a value to a local variable, but the value is not > read or used in any subsequent instruction. Often, this indicates an error, > because the value computed is never used. > Note that Sun's javac compiler often generates dead stores for final local > variables. Because FindBugs is a bytecode-based tool, there is no easy way to > eliminate these false positives. > - ContainerConfig.java:135, DLS_DEAD_LOCAL_STORE > DLS: Dead store to num in > org.apache.ofbiz.base.container.ContainerConfig.getPropertyValue(ContainerConfig$Configuration$Property, > String, int) > This instruction assigns a value to a local variable, but the value is not > read or used in any subsequent instruction. Often, this indicates an error, > because the value computed is never used. > Note that Sun's javac compiler often generates dead stores for final local > variables. Because FindBugs is a bytecode-based tool, there is no easy way to > eliminate these false positives. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OFBIZ-9562) [FB] Package org.apache.ofbiz.base.concurrent
[
https://issues.apache.org/jira/browse/OFBIZ-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-9562.
--
Resolution: Implemented
Fix Version/s: Upcoming Release
Thanks Dennis,
Your patch is in trunk at revision: 1804634
> [FB] Package org.apache.ofbiz.base.concurrent
> -
>
> Key: OFBIZ-9562
> URL: https://issues.apache.org/jira/browse/OFBIZ-9562
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Release
>
> Attachments: OFBIZ-No_org.apache.ofbiz.base.concurrent_bugfixes.patch
>
>
> ExecutionPool.java:122, EQ_COMPARETO_USE_OBJECT_EQUALS
> Eq: org.apache.ofbiz.base.concurrent.ExecutionPool$Pulse defines
> compareTo(Object) and uses Object.equals()
> This class defines a compareTo(...) method but inherits its equals() method
> from java.lang.Object. Generally, the value of compareTo should return zero
> if and only if equals returns true. If this is violated, weird and
> unpredictable failures will occur in classes such as PriorityQueue. In Java 5
> the PriorityQueue.remove method uses the compareTo method, while in Java 6 it
> uses the equals method.
> From the JavaDoc for the compareTo method in the Comparable interface:
> It is strongly recommended, but not strictly required that
> {{(a.compareTo(b)==0) == (a.equals(b))}}. Generally speaking, any class that
> implements the Comparable interface and violates this condition should
> clearly indicate this fact. The recommended language is "Note: this class has
> a natural ordering that is inconsistent with equals."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9562) [FB] Package org.apache.ofbiz.base.concurrent
[
https://issues.apache.org/jira/browse/OFBIZ-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-9562:
--
Assignee: Jacques Le Roux
> [FB] Package org.apache.ofbiz.base.concurrent
> -
>
> Key: OFBIZ-9562
> URL: https://issues.apache.org/jira/browse/OFBIZ-9562
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-No_org.apache.ofbiz.base.concurrent_bugfixes.patch
>
>
> ExecutionPool.java:122, EQ_COMPARETO_USE_OBJECT_EQUALS
> Eq: org.apache.ofbiz.base.concurrent.ExecutionPool$Pulse defines
> compareTo(Object) and uses Object.equals()
> This class defines a compareTo(...) method but inherits its equals() method
> from java.lang.Object. Generally, the value of compareTo should return zero
> if and only if equals returns true. If this is violated, weird and
> unpredictable failures will occur in classes such as PriorityQueue. In Java 5
> the PriorityQueue.remove method uses the compareTo method, while in Java 6 it
> uses the equals method.
> From the JavaDoc for the compareTo method in the Comparable interface:
> It is strongly recommended, but not strictly required that
> {{(a.compareTo(b)==0) == (a.equals(b))}}. Generally speaking, any class that
> implements the Comparable interface and violates this condition should
> clearly indicate this fact. The recommended language is "Note: this class has
> a natural ordering that is inconsistent with equals."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
