From hiramhunt at verizon.net Fri Jun 3 19:43:14 2016 From: hiramhunt at verizon.net (Hiram Hunt) Date: Fri, 03 Jun 2016 19:43:14 -0000 Subject: Possible typo in JLS 8 Section 4.10.4 Message-ID: <9228d534-f2fa-b9f5-1499-6d12e2d10e5e@verizon.net> Hello, In The Java Language Specification (Java SE 8 Edition) in section 4.10.4 (Least Upper Bound) on page 74 of my physical book and page 75 of the current jls8.pdf (online) there is text giving definitions for several cases of lcp(). Introducing those definitions are the words "where lcp(), the least containing invocation, is:" I think that "invocation" should be "parameterization" like in the smaller-font explanatory paragraph a bit above that location. -- Hiram Hunt (hiramhunt at verizon.net) From hiramhunt at verizon.net Fri Jun 3 20:09:19 2016 From: hiramhunt at verizon.net (Hiram Hunt) Date: Fri, 03 Jun 2016 20:09:19 -0000 Subject: Typo in JLS 8 Section 4.2.3 Message-ID: <313896c2-9ae2-1355-a67b-270144f46ca9@verizon.net> Hello, In The Java Language Specification (Java SE 8 Edition) near the end of section 4.2.3 (Floating-Point Types, Formats, and Values) there is an explanation of the behavior of NaN. There are three bulleted items. After the second bulleted item, there are the words "In particular, (x=y) will be false if x or y is NaN". The problem is that the second bulleted item has to do with what happens if a NaN occurs as an operand of ==, but the operands of == in the "In particular..." sentence are booleans. The words really belong right after the first bulleted item, which concerns the numerical comparison operators. Also, couldn't the expression be made simpler by dropping the logical negation and changing the word "false" to "true" in the misplaced text? Even shorter: "In particular, (x=y) if x or y is NaN." -- Hiram Hunt (hiramhunt at verizon.net) From hiramhunt at verizon.net Sun Jun 5 18:26:51 2016 From: hiramhunt at verizon.net (Hiram Hunt) Date: Sun, 05 Jun 2016 18:26:51 -0000 Subject: Typo in JLS 8 Section 5.2 Message-ID: <909c63d6-661e-7167-102d-ad7b7ff1d0b9@verizon.net> Hello, In the Java Language Specification (Java SE 8 Edition) in section 5.2 (Assignment Contexts) on page 112 of my printed copy but page 114 of the current online .pdf version there is a typo. In the last bulleted item of the explanation of Example 5.2-3 it says "because not every reference that could be the value of an expression of type ColoredPoint can correctly be the value of a variable of type Point." Here, "Point" and "ColoredPoint" are swapped. -- Hiram Hunt (hiramhunt at verizon.net) From hiramhunt at verizon.net Sun Jun 12 22:19:26 2016 From: hiramhunt at verizon.net (Hiram Hunt) Date: Sun, 12 Jun 2016 18:19:26 -0400 Subject: JLS typo section 7.4.1 Message-ID: Hello, In section 7.4.1 (Named Packages) of the Java Language Specification (Java 8 SE Edition) there is a typo. In the first paragraph of the small-font explanatory text there are several occurrences of "package-info.java". One of these refers to the name of a hypothetical, but illegal, class and should be "package-info" without the ".java". The JLS says "This file does not contain the source for a class called packageinfo.java; ...." -- Hiram Hunt (hiramhunt at verizon.net) From hiramhunt at verizon.net Sun Jun 12 23:02:37 2016 From: hiramhunt at verizon.net (Hiram Hunt) Date: Sun, 12 Jun 2016 19:02:37 -0400 Subject: JLS explanation or correction needed 7.5.3 & 7.5.4 Message-ID: The JLS (Java 8 SE Edition) says in section 7.5.3 "It is permissible for one single-static-import declaration to import several fields or types with the same name, or several methods with the same name and signature." and says in section 7.5.4 "It is permissible for one static-import-on-demand declaration to import several fields or types with the same name, or several methods with the same name and signature." My understanding is that it is not legal to declare several fields with the same name as members of one class nor several types with the same name as members of one class nor several methods with the same name _and signature_ as members of the same class. Thus, it is hard for me to understand the above quoted statements from the JLS. They need correction or explanation, possibly by example. -- Hiram Hunt (hiramhunt at verizon.net) From alex.buckley at oracle.com Wed Jun 22 23:27:58 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Jun 2016 16:27:58 -0700 Subject: Possible typo in JLS 8 Section 4.10.4 In-Reply-To: <9228d534-f2fa-b9f5-1499-6d12e2d10e5e@verizon.net> References: <9228d534-f2fa-b9f5-1499-6d12e2d10e5e@verizon.net> Message-ID: <576B1EFE.2080707@oracle.com> Yes, thanks. On 6/3/2016 12:43 PM, Hiram Hunt wrote: > Hello, > > In The Java Language Specification (Java SE 8 Edition) > in section 4.10.4 (Least Upper Bound) on page 74 of > my physical book and page 75 of the current jls8.pdf > (online) there is text giving definitions for several > cases of lcp(). Introducing those definitions are the > words "where lcp(), the least containing invocation, > is:" > > I think that "invocation" should be "parameterization" > like in the smaller-font explanatory paragraph a bit > above that location. > > -- Hiram Hunt (hiramhunt at verizon.net) From alex.buckley at oracle.com Wed Jun 22 23:28:24 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Jun 2016 16:28:24 -0700 Subject: Typo in JLS 8 Section 5.2 In-Reply-To: <909c63d6-661e-7167-102d-ad7b7ff1d0b9@verizon.net> References: <909c63d6-661e-7167-102d-ad7b7ff1d0b9@verizon.net> Message-ID: <576B1F18.3020300@oracle.com> Yes, thanks. On 6/5/2016 11:26 AM, Hiram Hunt wrote: > Hello, > > In the Java Language Specification (Java SE 8 Edition) > in section 5.2 (Assignment Contexts) on page 112 of my > printed copy but page 114 of the current online .pdf > version there is a typo. In the last bulleted item of > the explanation of Example 5.2-3 it says > > "because not every reference that could be the value > of an expression of type ColoredPoint can correctly > be the value of a variable of type Point." > > Here, "Point" and "ColoredPoint" are swapped. > > -- Hiram Hunt (hiramhunt at verizon.net) > From alex.buckley at oracle.com Wed Jun 22 23:28:53 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Jun 2016 16:28:53 -0700 Subject: JLS typo section 7.4.1 In-Reply-To: References: Message-ID: <576B1F35.50301@oracle.com> Yes, thanks. On 6/12/2016 3:19 PM, Hiram Hunt wrote: > Hello, > In section 7.4.1 (Named Packages) of the > Java Language Specification (Java 8 SE Edition) > there is a typo. In the first paragraph of the > small-font explanatory text there are several > occurrences of "package-info.java". One of > these refers to the name of a hypothetical, > but illegal, class and should be "package-info" > without the ".java". The JLS says > > "This file does not contain the source for > a class called package-info.java; ...." > > -- Hiram Hunt (hiramhunt at verizon.net) From alex.buckley at oracle.com Wed Jun 22 23:38:19 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Jun 2016 16:38:19 -0700 Subject: JLS explanation or correction needed 7.5.3 & 7.5.4 In-Reply-To: References: Message-ID: <576B216B.4040706@oracle.com> These "permissible" paragraphs do raise questions from time to time, so I have filed https://bugs.openjdk.java.net/browse/JDK-8160131 to clarify. Basically you have to know about the possibility of inheriting multiple members with the same name (and in the case of methods, same signature) from multiple supertypes, but that's not introduced until 8.3, 8.4.8, and 8.5. Alex On 6/12/2016 4:02 PM, Hiram Hunt wrote: > The JLS (Java 8 SE Edition) says in section 7.5.3 > > "It is permissible for one single-static-import > declaration to import several fields or types > with the same name, or several methods with the > same name and signature." > > and says in section 7.5.4 > > "It is permissible for one static-import-on-demand > declaration to import several fields or types > with the same name, or several methods with the > same name and signature." > > My understanding is that it is not legal to declare > several fields with the same name as members of one > class nor several types with the same name as members > of one class nor several methods with the same name > _and signature_ as members of the same class. Thus, > it is hard for me to understand the above quoted > statements from the JLS. They need correction or > explanation, possibly by example. > > -- Hiram Hunt (hiramhunt at verizon.net) From alex.buckley at oracle.com Wed Jun 22 23:51:34 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Jun 2016 16:51:34 -0700 Subject: Typo in JLS 8 Section 4.2.3 In-Reply-To: <313896c2-9ae2-1355-a67b-270144f46ca9@verizon.net> References: <313896c2-9ae2-1355-a67b-270144f46ca9@verizon.net> Message-ID: <576B2486.3010808@oracle.com> Yes, I see what you mean about the "In particular" of the second bullet being better off in the first bullet. As for the form of the == expression, it depends what kind of weird behavior you're trying to emphasize. Sure, it's weird that the truth of x=y, but it's also weird that something you would expect to be true -- the agreement of x=y) -- is false. So, I don't propose to reformulate the example. Alex On 6/3/2016 1:09 PM, Hiram Hunt wrote: > Hello, > > In The Java Language Specification (Java SE 8 Edition) > near the end of section 4.2.3 (Floating-Point Types, > Formats, and Values) there is an explanation of the > behavior of NaN. There are three bulleted items. > After the second bulleted item, there are the words > "In particular, (x=y) will be false if x > or y is NaN". > > The problem is that the second bulleted item has to do > with what happens if a NaN occurs as an operand of ==, > but the operands of == in the "In particular..." sentence > are booleans. The words really belong right after the > first bulleted item, which concerns the numerical > comparison operators. > > Also, couldn't the expression be made simpler by dropping > the logical negation and changing the word "false" to "true" > in the misplaced text? Even shorter: > "In particular, (x=y) if x or y is NaN." > > -- Hiram Hunt (hiramhunt at verizon.net)