Why would a team of developers spend tens of thousands of dollars developing a service framework when inexpensive and robust application servers are readily available on the market.
(Thomas Paul - bartender, July 2001)
More info at Amazon.com
More info at Amazon.co.uk
More info at FatBrain.com
I came from C, C++ background, almost everyone I know who is learning Java now is complaining the lack of low-level detail books (besides JVM books). In C, and C++, almost every programmers will come face-to-face with the low-level process. Yet, in Java world, many of the programmers (without previous experience often don't understand the low-level details that they need to become a good programmer). Granted, Java is supposed to be high-level that allows programmers only worry about using the API to accomplish tasks they need.
I think this book really touches the Java programming at a low-level. I remember a conversation with my friend, who happens to be one of old developers working with WebLogic. I asked him about the servlet and JSP, his answer is this: "Everyone can become a Java programmer without knowing the details of the language, all he needs to know is the API to become a so-called Java programmer. If this trend continues, eventually, Java language itself will suffered. As companies want to build their own systems cannot found enought programmers that understand how low-level systems work, they will just move to a different language like C, C++. Companies need to justify the ROI (Return on Investment)"
We often take it for granted about server-based programming because so many app servers are out there. Yet a lot of times, those servers are expensive, and you only need partial functions of them. If you have a good team of programmers, then you can easily create your own server, it will better, cheaper, and customize to your company's needs.
This book won't teaches you all the knowledge you need, but it will definitely help to understand just how an application server works. And maybe, just maybe, you will write the next Weblogic, Tomcat.
There were things that annoyed me about this book. For example, the section on Threads was so basic as to be useless. Page 138 contains a misunderstanding about overriding private methods. In the middle of the Sockets chapter, he suddenly switches to a completely different set of classes from a different book (because he says they are better than his) without really explaining what they do or why they are better.
Also, there is a sense of the book being thrown together. The chapter on JNI seems pointless. The section on modeling business objects seems completely unneeded. It's as if the author thought he had some good articles and decided to throw them together into a stew.
A book should be judged by what it claims to do. It says that it will, "teach those concepts that underlie the J2EE API and the best way to use them." In fact, little is mentioned of the J2EE and its APIs. In fact, J2EE is mentioned twice, once under servlets and once in the epilogue.
Think of it this way, there really is nothing in this book where I could say that this book handles topic "x" better than any other book available. Although there were things in this book I didn't know, there is nothing in this book that I can point to and say that I am a better programmer for knowing something that I learned.
But I still gave this book 6 out 10 which is a pretty good review considering that very few developers will find much in here. As I said in my review, if you are interested in writing your own app server then this book may be of some value, otherwise I would pass on it.
In many cases it is much easier and more practical to make an application-specific server by starting from a very simple basic framework, rather than trying to deconstruct a complex, optimized, and potentially buggy implementation of a much larger and not quite applicable standard.
As a concrete example: for one customer, download size was of vital importance as they were deploying over slow modems to approximately 20,000 relatively low-spec mobile devices. They needed a simple on-board server to allow the devices' built-in web browser to be used to gather data off-line, and then batch transmit it to a central repository from time to time. It would have made no sense to try and shoehorn something like Tomcat, Resin or even the more flexible Jetty into this scenario (look at their download sizes some time), so I wrote a very simple but extendable HTTP 1.0 server which (including all the application-specific code) fitted in a jar of about 80kb. Although this was a browser/HTTP/HTML project, If I had only known about programming to J2EE APIs, I would not have been able to solve this problem.
In the real world there is always a niche for understanding complex things at different levels.
Originally posted by shailesh sonavadekar:
I think People like to write chat applications by themselves. Not for thesis , Tom. I disagree with you on this. Chat applications with limited features is one of the most popular application which java programmers aspire to write.
OK, if you say so. I doubt many programmers get paid to do that.