[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] [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] [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,
