Web Development With JSP 102
| Web Development with JSP | |
| author | Duane K. Fields and Mark A.Kolb |
| pages | 543 |
| publisher | Manning |
| rating | 8.5 |
| reviewer | Gavin Bong |
| ISBN | 1884777996 |
| summary | Comprehensive coverage of JSP1.1. Suitable for beginning to intermediate Java developers. |
Prologue
Before I proceed with the review, I feel obligated to respond to Jayakrishnan's review of Core Servlets and JSP and Slashdot readers' comments.
I share the sentiments of most people that the use of JSP scriptlets (Model 1) is bad practice. The mantra, "Thou shalt not mix HTML and Java code," should be tattooed onto every JSP developer's forehead. And as the author and readers have suggested, either choose a Model 1.5 (JSP or custom tags with JavaBeans) or Model 2 (MVC) to implement moderate- to high-complexity Web applications.
However, I believe that the authors of this first generation of JSP books need to inform the populace of what JSP is fully capable of (warts and all) -- in order for developers to appreciate the other paradigms. And beyond that, these authors must then educate on how not to use JSP. And I believe that will be the difference between a complete JSP book and an incomplete one.
Secondly, JSP Model 1 has been often described as "servlets lite." It is a good paradigm for prototyping servlets. For example, SOAP4J (IBM's SOAP framework) was released using a JSP scriptlet to dispatch SOAP RPC invocations. The software has since been donated to the Apache group and in the latest public release; the aforementioned JSP scriptlet is now a servlet.
So on that note, let me begin the review.
Topics covered
The book starts with a survey of precursor technologies to JSP in Chapter 1 and quickly moves into the real subject matter. It is clear from the start, that this book is written with the Java programmer in mind. I'd say that only the first five chapters are useful reading for a JSP page designer. Concepts like "How to setup a JSP/Servlet engine?", "Incorporating applets with tag," JDBC, JNDI, and EJB are either relegated to the Annexes or lightly mentioned before detailed treatment follows. The authors only cite HTML and Java as prerequisites but it's more accurate to say that readers also need to have some knowledge of core J2EE services like servlets. Here's a tip: have the JSP v1.1 and Servlets v2.2 specifications within close reach when reading the book.
The book covers all the core JSP topics; here's a sampling:
1. JSP and JavaBeans
The book provides a very readable introduction to JavaBeans for those unfamiliar with it. This is required reading for those implementing the Model 1.5 architecture. However, features specific to visual-oriented beans are not covered. Page designers should specifically devour Chapter 5 on JSP bean tags. The two notable samples provided are:2. JSP Performance/Scalability
- CachedRowSet Bean - An example of paging through results using the JDBC 2.0 RowSet interface.
- JDBC Transaction Processing - An example of maintaining a JDBC transaction across several JSP pages using a Database Connection Bean and JSP implicit objects.
Performance and scalability issues are discussed accross several chapters. The authors attribute JSP's performance to servlet performance, which is tied to JVM server memory. No rule of thumb on sizing JVM server memory is given, but a tip is offered on how to use the serializable interface to estimate the size of Java objects that will be placed in the session object.Session migration over multiple load-balanced machines is touched upon lightly but no technical details were offered. I would have liked to see a practical example on session persistence coupled with a use case of load balancing a JSP website. It's unfortunate also that the authors didn't think that database connection pooling warrants a practical example.
3. Multithreading
Throughout the book, readers are reminded to be aware of thread safety issues when dealing with shared resources (e.g. JDBC Connections). This tip is offered: "Examine all static variables & objects whose scope is session or application."4. Exception Handling
A comprehensive coverage on how to handle exceptions in a JSP web application is provided and covers these areas:
5. JSP Web application architectures
- Error pages in JSP
- Null properties in JavaBeans
- Undefined values in Database tables
- Handling exceptions in servlets (JSP Model 2)
In Chapter 8, the page centric architecture (Model 1) is compared to a servlet centric one (Model 2). A discussion on the servlet RequestDispatcher interface culminates with a sample, that demonstrates how a servlet dictates application flow; relegating JSP pages to provide only presentation services, when called upon. A more complicated sample using this architecture is developed in Chapter 9.
6. Deployment
The book provides complete information on WAR files and Deployment Descriptors.
7. Three chapters of code samples
One full chapter is dedicated to a sample implementation of a real world example of a faq-o-matic tool. Also provided are two chapters of code snippets for Web-based functionality like form handling, cookie management and JSP's marriage with Javascript.
8. Custom tags
The last two chapters are dedicated to this very unique feature of JSP and in it they provide sample custom tags for content substitution and translation, coverage on how to package taglibs and more advanced techniques incorporating Java reflection in custom tag helper classes.
Weaknesses
The book comes with eight pages of errata - mainly spelling/naming errors in the code. I think publishers need to ensure that code be proofread as diligently as the prose. Fortunately the book has a Web site (taglib.com) with a link to a Web-based public forum.
The JSP API in Annex E is presented in the same style as Oreilly's Java in a nutshell book. A UML diagram would have been nice.
And finally, just like in the Core Servlets and JSP book; there's no mention of i18n or security. But this is probably a moot point since you gain i18n features directly from the Java language itself and the "contentType" @page directive attribute. Security of a JSP application is largely dictated by the Servlet/JSP engine configuration (albeit you can plug in your own authentication/encryption schemes) and would be better covered in a book dedicated to system administration and other deployment issues.
Is it worth buying?
It is important to mention that this book covers JSP 1.1 and Servlet 2.2, the production release of each technology. Recently JSP 1.2 and Servlet 2.3 have both entered the Proposed Final Draft stage. So the question is: should you wait for a new edition? My suggestion is: go buy the ebook version (in PDF) from Manning's website. And at a price of $16.50, that's a steal.
In terms of content, the book offers good value in its coverage of deployment issues, different JSP architectures and not forgetting some really good material on custom tags/taglibs. And by advocating an MVC styled development architecture; everyone from your JSP page designers, JavaBean/servlet developers and DBAs will be less coupled - and your code more maintainable.
Table of contents
- Chapter 1: Introduction
- Chapter 2: Fundamentals
- Chapter 3: Programming JSP scripts
- Chapter 4: Actions and implicit objects
- Chapter 5: Using JSP Components
- Chapter 6: Developing JSP Components
- Chapter 7: Working with databases
- Chapter 8: Architecting JSP applications
- Chapter 9: An example JSP Project
- Chapter 10: Deploying JSP applications
- Chapter 11: Performing common JSP tasks
- Chapter 12: JSP by example
- Chapter 13: Creating custom tags
- Chapter 14: Implementing advanced custom tags
- Annex A: Running the reference implementation
- Annex B: Incorporating Java applets
- Annex C: JSP resources
- Annex D: JSP syntax reference
- Annex E: JSP API reference
Besides the PDF version, you can also purchase this book at Fatbrain.
Re:Nothing But Good Vibes (Score:1)
pj
Re:CPU power needed to backend JSP pages? (Score:1)
Servers are 2GB RAM, Dual Pentium 700. We have a redundant setup (two front ends, two back ends).
Bottom line: we routinely serve >> one million pages per day with peak hours well over 100,000 pages (well over a million hits when gifs are included). A loss of one server degrades performance at peak times but only slightly.
Assuming by hits you mean dynamically generated pages then you are running at ~1% of what we do so you should be fine on CPU. The RAM looks light, though and swapping can kill you.
'Course "your mileage my vary" - there are too many things that influence performance to be able to just say x hits/day = y CPU.
Re:Garbage (Score:1)
Fact is, like or not, Java is today the DOMINANT platform, by far. .NET is still paper. Also it is the best advocat of Linux as a platform in deployment environments.
You have to understand this is real, much $$$ at stake and a FULL INDUSTRY today squarely pushing the computing envelope with Java (thinking of server side mostly, EJB etc etc).
I stopped really reading the /. threads on java about 2 years ago (ok i still do from time to time as you can tell ;-) because 30% was still "applets" showing the naivete and poor level of most the readers.
Now (and being a hardened professional) I am still amused at the "jsp/no jsp" discussion going on but very pleased by the status of some of the open source efforts going on (particularly in the EJB space) so i understand it is not all BS out there.
pj
Re:Good Read (Score:1)
Fraternally,
Bro. Mark
VanRensselaer Lodge, No. 87, F&AM of NY
Re:CPU power needed to backend JSP pages? (Score:1)
The best machine for the job [javaworld.com] is an AS/400, but your Pentium is probably up to the task. More RAM would help heaps.
Re:JVM vs. Native Code (Score:1)
I've liked the AS/400 as a backend, but why do shops who use them insist on making me enter my timesheets direct to the green screen?
Re:CPU power needed to backend JSP pages? (Score:1)
anyway, that was my rant. did i say that i hate websphere and visual age??
Re:Jakarta or Tomcat? (Score:1)
also there's Cocoon if you want to do some XSLT.
Re:Garbage (Score:1)
-------
i agree. the problem with xslt is i don't know any graphic artist that know what it is. is there any wysiwig xslt editor??
in the meantime, i think that jsp with a good tag library is a good compromise. java code in a jsp file should be avoided!!
anyway, i do most of my pet project with xml (generated on the fly by a servlet) and i apply an xsl stylesheet to it. i use jsp mostly as a glue (dataislands) or sometimes to generate a stylesheet.
Re:Nothing But Good Vibes (Score:1)
jboss suffers in the documentation area, but really, it's so easy to set up compared to commercial product like websphere that the readme file is enough.
Re:CPU power needed to backend JSP pages? (Score:1)
Re:Neither..(best JSP engine choices) (Score:1)
Re:Nothing But Good Vibes (Score:1)
It's also vastly easier to get working than the other EJB server we have around here, WebSphere.
Re:You DO have a choice, even in business (Score:1)
You also highlighted an important point about Java's success: since the JVM has become such a standard, some things have now become possible that might have been viewed with more suspicion in the past. I don't think you'd be stretching the truth too much to bill your solution as Java-based, although problems might arise if the code needed to be maintained by non-Scheme programmers.
Given Scheme's parsability, though, a translator to JSP might not be that difficult - or perhaps more perversely, a good Java decompiler could convert Kawa-generated bytecode back into Java... ;^)
Re:Say what? (Score:1)
john
Re:CPU power needed to backend JSP pages? (Score:1)
If you're going to do servlet / JSP stuff with an Apache tool, use tomcat - that's where the majority of the development has been focused for the last year or so.
Garbage? Welll... Not always. (Score:1)
Example: We have a site on our Intranet where jobs are posted. The practice was the client sent me a WP document from which I would extract the content, format it and then publish. Now, the client goes to a form page where the data is entered into a database. The server then takes that data and constructs the published pages. The savings in work time are (at a minimum) 50%.
Just my 2 cents to remind yez all that there is a place for dynamic content. Just mind what gfxguy was griping about. Don't get so carried away with the Neat Stuff that you screw up the client's experience on your web site.
Ahh! That's not O'Reilly! (Score:1)
Re:Garbage (Score:1)
Assuming that javascript is available is a major common sin.
But it's not the tool, it's the developers that are the real problem.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Re:Dynamic Web Content? Philip & Alex. (Score:1)
JVM vs. Native Code (Score:1)
That, and the fact that for raw I/O performance AS/400s rock.
Re:[OT] JSP IDE under Linux - Try JDE (Score:1)
Here's the url:
http://sunsite.dk/jde/
JSP's marriage with Javascript (Score:1)
i develop web applications and i've never read a good resource on this specific topic. i'm a firm believer is separation of presentation and business logic, but i've only seen XML-RPC and SOAP really offer an elegant solution to this problem.
Neither..(best JSP engine choices) (Score:1)
I wouldn't touch Tomcat with a 10ft stick. Its performance is really sluggish; and its overall maturity level is remarkably behind the other free/commercial alternatives. IMHO, the best JSP engine you can get for free now is Resin; it also happens to be the easiest one to set up. It's available at Caucho's site [caucho.com]. It's still possible to run Resin alongside Apache so Apache takes care of the static HTML pages while Resin handles the JSP. In my experience it was the ideal solution, and I scrapped JServ as soon as I discovered Resin.
JSP==Bad (Score:1)
Ah Hah! I bet you expected to find a java hating bigot. Nope, just a JSP hating one. If you want something similiar to JSP, but much more interesting (for a number of reasons I won't mention here, go to the webpage lazy ass) try Apache's Cocoon [apache.org]
With a name like Apache it's gotta be good...
Re:Anyone can do a better job that Sun (Score:1)
The information it provides is exactly what you appear to require, assuming that you are genuinely interested in the topic.
Re:Model 1/1.5? (Score:1)
http://www.javaworld.com/javaworld/jw-12-1999/j
The author of that article is misinformed Part 1 (Score:1)
<BR>
<BR>"Problem #1: Java Code Too Tempting"
<BR>"JSP makes it tempting to put Java code in the web page, even though that's considered bad design."
<BR>
<BR>Who says it is bad design? This statement of "Java code" is so general it is pathetic. What Sun and most authors state is that putting "business logic" in a web page is bad design. That is a very important distinction, because both authors and Sun do advocate putting "presentation logic" in a web page. That is the entire purpose of JSP. Presentation logic may require Java Code... maybe lots of Java Code. And why is that bad?
<BR>
<BR>"Problem #2: Java Code Required"
<BR>
<BR>Of course it does... read my response to #1. This is the strength of JSP. To be more than a scripting language and have the support of the entire Java API. It can also "hook-up" to other Java services.
<BR><BR>"Problem #3: Simple Tasks are Hard"
<BR>"In JSP the best way to do this is as follows:
<BR><% String title = "The Page Title"; %>
<BR><%@ include file="/header.jsp" %>
<BR>Your content here
<BR><%@ include file="/footer.jsp" %>"
<BR>
<BR>"In WebMacro including headers and footers is done easily:
<BR>#set $title = "The Page Title"
<BR>#parse "header.wm"
<BR>Your content here
<BR>#parse "footer.wm"
<BR>"
<BR>
<BR>Yeah, maybe simple tasks are hard. But I am not familiar with WebMacro, and the example given does not seem so easy! It looks more like the frame of reference of the author. I think the JSP snippet above is simple and understandable.... but that is just my frame of reference. My point is that the author's point is moot. The complaint of having to put semi-colons is almost equivalent of my complaint of the dollar sign before the title variable in WebMacro.
<BR>
<BR>"Problem #4: Lousy Looping"
<BR>"Looping is overly difficult in JSP. Here's the JSP code to iterate over a
<BR>vector of ISP objects printing the name of each.
<BR><%
<BR>Enumeration e = list.elements();
<BR>while (e.hasMoreElements()) {
<BR> out.print("The next name is ");
<BR> out.println(((ISP)e.nextElement()).getName());
<BR> out.print("<br>");
<BR>}
<BR>%>
<BR>"
<BR>
<BR>This problem completely demonstrates the author's understanding of JSP. First of all, the code for looping is just Java. Anyone familiar with Java can code that in a few seconds. Second, the code used to output to the web user is pathetic and old. The whole reason to move from Servlets to JSP for "presentation logic" is to avoid all the out.print() statments. Just the fact that the author used the out.print() statment shows that he is extremely inexperienced with JSPs. Here would be my version:
<BR><%
<BR>Enumeration e = list.elements();
<BR>while (e.hasMoreElements()) {
<BR> %>
<BR> The next name is <%=((ISP)e.nextElement()).getName()%> ;
<BR> <br>
<BR> <%
<BR>}
<BR>%>
<BR>
<BR>"Problem #5: Useless Error Messages"
<BR>
<BR>Yeah, I agree... the error messages could be better. That is simply on compilation and I do not think that ASP offers too much more. One thing that I have found useful is to put the option "keepgenerated" set to true on App Servers. This leaves the intermediate
<BR>
<BR>"Problem #6: Need a Compiler"
<BR>
<BR>And? Isn't that obvious. You would need a compilier (or a "sort-of" compiler) for any scripting language... but this is not a scripting language. Yeah, I find it annoying that I need the overhead of an app server jst to run my jsps, but Tomcat is free and pretty good. I have used Weblogic, WebSphere, and Tomcat and they all are very powerful and nice to have. You must remember the scope of JSPs. Although JSPs can be used on small sites, they flex their muscles on large complex sites. Most sites of this nature do not flinch at the fact of needing an industrial strengh app server.
<BR>The problem here, IMHO is that the author is failing to identify the scope of JSPs. It sounds more like ranting and raving.
<BR>
<BR>"Problem #7: Wasted Space"
<BR>
<BR>Give me a break. He is complaining about hard disk space!!! Again, I think he failed to realize and identify the scope of JSPs.
<BR>
<BR>"So is there a place for JSP in the future? Certainly. JSP is entirely
<BR>relevant if what you're trying to do is wean people off of ASP."
<BR>
<BR>If this is the only place that he can find a strength for JSPs, he is completely misguided and inexperienced. I almost find the fact that he is writing this article for servlets.com offensive. I deal with large complex projects everyday. JSP is one of the most viable solutions for many of our clients. This is not just a quick decision either. We go through a lot of design and consideration before arriving at these conclusions.
<BR>A good author would identify and distinguish the differences in uses and compare/contrast a little more responsibly. This author did neither; however, he succeeded in ranting and raving over his opinions based on inexperience giving fuel to people looking for a reason not to like JSPs.
<BR>
<BR>Michael
<BR>
<BR>- The requirements called for Windows 9x or better... so I installed Linux</CODE>
Re:ASP.NET is his main competitor. (Score:1)
The term was originally the verb to troll, as in trailing a net behind a boat, ensnaring whatever fish happens by. Because of the coincidence of the name for the bridge-dwelling sub-human mythical creatures, trollers came to be called trolls. My guess is this was out of ignorance, not cleverness.
[OT] JSP IDE under Linux (Score:1)
Comments on the review, not the book (Score:1)
This seems like a pretty critical omission to me. Creating a fast website with lots of server-side computing with a stateless transaction model is tricky, and some description of how to introduce caching of any kind into a load-balanced world seems like the most important single contribution a book like this would make to my library.
Yea, lots of managers think that too :-) Sorry, but internationalization cuts right down to the basics of your application design, unless you just want to create separate installations for each language.
Re:CPU power needed to backend JSP pages? (Score:1)
Oh, and 1GB of RAM apiece.
They do just fine in general. The slow pages are the ones that involve accessing big chunks of the database, though by being less stupid in our database implementation that's getting better.
Performance analysis (simple page timing logs) have shown that a considerable number of slow pages are the result of slow client links. That problem is exacerbated by the tendency of pages to be big (our pages anyway). That's one thing JSP sure makes easy!
Re:Garbage (Score:1)
If you can't view the page, it's not an ASP problem, it's just plain bad HTML. Again this has absolutely nothing to do with dynamic content. My dynamic content works fine on Netscape (and Opera) because I don't write code to generate bad HTML. Others are not very particular.
Re:Garbage (Score:1)
Most of the things that make pages slow are stupid counters and ad servers. A few judicious host file entries can really speed up your surfing experience.
Re:Servlets Far More Useful Than JSP's (Score:1)
Re:Good Read (Score:1)
Question: Can anyone recommend a good general primer for dynamic web design? There seems to be a fair selection out there for specific implementations (This book for JSP, a couple of PHP books, lots of Perl and Python stuff.), but I am looking for a more generic sort of "How can dynamic content make my life and my site better?" kinda thing. I admin for a universtiy department, and although I do not handle the web content myself, I feel like it could be improved by the proper application of server intelligence. I am just not quite sure how. If I could, by making backend changes, make the front end of the site prettier , more useable, easier to update, or any combination thereof, I'd be happy to put in the effort, but I am kind of at a loss as to where to start.
Re:Servlets Far More Useful Than JSP's (Score:1)
Isn't this called taglibs?
M.
Re:Garbage (Score:1)
I guess what pisses me off the most are things like ASP pages that I can't view on netscape on my SGI. Do these companies even realize they are losing my business?
What ASP pages? Why on earth can't you view them in Netscape? ASP just generate HTML. There's nothing specifically about ASP technology that limits it to being viewed in IE as you seem to imply.
-Ciaran
Re:You might be a little confused (Score:1)
You advocate pretty much the same style of programming I do, although I don't have much experience with JSP's. I agree completely - your application/business logic belongs in classes and functions, but code that is used to output variables, database records, etc. usually should be in the HTML(or XML, etc.).
At least one other poster advocated the "everything in a servlet" approach, stating that it could be changed to a GUI client/server type program more easily. If that is important, then I can see the advantage, however, I think its more likely you will need to work with graphic/web designers and in that case, the "mixing output code with HTML" approach works better.
Re:Garbage (Score:1)
It's the HTML / JavaScript that's generated by the ASP that's the problem.
Re:Say what? (Score:1)
--
01 13 19
TVDJC TDSLR AZNGT NWQSH KPN
Re:CPU power needed to backend JSP pages? (Score:1)
Re:Why even post when you don't have a clue ? (Score:1)
First of all if you don't know how to behave then i would say you should think if you ever post again.
Maybe my english is not good enough or maybe you just don't can or want to understand what i'am trieng to say. I now that in the and JSP become Servlets. What i'm speaking about is the readability of the code. Not what happens when the code is executed/ interpreted/ etc.. Same thing with the HTML wrapper classes. I'm realy curios if you are just to dump to understand or what. Sure i know that in the background some HTML tags get send to the Browser. The idea is that YOU don't have to do it yourself. Again that has something to do with the readability of your code.
My hole reply was ONLY about the readability of JSP vs. Servlets. So please, the next time you feel the need to reply, try to understand what the article is about.
--
Re:Rant about separation of code and HTML (Score:1)
Re:Nothing But Good Vibe(ration)s (Score:1)
Doot doot doo...
I suck with php
Doot doot doo...
so I'm gonna use jsp
A-doobie doobie doo...
don't know wtf i'm doin
Banana-wow
but the book i bought says enterprise and java on it so I must be on the right track
PHP issues? (Score:1)
I had a quick knee-jerk 'wtf?' reaction to your statement, but I am genuinely curious as to what you found the shortcoming to be that necessitated a switch to JSP.
Re:PHP issues? (Score:1)
Theoreticall, tying PHP to AOLServer would get you connection pooling too.
Still not sure how you architected your 'universal login' - I can't figure out what you'd be doing that PHP/Postgres wouldn't be fast enough, except that I know postgres hasn't always been a speed demon.
PHP wasn't meant to do anything you were trying to do, but application variable-style variables really all that hard in PHP - we 'eumlate' them all the time.
Not sure how you even *attempted* or *thought* of threading issues with PHP. We've used it for some rather large volume sites for years with no problems at all - threading issues never even came up on my radar as an issue. For standard web apps they're really not necessary.
Putting things in a 'set' variable - sounds like you're meaning application vars - again, emulating is no big deal.
Not getting into a flame war, but there's pretty much nothing you can do in your JSP model that I can't do with a PHP model, and probably just as quickly.
JSP doesn't support true threading - the underlying servlet engine does, but JSP itself doesn't.
Email me offlist if you want to continue this - I'd like to know what your 'universal login' system is doing that's so complex.
Re:Go ahead buy it (Score:1)
The book is also self-contained: if you did a little more than "hello world" in Java, you will be in good condition. There is even decent coverage of Beans and JDBC (I said "decent")
Don't be afraid of buying this or any other book because it covers "old tech". As an example, I'm returning "Java in a Nutshell" (oh! it covers Java 1.3!) to get the "Core Java 2" books.
Re:Java sucks! (Score:1)
You DO have a choice, even in business (Score:1)
Different people have different experiences re. management attitudes toward non-mainstream tools. Especially in this employee-favoring technical job market, you can get a lot of freedom once you prove your ability to solve problems quickly. I'm using Scheme for Intranet web apps in daily use by hundreds of employees.
I suppose if management did start getting hostile to non-mainstream tools, I could bill it as a "Java-based solution". There's just one servlet, which provides the web interface to a Scheme-to-JVM compiler.
Re:[OT] JSP IDE under Linux (Score:1)
Jakarta or Tomcat? (Score:1)
Thanks :)
Re:I would prefer C/C++. (Score:1)
Servlets Far More Useful Than JSP's (Score:1)
The reason for the "omissions"... (Score:1)
The reason for this is that both of these issues (session persistence across servers & connection pooling) are supposed to be handled by your application server. You, as a developer, should not have to worry about their actual implementation, only that it does happen, and of course the limitations of your vendor's scheme.
Where it can, a computer should proofread (Score:1)
Isn't it much better to test code instead of trying to proofread all the errors out of it?
I haven't been able to figure out why it it's so common for published code to have errors in it. Why wouldn't they test it and then just paste the code into the book text once it works?
Re:CPU power needed to backend JSP pages? (Score:1)
You need to to prototype your app in your env to see if it'll work for you. I would suggest either the latest version of iPlanet, Apache's JServ, or JRun. You also need JDK 1.3, it has _major_ speed increases over 1.2 and is quite stable.
Go ahead buy it (Score:1)
Re:Garbage (Score:1)
JSP pages compile as well, and well-implemented JSP/Servlet server (IE, Allaire's JRun) will do just fine for speed on a reasonable server. Beyond that, JDBC database access is quick and easy, and their connection pooling capability makes even Oracle run fast enough for web purposes.
Moreover, all e-commerce requires dynamic content, unless you are using static pages and emailing your credit card info to an operator. So don't be so down on the concept. Try to open your mind a little bit, instead of just lashing out at things you don't understand.
Re:PHP issues? (Score:1)
Second, we actually ran into threading issues with PHP... you see, we stored logged-in users in a set variable. But PHP doesn't really do a good threading job, and we ran into all sorts of errors... phantom users, etc. Java's Collections Interface has a built-in set object as well as syncrhonization.
Also, PHP doesn't have the different variable contexts that JSP does. Registering a variable with the page and passing that context to another page allowed for a real servlet-centric application instead of a few unrelated script pages. PHP is just a scripting language - you really do need something more powerful for real apps.
I appreciate your open-mindedness, though, as opposed to some other unnamed slash trolls who are against anything that might be used for an (oh!) capitalist pursuit.
Re:Nothing But Good Vibes (Score:1)
Re:Tomcat (Score:1)
Re:Good Read (Score:1)
Re:Comments on the review, not the book (Score:1)
Here's an article [javaworld.com] covering the load balancing problem.
Re:Java sucks! (Score:1)
To quote from the last [jwz.org] "Java Sucks" links the original poster provided:
"I think Java is the best language going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser languages that we have to work with out here in the real world. Java is far, far more pleasant to work with than C or C++ or Perl or Tcl/Tk or even Emacs-Lisp."
Talk about faint condemnation... But now that we've set the rules of engagement, I agree--Java sucks. So where do we go from there? SML servlets?
Re:Say what? (Score:1)
Standard shorthand for "Internationalization"
i(nternationalizatio)n
"nternationalization" has 18 chars.
i(18)n
i18n
Re:Garbage (Score:1)
4-5 years ago applets were a strength.
Over the last 5 years there has been enormous improvements in every aspect of Internet development.
Likewise Java has also evolved and moved on.
Re:Java sucks! (Score:1)
Sorry about the error.
- harborpirate -
Re:Java sucks! (Score:1)
Sure, Java has it's drawbacks (hint: where is UDP?), but it has a lot more positives than negatives, in my opinion.
I also find it funny that you say Java sucks, and yet the first line of one of the pages that you link to says: "I think Java is the best language going today". He goes on to say that it is merely slightly more acceptable than others, but he does mention that it easier to work with than C,C++,Perl,and Tcl/Tk.
I'm no Java crusader, but I would like to point out that Java does have its uses, and people shouldn't dismiss it out of hand.
- harborpirate -
Re:ASP.NET is his main competitor. (Score:1)
Re:goaty goaty goat sex! (Score:1)
Re:Jakarta or Tomcat? (Score:2)
Jakarta [apache.org] is the project. Tomcat is one of the products of the project. In particular Tomcat is the servlet engine. I think the name of the JSP implementation is Jasper, but don't quote me on that.
Aditionally there are a lot of other things happening in the project, like application frame works, the Jakarta ORO Matcher regular expression library, and a number of other things. Take a look at the site.
Mark
Good Read (Score:2)
Personally I picked up this book a while ago. I needed to get up to speed on JSP. It is a good read. I didn't find I needed the JSP or the Servlet specification handy to get through it, and I had only a passing familiarity with JSP when I started.
Mark and Duane deal with the subject well. The chapter on "Architecting JSP applications" is very helpful for someone coming new to the Java way. The coverage of java beans is decent, although I'm not personally a big user of them.
I would recommend the book as a good starting point for using Java as a web development platform, but as a starting point. Take a look at some of the alternatives to JSP. Personally I've moved away from JSP, and haven't used them in a single large project to date, except in a purely cursorial manner. We've since moved to using Enhydra [enhydra.org] as our framework for using Java on the web. I highly recommend it, but also check out some of the stuff over at the Jakarta Project [apache.org] for some other alternatives to JSP.
Mark
Re:Rant about separation of code and HTML (Score:2)
Now, sure, with JSP and the like, it does seem that all you'll be serving is web pages, so why not intermix the HTML code with Java code? What if with the change of one line, you could run the JSP as an independant app (no browser required?) -- or in text mode? Or whatever other interface might come along next? It's much easier to do that separation now that if the next big thing comes along, you can easily adapt your program, than to rewrite from scratch.
CPU power needed to backend JSP pages? (Score:2)
Re:Garbage (Score:2)
Re:Garbage (Score:2)
2) What is your problem with cookies & javascript?
Re:Say what? (Score:2)
Apparently because it starts with an 'i', ends with an 'n', and has 18 letters in between...
Cheers,
Tim
Would you prefer Visual BASIC? Or COBOL??? (Score:2)
At the same time, in a typical business programming environment, all these criticisms are 98% irrelevant. Very often, in these environments, the alternatives are things like Visual BASIC - or COBOL! Languages like Python on the practical side, and Scheme or ML on the academic side, are no more on the radar of most business developers and their bosses, than Smalltalk ever was.
The reasons for this are many, complex, and intertwined, ranging from history and comfort factors to industry support and available tools. But a big part of it is that the proportion of programmers with the CS experience to recognize the flaws in Java are miniscule. To those happily using it, Java seems like a hell of an improvement on what has gone before, and the criticisms of it seems hopelessly abstract and theoretical.
Advanced features take decades to reach programming languages used for business. The evolution of business programming languages so far goes something like this: FORTRAN, COBOL, BASIC, assorted 4GLs, Java. Progress, don't you agree?
Unfortunately, ubiquity in business translates to ubiquity elsewhere, which is partly why Java has started becoming popular as a teaching language. Actually, compared to Pascal which has been a common teaching language in the past, Java isn't bad. For those wanting an "applied" degree that'll let them go out and get a decent job as a programmer, it'll work. But it is sad that people who might aspire to more are being taught Java as a prototypical programming language. Luckily, the smartest, most inquisitive students won't be satisfied knowing just one rather constraining language, so they'll find alternatives.
Re:Anyone can do a better job that Sun (Score:2)
It's not a pity for analysts (and wankers) who want exactly the sort of information you're complaining about, presented in the style that you're complaining about. Developers, I'm assuming, are expected to have enough intelligence to track down the Java Developer Connection [sun.com], where they would find a clear and concise introduction to EJBs [sun.com]. Or, if they wanted something a lot more in depth, they'd take a look at the EJB specification [sun.com], which thanks to the good design of Sun's site is merely three clicks away from the front page of the Java site.
The page that you complain about (http://java.sun.com/j2ee/overview.html [sun.com]) is a relatively good non-technical overview of J2EE, and doesn't pretend to be anything else. However, having found it, a quick click on 'documentation [sun.com]', followed by 'tutorials [sun.com]' takes you to yet another developer-level introduction to J2EE which seems to fit your requirements a lot better.
The only problem I see with the information provided is that it's not great for impatient developers who can't be bothered to look round the site. Perhaps if you'd spent more time reading the navigation options than 'mindless marketing drivel' then you'd have found what you wanted more quickly.
Incidentally, I always find that you get better results when complaining about issues like this if you at least run your mail through a spell-checker first. ('pitty', 'particulary', 'nosence' etc.) It's always helpful to make a good impression when what you have to say is inherently negative.
Re:Garbage (Score:2)
So you are complaining about:
Soooo, the first thing has nothing to do with JSP, which is server side, and the second thing is about how you perceive the trade-off between performance and content.
Given that you read (and post to) slashdot -which uses server side CGI scripts, and that you appreciate some customization, you do, infact like dynamic server-side content generation. Just as long as it's efficient.
JSP offers an alternative to CGI, which, in some situations can be faster than Perl because of the way the server deals with processes. (One process for the Java Virtual machine with threads handling
requests, rather than one process per CGI request).
So perhaps your rant was a little misdirected.
A better reason to dislike JSP is that it doesn't enforce the seperation between content and presentation. An XML + XSLT/XSP with Cocoon is an alternative that is, IMHO a cleaner solution.
Re:CPU power needed to backend JSP pages? (Score:2)
Re:Garbage (Score:2)
Are you on drugs? Dynamic content and JSP is not about flashy applets dancing on the screen. It's about HTML that is created on the fly. Like... umm.. well, slashdot.org comes to mind. e-Bay comes to mind. Amazon.com comes to mind. About a gazillion other database driven sites come to mind.
Even if you don't have dynamic content, it makes a lot of sense to use something like JSP, PHP or ASP (or why not Perl), because it allows you to separate the actual content from the template. If you do a re-design of the site and you have 50000 pages, it's easier to just change one template than to do some silly Perl script that does a search-and-replace on all of your 50000 html files, complete with re-building navigation etc.
Yes, you can misuse "dynamic content" but that's hardly a reason to say that "the only people interested in dynamic content are those pushing tools to create it". THAT is garbage.
Re:Java sucks! (Score:2)
Re:CPU power needed to backend JSP pages? (Score:2)
However, our internal development server is a dinky little Celeron 333 / 156MB RAM with the whole mess on it (MySQL, Apache, Jrun, etc). It works fine for our dev staff, but if several heavy pages are requested too close to one another, the machine bogs down horribly. Could your P200 dish out 10,000 pages a day? Maybe - if every hit was evenly spaced out throughout the entire day. But hits never come like that. You'd need a REALLY fast disk subsystem to keep up with all the swapping you'd be doing. Money that would be better invested in more RAM.
In order to run a DB driven JSP site, RAM is God. If you can avoid it, don't run the DB server and your web / JSP engine on the same machine. They're both RAM hungry beasts and I find it easier to put together two cheapo machines from spare parts with 128MB of RAM each than one cheapo machine with 256MB.
The most important thing to keep in mind is that regardless of hardware, your code is what makes the biggest difference. Sloppy, inefficient code will kill you - fast!
Depending on your content, you might be able to get away with a Slashdot style cache system. You write your JSP to generate the content (a story, etc), then store that in a static file. You can then either serve the static file directly (having a scheduler run the JSP-updater) or include the file into another JSPs output
You might be a little confused (Score:2)
"I think its much more natural to do things HTML style such as >(sorry, ASP code here) than try to spit out the HTML from inside a DisplayCustomer() function."
"Not possible if everything is inside a system.out.println() or whatever."
Separating of code and HTML does *not* mean that you will be coding out.println() statements from a Servlet or non-jsp code. You must remember that a JSP IS a Servlet. Some authors like to think of them as Servlets "inside-out".
That being said, the MVC and other designs do not dictate that you print the html from a Servlet... taht would be absurd. If you were do that, then you are not using the power of JSPs.
Separating of code and html is simply this (in a very simplified form)...
Code: Put all your business logic and backend connections here.
HTML: Put all your presentation logic here. This does not mean at all that you cannot put jsp code here... even lots of jsp code here. The point is simply that all the code should be related to the presentation and organization of the presentation.
Now I will admit that putting all the business logic and presentation logic in a JSP is much easier on "not-so-complex" sites. My approach above is in respect to more complex sites, which I deal with daily.
So for everyone posting their opinion regarding separation of code and html (or as I would put it, separation of business logic and presentation logic) please distinguish whether you are speaking about complex sites or not-so-complex sites.
Michael
-The requirements called for Windows 9x or better... so I installed Linux
Re:Rant about separation of code and HTML (Score:2)
You will find that in many companies, the job of web application programmer and site builder (HTML) are pretty clearly cut.
Phillip.
Re:Garbage (Score:2)
Slashdot is the kind of place where dynamic content is necessary - and there are dynamic parts of a lot of websites that are necessary. There's also a lot of junk.
I guess what pisses me off the most are things like ASP pages that I can't view on netscape on my SGI. Do these companies even realize they are losing my business? Because, more often than not, it's a small business running some MS web solution than a place like slashdot, or CNN.
I don't know. I guess I'm just in a bitch-and-moan mood when it comes to the web. I was trying to look up cellphone plans and half the places I went I couldn't even look at the offerings without cookies or javascript. And even then some of them wouldn't display the content in Netscape on Irix.
----------
You're all right, of course. (Score:2)
----------
Re:Dynamic Web Content? Philip & Alex. (Score:2)
Even if you don't go their AOLServer/TCL route, _Philip and Alex's Guide to Web Publishing_ is the best book I've seen about the goals and issues relevant to all non-static sites (plus a lot that's useful for static sites too).
JSP is a Sun marketing tool... (Score:2)
The Problems with JSP [servlets.com]
There are plenty of better alternatives out there - this article mentions some, just search past slashdot for more.
Rant about separation of code and HTML (Score:2)
In a lot of cases, I think its easier to just mix the code. Say you are presenting a customer a page to update his/her customer information. You retrieve the information in the database, then display it in a form. I think its much more natural to do things HTML style such as >(sorry, ASP code here) than try to spit out the HTML from inside a DisplayCustomer() function.
In pretty much any programming language I've ever used, the code must somehow interface with the GUI. So if you're doing web programming, I think one should be just as comfortable with HTML as they are with their programming language. To me there are many situations where it is more appropriate to have code interspersed with the HTML than to try to output everything from the classes and functions you are using.
In my experience, this can be just as flexible and maintainable as doing everything within the code. In the above example, I retrieved the customer record and displayed it in a table. If the underlying data ever changed it would easier to fix this than it would be to change the function. And doing this doesn't prevent me from using classes, functions, or HTML templates that speed development and promote code reuse.
Not only that, but I have to admit, sometimes when I am working with complex tables(tables that have rowspans, colspans, or nested tables) I will often view them with a visual editor like FrontPage, not because I don't know HTML, but because its faster and more productive. I can still do this if I have code inside the HTML, rather than the other way around. Not possible if everything is inside a system.out.println() or whatever.
Re:Nothing But Good Vibes (Score:2)
What I found was that Bean object had trouble loading via the <jsp:useBean> tag. That tag would load a default Bean with no problems. The book recommended that multiple beans of the same type could be loaded as follows:
<jsp:useBean id="myBean" class="MyBeanClass"/>
<% MyBeanClass myBeanArray[];
for (int i=0; i < myBeanArray.size(); i++) {
myBean = myBeanArray[i]; %>
<jsp:getProperty name="myBean" property="myProperty"/>
<% } %>
Theoretically, the for loop sets each object in the array to myBean, then displays "myProperty". In Tomcat, myBean in the jsp:useBean context and myBean in the scriptlet context were two very different objects. In fact, that code gave me an error for not declaring myBean as a MyBeanClass instance. I found other people with similar problems, but no official bug report or solution/workaround. Any idea, my geek brothers?
Re:Java sucks! (Score:2)
- harborpirate -
Re:CPU power needed to backend JSP pages? (Score:3)
--JRZ
Re:Java sucks! (Score:3)
UDP? As in UDP/IP? It's right there with the rest of the networking classes: java.net in such classes as DatagramSocket, DatagramPacket and DatagramSocketImpl.
Re:CPU power needed to backend JSP pages? (Score:3)
Nothing But Good Vibes (Score:3)
I had never used JSP before - I had never even written Java code! But the book was written well for someone with a background in scripting languages, and I found myself working with JSP projects easily in no time at all. I even learned Java from that book, and did so well enough to get a new job and excel at it.
As far as the book is concerned, there are two parts which especially interested me. The first was their overview of Javabeans, which was done clearly and concisely. However, you should know that when I set up the Apache Tomcat JSP server, Javabeans were busted pretty bad (just a warning).
The FAQ example (I believe it is chapter 9) was also excellent, because it introduced some very good methods for web application design. The first is the FAQRepository, which encapsulates DB calls into a single class. This enhances portability and allows changes to be implemented quickly in the case of a DB software or design change. The second is the so-called "octopus" design, whereby an intelligent central servlet does the bulk of the processing, and then passes control off to a JSP "tentacle" for minor alterations and display. This keeps code clean and organized, and allows for great scalability.
I would highly recommend this book to anyone looking to learn JSP as well as develop a strong technique. I know it did wonders for me.
Sorry about all the buzzwords ;)
Dynamic Web Content? Philip & Alex. (Score:4)
Sure, you could read this book...
OR, you could read Philip and Alex's Guide to Web Publishing [arsdigita.com], and learn everything there is know about creating dynamic web sites, for free. That's right; click on the book, and you'll be face to face with one of the best books (and websites) that I have ever read, period.
I've bought the book 3 times in print, because it has the highest circulation amongst my book collection.
Re:Garbage (Score:5)
I REALLY wish people would stop immediately associating Java with eye-candy applets. This is, IMHO, the weakest use for Java.
As a server side language Java is extremely powerful, primarily due to the huge number of APIs available but also due to the basic design of the language and the core API. Java also promotes code reuse better than any mainstream language out there (once again this is my opinion).
If you don't like Java as a server side language then don't use it. But please, stop saying Java == applets or JavaScript and using that as a reason to trash the Java platform.