Incorrect casts used with invoking may leave "eventually" calls in invalid state.

[brianoliver]

Something like the following call:

Eventually.assertThat((String) invoking(foo).getValue(), matcher);

while it may compile correctly, at runtime Oracle Bedrock may generate an exception when the returned dynamic proxy (from invoking) can't be cast to a String. This will then leave the internal state of the ThreadLocal being used to manage the proxy in an invalid state, thus causing later uses of Eventually.assertThat(...) or the eventually(...) method to immediately fail and throw the following misleading exception:

UnsupportedOperationException: An attempt was made to call 'invoking' without being wrapped inside an 'eventually' call. Alternatively two or more calls to 'invoking' have been made sequentially. Calls to 'invoking' must be contained inside an 'eventually' call.

The solution to this is to allow further calls and log the issue instead of throwing an exception. It's far more important to allow other tests to succeed than to corrupt (and fail) other tests.

NOTE: Developers usually do this type of thing to "fix" a compiler type error if the "matcher" is of the incorrect type. Instead attempting to cast the result of "invoking" they should fix the matcher type or cast it instead.

[brianoliver]

This issue was imported from JIRA ORACLETOOLS-208

[brianoliver]

Reported by @brianoliver

[brianoliver]

No longer an issue as the DeferredHelper.eventually(...) method always checks for a deferred value and uses that regardless of the (casted) value provided.