This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 191899 - Improved hints for classes that use AtomicIntegerFieldUpdater, AtomicReferenceFieldUpdater, and AtomicLongFieldUpdater
Summary: Improved hints for classes that use AtomicIntegerFieldUpdater, AtomicReferenc...
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 7.0
Hardware: PC Windows Vista
: P3 normal (vote)
Assignee: Svata Dedic
Depends on:
Reported: 2010-11-12 15:20 UTC by jplatts
Modified: 2016-07-13 13:35 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description jplatts 2010-11-12 15:20:45 UTC
I have been using AtomicIntegerFieldUpdater, AtomicReferenceFieldUpdater, and AtomicLongFieldUpdater in several Java classes. However, there are some undesired warnings that appear in the editor when these classes are used. In addition, fields are sometimes incorrectly marked as unused by the NetBeans editor (but are actually in use because they are referenced by an AtomicIntegerFieldUpdater, an AtomicReferenceFieldUpdater, or an AtomicLongFieldUpdater). The reason that I often prefer using the AtomicIntegerFieldUpdater, AtomicReferenceFieldUpdater, and AtomicLongFieldUpdater classes over AtomicInteger, AtomicReference, and AtomicLong is to avoid the overhead of allocating AtomicIntegers, AtomicReferences, and AtomicLongs and reduce the memory usage.

One of the undesired warnings that appears when I write to volatile fields within constructors through an AtomicIntegerFieldUpdater, an AtomicReferenceFieldUpdater, or an AtomicLongFieldUpdater is that a Leaking this in constructor warning appears in the NetBeans editor.

The following snippets of code are safe to call within a constructor, where anUpdater is an AtomicReferenceFieldUpdater that is a static final field defined in the same class and refers to a field in the same class as the constructor:
anUpdater.set(this, new ExampleObject());
anUpdater.lazySet(this, new ExampleObject2());
anUpdater.compareAndSet(this, null, new ExampleObject3());

In addition, there are cases in which the NetBeans editor marks a field as unused, but the field is indeed not unused because it is being accessed through an AtomicIntegerFieldUpdater, an AtomicReferenceFieldUpdater, or an AtomicLongFieldUpdater. I really would like to see the NetBeans editor mark these fields as actually being used.

Here is an example of a snippet that will compile successfully, but will always result in a run-time error:
class TestClass {
    static final AtomicReferenceFieldUpdater<TestClass, ExampleObject>
        exampleObjectUpdater = AtomicReferenceFieldUpdater.newUpdater(
        TestClass.class, ExampleObject.class, "exampleObject");

In the above example, an AtomicReferenceFieldUpdater is created for the exampleObject field, which does not exist in TestClass. It is already known that a run-time error will result in this case (assuming there is no bytecode enhancement or manipulation of the source prior to compilation), as the exampleObjectUpdater is a static final field defined in TestClass that refers to an updater for a field that does not exist in TestClass. The NetBeans editor should detect AtomicIntegerFieldUpdater, AtomicReferenceFieldUpdater, and AtomicLongFieldUpdater creation expressions that are assigned to static final fields and refer to fields that are known to not exist (like the example above).
Comment 1 Svata Dedic 2013-09-04 18:40:40 UTC
This is an enhancement request - actually two of them:

a/ the "unused" field analysis should understand the AFieldUpdater semantics  - I am afraid this is not doable but in trivial case the updater is defined in the class itself (package-private members may be accessed by peers). 

b/ the 'leaking this' is actually a correct warning. "this" reference should not escape the object before the construction is complete. Escaped 'this' means the final values of the object may be observed by others before they are initialized etc, so in general it is a bad idea.
JDK lacks meta-data, which would for example mark FieldUpdater as 'safe' with respect to this escaping. Such metadata could be invented (other features could use similar metadata, too) and shipped with NetBeans, but it's not in the plan near soon.
Comment 2 Svata Dedic 2016-07-13 13:35:12 UTC
Reopening; it falls into more general category of support for 'externally used' fields or metadata.