Doug Dunn

I just dropped in to keep you busy...haven't researched this yet, but is there a servlet based certification that does not require presentation skills (i.e. AWT, Swing, JSP, and JSF)...just the core business stuff...servlets, JDBC, JNDI, EJB, authentication, persistence, etc.??? If not, what is your opinion on the subject?

Hi Bert,

Your private email box is full, so I will respond here.

The only editing I did of my posts at https://coderanch.com/forums/ were immediately after making them...no "dirty pool" just simple typos. Besides that, there's nothing wrong with Brett's book. I was just letting him know that his damning references to practically every other style of technical writing on the planet earth in the intro to his book were not appreciated. At least, I hope he got that message.

Regards,
Doug

Brett, I found this book useful in researching Java 1.5 release updates for Mastering the Fundamentals, and sincerely thank you for that. Congradulations on the ten horseshoe rating. I'm sure you guys will make a lot of money. -Doug

Okay this is beginning to sound like a "Doug Diatribe" so this will be my last post, but I did want to include the following quote:

"What about...

"...using a class to extend an enum, instead of another enum? That doesn't work either. There's just no getting around this limitation, at least that I've been able to find..[sic]"

A [sidebar] note also says "if you find a sneaky way to extend an enum, let us know! We'll add it to the next edition."

This entire three page discussion of "Manually Defining an Enum" is a complete waste. An enum cannot be extended. It is that simple. The reason why they cannot be extended is explained as follows in the FAQ section of the �A Typesafe Enum Facility for the Java Programming Language� document.

"The semantics of inheritance for enum types is too confusing. People expect subclasses to contain the enumeration constants from both the superclass and the subclass, but they contain only the subclass constants. Further, the compiler generates two static methods for each enum class providing operations on the entire class (values() and valueOf(String)). These methods are defined using the list of constants found in the enum declaration, hence subclassing would break them. More seriously, allowing subclassing of enums would render switch statements ambiguous if multiple subclasses of an enum class contained enum constants with the same simple name. All things considered, the complexity inherent in allowing subclassing is too great to justify it."

The significance of this is that it at least suggest the writer did not even read the available Sun documentation on the subject, relying instead entirely on David Flanagan's research notes.
[ September 01, 2004: Message edited by: Doug Dunn ]

I thought an example would help others to make up their mind. The writer actually recommends the use of switch statements to implement constant-specific behavour rather than the "constant-specific methods" recommended by Joshua Bloch in 1.5 Tiger release documentation. He completely misses the vital point that an enum will not compile unless all of the constants provide an overriding implementation of an abstract method. This effectively avoids the maintenance problem associated with comparable switch statements.

He reasons as follows.

"What about just using a more generic method that determines what to do based on a switch statement? Well, that's a better idea, to be honest. Here's the (much cleaner) way to write OpCode:

...[code example omitted]...

"This is so painfully simpler than the first version of OpCode that I hesitated to even include this lab-but [sic] for completeness, here it is. If at all possible, though, consider using switch in your method bodies to direct program flow, rather than [constant-specific methods]."

Essentially his argument is one of code aesthetics, which makes me wonder if he is even a programmer. Again, he completely misses the raison d'etre for this language feature and seriously misguides his readers.

And then there is the issue of style. I am so sick of reading "How do I do that?" and "What just happened" along with the author's generally condescending tone. For example, at the start of the above quoted section on what he likes to call "Value-Specific Class Bodies" (rather than using Bloch's name of "constant-specific methods"), the author concludes the introductory paragraph by saying: "This is a rather obscure bit of functionality, but sort of cool to talk about around the water cooler." There is nothing obscure about constant-specific methods; they are quite simply anonymous class bodies that implicity extend the enum type.

[ September 01, 2004: Message edited by: Doug Dunn ]

[ September 01, 2004: Message edited by: Doug Dunn ]

[ September 01, 2004: Message edited by: Doug Dunn ]
[ September 01, 2004: Message edited by: Doug Dunn ]

This is all the hype from the cover. A senior software engineer at Sun Mircosystems (and the author of a very popular book in The Java Series) once told me that technical writers should not bash their competition, but I am going to make an exception here because the Notebook series editor rather arrogantly attacks almost every other sytle of technical writing imaginable.

I paid $30 for this book and found it to be poorly written. It follows in the time-honored tradition of major publishers racing to be the first to market in order to profit from a new release. A quick internet search will save you the cost of this book.

I may be setting myself up for reprisal, but I just hate to see the Java book market abused like this. You work too hard for your money.
[ August 28, 2004: Message edited by: Doug Dunn ]

