What possible use? Isn't it obvious?
Static analysis tools can look at @Immutable and make assumptions
about it. Yes, immutability is complicated but there are certain
analyses you can perform. For example, if someone is making a
defensive copy of an immutable, a warning should appear. Scanning for
@Immutable makes for more sense that scanning the javadoc for some
keyword.
Possibly a simplish solution is to have @Unchanging and
@SideEffectFree (obviously with better names than that), which are
both method-level (though you can annotate a class too, which means it
applies to all methods in it). @Unchanging means that once created and
initialized, calling the method with the same parameters always
results in the same answer. @SEF means that calling the method doesn't
change anything, it merely calculates something. There are certain
checks one can do to double-check that methods really are @Unchanging
or @SEF, and knowing that a method call is to an @Unchanging or @SEF
method gives you more debugging options:
- Calling a @SEF method without using the return type is a no-op, and
should thus generate a warning.
- @Unchanging methods can be cached (memoized) at the JVM level.
There's potential for some serious performance benefits (as in,
changing an O(n^2) algorithm to an O(n) one!) if the JVM can arranging
caching of intermediate results for you according to the platform's
available memory.
- @Unchanging also simplifies reasoning for static tools
considerably; a call to "foo".toLowerCase() can be treated as the same
final variable. That means that if you write something like:
if (foo.bar() == null) {
foo.bar().baz();
}
with bar()'s method marked as @Unchanging, you get a severe warning
that this code will necessarily NPE if the 'if' clause is true. You
already get this in i.e. eclipse if you just use 'foo', but it won't
work with 'foo.bar()' because eclipse doesn't know that the result of
bar() is always the same.
The definitions are also not disputed.
On Oct 12, 7:56 am, Miroslav Pokorny <[email protected]>
wrote:
> If it (@immutable) is intended for just a human consumption then put it in
> the javadoc. What possible value is there in creating an non functional
> annotation. At least @deprecated has a purpose one gets a warning, whats the
> point of immutable if nothing changes if its there or not there. If anything
> its a bad thing because now instead of people writing up some nice
> reasonable javadoc explaining the class etc, we are just going to get an
> @immutable with no doco. This seems just another excuse so developer types
> can type even less and still claim that the fact is clear and in the source
> - when its not...
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
