Adam Barr said:
For a book I am working on, I have written a brief (11 page) summary
of Java. The intent of this is that an experienced programmer who did
not know Java would be able to get enough information to read and
understand Java programs (assuming they also read the documentation of
specific classes used). It is not meant to be a 100% complete summary
of the language, but everything in there should be correct.
If anyone is interested, please feel free to read it and send me
comments (or post here). Note that the material is copyrighted, this
document is provided for review only, and the ideas contained in any
comments may be used in the book, in whole or in part, with no rights
granted to the person who provided the comments. I will however
acknowledge by name (if desired) anyone who sends comments.
The information is in PDF form per my publisher's request, but if this
is a problem for anyone, email me and I can send it to you in plain
text.
The file is at
http://www.proudlyserving.com/language/java.pdf
As you may have noticed if you read other language newsgroups, I have
written similar summaries for other languages and have or will posted
about them.
Thank you.
- Adam Barr
(e-mail address removed)
Overall, looks good.
Some comments seem a bit flaky, and thus, if I were reading this to learn
something, and I read something that I knew about that gave me the flaky
feeling, I might not trust some of the other things that I still haven't
learnt about (if you know what I mean).
Some of the comments appear to be a little bit misleading or possible
ambiguous,
The ones worth noting:
1.
"Beyond the basic types [these are usually referred to as "primtive types"]
everything in Java is stored in objects. An object is a grouping of
variables and methods ..."
would be better written as:
"Beyond the 8 primitive types, every other type in Java is declared as a
class. A class is a grouping of variables, methods, constructors,
initialisers, and inner classes"
2.
I also believe that referencing classes without context, should be fully
qualified (at least once in the context) to prevent ambiguity:
"One such class is String"
would be better written as:
"One such class is java.lang.String"
3.
"How many parameters a constructor takes, and what types those parameters
are, is part of the class definition"
Incorrect.
"How many parameters a constructor takes, what types those parameters are,
AND THE ORDER of those parameters, is part of the constructor signature
[also applies to method signatures]"
4.
Spelling error:
"A String cannot be changed one initialized"
"A String cannot be changed once initialized"
5.
"When Java sees a string [should be capitalised for consistency and
correctness] in double quotes, it automatically converts it to a String
object ... The automatic creation of an object from a constant is unique
...."
"When Java sees a String literal (an expression in double quotes), it
automatically converts it to a String object ... The automatic creation of
an object from a String literal is unique ..."
It is also important to recognise that there are other literal expressions,
just none of them represent an object (the rest are primitive).
6.
On the issue of the java.lang.String(java.lang.String) constructor, is might
be wise to mention how literals are handled and why you might want to use
this constructor to prevent "interning" (a perfect example of "flakiness" -
does the author understand how String literals are handled ?)
7.
"objects are destroyed after the last reference to them is removed"
A common fallacy resulting in many painstaking hours of debugging.
"objects are destroyed when the garbage collector runs. The object must be
in an Unreachable [this is NOT the same as having no valid references] state
in order to be eligible for collection."
Further information:
http://java.sun.com/developer/Books/performance/performance2/appendixa.pdf
9.
import java.lang.*;
is implicit (Java 2 Language Specification) and is quite ugly, since it
indicates a lack of understanding of this fact.
Perhaps use another example from another package ?
10.
"Arrays can also be created at declaration time, if values are specified"
can be clarified with:
"Arrays can also be created at declaration time, if values are specified
using an array initializer"
11.
"Any Java program requires that the author define at least one class."
incorrect/ambiguous
First define a "program".
If you mean, any compilable unit, then you don't even need a class - a blank
file will compile.
If you mean, any application that will run through the JVM, then you need to
"define at least one class with a public static void
main(java.lang.String[]) method"
12.
Grammatical.
"A subclass inherits all the state and behavior of the its superclass"
"A subclass inherits all the state and behavior of its superclass"
13.
"... can override variables and methods ..."
incorrect. A class data member (referred to here as "variable") can NOT be
overridden.
Because of this, it is perfectly valid to declare a variable with the same
name in a subclass, even if the superclass declares it as final (which
contradicts the next statement).
14.
"Actually, to be more precise, subclasses can only access a protected ..."
Huh ? This statement appears to be redundant with the previous one (it is
not more precise, it is just misleading) and ambiguous - what exactly are
you getting at ?
15.
"Class variables and class methods exist just once"
Technically, this is incorrect. But given the context (discussing the
meaning of the static keyword), it may be forgiven, but I think it may be
misleading. But even more technically (if you want to get nitty-gritty), it
is still incorrect.
Better written as:
"static Class variables, methods, initializers, and inner classes exist just
once per class loader [not per VM as some might suspect]"
16.
"An interface is like an abstract class, except it can't implement any of
its methods"
Huh ? Very misleading. Perhaps you mean:
"An interface is like an abstract class, except all methods are pure virtual
[I use this term since there is contrasting to C++], where an abstract class
defines none, some or all methods as pure virtual"
17.
"classes can implement as many interfaces as they like, as long as they
provide implementations of the methods"
Very misleading.
"non-abstract classes [or concrete classes depending on preferred
terminology] can implement as many interface as they like, as long as they
provide implementations of all implemented interface methods."
18.
Declaring to catch ArrayIndexOutOfBoundsException is poor form. You might
want to distinguish the three types of Throwables; checked exceptions,
unchecked exceptions, and errors. You could then go on to say that declaring
to catch unchecked exceptions is generally bad practice and change your
example to use a checked exception. Declaring to catch unchecked exceptions
can sometimes be justified, but the example given can never be justified
(catching ArrayIndexOutOfBoundsException can never be justified).
19.
The whole "exceptions" paragraph(s) leads me to speculate if the author
understands the Java exception handling mechanism, since there is no
distinction made between checked and unchecked exceptions. This is
fundamental knowledge (rather than a technical intricacy) that really should
be covered.
If you have any further queries, please feel free to contact me personally:
(e-mail address removed)
--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform
