Moving from VVT to the L-world value types (LWVT)
srikanth.adayapalam at oracle.com
Tue Feb 27 06:34:22 UTC 2018
On Tuesday 27 February 2018 05:09 AM, John Rose wrote:
> On Feb 13, 2018, at 8:39 PM, Srikanth <srikanth.adayapalam at oracle.com
> <mailto:srikanth.adayapalam at oracle.com>> wrote:
>> Instead of a modifier to request flattenable fields, I have an almost
>> working version in my workspace
>> that introduces and uses a new annotation java.lang.Flattenable
>> (alongside, @Deprecated, @FunctionalInterface, @Override,
>> @SafeVarargs, @SuppressWarnings ...)
>> Modifiers bring in issues around context sensitive keywords,
>> annotations are cleaner IMO.
>> I will be pushing this to the branch soon. Let me know if there is a
>> strong reason to prefer a modifier at the prototyping stage itself.
> (Late response, but with something I want to put on the table.)
No problem. Agree with your observations. Javac behavior changed so that the
@Flattenable annotation is withdrawn and a new modifier __Flattenable is
> For the record, I prefer a modifier, but one named like __ByValue, so that
> it is clear that the syntax is temporary and will go away. Using an
> is OK too, but has the downside of looking permanent when it may not be.
> (I realize that javac code complexity is an issue also. But there are
> code paths to handle quasi-modifiers, so adding more should be just
> incremental effort, right?)
> A field annotation that affects the load sequence and allowed range of
> field values (@Flattenable) is probably too "semantic" to fly as an
> Annotations are *not* allowed to affect base semantics of a Java program.
> Of course we *are* changing base semantics, so there is a certain gray
> area here, but in the end it would be a bad move if the meaning of a
> Java program hinged on the presence or absence of @Flattenable
> on some field. Thus @Flattenable seems temporary, and __Flattenable
> would be just as temporary but more obviously so.
> — John
More information about the valhalla-dev