New O'Reilly Java Enterprise Best Practices

by Steve Anglin

Related link: http://www.oreilly.com/catalog/javaebp/



Java developers typically go through four "stages" in mastering Java. In the first stage, they learn the language itself. In the second stage, they study the APIs. In the third stage, they become proficient in the environment. It is in the fourth stage --"the expert stage"-- where things really get interesting, and Java Enterprise Best Practices is the tangible compendium of experience that developers need to breeze through this fourth and final stage of Enterprise Java mastery.



Crammed with tips and tricks, Java Enterprise Best Practices distills years of solid experience from eleven experts in the J2EE environment into a practical, to-the-point guide to J2EE.



Java Enterprise Best Practices gives developers the unvarnished, expert-tested advice that the manual pages don't provide--what areas of the APIs should be used frequently (and which are better avoided); elegant solutions to problems you face that other developers have already discovered; what things you should always do, what things you should consider doing, and what things you should never do--even if the documentation says it's ok.



Until Java Enterprise Best Practices, Java developers in the fourth stage of mastery relied on the advice of a loose-knit community of fellow developers, time-consuming online searches for examples or suggestions for the immediate problem they faced, and tedious trial-and-error. But Java has grown to include a huge number of APIs, classes, and methods. Now it is simply too large for even the most intrepid developer to know it all. The need for a written compendium of J2EE Best Practices has never been greater.



Java Enterprise Best Practices focuses on the Java 2 Enterprise Edition (J2EE) APIs. The J2EE APIs include such alphabet soup acronyms as EJB, JDBC, RMI, XML, and JMX. Java Enterprise Best Practices is a companion title to Java Best Practices, which covers the Java 2 Standard Edition (J2SE) APIs, such as Swing, the collections classes, performance tuning, and NIO.



As a Java developer myself, I would like to see more best practices books. I can envision a need for wireless Java and Java Web services best practices. In general, I see a need for Web services best practices as the need for Web services design patterns and more will become evident. What do you think?



What do you think of best practices books in general?


5 Comments

tpherndon
2002-12-18 12:29:26
"Best Practices" series
I think that "Best Practices" would make an EXCELLENT series for O'Reilly, and should not be limited to Java. Instead, I can see an amazing sell point for similar titles in equally large and advanced areas as Oracle development and dba, Unix administration, and Windows administration. In fact, I think such titles are appropriate wherever and whenever an area of focus becomes mature enough to develop such a community of advanced users and advanced projects. The "Cookbook" idea is similar in concept, but seems to be a bit more limited, in that it provides recipes for common idioms in the language/platform/whatever, but doesn't really address the larger scope and scale that a "Best Practices" series should probably address. I, for one, would absolutely LOVE to see a "Best Practices" book for Python, my language of choice.


What do you think?

chrisrimmer
2002-12-19 02:36:31
"Best Practices" series
There is already an Oracle PL/SQL Best Practices Book...
tpherndon
2002-12-19 15:25:14
"Best Practices" series
Um, I'd forgotten that one. Well, not having read the book, I can not say definitively, but from the title I'd bet it doesn't cover the dba arena, and probably doesn't cover Java, etc. And that doesn't mean that there aren't books that cover those areas, because there certainly are. But I think my main quibble is that so many technical books cover HOW without covering WHY, and also what would be the _recommended_ ways to do it.
mentata
2002-12-20 11:34:56
alternative servlet framework speaking
As the creator of a servlet framework
( http://www.mentata.com/ldaphttp/ )
which is not represented, I feel I should address the criteria for a good framework listed in the first excerpt.


Integration with a template language or IDE are means to support/enforcement of designer/developer separation, so the three criteria should be one. I agree in the need for separation, and plan to address that with JSP later this year (despite all the bad press it gets). I'm working back end first; my framework doesn't preclude the use of a template language, IDE, or whatever, but minimizing dependencies and allowing options is an important goal of the effort. I personally eschew IDEs.


Form validation is dependent on application layer behavior, so a framework should not necessarily be responsible for this.


Web services are still maturing. In the meantime, I will prefer to support XML with a public DTD over the alphabet soup currently delivered by proprietary vehicles like WS-I.


Using directory databases as part of my framework, I get lots of easy wins in security, persistence, and internationalization. There's also additional security measures and lots of error handling in my code. Best of all, I'm small with room to grow: the framework and gateway application are delivered in a jar that's less then 85K. I'd add a criteria for footprint, myself.


Overall, the book looks like a great idea. I enjoyed the excerpt; if this is how I can get feedback from this corner of the open source community, so be it. However, this is the kind of thinking that can get outdated quickly after it's voiced so it may not pay as handsomely to put it in print. As a longtime perl programmer I know: there's always more than one way to do it.


As a final note, I was already planning a blog example, so I may participate in WAFER, though perhaps on my own terms.

mentata
2002-12-26 15:02:59
..... and wanting this book
Excerpt 2 has me sold. Jason Hunter once again takes me to school on servlets. I will buy this book. Thanks O'Reilly for producing it.