[
https://issues.apache.org/jira/browse/SHINDIG-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598883#action_12598883
]
Kevin Brown commented on SHINDIG-294:
-------------------------------------
The simplest reason is that it's not consistent with the existing code.
The reason it's not used in the existing code is because most of the original
code came from coding styles that the majority of us were previously
comfortable with.
The reason those coding styles don't use it is because it doesn't have a lot of
value. When final parameters were added (Java 1.1 I think?), it was mostly
billed as an optimization opportunity and to make sure that the code didn't
modify the variable. Today javac is sufficiently advanced to not need it.
That leaves it with the "non-modifying" (potentially more correct case). Unlike
const in C++, final doesn't actually prevent you from modifying the input
value, so there's no gain there. All it does is prevent you from doing this:
public void foo(final Bar bar) {
bar.doThing();
bar = new Bar();
bar.doThing();
}
...which seems to be of highly limited utility for the added burden of writing
more code, does it not?
If everyone that's been writing code changes their mind and the majority of
committers decide that using final everywhere is the way to go, we can go ahead
and do that, but I don't think it gets us anything, and not using it is more
consistent with the existing code.
> GadgetFeatureRegistry needs not to be restricted on Sets
> --------------------------------------------------------
>
> Key: SHINDIG-294
> URL: https://issues.apache.org/jira/browse/SHINDIG-294
> Project: Shindig
> Issue Type: Improvement
> Components: Common Components (Java)
> Reporter: Henning Schmiedehausen
> Attachments: collection.patch
>
>
> Actually, Collection is fine and it allows to pass in things like
> Arrays.asList(<stuff>).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
