Effective Java

benjiboo writes "From the back page: 'Are you looking for a concise book packed with insight and wisdom not found elsewhere? Do you want to gain a deeper understanding of the Java programming language? Do you want to write code that is clear, correct and reusable?' I did, so I bought the book and decided to use it for my first review :)" Read on for bejiboo's review of Effective Java.

Effective Java Programming Language Guide
author	Joshua Bloch
pages	252
publisher	Addison Wesley
rating	8/10
reviewer	Ben
ISBN	0201310058
summary	57 pieces of Java wisdom.

Introduction

Effective Java is a book very much in the style of Scott Myers' earlier C++ "Effective" series. The book contains 57 individual snippets of Java wisdom, broadly categorised into 10 sections including Classes and Interfaces, Exceptions, Threads and Serialisation. Scott Myers' books are classics; I was interested to see how this would compare.

The author, Joshua Bloch, has been involved in writing many industrial-strength Java libraries. His background is very much evident, in this, his first text. He consistently demonstrates the virtues of favouring libraries, clean APIs and advance design. I found the author very readable, and able to make a convincing argument, even in his more 'controversial' pieces. As with Scott Myers' books, there is a real-world, rather than purist approach taken to the language, with most of the code examples having a real-world feel to them. This is a breath of fresh air when lots of programming books tend to use more contrived examples.

The items

The author has endeavoured to keep the book accessible to less-experienced programmers throughout, while providing food for thought for the more advanced reader. For the most part this is succesful, but a small percentage of articles tend toward the simple side. Examples include 'Minimise the accessibility of classes and embers,' 'Write doc comments for all exposed API elements,' and 'Know and use the libraries.' We've all heard this advice many times and I don't feel that these add value. The vast majority however, are pitched at the right difficulty level. The selection of items is well balanced and broad, although unfortunately there are none pertinent to GUI programming.

Many of the articles are fundamentally based on known design patterns and idioms. Although a useful index to these patterns is included, I would have liked to see the virtues of design patterns summarised and demonstrated to a greater extent, perhaps in the introduction.

I was highly impressed with all code examples. Where used, they are consistently short, relevant and concise, with more verbose examples included on the website. The chosen code examples only ever assist in explaining complex concepts clearly.

The strongest area of the book for me was the section on threading. The author clearly demonstrates, for instance, how overuse of synchronised methods can lead to deadlock. He also provides food for thought on how the thread scheduler might trip us up. A section on moving from C constructs, which initially struck me as an odd category, proved very interesting and thorough. 'Replace enum constructs with classes' is a particularly interesting item, demonstrating the fragility of C enums, and indicating why the often-used replacement in Java (a bunch of public static constants) suffers from the same failings.

In conclusion

Ideally I would have liked to see some of the thinner items removed, and perhaps replaced with a section on the GUI libraries. I also liked the short prose sections, and thought the author could have spent more time setting out his stall before launching in to the items. Having said this, this is one of those rare books which could help a good programmer become an excellent one. Many of the books currently out there are aimed at either the beginner or the guru, and this book fills a gap.

I find this style of book very useful, in that I could foresee meeting the vast majority of the described situations at some point or another. So long as you aren't looking for tips to help you with your GUIs, this title is more than worth the investment.

For anyone interested, those sections in full:

• creating and destroying objects
• methods common to all objects
• classes and interfaces
• substitutes for C constructs
• methods
• general programming
• exceptions
• threads
• serialisation

---

You can purchase Effective Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Re:From the people who brought you:

[blinder]

having developed many effective applications for a few years using java, i can, with confidence respond that "Effective Java" is not a contradiction. i've found that most "java haters" are those whose experience goes no further than the applet. too bad sun ever conceived of that little painful abomination.

java is like any other language, its a tool to get your job done, and contrary to popular belief, it gets it done rather nicely.

of course i don't mean to wax religious here... there's enough of that here.

Re:Practical Applications

[dissonant7]

In a Windows dominated enviorment, is there any other better alternative to what I am already using?

The abortion that is .NET seems to work alot better than the hideous quivering zygote that is VB6, IMHO. In particular C#.

Really, I would say that it depends on the environment. If the back end is Oracle or DB2, I'd probably go with Java; if it's SQL Server I'd be more inclined to go with .NET. I'd also go with Java if your IT department had any plans to change platforms in the future. .NET and company allow MS to keep a string tied to your IT decisions unless you're willing to abandon your code.

Re:Advice: Stick with a real OO language

[Anonymous Coward]

Yes, yes, well said. Unfortunately not many people will PAY ME to code in Smalltalk these days! Times are tough, man, and you still have to eat. Even if I did make an effort to learn a subpop language for career purposes, I'd ultimately have to spend lots of time justifying it and marketing it to employers and customers. Ok, granted, there would probably be fewer people competing for these jobs, but that's a risk that few are willing to take.

