Asking that the static variables be "final" actually means that they should
be immutable. E.g.
static final int ONE = 1;
declares a constant. The compiler will even optimize that away in most cases.
However a set is per-se not immutable. By declaring it final, you prevent
a new set from being assigned to your static variable, but you do not prevent
the set from being changed. If you really do not want to change the set, you
could do this:
static final Set<String> myset;
static {
Set<String> set = new HashSet<String>();
set.add(…);
set.add(…);
set.add(…);
myset = Collections.unmodifiableSet(set);
}
Non-modifying actions like iterating over the set or checking if the set
contains
a particular string, etc. should be thread-safe.
Cheers,
-- Richard
Am 30.08.2013 um 19:03 schrieb Glenn Gobbel <[email protected]>:
> Does anyone know what the problem might be with using instances of
> classes that contain static final variables? Why should I limit it to
> primitive data types? The "UIMA Tutorials and User Guides" for version
> 2.4.0 lists common pitfalls on page 39 and one involves the use of
> static variables.
>
> "In general, you should not use static variables other than static final
> constants of primitive data types (String, int, float, etc). Other types
> of static variables may allow one annotator instance to set a value that
> affects another annotator instance, which can lead to unexpected
> effects. Also, static references to classes that aren't thread-safe are
> likely to cause errors in multithreaded applications."
>
> I'd like to use a HashSet<String> static variable field. If I set it to
> final, I would think it would be okay to use in multi-threaded
> applications - even though the HashSet class itself is not thread safe.
>
> Am I correct, or am I missing something?
>
> Thanks for any feedback,
>
> Glenn Gobbel
>
> ----
> Glenn Gobbel, DVM, PhD
> Asst Res Professor, Vanderbilt University
>
