Can @Stable (or something similar) be made accessible?

[Jason Greene]

> On Jan 15, 2018, at 6:51 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Jason,
> 
> I wouldn't consider @Stable as a scalpel :-)
> 
> It's heavily locked down for a reason: it wasn't designed for eventual standardization, but as (1) an experiment in _multiple_ directions; and (2) solution for immediate problems in java.lang.invoke.
> 
> @Stable mixes (incomplete implementations of) 2 independent features (lazy initialization of finals + constant arrays), while trusting instance finals is just a consequence of locking it down to privileged code (JIT-compilers already trust final instance fields in different core packages).
> 
> Current implementation doesn't enforce at runtime the contract and allows multiple writes to @Stable field. It is useful in rare cases, but overall significantly complicates proper usage of @Stable.
> 
> All those factors make @Stable unfit for public exposure in it’s current form.
> 
> Both referenced features are independently explored (as lazy finals and frozen arrays).
> 
> Also, @Stable is not a substitute for final fields: default value is treated specially (not optimized), while "final" covers the whole range of values of a type.
> 
> For optimizing final fields there are much more promising approaches:
> 
>  (1) optimistic optimizations in JITs: treat finals as constants and track updates invalidating code which relies on that (there were some experiments, e.g. [1]);
> 
>  (2) forbid final field updates at runtime after initialization is over and freely optimize them in JITs.
> 
> Both approaches still have some roadblocks on their way (deserialization relies on modifying final fields, hard to track final field values of individual objects in JVM, etc), but the platform steadily moves in the direction of treating final fields as truly final by default.

Thanks for the explanation Vladimir,

I can certainly understand optimistic optimization being the end goal, but, correct me if I am wrong, it seems an improvement in the distant future. I can see the issue is scheduled for 11, but I imagine that is more of a placeholder.  

Has a narrow variant of (2) in the same vein as @Stable been considered, as it seems to overcome the roadblocks mentioned? An annotation placed on a final field (something like @Constant, @StrictFinal, @ImmutableAfterPublish, whatever) could indicate opting in to the contract of this field as a truly final field, freeing the JVM to optimize and validate as desired (e.g. special case serialization, preventing setAcessible/JNI set field/VarHandle/etc), and without introducing compatibility issues. I realize validating access via Unsafe is non-trivial, but I argue there is limited value in doing so, since the effects are not worse than other actions one might take with Unsafe. Further, I argue any validation at all is going above and beyond, as “undefined” is a perfectly reasonable result for contract violations.

-Jason