Java and C++ are popular because they're popular. Managers are often idiots, but most are smart enough to know that when you leave they'll have to find a replacement with your skills. There are lots of Java/C++ people out there, lots of books, lots of classes. Smalltalk, not so much...

And yes, I agree, BeOS and Betamax were better, but don't forget...there's a REAL WORLD out there!

Re:Advice: Stick with a real OO language

[FiskeBoller]

Java is slow, as annoying to program as Microsoft's C# language, and just plain impractical.

Java is slow? Maybe that's just your coding. These guys (among others) don't agree with you...

http://www.sosnoski.com/Java/Compare.html
http://www.javagrande.org/jgsc98/index.html

IBM has achieved 90% the speed of C in Java. I personally use the CERN numerical libraries ... very cool, very fast. Java certainly can be fast. I've seen distributed Java beat C++ implementations hands down (that was hard to everyone to believe ... problem was C++ CORBA marshalling and the RTTI overhead in C++).

I've used Squeak, and have a background in coding Smalltalk (Digitalk, ParcPlace, IBM VA). Squeak is a great up-and-coming environment, but FAR from commercial. Can you name one commercial implementation in Squeak?

I think that lack of commercial viability makes Squeak impractical. Java, on the other hand, has scads of drop-in commercial libraries and components. This makes economic sense in business. Java also has a proven track record on the server side, and there are many, many successful commercial implementations in mission critical environments.

And NO, I don't think Java is the perfect enviroment; far from it. I've yet to see my ideal language, and I keep looking on the horizon for a dynamic functional/object/aspect language that performs and holds up in a commercial setting. In the meantime, I've got real work to do.

Re:An intelligent reply? What gives??

[MojoMonkey]

whenYouCan(keepReferencingYourObjects)->LikeThis An d(you->use)->VerboseVariableNames(then, line(breaks,can->be))->Few(andFarBetween);


Actually, it should be:

whenYouCan(keepReferencingYourObjects).LikeThisA n d(you.use).VerboseVariableNames(then, line(breaks,can.be)).Few(andFarBetween);

remember, no pointers... *wink, wink*

Anyways, I have yet to see anything that bad (I know you were making a point), nor have I seen anything similar that can't be fitted within 80 columns on 2 lines. You can't seriously tell me you have never seen a C/C++ line that long. You can always write horrible code no matter the language, blaming it on the language itself is just an excuse.

What are your reasons for preferring C++ (or even C#) over Java? Speed, standards-compliance, readability, lower memory usage, saner language constructs, not controlled by Sun?

Speed - used to be, IBM is doing some amazing things with their JIT compilers. I think someone else mentioned they were getting 90% of native code. So this is no longer an issue for me. I've even writing some fairly advanced 3D apps using GL4Java.

Standards-compliance - well... not sure what to say here. There's not ASCI Java if that's what you mean. Never been much of an issue for me.

Readability - as I have been arguing above, I prefer Java's... just me I guess?

Lower Memory Usage - For sure! Java's memory footprint is horrible. Price you pay for a virtual machine. I do hate this.

Saner Language Constructs - see Readability.

Not Controlled By Sun - someone has to control it, I'd say they are doing a decent job of maintaining the API. They also seem to do a fine job of listening to the needs of the users. I think sun does a fine job with the API itself, they need to improve their application of it (Sun's JVM pretty bad, etc).

My main reasons for preferring C++...
- lower level, like the control I think.
- Sun's Swing and AWT API's suck IMHO.
- Java is very large API, I get a bit overwhealmed at times.

question for all you Java experts

[pb]

I'm not a big fan of Java, but I was impressed by everything that has been said here about how much Java has matured, so I figured I'd put it to the test.

I dug up some old benchmarks (the BYTEmarks, which includes a jBYTEmark, normalized to that same P90) that I can use to fairly compare Java and C performance.

I've got a 1.2Ghz Duron, and the C version of the BYTEmarks seems to reflect this accurately--with scores of 26.6 Integer and 21.4 FP, with a P90 being 1.00.

I'm comparing this against two separate Java implementations--Sun's JVM for Linux, and gcj (I also tried out a program that translates Java bytecodes to C, but the resultant executable didn't perform correctly). Here's a table of results:

C Bytemark: INT: 26.6 FP: 21.4
SUN (--server) INT: 4.21 FP: 1.80
GCJ INT: 3.63 FP: 1.71
SUN (Default) INT: 2.18 FP: 2.14

Now, I'm not surprised that the C version ran so fast, but I am surprised the the Java benchmarks did so badly, considering that both benchmarks were normalized to an index of 1.0 for the same Pentium 90! Maybe I got a bad copy of the jBytemarks--it was hard to find a copy at all--but it looks pretty legit.

Do any of you Java people have some amazing tips for me? I did use all the optimization flags I could find. Or is this typical performance for Java, making a 1.2Ghz Duron run as slow as a P200 or a K6/300?