Well, my argument was exactly the opposite: There is *NO* clear
understanding of what Immutable is supposed to mean. Sure, we can all
agree that this:
@Data public class Point {
private final int x, y;
}
is clearly and undeniably immutable (and all its methods are SEF and
Unchanging, too), but the borderline where things are grey and some
deem a class immutable while others don't is rather large:
java.io.File, that tricky weak hashmap situation, read-only wrappers
around collections, the general issues with java.util not actually
supporting immutability at all (at least not on the type level),
scaling old code (what if I hold a reference to an object of a type
that is immutable, but because its old isn't marked as such?), and
many more.
I'm not trying to argue against the idea of @Immutable in general; on
the contrary, I'd like java to have such a device. I'm trying to argue
that including it in JDK7 is extremely premature. These things need to
be sorted out. I'm also trying to argue that @SEF and @Unchanging,
being far better defined, might be more useful. After all, if
@Immutable is not compiler-enforced, then we must assume mistakes are
made that are not going to be tested appropriately, and this in turn
means that tooling that makes use of @Immutable annotations is going
to have to deal with the fact that developers have different ideas of
what @Immutable even means. That sounds like it would significantly
weaken the utility of the diagnostics provided by such checker tools.
On Oct 13, 10:30 am, Graham Allan <[email protected]> wrote:
> Hey,
>
> I'd say this kind of pattern falls in that last 5% of cases where
> static analysis tool authors are justified in saying "Well, yeah,
> instances of that class are technically immutable, but meh, you're
> doing weird stuff". That may not be a good enough view to take for a
> compiler, but I think it's fair and useful for "ACME Static Tool". The
> most common cases (e.g. accidentally adding a setter method) are where
> most of the benefits lie. Also, in this domain, a false positive is a
> much better prospect than a false negative.
>
> IMO there's enough of an understanding of what's intended with
> @Immutable, that we should just agree to use one annotation, and let
> the tools and knowledge revolve around it. But yeah, I can see how
> that would be really messy :-)
>
> Regards,
> Graham
>
> On Oct 12, 5:25 pm, Reinier Zwitserloot <[email protected]> wrote:
>
>
>
>
>
>
>
> > Perhaps now is a good time to show off this little snippet just to
> > highlight how nigh-impossible it is to track immutability:
>
> > public class SeeminglyImmutablePointer {
> > private static final Map<SeeminglyImmutablePointer, Object> map =
> > new MapMaker().weakKeys().makeMap();
>
> > public void set(Object val) {
> > map.put(this, val);
> > }
> > public Object get() {
> > return map.get(this);
> > }
>
> > }
>
> > Note that @SEF and @Unchanging have no problem with this snippet; a
> > compiler can clearly determine that set is not SEF, and that get() is,
> > and it can also determine that set() is unchanging (trivially - any
> > method with return type void will have that property), and that get
> > isn't.
--
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.
