Hi Babak
Nice you got attention on these details as well.
After the 2.9.0 release we could take a look what makes sense.
For example changing/adding serial version UUID would break backwards comp.
So IMHO only to be done on the 2.10 release. etc
On Tue, Dec 13, 2011 at 3:48 PM, bvahdat <babak.vah...@swissonline.ch> wrote:
> Hi again,
>
> I already messed it up with the provided links in the botom of my previous
> post, so here a second try:
>
>
> Hi Devs,
>
> As Claus has already once stated [1] thanks to my own professionalism I
> intend to take over the trunk code-clean-up activity :-)
>
> This task (at least to the main extend) can be of course achieved in an
> (almost) automated manner (*even* eclipse can do that!), which is through
> the "Clean Up..." pop-up-menu. But before digging into it I want to get your
> "taste" about what YOU expect to be in there and what not, so here my
> proposal:
>
> 1- Add of the missing Annotations for @Deprecated & @Override:
> As per Java Tiger, other than Javadoc @deprecated tag there's also the
> annotation @Deprecated, good to be used because of the reasons mentioned in
> [2].Also as per Java-Mustang, the semantics of the @Override annotation has
> been extended to not only mean "implements" but also "overrides", so that
> new Processor(){
> public void process(Exchange exchange) {
> ...
> }
> }
>
> becomes:
> new Processor(){
> @Override
> public void process(Exchange exchange) {
> ...
> }
> }
>
> or:
> return new RouteBuilder() {
> public void configure() {
> ...
> }
> };
>
> becomes:
> return new RouteBuilder() {
> @Override
> public void configure() {
> ...
> }
> };
>
> Do you think this is an overkill?
>
> 2- Add of serialVersionUID with default to 1L by all those classes which
> claim to be Serializable (like CamelAuthorizationException which has not
> serialVersionUID), as per spec. letting the JVM to calculate the value at
> runtime is not the best practice (for good reasons). Also by all other camel
> serializable classes which already have that serialVersionUID change the
> value to 1L. Any API/Field/Method serialization-breaking-change a Commiter
> does on those classes should also include a count-up of that field (1L -> 2L
> or 7L->8L).
>
> Example:
>
> from:
> public class CamelAuthorizationException extends CamelExchangeException {
> private final String policyId;
> ...
>
> to:
> public class CamelAuthorizationException extends CamelExchangeException {
> private static final long serialVersionUID = 1L;
> private final String policyId;
> ...
>
> 3- Remove unused imports: I think all of us already agree on this.
>
> 4- Remove unnecessary casts
> from:
> List<MBeanServer> servers =
> (List<MBeanServer>)MBeanServerFactory.findMBeanServer(null);
>
> to:
> List<MBeanServer> servers = MBeanServerFactory.findMBeanServer(null);
>
> Even here, I assume we all do agree on this.
>
> 5- Remove trailing whitespace on *all* lines, even on the empty ones! Would
> we maybe want to also extend the checkstyle rules to bawl on that as well?
>
> 6- Remove of all unused *private* members: Types, Constructors, Fields and
> Methods! We maybe want to be careful about this when the Reflection-API
> usage in Camel comes into the play.
>
> 7- Remove unnecessary $NON-NLS$ tags: just hit 2 of them in [3] & [4] see
> also [5] for it's semantics in eclipse
>
> Applying the clean-up rules I mentioned above on my workspace, I see
> currently around 343 out-going-source-changes.
>
> I would of course run a full install including all unit-test-run &
> checkstyle-checks to garantie no side effect. BTW, my intention is *not* to
> force this into the 2.9.0 final release as this would be already too late
> for that sun-shine-release.
>
> Another *important* clean-up activity would be of course the generics-stuff
> which is completely another story I may also get some time to take care of
> that in the future (for example look at the ProcessorDefinition class).
> However there I don't see any automatable approach which I could apply :-(
> So maybe I have to dig into [6] again to get an idea about all those already
> well-known generics magics ;-))
>
> [1]
> http://camel.465427.n5.nabble.com/HEADS-UP-Adjustments-to-ExecutorServiceManager-on-trunk-tp4693698p4715407.html
> [2]
> http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html
> [3]
> https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/main/java/org/apache/camel/impl/osgi/tracker/AbstractTracked.java
> [4]
> https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/main/java/org/apache/camel/impl/osgi/tracker/BundleTracker.java
> [5]
> http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html
> [6] http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
>
> Babak
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-Trunk-Code-Cleanup-tp5071594p5071664.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
