JLS 3/e -- Lots Of Errors

Discussion in 'Java' started by Lawrence D'Oliveiro, Feb 4, 2011.

  1. 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?
    Lawrence D'Oliveiro, Feb 4, 2011
    #1
    1. Advertising

  2. In article <iiflvc$keg$>,
    Lawrence D'Oliveiro <_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>
    John B. Matthews, Feb 4, 2011
    #2
    1. Advertising

  3. "John B. Matthews" <> wrote in message
    news:...
    > In article <iiflvc$keg$>,
    > Lawrence D'Oliveiro <_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.
    Mike Schilling, Feb 4, 2011
    #3
  4. 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]â€.
    Lawrence D'Oliveiro, Feb 4, 2011
    #4
  5. 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.
    Lawrence D'Oliveiro, Feb 5, 2011
    #5
  6. Lawrence D'Oliveiro

    Lew Guest

    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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #6
  7. Lawrence D'Oliveiro

    Lew Guest

    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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #7
  8. 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
    Joshua Cranmer, Feb 5, 2011
    #8
  9. In message <iiimec$dh1$-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.
    Lawrence D'Oliveiro, Feb 5, 2011
    #9
  10. In message <iiilep$spb$>, 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?
    Lawrence D'Oliveiro, Feb 5, 2011
    #10
  11. * Section 4.5.1.1, page 55:

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

    One of these is the wrong way round.
    Lawrence D'Oliveiro, Feb 5, 2011
    #11
  12. * 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.
    Lawrence D'Oliveiro, Feb 5, 2011
    #12
  13. * 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?
    Lawrence D'Oliveiro, Feb 5, 2011
    #13
  14. * 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).
    Lawrence D'Oliveiro, Feb 5, 2011
    #14
  15. Lawrence D'Oliveiro

    Lew Guest

    On 02/05/2011 01:42 AM, Lawrence D'Oliveiro wrote:
    > In message<iiilep$spb$>, 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?


    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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #15
  16. Lawrence D'Oliveiro

    Lew Guest

    Lawrence D'Oliveiro wrote:
    > * 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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #16
  17. Lawrence D'Oliveiro

    Lew Guest

    On 02/05/2011 07:30 AM, Lawrence D'Oliveiro wrote:
    > * 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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #17
  18. Lawrence D'Oliveiro

    Lew Guest

    On 02/05/2011 07:31 AM, Lawrence D'Oliveiro wrote:
    > * 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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #18
  19. Lawrence D'Oliveiro

    Lew Guest

    On 02/05/2011 07:32 AM, Lawrence D'Oliveiro wrote:
    > * 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|
    |_____|_____|
    |===========|
    Lew, Feb 5, 2011
    #19
  20. On 02/05/2011 01:41 AM, Lawrence D'Oliveiro wrote:
    > In message<iiimec$dh1$-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.


    A type *name* is not a *type*.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Feb 5, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Schilling
    Replies:
    10
    Views:
    705
    Mike Schilling
    Sep 29, 2003
  2. VisionSet

    JCert & JLS gotcha

    VisionSet, Oct 6, 2003, in forum: Java
    Replies:
    0
    Views:
    343
    VisionSet
    Oct 6, 2003
  3. Mike Schilling

    JLS 3 Errata

    Mike Schilling, Oct 2, 2005, in forum: Java
    Replies:
    3
    Views:
    446
    Mike Schilling
    Oct 2, 2005
  4. brad
    Replies:
    9
    Views:
    354
    Bruno Desthuilliers
    Jun 19, 2008
  5. coolneo
    Replies:
    9
    Views:
    178
    coolneo
    Jan 30, 2007
Loading...

Share This Page