JLS 3/e -- Lots Of Errors

  • Thread starter Lawrence D'Oliveiro
  • Start date
L

Lawrence D'Oliveiro

I’ve been going through the Java Language Specification, 3rd Edition, and
I’ve been finding a lot of errors and just sloppy things. The PDF file I
downloaded was generated March 2007, so presumably others have been through
this and noticed the problems. Has anyone listed them anywhere?
 
J

John B. Matthews

L

Lawrence D'Oliveiro

Here’s an example of what I mean, from section 5.1.10, pages 89-90:

5.1.10 Capture Conversion
Let G name a generic type declaration with n formal type parameters A1
... An with corresponding bounds U1 ... Un. There exists a capture
conversion from G<T1 ... Tn> to G<S1 ... Sn>, where, for 1 ≤ i ≤ n :
• If Ti is a wildcard type argument (§4.5.1) of the form ? then Si is a
fresh type variable whose upper bound is Ui[A1 := S1, ..., An := Sn]
and whose lower bound is the null type.
• If Ti is a wildcard type argument of the form ? extends Bi, then Si is
a fresh type variable whose upper bound is glb(Bi, Ui[A1 := S1, ...,
An := Sn]) and whose lower bound is the null type, where glb(V1,...
,Vm) is V1 & ... & Vm. It is a compile-time error if for any two
classes (not interfaces) Vi and Vj,Vi is not a subclass of Vj or vice
versa.
• If Ti is a wildcard type argument of the form ? super Bi, then Si is a
fresh type variable whose upper bound is Ui[A1 := S1, ..., An := Sn]
and whose lower bound is Bi.

In all those three cases, Si occurs in its own definition. How are you
supposed to make any sense of that circularity? It’s complete nonsense. The
only way I can understand it is if all those instances of “Ui[A1 := S1, ...,
An := Sn]†should actually be “Ui[A1 := T1, ..., An := Tn]â€.
 
L

Lawrence D'Oliveiro

Here’s another fun one.

In section 4.8, on page 58, it says:

The use of raw types is allowed only as a concession to compatibility of
legacy code. The use of raw types in code written after the introduction
of genericity into the Java programming language is strongly
discouraged. It is possible that future versions of the Java programming
language will disallow the use of raw types.

(That last sentence is in bold.) However, in the discussion on page 136:

Note that expression names may be qualified by type names, but not by
types in general. A consequence is that it is not possible to access a
class variable through a parameterized type
class Foo<T> {
public static int classVar = 42;
}
Foo<String>.classVar = 91; // illegal
Instead, one writes
Foo.classVar = 91;
This does not restrict the language in any meaningful way. Type
parameters may not be used in the types of static variables, and so the
actual parameters of a parameterized type can never influence the type
of a static variable. Therefore, no expressive power is lost.
Technically, the type name Foo above is a raw type, but this use of raw
types is harmless, and does not give rise to warnings.

So one the one hand raw types are deprecated, but on the other hand they are
the only permitted way to access static fields of a parameterized type.
 
L

Lew

Here’s an example of what I mean, from section 5.1.10, pages 89-90:

5.1.10 Capture Conversion
Let G name a generic type declaration with n formal type parameters A1
... An with corresponding bounds U1 ... Un. There exists a capture
conversion from G<T1 ... Tn> to G<S1 ... Sn>, where, for 1 ≤ i ≤ n :
• If Ti is a wildcard type argument (§4.5.1) of the form ? then Si is a
fresh type variable whose upper bound is Ui[A1 := S1, ..., An := Sn]
and whose lower bound is the null type.
• If Ti is a wildcard type argument of the form ? extends Bi, then Si is
a fresh type variable whose upper bound is glb(Bi, Ui[A1 := S1, ...,
An := Sn]) and whose lower bound is the null type, where glb(V1,...
,Vm) is V1& ...& Vm. It is a compile-time error if for any two
classes (not interfaces) Vi and Vj,Vi is not a subclass of Vj or vice
versa.
• If Ti is a wildcard type argument of the form ? super Bi, then Si is a
fresh type variable whose upper bound is Ui[A1 := S1, ..., An := Sn]
and whose lower bound is Bi.

In all those three cases, Si occurs in its own definition. How are you

No, it doesn't. In all those three cases, Si is defined. Each of those three
statements is a production of Si.
supposed to make any sense of that circularity? It’s complete nonsense. The
only way I can understand it is if all those instances of “Ui[A1 := S1, ...,
An := Sn]†should actually be “Ui[A1 := T1, ..., An := Tn]â€.

That would not be what they're trying to say. They're saying that, taking the
first one, the capture conversion is to a capture type Si with the upper bound
Ui, where the formal parameter Ai is substituted with the capture type Si. I
do agree that their notation is obfuscatory, but there's no typo there.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
L

Lew

Here’s another fun one.

In section 4.8, on page 58, it says:

The use of raw types is allowed only as a concession to compatibility of
legacy code. The use of raw types in code written after the introduction
of genericity into the Java programming language is strongly
discouraged. It is possible that future versions of the Java programming
language will disallow the use of raw types.

(That last sentence is in bold.) However, in the discussion on page 136:

