Use of class instances with static variable fields

[Glenn Gobbel <gl...@vanderbilt.edu>]

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

Re: Use of class instances with static variable fields

[Glenn Gobbel <gl...@vanderbilt.edu>]

Richard,

Ah, this is exactly the sort of information I was hoping for.  I was
overlooking the ability to change the set itself without changing the
set assigned to the static variable.  And I didn't know about the
availability of Collections.unmodifiableSet(set).

Fantastic.

Thank you, 
Glenn

Re: Use of class instances with static variable fields

[Richard Eckart de Castilho <ri...@gmail.com>]

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 <gl...@vanderbilt.edu>:

> 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
>