Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > JLS 3/e -- Lots Of Errors

Reply
Thread Tools

JLS 3/e -- Lots Of Errors

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-04-2011
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?
 
Reply With Quote
 
 
 
 
John B. Matthews
Guest
Posts: n/a
 
      02-04-2011
In article <iiflvc$keg$(E-Mail Removed)>,
Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:

> 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?


The authors welcome errata:

<http://java.sun.com/docs/books/jls/>

Here are some updates:

<http://java.sun.com/docs/books/jls/updates.jsp>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      02-04-2011


"John B. Matthews" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <iiflvc$keg$(E-Mail Removed)>,
> Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:
>
>> 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?

>
> The authors welcome errata:


Which is why they created so many of them.


 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-04-2011
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]”.

 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-05-2011
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.

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-05-2011
On 02/04/2011 05:33 PM, Lawrence D'Oliveiro wrote:
> 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|
|_____|_____|
|===========|
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-05-2011
On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
> 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|
|_____|_____|
|===========|
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      02-05-2011
On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
> 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.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-05-2011
In message <iiimec$dh1$(E-Mail Removed)-september.org>, Joshua Cranmer wrote:

> On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
>
>> 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:
>>
>> Technically, the type name Foo above is a raw type ...

>
> I trimmed this down to the key sentence.


So did I. Try again.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-05-2011
In message <iiilep$spb$(E-Mail Removed)>, Lew wrote:

> 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for lots of words in lots of files brad Python 9 06-19-2008 07:59 AM
Downloading lots and lots and lots of files coolneo Perl Misc 9 01-30-2007 02:34 PM
JLS 3 Errata Mike Schilling Java 3 10-02-2005 06:54 AM
JCert & JLS gotcha VisionSet Java 0 10-06-2003 02:13 PM
JavaC and Jikes both violate JLS calling super of inner class Mike Schilling Java 10 09-29-2003 04:49 PM



Advertisments