This is the second part of brief summary and description raised by Bruce Tate's book Beyond Java. The first part is available here and seemed to ruffle a few feathers. Since that time, I've finished the book and plan to pass it along to a few other people from whom I'd like to hear some thoughts.
First, let me lay out my Java background. I have about five years of Java experience now. I think I timed it well as I joined the movement about the time Ant and Tomcat were catching the hearts and minds of many Java developers. I have since picked up Maven, Struts, and wading through the fun that is Hibernate and Spring.
In terms of length, I thought the book was very solid. Bruce spent a huge amount of time describing how and why Java became so popular. The summary of which is simple: Java solved many of the pains of the C++ community in a way which was familiar and powerful without being scary. He also posits that the biggest single strength of Java may not be in the language itself, but the JVM. I think I agree with this one. Sun – and the smart people around them – did something fantastic in pushing forward the idea of WORA. Sure, it's not perfect, but it set the standard incredibly high for future competition. I'm not doing justice to Bruce's explanations here, but you get the idea.
Next, Bruce goes into great detail on the weaknesses of Java. Although there are a handful of fundamental problems which he lays out, the bulk of them get into the complexity and “features” which have been added to the language in recent years. The plethora of frameworks and infrastructure required in just about any projects is making it downright painful to do much in some areas. Sure, you can embed Java into your jsp's, but you will get your hand slapped as a result. Second, the checklist of “features” that are making it into the language.
Here's an experiment that I've seen and have been dying to try myself: Find a Junior Java Developer and try to integrate them into your team, and ask yourself these questions:
How much time do they spend learning the tools?
How much time do they spend learning about your project?
Yes, all the time spent learning the tools is important and investment in future projects, efforts, etc. But how long does it take for them to be productive on *your* project? For a long time, I've taken the stance that new team members should begin their contribution by writing Unit Tests. I always considered the benefits to the team member in terms of moral and the benefits to the team in terms of evaluation and testing coverage… I never considered what actually caused this scenario.
Finally, Bruce analyzes a few of the alternatives. Some – like Smalltalk, .Net, and Lisp – he discards immediately for a variety of reasons. Others – like PHP, Python, and Perl – he goes into a bit more detail about and where they fail to fit the bill. Then he goes into Ruby. He's a Ruby convert for a variety of reasons, but he makes a point of applying the same standards and requirements that he laid out early on. Ruby – especially with Rails – fits many of the requirements but still fails on a few. All in all, I think he gave them fair treatment, even if you don't agree with him.
In summary, if you're a Java developer, I think you need to read this book. If you're not a Java developer but you want to learn about what features the next languages will have, I think you need to read this book. Coming from either direction, it gives a great chronology on the success of Java, why it got there, and where its weaknesses are. Even if you don't care, your boss will… either today or a couple years from now.