Community
Participate
Working Groups
https://mail.openjdk.java.net/pipermail/amber-spec-observers/2019-January/001029.html Highlights from the above link: Over time, as the language evolves, language designers face a challenge; the set of keywords imagined in version 1.0 are rarely suitable for expressing all the things we might ever want our language to express. .. ## We need a new source of keyword candidates Every time we confront this problem, the overwhelming tendency is to punt and pick one of the bad options, because the problem only comes along every once in a while. But, with the features in the pipeline, I expect it will continue to come along with some frequency, and I’d rather get ahead of it. Given that all of these current options are problematic, and there is not even a least-problematic move that applies across all situations, my inclination is to try to expand the set of lexical forms that can be used as keywords. ... Here’s some examples where this approach might yield credible candidates. (Note: none of these are being proposed here; this is merely an illustrative list of examples of how this mechanism could form keywords that might, in some particular possible future, be useful and better than the alternatives we have now.) - `non-null` - `non-final` - `package-private` (the default accessibility for class members, currently not denotable) - `public-read` (publicly readable, privately writable) - `null-checked` - `type-static` (a concept needed in Valhalla, which is static relative to a particular specialization of a class, rather than the class itself) - `default-value` - `eventually-final` (what the `@Stable` annotation currently suggests) - `semi-final` (an alternative to `sealed`) - `exhaustive-switch` (opting into exhaustiveness checking for statement switches) - `enum-class`, `annotation-class`, `record-class` (we might have chosen these as an alternative to `enum` and `@interface`, had we had the option) - `this-class` (to describe the class literal for the current class) - `this-return` (a common request is a way to mark a setter or builder method as returning its receiver)
See also bug 542560 comment 14
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.