5 ms·

Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?

JCWasmx86 6y ago
Yes. It feels out-of-place. All other keywords are like one word: enum, class, public, protected, native, sealed, ... But looks entirely different: Two words, connected by a hyphen. But I think, it was done because of backwards compatibility. If they would have called it "closed", it would maybe break hundreds of programs that have methods/variables called "closed"
- Macha 6y ago
  I made this argument before, but was informed that they have support for contextually distinguishing between names and keywords some time between Java 8 and 10. So while e.g. the introduction of enum did cause all these issues for variables named enum, "var" did not and a hypothetical "closed" would not.
- mdaniel 6y ago
  There are plenty of languages which have contextually sensitive keywords for that exact reason. C# (a closer peer to Java syntactically) has contextual keywords including "var" and "notnull": https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/#contextual-keywords https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- hugi 6y ago
  There was a lot of discussion about this and they eventually settled on the hyphen. Consider this our introduction to hyphenated keywords and expect to see a lot more of them in the future.
- BoyRobot777 6y ago
  There was a lengthy discussion some time ago[0]. Quote: #### Why not "just" make contextual keywords? At first glance, contextual keywords (and their friends, such as reserved type identifiers) may appear to be a magic wand; they let us create the illusion of adding new keywords without breaking existing programs. But the positive track record of contextual keywords hides a great deal of complexity and distortion. Each grammar position is its own story; contextual keywords that might be used as modifiers (e.g., `readonly`) have different ambiguity considerations than those that might be use in code (e.g., a `matches` expression). The process of selecting a contextual keyword is not a simple matter of adding it to the grammar; each one requires an analysis of potential current and future interactions. Similarly, each token we try to repurpose may have its own special considerations; for example, we could justify the use of `var` as a reserved type name because because the naming conventions are so broadly adhered to. Finally, the use of contextual keywords in certain syntactic positions can create additional considerations for extending the syntax later. Contextual keywords create complexity for specifications, compilers, and IDEs. With one or two special cases, we can often deal well enough, but if special cases were to become more pervasive, this would likely result in more significant maintenance costs or bug tail. While it is easy to dismiss this as “not my problem”, in reality, this is everybody’s problem. IDEs often have to guess whether a use of a contextual keyword is a keyword or identifier, and it may not have enough information to make a good guess until it’s seen more input. This results in worse user highlighting, auto-completion, and refactoring abilities — or worse. These problems quickly become everyone's problems. So, while contextual keywords are one of the tools in our toolbox, they should also be used sparingly. [0]. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...
- Jabbles 6y ago
  Surely migrating variables named "unsealed" would be fairly trivial?
Erlangen 6y ago
It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.
- bartvk 6y ago
  Whenever Swift adds a new keyword, they just add it and break everyone’s code. They do provide migration tools in Xcode though.
- m45t3r 6y ago
  I think non_sealed would be better than non-sealed though, because AFAIK there used to be no identifiers with hifen before.
  - fomine3 6y ago
    int non, sealed; ?
- gpderetta 6y ago
  co_await is so bad that co_X has become a running joke in the C++ community.
