From alex.buckley at oracle.com Mon Aug 17 22:51:35 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Aug 2020 15:51:35 -0700 Subject: 'Category' and 'Kind' terms are used to describe same thing. In-Reply-To: References: Message-ID: <47dbff27-252b-9ccc-ea21-79c74ff7c6ed@oracle.com> I agree that switching from "categories" to "kinds" is redundant. JLS 5.1 does the same thing: the section title "Kinds of Conversion" is immediately followed by "Specific type conversions in the Java programming language are divided into 13 *categories*." "kinds" is far more common than "categories" in the JLS, so I will edit 4 and 5.1 accordingly. Alex On 7/17/2020 12:09 PM, Dmitry Lazutkin wrote: > Hi. I found two sentences that use different wording to describe diversity > of Java types. > > In introduction to *Chapter 4:* > > *The types of the Java programming language are divided into two > categories: primitive types and reference types.* > > And further right at the beginning of *4.1. The Kinds of Types and Values:* > > *There are two kinds of types in the Java programming language: primitive > types (?4.2 > ) > and reference types (?4.3 > ).* > > IMHO: For me, as non-native English reader the terms 'Category' and 'Kind' > in that context mean pretty much the same thing but have some subtle > differences so I think that it would be better to use only one term > (personally I vote for 'Category') > From alex.buckley at oracle.com Mon Aug 17 22:58:19 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Aug 2020 15:58:19 -0700 Subject: A little mistakes in Java Language Specifications 13 In-Reply-To: References: Message-ID: <614dbb2b-ff82-4ea5-a950-828fbd4a1f99@oracle.com> I don't disagree that more exposition would be helpful. Filed https://bugs.openjdk.java.net/browse/JDK-8251913 Alex On 4/18/2020 12:16 AM, Duy Tr?n wrote: > Dear Sir or Madame, > > When I read the Java Language Specification 13 (JLSE), I found a little > mistake (I think so) and it can cause some confusions to readers. > > In page 24, I found that "*Comment do not nest*" > [image: image.png] > Although this sentence is not false, it can cause some confusions to > readers with the question "*What type of comment which do not nest? > Traditional Comments or End-Of-Line Comments?*". For this mistake, I > suggest some modification like that: > 1. Traditional comment can apply to multi-lines > 2. Nested comment in Java is allowed, except nested comment of multi-lines > *** End-of-line comment inside another End-of-Line comment is acceptable > *** End-of-line comment inside an multi-line comment is also acceptable > (even though it does not make sense) > **** But, /*....*/ inside another /*...*/ is forbidden* > > Or, you can consult the modification like that > [image: image.png] > > If you have any question, please let me know > > Thank you and best regards > > Duy > From alex.buckley at oracle.com Mon Aug 17 22:58:59 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Aug 2020 15:58:59 -0700 Subject: Grammatical error in JLS In-Reply-To: References: Message-ID: <1adedb96-b7c1-3b20-ba78-325cf54232c9@oracle.com> Thanks, will be fixed in 15. On 2/20/2020 6:26 AM, Aaron Fihn wrote: > Hi, > > I found a minor grammatical error in section 8.4.2 of the Java Language > Specification, SE 13 edition. The word "the" is used twice consecutively. > See below: > > "Two methods or constructors, M and N, have the *same signature* if they > have the same name, the same type parameters (if any) (?8.4.4 > ), > and, after adapting the formal parameter types of N to *the the* type > parameters of M, the same formal parameter types." > > Thanks, > Aaron Fihn > From alex.buckley at oracle.com Mon Aug 17 23:08:29 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Aug 2020 16:08:29 -0700 Subject: JLS Technical Amguity In-Reply-To: References: Message-ID: As you say, a type parameter in a class declaration is ultimately a TypeIdentifier, just like the name specified for the class itself. A TypeIdentifier cannot be `var` or `yield`. On JDK 14, javac correctly rejects `class A {}` and `class B {}`: | Welcome to JShell -- Version 14 | For an introduction type: /help intro jshell> class A {} | Error: | 'var' not allowed here | as of release 10, 'var' is a restricted type name and cannot be used for type declarations | class A {} | ^ jshell> class B {} | Error: | 'yield' not allowed here | as of release 13, 'yield' is a restricted type name and cannot be used for type declarations | class B {} | ^ Alex On 6/18/2020 5:38 PM, Sam Hooper wrote: > Hi, > There appears to be a technical ambiguity in the JLS 14. The restricted > identifier yield is allowed as the name of a type variable when, according > to the specification, it should not be. The following compiles fine: > class Outer{ > > class Inner{ > > void method() {} > > } > > } > > which it should not according to the following productions from JLS 14: > > TypeParameters: > < TypeParameterList > > > > TypeParameterList: > TypeParameter > > {, TypeParameter > > } > TypeParameter: > {TypeParameterModifier > > } TypeIdentifier > > [TypeBound > > ] > TypeIdentifier: > Identifier > > but not var or yield > > Thanks for your time. > > -Sam Hooper > From alex.buckley at oracle.com Mon Aug 17 23:23:31 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Aug 2020 16:23:31 -0700 Subject: JLS does not allow method call on Primary of array type In-Reply-To: <9BV.8sGc.4fffxjLOYc9.1UMcFK@seznam.cz> References: <9BV.8sGc.4fffxjLOYc9.1UMcFK@seznam.cz> Message-ID: <40a3dc2e-4d66-07b7-39c0-0b1dddcb38b9@oracle.com> Thanks. `new int[0].clone()` and `new float[1][2].toString()` and `new Object[100][200][300].hashCode()` are legitimate method invocation expressions. It does seem like everyone missed the possibility of an array type when analyzing T. Filed https://bugs.openjdk.java.net/browse/JDK-8251914 Alex On 2/29/2020 5:15 AM, Lukas.P at seznam.cz wrote: > Dear JLS Team, > > when reading the JLS of Java 13, I think I found an omission in the section "15.12. Method Invocation Expressions". Because of that omission it is not possible to invoke methods of array type objects. > > Example code: > > ?new int[0].clone(); > > When trying to find out the semantics of such a statement I go to section 15.12, as the clone identifier should identify a method to be called. That section of the specification states that determining the method to be called progresses through several steps. The section 15.12.1 gives the first step. Here, there are six cases considered. > > For the given example above, I think the following case applies: > >> If the form is Primary . [TypeArguments] Identifier, then let T be >> the type of the Primary expression. The class or interface to search >> is T if T is a class or interface type, or the upper bound of T if T >> is a type variable. > > Now, the type of the primary expression is an array type with component type int, T is int[], T is not class or interface type, T is not a type variable. So, this case does not provide us with any class or interface to search, and the compile time determination cannot continue with any further steps. > > Here, one possibility would be to consider that array type is a class type, but looking at chapter 10, we see at section 10.8: > >> Although an array type is not a class, the Class object of every >> array acts as if ... > > I assume this means that array types and class types should be regarded as different notions. > > I think the specification should be augmented to specify where to search for a method when T is an array type. > > Kind Regards, > Lukas > From alex.buckley at oracle.com Wed Aug 19 16:54:22 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 19 Aug 2020 09:54:22 -0700 Subject: Apparent conflict in ACC_SUPER rules In-Reply-To: References: Message-ID: Thanks. Filed https://bugs.openjdk.java.net/browse/JDK-8252006 Alex On 1/28/2020 8:39 AM, Lukas Petru wrote: > Hello. > > This is my feedback and request for clarification sent to the e-mail address > as suggested in chapter 1 of Java Virtual Machine Specification. > > When reading the Java language specification, I found the following pieces > of text that seem to be in contradiction: > > Java SE 13 > Released September 2019 as JSR 388 > (https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-4.html) > > chapter 4 section 4.1. The ClassFile Structure > > access_flags > >> If the ACC_INTERFACE flag is set, the ACC_ABSTRACT flag must also be set, >> and the ACC_FINAL, ACC_SUPER, ACC_ENUM, and ACC_MODULE flags set must >> not be set.> > I.e. for interface, never set ACC_SUPER. > >> Compilers to the instruction set of the Java Virtual Machine should set >> the ACC_SUPER flag. > > I.e. always set ACC_SUPER. > > Which one is true? Should interfaces have the ACC_SUPER always set or never > set? > > Kind regards, > Lukas