Path: csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!goblin3!goblin.stu.neva.ru!exi-transit.telstra.net!pit-in1.telstra.net!news.telstra.net!newsfeeds.ihug.co.nz!lust.ihug.co.nz!ihug.co.nz!not-for-mail From: Lawrence D'Oliveiro Newsgroups: comp.lang.java.programmer Subject: Re: JLS 3/e -- Lots Of Errors Followup-To: comp.lang.java.programmer Date: Mon, 07 Feb 2011 13:02:27 +1300 Organization: Geek Central Lines: 30 Message-ID: References: NNTP-Posting-Host: 118-92-86-70.dsl.dyn.ihug.co.nz Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: lust.ihug.co.nz 1297036947 4025 118.92.86.70 (7 Feb 2011 00:02:27 GMT) X-Complaints-To: abuse@ihug.co.nz NNTP-Posting-Date: Mon, 7 Feb 2011 00:02:27 +0000 (UTC) User-Agent: KNode/4.4.7 Xref: csiph.com comp.lang.java.programmer:26209 There are several constructs and terms that are used before they are defined, without any reference to where the definition may be found. For example, “strictfp” is first used in section 5.1.2, page 81, with no reference to where it is defined. The “<:” operator first occurs in section 4.5, page 51. There is no hint as to what it means until you get to page 55. Section 4, page 34: Type arguments and type variables (§4.4) are not reified at run-time. But reification is not explained until section 4.7, page 56. Section 4.3.2, page 48: The type of a method invocation e.getClass(), where the expression e has the static type T, is Class. The |T| notation is not explained until section 4.6, page 56, where it turns out it denotes erasure. Section 6.3.1, page 119: “type-import-on-demand” and “static-import-on- demand” are not defined yet. No hint is given until page 127 that “static- import-on-demand” is defined in §7.5.4. Similarly no reference for “type- import-on-demand” is given until page 130, where it seems it comes from §7.5.2. It should be the job of an editor to catch this sort of thing.