- kccqzy 6y ago
  C++ has had two-word keywords since the beginning, static_cast, dynamic_cast, etc. What I truly don't like is C's propensity to add new keywords that begin with an underscore and an uppercase letter. Like _Bool, or _Atomic. (I know the rationale, these can't be used as identifiers due to UB, but it still looks weird to me.)
elygre 6y ago
Following the various openjdk mailing lists is an awesome way of learning about all the considerations that go into making language choices for java. And indeed this was not random, but the result of a lot thinking (as shown in a another sibling post).
nikanj 6y ago
Oracle had no qualms about breaking a metric boatload of code by shutting down the old sun.* APIs. Their justification was "You were not supposed to use these internal tools", but the reality of the matter is that migrating to a new Java version took lots of code rework. I'm surprised they were so shy to break code by introducing new keywords, after they wreaked havoc on people's codebases with removing sun.misc.BASE64Decoder etc

JCWasmx86 6y ago

Yes. It feels out-of-place. All other keywords are like one word: enum, class, public, protected, native, sealed, ... But looks entirely different: Two words, connected by a hyphen. But I think, it was done because of backwards compatibility. If they would have called it "closed", it would maybe break hundreds of programs that have methods/variables called "closed"

Macha 6y ago
I made this argument before, but was informed that they have support for contextually distinguishing between names and keywords some time between Java 8 and 10. So while e.g. the introduction of enum did cause all these issues for variables named enum, "var" did not and a hypothetical "closed" would not.
mdaniel 6y ago
There are plenty of languages which have contextually sensitive keywords for that exact reason. C# (a closer peer to Java syntactically) has contextual keywords including "var" and "notnull": https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/#contextual-keywords https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
hugi 6y ago
There was a lot of discussion about this and they eventually settled on the hyphen. Consider this our introduction to hyphenated keywords and expect to see a lot more of them in the future.
BoyRobot777 6y ago
There was a lengthy discussion some time ago[0]. Quote: #### Why not "just" make contextual keywords? At first glance, contextual keywords (and their friends, such as reserved type identifiers) may appear to be a magic wand; they let us create the illusion of adding new keywords without breaking existing programs. But the positive track record of contextual keywords hides a great deal of complexity and distortion. Each grammar position is its own story; contextual keywords that might be used as modifiers (e.g., `readonly`) have different ambiguity considerations than those that might be use in code (e.g., a `matches` expression). The process of selecting a contextual keyword is not a simple matter of adding it to the grammar; each one requires an analysis of potential current and future interactions. Similarly, each token we try to repurpose may have its own special considerations; for example, we could justify the use of `var` as a reserved type name because because the naming conventions are so broadly adhered to. Finally, the use of contextual keywords in certain syntactic positions can create additional considerations for extending the syntax later. Contextual keywords create complexity for specifications, compilers, and IDEs. With one or two special cases, we can often deal well enough, but if special cases were to become more pervasive, this would likely result in more significant maintenance costs or bug tail. While it is easy to dismiss this as “not my problem”, in reality, this is everybody’s problem. IDEs often have to guess whether a use of a contextual keyword is a keyword or identifier, and it may not have enough information to make a good guess until it’s seen more input. This results in worse user highlighting, auto-completion, and refactoring abilities — or worse. These problems quickly become everyone's problems. So, while contextual keywords are one of the tools in our toolbox, they should also be used sparingly. [0]. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...
Jabbles 6y ago
Surely migrating variables named "unsealed" would be fairly trivial?

Erlangen 6y ago

It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.

bartvk 6y ago
Whenever Swift adds a new keyword, they just add it and break everyone’s code. They do provide migration tools in Xcode though.
m45t3r 6y ago
I think non_sealed would be better than non-sealed though, because AFAIK there used to be no identifiers with hifen before.
- fomine3 6y ago
  int non, sealed; ?
gpderetta 6y ago
co_await is so bad that co_X has become a running joke in the C++ community.
kccqzy 6y ago
C++ has had two-word keywords since the beginning, static_cast, dynamic_cast, etc. What I truly don't like is C's propensity to add new keywords that begin with an underscore and an uppercase letter. Like _Bool, or _Atomic. (I know the rationale, these can't be used as identifiers due to UB, but it still looks weird to me.)

elygre 6y ago

Following the various openjdk mailing lists is an awesome way of learning about all the considerations that go into making language choices for java. And indeed this was not random, but the result of a lot thinking (as shown in a another sibling post).

nikanj 6y ago

Oracle had no qualms about breaking a metric boatload of code by shutting down the old sun.* APIs. Their justification was "You were not supposed to use these internal tools", but the reality of the matter is that migrating to a new Java version took lots of code rework. I'm surprised they were so shy to break code by introducing new keywords, after they wreaked havoc on people's codebases with removing sun.misc.BASE64Decoder etc