Moving from VVT to the L-world value types (LWVT) (original) (raw)
Srikanth srikanth.adayapalam at oracle.com
Tue Feb 27 06:34:22 UTC 2018
- Previous message (by thread): Moving from VVT to the L-world value types (LWVT)
- Next message (by thread): [PATCH] GPU Exploitation Infrastructure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 introduced via: http://hg.openjdk.java.net/valhalla/valhalla/rev/ed5e12610039
Thanks! Srikanth
_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 annotation 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 already 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 annotation. 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
- Previous message (by thread): Moving from VVT to the L-world value types (LWVT)
- Next message (by thread): [PATCH] GPU Exploitation Infrastructure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]