25

Java 10 comes with the new Local Variable Type Inference. The token var can be used to reduce the boilerplate required when declaring a variable. e.g.

var s = "hello";

According to What type of token is exactly "var" in Java 10? this new token is not a "keyword" but rather is a "reserved type name". As such the word "var" can still be used as a variable name which maintains backwards compatibility with existing code.

var var = "you can do this";

When the "module" feature was introduced in Java 9 the type of this new token (along with its 9 other related tokens) were called a "restricted keywords". Which is to say they were only considered keywords under certain context specific restrictions. e.g. you can still have variables called module.

When new language features were added to C++ in such a way that they did not clobber existing user defined symbols they were called "context-sensitive keywords".

Is there a conceptual difference between the new "reserved type name" var token in Java 10 and a "context-sensitive keyword" or "restricted keyword". Which is to say isn't the new var token really just a keyword under certain context specific restrictions. If that is the case why wasn't it simply added to the list of "restricted keywords"?

To add to my confusion further the current draft version of the JLS says that:

The character sequence var is generally treated as an identifier, but in certain special cases acts as if it were a keyword instead.

That definition certainly sounds like a "restricted keyword".

bhspencer
  • 13,086
  • 5
  • 35
  • 44
  • 2
    You can not have a type with the name of a reserved type identifier, so `class var` is forbidden. – Johannes Kuhn Mar 05 '18 at 02:19
  • Yes I know that. But that does not answer the question why is the new token not called a "restricted keyword" – bhspencer Mar 05 '18 at 02:20
  • Mhh, ok, to boil it down: A restricted keyword is only a keyword in some contexts. So, `var` is now reserved at all places where you would write a type. Does that make `var` a restricted keyword? – Johannes Kuhn Mar 05 '18 at 02:24
  • It certainly seems like a restricted keyword to me. I don't get why a whole new type of thing has been introduced for this one case. Thats why I asked. – bhspencer Mar 05 '18 at 02:27
  • Probably because of the `enum` debacle when Java 5 came out. – chrylis -cautiouslyoptimistic- Mar 05 '18 at 02:35
  • I suppose my point comes down to this; I claim "var" fits into the description of a "restricted keyword" just as "module" does, but under the hood it is implemented in a different way than the other restricted keywords. The fact that the implementation is different should not mean that it should be thought of from the language perspective as a conceptually different class of thing. – bhspencer Mar 05 '18 at 02:42
  • 5
    What it boils down to is that "keywords", being "tokens", are recognized during the tokenization phase. They are part of the *lexical structure* of the language. "restricted keywords" (and also the tokenization of `<<` and `>>` as single angle brackets in a generic type context) are slight deviations from this rule, but can still be handled by a lexer. A "reserved type name" is interpreted as part of the grammatical structure of the language. In that sense `var` is not very different from the use of a generic type variable, in that the real type is determined using an additional lookup step. – Erwin Bolwidt Mar 05 '18 at 06:47
  • 2
    @ErwinBolwidt I have my doubt that the special treatment of `<<`, `>>`, and `>>>` really can be handled by the lexer (unless you are fine with accepting that the lexer does a lot more than a lexer’s work). – Holger Mar 05 '18 at 08:37
  • 2
    @Holger It's done in the lexer (probably by instructing it from the parser level) - you can find it in Section 3.2 of the JLS https://docs.oracle.com/javase/specs/jls/se9/html/jls-3.html#jls-3.2 - it's in the blueish-background box at the bottom of that section. – Erwin Bolwidt Mar 05 '18 at 08:52
  • 2
    @ErwinBolwidt since the lexer’s only purpose is to provide the input for the subsequent parser, there is no point in back-feeding the parser’s knowledge into the lexer, looping it back to the parser, just to fulfill the specifications wording. In practice, the parsers did the right thing even in Java 5 to 7, where the specification authors have forgotten to mention that behavior at all. And I doubt that anyone has rewritten the code, just because now the spec says that it has to happen in the lexer. – Holger Mar 05 '18 at 11:19
  • The `>>` discussion seems a bit off-topic. But for the curious: [This caused considerable headaches in C++](https://stackoverflow.com/q/7087033/3182664) ... – Marco13 Mar 06 '18 at 00:37
  • An vague guess: One difference is that the *restricted keywords* appear "below" new language constructs (e.g. below `ModuleDeclaration`). The introduction of the `TypeIdentifier` is a restriction that affects the places where originally, `Identifier` had been used, and thus, is far more disruptive and a very special case. – Marco13 Mar 06 '18 at 00:59
  • Why would you want to do this? because I think I'm better than you and don't understand your use-cases and I don't want to give meaningful responses. so I will just criticize your question for no reason. – LizardKing May 02 '23 at 16:29

1 Answers1

13

The very next sentence of the section you quote (3.8: Keywords) is:

A further ten character sequences are restricted keywords: open, module, requires, transitive, exports, opens, to, uses, provides, and with.

Note that var is not on this list. The mention of var in this section was included precisely to make it clear that while in some cases it may act like a restricted keyword, and while it may sound that way to you in your informal reading of the specification, it is not.

Context-sensitive keywords is one of the tools we have at our disposal for evolving the language in a compatible way; reserved identifiers are another. In this particular case, either could have been applied, and in the end, the latter tool was considered (for the purposes of specification and compiler implementation) to be preferable.

The specification, like most compiler implementations, separates lexical, syntactic, and typing concerns. Keywords are handled primarily at the level of lexer and parser productions; reserved type names are checked later in the compilation process, during type analysis, and can share the parser productions with non-reserved names.

From the perspective of a developer who is neither a spec author nor a compiler implementor, the difference is largely theoretical; the desired effect can be accomplished with either path.

Brian Goetz
  • 90,105
  • 23
  • 150
  • 161
  • 10
    I am sorry @BrianGoets but your answer still doesn't help me understand conceptual difference. Best I can get from this answer is that var is not a "restricted keyword" because it is not on the list. – bhspencer Mar 05 '18 at 03:18
  • 4
    I think the difference it makes to me is that I write Java and talk about Java all day long, five days a week and have done for many years. Having an accurate shared vocabulary when talking about programs with my peers is essential. The terms-of-art that the spec authors create become part of the vocabulary of developers. – bhspencer Mar 05 '18 at 03:33
  • 11
    With all due respect, this doesn't begin to answer the question. All you've done is assert that they *are* different concepts. OP was already aware of that. OP wants to know how and why they are different. "What difference does it make?" is not an answer, and actually only makes it sound like there needn't be a distinction. – Michael Mar 05 '18 at 08:20
  • 1
    @Brian Slight correction, maybe you meant *The mention of var here was **excluded*** in your answer. – Naman Mar 05 '18 at 09:54
  • 3
    @nullpointer No, I didn't mean that ;) I meant that there is a sentence on `var` in the section on Keywords, even though it is not a keyword (restricted or not), and this sentence was _included_ deliberately, for clarity. – Brian Goetz Mar 05 '18 at 16:05
  • 4
    Extending the answer with ... *"considered (...) to be preferable,* ***because*** *[insert some convincing reason here] ..."* could already reveal the "conceptual difference" that the asker is looking for. – Marco13 Mar 06 '18 at 00:48