Note that expression names may be qualified by type names, but not by
types in general. A consequence is that it is not possible to access a
class variable through a parameterized type
class Foo<T> {
public static int classVar = 42;
}
Foo<String>.classVar = 91; // illegal
Instead, one writes
Foo.classVar = 91;
This does not restrict the language in any meaningful way. Type
parameters may not be used in the types of static variables, and so the
actual parameters of a parameterized type can never influence the type
of a static variable. Therefore, no expressive power is lost.
Technically, the type name Foo above is a raw type, but this use of raw
types is harmless, and does not give rise to warnings.

So one the one hand raw types are deprecated, but on the other hand they are
the only permitted way to access static fields of a parameterized type.

That is neither an error nor a typo, nor sloppy, but a precise description of
the actual rules.

You may think the rules are screwy, but the JLS itself is not sloppy nor
erroneous there.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
J

Joshua Cranmer

Here’s another fun one.

In section 4.8, on page 58, it says:

The use of raw types is allowed only as a concession to compatibility of
legacy code. The use of raw types in code written after the introduction
of genericity into the Java programming language is strongly
discouraged. It is possible that future versions of the Java programming
language will disallow the use of raw types.

(That last sentence is in bold.) However, in the discussion on page 136:

Note that expression names may be qualified by type names, but not by
types in general.

I trimmed this down to the key sentence. The discussion notes that it's
a type name *and not a type* that defines the expression name. Raw types
are generic types that are not used in a generic manner, e.g., in class
instance creation expressions. I suspect this may have been done, in
part, to emphasize that Java's generics are not C++'s templates.
 
L

Lawrence D'Oliveiro

You may think the rules are screwy, but the JLS itself is not sloppy nor
erroneous there.

You don’t think it “sloppy†to have a technique recommended in one place and
deprecated in another part of the same spec?
 
L

Lawrence D'Oliveiro

* Section 4.5.1.1, page 55:

T <= ? extends T
T <= ? super T

One of these is the wrong way round.
 
L

Lawrence D'Oliveiro

* Section 3.1, Page 14:

For characters in the range U+0000 to U+FFFF, the values of [Unicode]
code points and UTF-16 code units are the same.

No they are not. U+D800 .. U+DFFF are not valid Unicode code points.
 
L

Lawrence D'Oliveiro

* Section 4.9, page 62:

• For each Ti, 1 ≤ i ≤ n , let Ci be the most specific class or array
type such that Ti <: Ci

Surely that type is Ti. Unless "specific†means something that hasn’t been
defined yet?
 
L

Lawrence D'Oliveiro

* Section 5.1.8, page 88: no mention of what happens when you unbox a NaN
(the previous page said only that the boxed object had isNaN() evaluating to
true, no mention of what floatValue() or doubleValue() might return).
 
L

Lew

You don’t think it “sloppy†to have a technique recommended in one place and
deprecated in another part of the same spec?

Where does that happen? You haven't cited any such thing and I don't know of
such a thing. In the particular case here, Joshua Cranmer has already shown
you where you went wrong. Don't you assimilate these responses, or are you
simply a troll?

The JLS is obfuscatory in parts, and a bit light in other parts. but I don't
agree that it's "sloppy". That is not to claim it cannot be improved, but
overall I find it precise and reliable.

Anyway, you started this thread with the claim that the JLS is riddled with
errors and typos. Now you're saying merely that it is "sloppy" (whatever that
means) in parts. Some of what you offer as evidence is not sloppy, but
difficult to understand and clearly you have not yet understood those parts.
While I see why they're difficult to understand, as they are for me and for
just about anyone, our lack of understanding is not equivalent to error or
typo in the JLS.

Try fixing your understanding instead of what isn't broken.

If your goal is rather to troll, and refuse to accept anything that folks are
telling you, I'm sorry to say you aren't being very notable. Trolls here set
a much higher standard. You'll have to step it up. Start attacking us
personally! Shift the ground of your discourse more. You're already on the
way with erroneous statements of fact ("Virtual methods started with C++") and
simple restatement of claims already refuted in the discussion. But that's
kid stuff. Bring it, dude!

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
L

Lew

Lawrence said:
* Section 4.5.1.1, page 55:

T<= ? extends T
T<= ? super T

One of these is the wrong way round.

Nope. Both are true.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
L

Lew

* Section 3.1, Page 14:

For characters in the range U+0000 to U+FFFF, the values of [Unicode]
code points and UTF-16 code units are the same.

No they are not. U+D800 .. U+DFFF are not valid Unicode code points.

It says, "for characters in the range". Those are not characters in the range.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
L

Lew

* Section 4.9, page 62:

• For each Ti, 1 ≤ i ≤ n , let Ci be the most specific class or array
type such that Ti<: Ci

Surely that type is Ti. Unless "specific†means something that hasn’t been
defined yet?

No, Ci can be a subtype of Ti. "More specific" means "descendant from".

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
L

Lew

* Section 5.1.8, page 88: no mention of what happens when you unbox a NaN
(the previous page said only that the boxed object had isNaN() evaluating to
true, no mention of what floatValue() or doubleValue() might return).

Nor is such a mention required, therefore its omission is not an error.
However, it's pretty clear that if 'isNan()' is true, then 'doubleValue()'
must return 'Double.NaN'. That's an API issue and not strictly something to
find in the JLS.

So far not one of the things you've cited as an error has actually been an
error in the JLS. There've been some things difficult to understand, and
you've made some errors, but none have actually come from the JLS.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top