The standard idiom for looping through an array is as follows.
for(int x=0; x < b.length; x++) { b[x] = !b[x]; }
Do you see the difference? In this case, the length of the array is four, but the highest index value is three.

I had to come back one last time because of this: http://ivaturis.blogspot.com/. I was a little shocked when my reciprocal link software came across this web site. I see now it was Ivaturi Srinivas
who copied the answer. I think it was my mom who said never to write anything unless you wanted to see it on the front page of the New York Times the next morning. I guess she was right.
By the way, in my last response to this post I said that only the section on "enumerators" had to be changed in the second volume to make it "Java 1.5 Ready". I meant to say the section on "enumerated types." The Tiger release, however, is requiring huge changes in Volume 1 because of parameterized type.

Doug thinks so, too.

Meanwhile, I feel aweful that I assumed this was Sun exam question. I owe Sun Microsystems, Neal Gafter (who I misled into thinking this was a Sun exam question), and especially Evelyn Cartagena an apology.

And I thought I would escape my week at the ranch without being flamed . Look anyone who has read my work knows that I would never use someone else's material without proper credit. I received special permission to liberally quote from Sun material precisely because of the professional quality citations in my work. In this case, the idea needs to considerably broadened, so much so that I am sure I will address it in the chapter on type conversions with only a cross-reference in the section on inlined constants. Nevertheless, since I have received a private email requesting that I cite this material, as well as this public reminder, I will make a point of citing Dan Chisholm as the source of the idea. Chisholm certainly deserves credit because he is obviously making a huge contribution to Java or else his mock exams would not be so popular on this Web site. In fact, I will be asking him to consider a full technical review of Mastering the Fundamentals, in which case you will find his name plastered all over my book.

Marlene! Are picking apart Gafter's compiler because you don't like the line he chooses to say is missing the semicolon!? That's bizarre. I think he is doing you a favor saying that it is missing on line seven because that is where most people would code it. STOP THE PRESS...
Okay I couldn't believe that was your objection, and just went back and carefully reread your post. I see now it is the exam question you are objecting to. Yes, IT IS COMPLETELY ARBITRARY TO SAY THAT THE ERROR OCCURS ON LINE SEVEN BECAUSE JAVA IS A FREE FORMAT LANGUAGE. It is merely a matter of perspective and is equally valid to say (as you do) that the error occurs on line 8 when the next token arrives at the compiler and it becomes evident that the semicolon is missing.
The problem here is that the test exam writer is taking javac compiler errors as gospel, and that is a very dangerous thing to do. The JLS specifies compiler errors, not compiler error messages. Neil Gafter writes the javac compiler and has done a wonderful job making compiler error messages as helpful as possible. But in so doing, he introduces a measure of art. If the Sun test exam people do not understand this then they are indeed doing all of us a great disservice. I think you have hit the nail on the head with this example, Marlene. By the way, I was contacted by that Sun text exam manager and insisted she review your posts. I am going to make sure she sees this one by sending her the URL and saying that it is the quintessential example of what is gong wrong. On behalf of the millions of test exam takers around the world, HATS OFF TO MARLENE FOR STICKING TO HER GUNS. I feel confident in saying that Evelyn Cartagena will follow through on this, and not just this one example, but any notion the Neil's error messages are gospel in terms of what line an error occurs on.

Hi I came back one last time to make sure I didn't leave any mess behind, and I'm glad I did. I see now what is happening in this example, and why the fact the method or constructor parameters could never be inlined is significant. I can tell you I know some very smart programmers who have been compiling lists of the significance of inlined constants (or compile-time constant expressions) for years, and I have never seen this. I have such a list in my book in the section on inlined constants, and will add this example, or a comparable one. A nice parting gift for me (since no one else gave me anything )

I haven't taught a class in a long time, so this has been a fun distraction. This is a really great forum. The JavaRanch is very well run. I hope my answers have helped. Please tell your friends about Mastering the Fundamentals. I am averageing about 50 downloads a day now, but would like to see it up to around 200-300 before I go to print. I need all the technical feedback I can get, and letters of praise are always welcome.

The only section I know for sure that will have to be revised in Volume 2 for the Tiger release is the section on enumerators. Volume 2 is otherwise current as of the 1.4.2 release. Most of Toger affacts Volume 1, which is what is holding up the Second Edition.

I'm not sure what the practical significance of this is, but a method or constructor parameter--regardless of the fact that it is declared final-- could never be a "compile-time" constant expression for the simple reason that it is not initialized until run time when the method or constructor is invoked.