field not declared on base class ..

[Stephane Le Dorze]

     [java] net/blackmamba/persistence/asset/FFAssetModel: field not declared on base class -> _refDataRef

I have such output when declaring fields in derived classes.

I know that constructors of this class will never be called and I use these members as holder for lazy initialized values.

(They are affected when one call specific methods to initialize them)

I wonder if we could manage a way (annotation) not to pollute the compiler output.

This is a minor request however.

Thanks!

Stephane

[Joao Cachopo]

Stephane Le Dorze <stephane...@gmail.com> writes:

> [java] net/blackmamba/persistence/asset/FFAssetModel: field not declared on base class -> _refDataRef
>
> I have such output when declaring fields in derived classes.
> I know that constructors of this class will never be called and I use
> these members as holder for lazy initialized values. (They are
> affected when one call specific methods to initialize them) I wonder
> if we could manage a way (annotation) not to pollute the compiler
> output.

I'll add to the todo-list, but I want to point out that it is dangerous
to have such fields.

Are you sure that this field is accessed in a transactionally-safe way?

Is it being lazily initialized outside of a transaction and then never
more mutated or is it initialized within a transaction?

In the former case, you still have to ensure thread-safety in the access
to the field (if it is shared, as it probably is), either by making the
field volatile or accessing it only after some other form of
synchronization.

In the latter case, what happens if the transaction doing the lazy
initialization aborts because of a conflict? Will the field value still
be valid?

Best regards,
--
João Cachopo

[Stephane Le Dorze]

Hi Joao!

The field is derived from a VBox value.

Each access to the field is done with a comparison between last VBox value (from which the last value has been calculated) and the current one (always within a transaction) so the visible result is completely equivalent to uncached value version.

There's no semantic difference.

Perhaps a more general pattern is waiting for being captured here..

Stephane

2009/10/28 Joao Cachopo <joao.c...@ist.utl.pt>