Discussions

News: Book: Murach's Java Servlets and JSP (2nd Edition)

  1. Murach has published "Murach's Java Servlets and JSP, Second Edition." This is a book aimed squarely at core skills with the two most commonly-used APIs in the Java enterprise space, and ... wow, do they cover them. Murach says they have a unique approach to books. Instead of hiring freelancers, Murach has a set of programmers that focus on using the technologies being written on, which allows them to go very much in-depth into a given subject, as well as maintaining a lot of consistency across books. This book covers a ton of things. In fact, if it has to do with the core servlet or JSP specifications, it's hard to find things it doesn't cover in some depth - surprisingly, JNDI is the prime example of a core API not addressed very well. The subjects addressed are, in no particular order: servlets, filters, context listeners, JSP, tag libraries, MVC, sending emails, SSL, the ins and outs of HTTP and HTML, and others. The book uses an instructor's approach to the subject, and is very simple - it's hard to imagine someone reading this book and having trouble with it. The code supplied is extremely thorough and complete, and the authors (Joel Murach and Andrea Steelman) take a lot of trouble to make sure subjects are introduced slowly. The book is written with a solution-based approach, so chapters are titled "how to work with sessions and cookies," for example, as seen in the online table of contents. This makes the book appropriate as a reference as well as a tutorial, because if you're trying to remember the vagaries of form-based authentication, you can always zero in on "How to restrict access to a web resource" and find a detailed reference. Two sample chapters - the introduction and the fifth chapter, "How to develop JavaServer Pages," are available with email registration. The second sample chapter is a good example of what makes the book very strong. It's not often that you need this kind of (occasionally excruciating) detail about a specification, but if you were to need detail, this book has it. (Plus, it's organized well enough that you can skim the bits you don't need quite so much.) The coverage is really impressive, exploring the nooks and crannies of the APIs in great detail - if the book doesn't address a feature in the core APIs, chances are that the feature is so obscure that few even remember it's there. (The primary exception that jumped out at the reviewer: internationalization. The book makes one reference to it, and that's pretty much it.) The primary criticisms of the book lie in how difficult the subject area is. Servlets and JSP are just too broad for a book of only 730 pages! The book focuses on Tomcat and MySQL, hardly bad choices - but the focus on these two technologies means that with the authors' approach to thoroughness, you end up with a lot of Tomcat specifics (configuring realms, data sources, etc.) or MySQL information, when you might be interested in another application platform, or - horrors - a different database. JPA isn't mentioned, nor is JSF, despite these being core parts of Java EE. In fact, a lot isn't mentioned - even the chapter on MVC ignores technology that isn't directly part of the Servlet or JSP apis. No Struts (1 or 2), no Spring, no Wicket, nothing unless it's in the core Servlet or JSP specifications. Even some ideas that are present - like resource injection - are skipped over, but it's not clear if resource injection is all that common yet, and anecdotal studies certainly show that the finer uses of JNDI aren't all that common. This isn't really so bad, except that it's hard to imagine writing an application such as the (complete, working, fully documented, and useful) sample applications provided in the book without using ... something. Based on the book's information, one wouldn't know that Struts existed, although one could see the conditions under which Struts would be created. This book really is quite impressive - the primary complaints about it, if there were any, would be its lack of mention of ancillary libraries like Struts, Spring, et al., and its non-use (or underuse) of Java EE concepts like resource injection and JNDI. JNDI is probably the most worrisome, as the example web applications don't even use in the web.xml. As far as the environments go, the most common deployment environment for Java applications seems to be Tomcat with MySQL, so the focus on these two products hardly seems out of place. The authors take great pains to make sure that every question that could be raised based on their instructions have answers. Excellent book. It has a $52.50 USD list price, and should be available through many channels.

    Threaded Messages (29)

  2. We shouldn't be teaching people how to write crap like this... <% // get parameters from the request String firstName = request.getParameter("firstName"); String lastName = request.getParameter("lastName"); String emailAddress = request.getParameter("emailAddress"); // get the real path for the EmailList.txt file ServletContext sc = this.getServletContext(); String path = sc.getRealPath("/WEB-INF/EmailList.txt"); // use regular Java objects User user = new User(firstName, lastName, emailAddress); UserIO.add(user, path); %>
  3. We shouldn't be teaching people how to write crap like this... <% // get parameters from the request String firstName = request.getParameter("firstName"); String lastName = request.getParameter("lastName"); String emailAddress = request.getParameter("emailAddress"); // get the real path for the EmailList.txt file ServletContext sc = this.getServletContext(); String path = sc.getRealPath("/WEB-INF/EmailList.txt"); // use regular Java objects User user = new User(firstName, lastName, emailAddress); UserIO.add(user, path); %>
    That's fair to say, but I respectfully disagree. In context of what they're trying to show in that example, they're exactly right. At that point of the book, they've not gone into MVC, so if you're going to do things in JSP, this is how you do it. They show much better practices later in the book.
  4. At that point of the book, they've not gone into MVC, so if you're going to do things in JSP, this is how you do it. They show much better practices later in the book.
    I'd suggest that any code like this should come with a "government health warning" clearing showing it's bad practice and referencing later chapters in the book where (hopefully) the authors describe how things should be done. Without access to the later chapters I won't presume that they've stated, "forget everything you've learned so far, it was in there for purely historical reasons, the following is how you should be writing web apps."
  5. Without access to the later chapters I won't presume that they've stated, "forget everything you've learned so far, it was in there for purely historical reasons, the following is how you should be writing web apps."
    May I ask a question? Why sould anybody want to use JSP when it's possible to use facelts? I personally find JSF-Facelets so much more elegant and simple after having used Struts-Tiles-JSP for years.
  6. Without access to the later chapters I won't presume that they've stated, "forget everything you've learned so far, it was in there for purely historical reasons, the following is how you should be writing web apps."
    May I ask a question? Why sould anybody want to use JSP when it's possible to use facelts? I personally find JSF-Facelets so much more elegant and simple after having used Struts-Tiles-JSP for years.
    Well, there's the obvious "What if I don't want to use JSF?" question, and then there's the "But even facelets may not be the preferred rendering mechanism for JSF 2.0..." point.
  7. Well, there's the obvious "What if I don't want to use JSF?" question, and then there's the "But even facelets may not be the preferred rendering mechanism for JSF 2.0..." point.
    Touché... aside of the obvious, I just wanted to focus on the fact that JSP are neither nice nor "elegant". I believe that JSP still make sense mostly in outdated action-based frameworks for small scale projects. I've seen recently a full MVC web app to access a business intelligence platform written entirely with JSP and one servlet. Working on large scale enterprise projects I think that not having a JSP tier makes maintenance and evolutions a lot simpler.
  8. ... aside of the obvious, I just wanted to focus on the fact that JSP are neither nice nor "elegant". I believe that JSP still make sense mostly in outdated action-based frameworks for small scale projects. I've seen recently a full MVC web app to access a business intelligence platform written entirely with JSP and one servlet. Working on large scale enterprise projects I think that not having a JSP tier makes maintenance and evolutions a lot simpler.
    Sure. I don't think anyone would say that in a perfect world, new development would start off with ONLY servlets + JSP. But I don't think this is a perfect world, nor do I think that the slightly elitist view being expressed here is acceptable for a lot of places, whether we like it or not.
  9. Right, there's not such a thing as the perfect tool. I come to appreciate that the best solution is generally an heterogenous stack where you take the best of each components in order to minimize the drawbacks.
  10. Point taken. I should have written, "forget everything you've learned so far... the following is how you should be writing JSPs". It was not my intention to state that Servlets + JSPs were the best way to write web apps.
  11. We shouldn't be teaching people how to write crap like this... main() { printf("hello, world\n"); } You gotta start somewhere...
  12. The core Servlet API is powerful enough to make some very fancy things indeed. See for example my monitoring project, built using only standard Java EE APIs.
  13. This is a great book to learn the main skills of Java webapp development. The first edition was extremely useful for me and was my main reference to pass the SCWCD exam. The second edition should be even better, i'll take a look soon. Congrats! Bruno Luiz Pereira da Silva http://blpsilva.wordpress.com
  14. I have the Java 6 SE book from Murach's, and it's equally impressive. I love the layout, style, organization, thoroughness, ease of understanding, and overall excellence of the Murach books. They explain everything very clearly, step by step, in a mentor/instructor conversational style, and in a problem solving context. The problem solving context is especially valuable, as it really drills the topic into one's brain. It's one thing to read about an API and see how it works, it's another thing to see being used to solve a common business process or problem. Also, the layout, where descriptive text is on the left page, and figures and code examples are on the right page, is perfect. It makes learning the subject very easy. By contrast, many tech books will scatter that stuff across a number of pages, and don't give clear figures or code examples. This latest Servlets and JSP 2nd Edition book from Murach is no exception. It makes a rather complex subject (Java web applications) much simpler. It's explanation of setting up your development environment is very clear and easy to follow. It has you download and set up Tomcat, the sample apps and exercises, MySql, NetBeans, and of course the jdk. I also like the fact that it focuses on the basics of Java web development, and sticks with the essentials - Servlets, JSP, JSP tags, http, html, basics of MVC, and so on. These are skills that server side Java programmers can build on, and go from there. If the book brought in other stuff like Struts, Spring, ORM, EJB, JNDI, it would have very much muddied the waters. And those frameworks/APIs are non-essential (albeit common). The Java web field tends to get over obsessed with the 12 billion different frameworks out there, and domain driven design, and ORM, and remoting, etc. It's refreshing for a book to focus on the essentials. It's also refreshing for a book to fully cover both Servlets and JSP, as opposed to many books that focus on one or the other. To me, Servlets and and JSPs are two sides to the same coin, and both need to be fully covered in the same book. Having them covered in separate books is totally stupid, unless it's a complete reference manual. In short, I cannot recommend Murach's Java Servlets and JSP 2nd edition, or any of the Murach books, enough. This book is a pleasure to read, and I've learned a ton, and solidified my knowledge and skills regarding Java web development, thanks to the excellence of this book. Get it. You'll like it. It's well worth the $52 price tag.
  15. Re: Murachs's books are outstanding[ Go to top ]

    Jeff, I largely agree with you, but I think the lack of coverage of JNDI is a severe problem. I don't think JNDI is going to save the world or anything, but it's a core technology that is fairly well mandated by real enterprises - and if they don't mandate its use, then they need a swift kick in the head.
  16. Re: Murachs's books are outstanding[ Go to top ]

    It's also refreshing for a book to fully cover both Servlets and JSP, as opposed to many books that focus on one or the other. To me, Servlets and and JSPs are two sides to the same coin, and both need to be fully covered in the same book.
    Head First Servlets and JSP does that too!
  17. Disservice to JSP[ Go to top ]

    Now, all of this I'm getting from the TOC of the book, so I may be wrong. There seems to be no mention of JSP 2.0 tag files in the book, which pretty much disqualifies for me. Tag Files are a "hidden gem" of modern JSP that many don't know about, and they change the way you work with it. Tag files add a simple refactoring capability to JSPs that didn't exist before. They been out for years, are REALLY easy to use, and very powerful. There's no excuse for leaving them out of any modern JSP book. The coverage of the JSTL also seems weak, plus no mention of how to make your own EL functions. EL, JSTL, and Tag Files are what modern JSP 2.0 are all about, and they completely change how JSP is used today. Old School JSP was horrible, but with all of the 2.0 technologies, JSP is much, much nicer and easier to use today. There's also no reason you can't do MVC programming with simple Servlets, with no Framework required. MVC programming should always be presented along with JSP. This looks like an old school book, lightly updated, and that does a disservice to JSP IMHO.
  18. Re: Disservice to JSP[ Go to top ]

    Will, I thought about that, too. But then I considered the audience again - I don't know that tag files really fit the "typical servlet/jsp developer," even though perhaps they should. It's a fine line, admittedly. EL is another issue, but considering my history with EL, I figured I'd better stay out of that subject.
  19. RE. Disservice to JSP[ Go to top ]

    Tag files add a simple refactoring capability to JSPs that didn't exist before. They been out for years, are REALLY easy to use, and very powerful. There's no excuse for leaving them out of any modern JSP book.
    Other than the fact that you have to learn to walk before you learn to run. Again, this book sticks with basic essentials.
    The coverage of the JSTL also seems weak, plus no mention of how to make your own EL functions.
    I don't think the book is meant to be completely comprehensive. If it were, it would be twice as thick.
    EL, JSTL, and Tag Files are what modern JSP 2.0 are all about, and they completely change how JSP is used today. Old School JSP was horrible, but with all of the 2.0 technologies, JSP is much, much nicer and easier to use today.
    Agreed. But you need to understand the basics JSP tags before you understand the benefits of EL, JSTL, and Tag Files. Again, the book is all about basic essentials.
    There's also no reason you can't do MVC programming with simple Servlets, with no Framework required. MVC programming should always be presented along with JSP.
    I disagree. JSP should be presented by itself, before the waters are muddied by also talking about MVC at the same time. The two should be presented separately, in order to gain a solid understanding of JSP, and to understand the benefits of MVC. And MVC is covered in the book, only later, as it should be. This goes back to my previous comment in my review. The subjects are presented in this book under problem solving context. With JSPs being presented by themselves, the newbie might be thinking about a PHP-ish glob of JSPs design (which would be bad design in any substantial project). But they are getting the basics of how JSPs work. Later on, they are presented with the problem of designing a Model 1, glob of JSPs with lot's Java code in them, web app, and are told how to solve the problem by applying MVC. I think that's extremely effective as a learning technique.
    This looks like an old school book, lightly updated, and that does a disservice to JSP IMHO.
    Not old-school per se, but rather sticking with basic essentials. IMHO, that provides a solid foundation for the newbie Java Web developer. I think you're looking at it from the perspective of an experienced JEE professional, to which your points are extremely valid. But to the newbie, your points are bit overwhelming and not immediately relevant. Let's face it, JEE is overwhelming to the newbie. So many different things to learn, so many different APIs, frameworks, design patterns, etc, and can take several books, and months, if not years, to get fully up to speed. A book like Murach's Java Servlets and JSP helps provide a solid foundation upon which to build, IMHO.
  20. Re: RE. Disservice to JSP[ Go to top ]

    Well, let me put it this way then. While we can talk about it presenting the basics and what not, I do not think that modern JSP should be presented this way today. Basically, as a rule, The Community frowns upon JSPs being used as presented in this book. While it's all basic, useful information, it's not relevant in modern JSP. It would be like presented C++ but ignoring templates and the modern standard library, when it can be argued that today C++ training should START with templates and work back from there. I have LOTS of JSPs in my projects, and hardly any of them have any Java code in there at all. EL, JSTL, and tag files make it mostly unnecessary. I think it would be better for a new user to be "surprised" that they can embed Java in a JSP and, hopefully, question "why would they want to do that". And there's simply nothing "basic" about writing a custom Tag implementation compared to a simple Tag File. A Tag File is no harder than a jsp:include, and a lot more flexible. "Old School" JSP in unpopular for a reason. Just because it's possible to still do it, doesn't mean it should be advocated, and to not advocate the new models I think hurts the platform. Simple MVC with Servlets and simple beans, post->redirect, EL/JSTL/Tag Files, leveraging the request (vs the session), and JDBC using prepared statements, binding, and a connection pool (for security and performance) are enough tools to do most any small to medium project. The project will be efficient to run, efficient to write, have good results, and be decently organized. The hardest part to grok there is the fact that Servlets aren't thread safe, the rest is very straighforward. Toss in a few utility functions help with binding (i.e. string to int, string to date, simple bits like that). And that's what a modern book on Servlets and JSP should be teaching.
  21. Re: RE. Disservice to JSP[ Go to top ]

    Will, again, I gotta step back here and defend "The Community." There are two communities here: one's cutting edge, efficient, on top of it, aware, well-informed. The other is in the trenches slogging away. Often, people who should be in the former group are in the latter group too. It's not fun, but it's reality. Books like this aren't going to really target the literati very much, much less the glitterati. (I can tell you that I learned very little new from the book.) But they target the people in the trenches, who might love to know all about Spring-MVC or JSF or what-have-you, who'd love to use JPA, but are stuck with using JDBC. It's out there. It's more common than perhaps it should be, but it's out there. Ignoring that market's needs by saying "We're not going to help you until you come out of 1997" isn't helpful.
  22. Re: RE. Disservice to JSP[ Go to top ]

    The reality is folks will take what they see and cut and paste their way to a solution. That's plain fact. Programmers are lazy, ESPECIALLY today. I think it's a GOOD thing that lazy, less skilled programmers can develop systems. We still have a backlog, and the more the merrier in my book. A book reiterating 1997 isn't helpful for two reasons. One, we already have a zillion books pushing 1997 and, two, it doesn't advance the art AT ALL, even incrementally, even a smidge. It just gives the poor soul in the trench a different colored shovel when we should be giving them a hand up out and the keys to a small backhoe, or maybe at least a pick. I'm all for supporting the guys in the trenches. I routinely bulldoze Ivory Towers, and I'm a vocal supporter of the common coder. JSP and Servlets are well documented, several times over, in books and online. As I mentioned to the other poster, TSS has a good book here. But there's an obligation I think for authors to not simply reiterate Spec documents, but also to provide "best practices". The best practices of today are different than they were in 1997. There's no reason a JSP book couldn't present JSP basics, and a chapter on "here's how it was done, here's how we do it today", with sample code and projects for folks to copy and paste their way to glory. At least when they c&p something, give them GOOD CODE to c&p. Don't just focus on "here's how we can put code in a JSP". Of course, that's the first thing everyone shows folks. And it's the LAST thing they should be doing, and we all KNOW that. We don't guess, we don't consider, we don't hem and haw, we KNOW the issues of code in a JSP. We KNOW why it should not be done. Yet, out the gate, first thing we get is how to stick our hands in the fire. That is not helpful. When someone doesn't know any better, they take the examples given to them as gospel. They have to, they don't know any better, and that's not a criticism of them, it's simply on observation, they're learning for a reason. So, why not give them better gospel instead of regurgitating the bad practices of 10 years gone?
  23. you win, the book must suck[ Go to top ]

    The reality is folks will take what they see and cut and paste their way to a solution.

    That's plain fact. Programmers are lazy, ESPECIALLY today. I think it's a GOOD thing that lazy, less skilled programmers can develop systems. We still have a backlog, and the more the merrier in my book.

    A book reiterating 1997 isn't helpful for two reasons. One, we already have a zillion books pushing 1997 and, two, it doesn't advance the art AT ALL, even incrementally, even a smidge. It just gives the poor soul in the trench a different colored shovel when we should be giving them a hand up out and the keys to a small backhoe, or maybe at least a pick.

    I'm all for supporting the guys in the trenches. I routinely bulldoze Ivory Towers, and I'm a vocal supporter of the common coder.

    JSP and Servlets are well documented, several times over, in books and online. As I mentioned to the other poster, TSS has a good book here.

    But there's an obligation I think for authors to not simply reiterate Spec documents, but also to provide "best practices". The best practices of today are different than they were in 1997. There's no reason a JSP book couldn't present JSP basics, and a chapter on "here's how it was done, here's how we do it today", with sample code and projects for folks to copy and paste their way to glory. At least when they c&p something, give them GOOD CODE to c&p.

    Don't just focus on "here's how we can put code in a JSP". Of course, that's the first thing everyone shows folks. And it's the LAST thing they should be doing, and we all KNOW that. We don't guess, we don't consider, we don't hem and haw, we KNOW the issues of code in a JSP. We KNOW why it should not be done. Yet, out the gate, first thing we get is how to stick our hands in the fire. That is not helpful.

    When someone doesn't know any better, they take the examples given to them as gospel. They have to, they don't know any better, and that's not a criticism of them, it's simply on observation, they're learning for a reason.

    So, why not give them better gospel instead of regurgitating the bad practices of 10 years gone?
    Okay, I get it. You're utterly against anything newbie friendly. You're utterly against teaching basics, then moving on to more advanced topics. You're totally into embracing massive complexity, and taking all the gazillion frameworks, and design patterns, and forcing them down the throats of newbies, well before they're even close to being able to comprehend them. To be honest, I don't think the JSP/Servlet architecture is very good. And you're right that doing basic stuff with JSPs and Servlets is very 1997. I think the LAMP stack is vastly superior to JEE for all but the biggest of the big projects in the largest of enterprises. The only Java web framework that impresses me is Wicket, because it's just simple HTML with Java classes behind, which use Servlets under the hood.
  24. Re: RE. Disservice to JSP[ Go to top ]

    But there's an obligation I think for authors to not simply reiterate Spec documents, but also to provide "best practices". The best practices of today are different than they were in 1997. There's no reason a JSP book couldn't present JSP basics, and a chapter on "here's how it was done, here's how we do it today", with sample code and projects for folks to copy and paste their way to glory. At least when they c&p something, give them GOOD CODE to c&p.

    Don't just focus on "here's how we can put code in a JSP". Of course, that's the first thing everyone shows folks. And it's the LAST thing they should be doing, and we all KNOW that. We don't guess, we don't consider, we don't hem and haw, we KNOW the issues of code in a JSP. We KNOW why it should not be done. Yet, out the gate, first thing we get is how to stick our hands in the fire. That is not helpful.

    When someone doesn't know any better, they take the examples given to them as gospel. They have to, they don't know any better, and that's not a criticism of them, it's simply on observation, they're learning for a reason.

    So, why not give them better gospel instead of regurgitating the bad practices of 10 years gone?
    +1 There is absolutely a need for a book like Will describes, unfortunately Murach's Java Servlets and JSP (2nd Edition) appears* to have fallen short in this regard. *somewhat presumptuous of me since I've only read the sample chapter.
  25. Will, can you recommend any good books that cover EL, JSTL, and Tag Files for JSP 2.0? I'm definitely in the market for one. All I've found so far seems to treat JSTL and tag files as sort of afterthoughts.
  26. The free JSP book here on TSS isn't so horrible. It's not a good reference (they hand wave the SQL tags completely because they don't approve of them), but the text is decent. http://www.theserverside.com/tt/books/addisonwesley/ServletsJSP/index.tss I found the online Oracle tutorials for Tag files et al the most informative though.
  27. Re: Disservice to JSP[ Go to top ]

    As one of the authors of this book, I would like to say that I don't think that we've done a disservice to JSP. On the contrary, I think our book is one of the few servlet/JSP books on the market that consistently shows how the MVC pattern can allow you to use servlets and JSPs to create web applications that follow best practices and are maintainable. As the book progresses, all examples from chapter 7 on use the MVC pattern to move Java code out of the JSPs and into servlets and JavaBeans, which clearly shows why it doesn't make sense to write code like the code presented in the sample chapter (chapter 5). In retrospect, I wish I had put more language in this chapter to warn against using this code as it is and to recommend using the code that's presented later in the book. True, we could have structured the book differently so we didn't start out by presenting "bad" JSP code. But then what happens to developers who need to maintain that "bad" code that was written in 1997? In short, when we design our books, we try to present best practices for when you're writing new code, but we also try to show how everything works in case you need it to maintain existing code. We didn't cover Struts or Spring or any of the other frameworks in this book because we think that these subjects are worthy of their own books. We hope to publish books on those subjects someday, but we're a small company with limited resources, so I'm not sure when we will get around to that. True, we don't provide coverage of tag files. Somehow, we completely missed this feature of JSP when we were researching the book. But I agree that this feature should have been covered in our book, and I hope to correct this by adding a PDF to our web site to cover this feature in the near future and by adding this coverage to the next edition of the book. In the meantime, I think it's still possible to create decent Java web applications without this feature, even though it does appear to be a handy feature, and there are several good tutorials available from the web on this feature. True, we don't show how to make your own EL functions, but I think our coverage of EL and JSTL is solid and will get you up to speed quickly if you don't know these subjects. Thanks for the spirited discussion here. I'm sure I will use some of the ideas that you guys are kicking around to improve the next edition of this book or to create an excellent book on one of the frameworks.
  28. Just checked Amazon Bestsellers - Books - Java. Head First Servlets and JSP is usually more popular than this book, but today it is less popular.
  29. JSP?[ Go to top ]

    Are there in this day and age living mortals still using this JSP thing? Please God save us!! Jan
  30. Re: JSP?[ Go to top ]

    Are there in this day and age living mortals still using this JSP thing?
    Yes indeed, and it is a pain... and a necessary one in some very specific circumstances. For example, my previously-cited monitoring tool can be added to any (binary) Java EE application, and thus can not bring its own dependencies. Therefore I must rely on the least common denominator, which happens to be JSPs. This is the price to be totally non-obtrusive...