what the benefit is by using annotation, like "@Immutable" ?
in [Java Help]
|
Prev: Immediate Start: Need Designer's (Visual/Graphic),Beverly Hills,California,
Next: a question about alias of reference
From: Lew on 16 Jul 2010 16:18 On Jul 16, 3:39 pm, Eric Sosman <esos...(a)ieee-dot-org.invalid> wrote: > On 7/16/2010 2:27 PM, Lew wrote: > > > [...] > > > String is the most basic immutable class in the API. > > More basic than Object? > Yes. Object doesn't have attributes, so describing it as "immutable" runs into a triviality exception. There's nothing to change, so there's nothing to be immutable. String actually has attributes for which the question of [im]mutability matters. -- Lew
From: Eric Sosman on 16 Jul 2010 16:27 On 7/16/2010 4:18 PM, Lew wrote: > On Jul 16, 3:39 pm, Eric Sosman<esos...(a)ieee-dot-org.invalid> wrote: >> On 7/16/2010 2:27 PM, Lew wrote: >> >>> [...] >> >>> String is the most basic immutable class in the API. >> >> More basic than Object? > > Yes. Object doesn't have attributes, so describing it as "immutable" > runs into a triviality exception. There's nothing to change, so > there's nothing to be immutable. String actually has attributes for > which the question of [im]mutability matters. Okay; more basic than Integer? (Prediction: Lew's answer will be "Yes," accompanied by a treatise on the philosophic phylogeny of para-abstract psycho-paradigms, which no one will be able to follow -- not even Lew!) -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Lew on 16 Jul 2010 16:43 Lew wrote: >>>> String is the most basic immutable class in the API. > Eric Sosman wrote: >>> More basic than Object? > Lew wrote: > > Yes. Object doesn't have attributes, so describing it as "immutable" > > runs into a triviality exception. There's nothing to change, so > > there's nothing to be immutable. String actually has attributes for > > which the question of [im]mutability matters. > Eric Sosman wrote: > Okay; more basic than Integer? > That depends. > (Prediction: Lew's answer will be "Yes," accompanied by a treatise > on the philosophic phylogeny of para-abstract psycho-paradigms, which > no one will be able to follow -- not even Lew!) > It depends on the ontological semantics of "basic". Beginning Java programmers typically are introduced to the use of 'String' well before 'Integer' so in a pedagogical sense 'String' is the more basic type. Of course, within the para-abstract psycho-paradigm of inherent basicity, no one could argue for 'String' over 'Integer'. -- Lew
From: Jim Janney on 16 Jul 2010 17:01 "John B. Matthews" <nospam(a)nospam.invalid> writes: > In article <2p4ofzz6xu.fsf(a)shell.xmission.com>, > Jim Janney <jjanney(a)shell.xmission.com> wrote: > >> www <www(a)nospam.com> writes: >> >> > I wrote an immutable class. By following the samples of tutorials, I >> > also added "@Immutable" right above the class name. >> > >> > import net.jcip.annotations.Immutable; >> > >> > @Immutable //<--- what is this benefit? Without this line, the code >> > is also ok. Does this line make any difference? >> > public class MyClass >> > { >> > ... //all the code >> > } >> > >> > Thank you very much. >> >> There's no immediate effect on the generated code: it simply asserts, >> in machine-readable form, the programmer's belief that instances of >> the class are immutable. Other Java code may look for this >> annotation and possibly make optimizations based on it. A quick >> Google search suggests that Findbugs, IntelliJ IDEA, and possibly >> AspectJ look for this. I'd call it an interesting idea that hasn't >> really caught on. > > In addition, the API elaborates on this: > > <http://www.javaconcurrencyinpractice.com/annotations/doc/net/jcip/annotations/Immutable.html> > > For reference, the package summary offers additional perspective, and > it mentions static code-analysis specifically: > > <http://www.javaconcurrencyinpractice.com/annotations/doc/net/jcip/annotations/package-summary.html> My guess is that in the general case, any program that tries to decide if a class is immutable will run into Rice's theorem (a.k.a. the halting problem). It might be possible to define a useful subset of immutable classes that are always verifiable, but I don't see that anyone has done that. IntelliJ IDEA apparently requires all fields to be final but that's clearly not right: even String has a non-final field. Without a consistent definition you can get a situation where one tool says a class is immutable and another tool says it isn't. -- Jim Janney
From: Peter Duniho on 16 Jul 2010 17:40
Jim Janney wrote: > My guess is that in the general case, any program that tries to decide > if a class is immutable will run into Rice's theorem (a.k.a. the > halting problem). It might be possible to define a useful subset of > immutable classes that are always verifiable, but I don't see that > anyone has done that. IntelliJ IDEA apparently requires all fields to > be final but that's clearly not right: even String has a non-final > field. > > Without a consistent definition you can get a situation where one tool > says a class is immutable and another tool says it isn't. If you define "immutable" as simply that the instance fields within the class itself don't change after initialization, I think it would be sufficient to identify types that a "definitely immutable". In particular, inspecting the code to determine whether instance fields are modified anywhere other than the constructor or as an initializer would be able to determine that. Classes where fields are assigned only in those locations could be "definitely immutable". Classes where fields are assigned anywhere else would not be. Of course, even less rigorous analysis could be done using only the "@Immutable" annotation. Someone could always make a mistake (or lie!), but it would be more efficient to process. :) In either case, having the ability to identify an individual class as "immutable", one could then very easily follow the chain of dependencies (i.e. types that are referenced by "immutable" types) if one wanted a broader definition of "immutable" to be supported (i.e. the definition used by the "@Immutable" annotation: not only do the fields in the type not change, none of the data reachable via that type changes either). If you want to do a more complete analysis that attempts to differentiate methods that are called only during initialization from those that may be called at other times, especially if you want the analysis to operate in context and take into account the possibility of reflection modifying members of the class, then yes. I'd think that be a much harder, potentially unsolvable problem. But as far as the type of immutability described by the annotating documentation, I would expect static analysis tools to be able to successfully verify that. Pete |