Core Servlets and Java Server Pages 74
| Core Servlets and Java Server Pages | |
| author | Marty Hall |
| pages | 575 |
| publisher | Prentice Hall |
| rating | 5 |
| reviewer | jayakrishnan |
| ISBN | 0130893404 |
| summary | The basics are well covered and there is lots of practical information, but the coverage is not comprehensive. |
The book is made up of three parts: Servlets; Java Server Pages; and the supporting technologies.
The nine chapters in the first part are about Servlets, if you read through all nine, you will learn how to handle form data, access the request headers, generate the response, handle cookies and track sessions. The Java way of separating presentation and content, called Java Server Pages (also called "put everything in a single file!"), is discussed in the next section. This section includes using JavaBeans with JSP, creating custom tag libraries and a chapter on integrating servlets and JSP. The third part has three chapters on the supporting technologies -- HTML forms, using Applets as servlet front-ends, and JDBC and Database connection pooling. The appendix provides a short summary of information from each chapter and the book does has a Web site from which you can download the source code for the examples.
The structure of most of the chapters is the same: Introduce a concept, explain the basics and then develop an example that illustrates the concept. In the chapter on "Generating the Server Response: HTTP Status Codes," the various status codes and their purpose are explained followed by an example which is developing a single interface to various search engines on the Web. The other examples developed in this book are a resume-posting service, using cookies to provide customization, the mandatory shopping cart example, and an online travel agent.
Also, scattered along the book are specially marked techniques, notes and warnings called the "Core Approach." For example if there is an error in the dynamic portion of your JSP, it may not be properly translated to a servlet and the server will present a page describing the problem. But if your browser is Internet Explorer 5, then you will see a standard error page instead of the one with the error message. This "user-friendly" feature has to be turned off while debugging JSP pages and this is one of the Core Warnings.
Even though the Servlet API provides a standard for writing portable code their deployment is not standard, at least until Servlet 2.2. While Sun's Java Web Server provides a graphical applet, Apache Tomcat uses an XML file for configuration. This book talks about three servers in specific and provides instructions on how to get your code running with Tomcat 3.1, Java Web Server 2.0 and JavaServer Web Development Kit. There is a section in the first chapter that talks about the installation of each of these servers and specific information on where your classes and jar files should go. Then as we go along the text, the specifics are discussed like how to specify the initialization parameters for servlets or how to configure the server to make the servlets generated from JSPs persistent.
Though the basics are covered well, some serious topics are left out, and the discussion is inadequate on others. The book's coverage of security is very limited, for instance. There is an example of protecting a page using the basic authentication provided by HTTP, but we need more than that for any site that takes a credit card number. There is very limited discussion on SSL and on what it takes to build a secure Web site.
Servlets can (very usefully) provide internationalization using either HTML character entities or Unicode escape sequences. This involves setting the Content-Language in the header and setting the char set in the content type while sending the response. By reading the preferences set by the user in the browser for his language and char set, it is possible to send content in the user's preferred language. The topics of internationalization and customized content generation, though, are totally left out in the book.
For the deployment of Java-based Web applications, the servlet and JSP specifications support a single Web archive file similar to the jar file. The war file will also contain HTML files, images, and applets along with an XML based configuration file, which can then be placed in the directory on the Web server. Though it is mentioned in the introduction that the book covers servlet 2.2 specifications, the Web application archive is not discussed. Also missing is discussion about the new methods in HttpServletRequest that support role-based authorization.
With the knowledge of Servlets and JSP gained from this book do you get enough wisdom to architect a project? No. I wish there was a chapter which stepped back away from all the code and talked about design at a higher level. All the information is there in the book, but only scattered about.
Finally, I have one major gripe against the publisher---Prentice Hall. The margins used are too wide compared to all other publishers, making this book much more thick than required. This, along with the very large font used for section and sub-section titles makes the book look very ugly and the appendix can be used as an example on how not to format text.
To summarize, if you are a Java programmer who wants to start server side programming then this book is for you. The introduction is gentle and the book is illustrated with numerous code samples that you can extend and adapt. But the coverage is not comprehensive, as the discussion on security is limited and internationalization and some topics of the Servlet 2.2 specification are left out.
You can purchase this book at ThinkGeek.
Re:Oh the day.... (Score:1)
--
MailOne [openone.com]
Re:Oh the day.... (Score:2)
Re:Since many 'disable Java/JS' why code in it? (Score:1)
Heh... this is my favourite. We were auditioning some web design firms a while back and I was sure to uninstall the flash plugin & nuke the cache an hour before they arrived, so that their demo times would be more realistic.
Nothing better than watching an overpaid 23 yr old wannabe flash hotshot stumbling through the flash plugin download & installation.
"oh.. you don't have flash.. ok.. well uh.. this will just take a second or two for most people.." (cue 15min of pain as he watches his asking price for his work sink)
oh and you forgot your end tag:
#end RANT_AGAINST_BAD_WWW_DESIGN
Re:Since many 'disable Java/JS' why code in it? (Score:1)
What is good about these things is precisely that you can write display logic in your JSPs or servlets that will output a text-only links for old modems, large fonts for the visually-impaired or whatever you want. The business logic should be another layer deeper and is common to the entire website.
Re:Oh the day.... (Score:1)
It looks like a nicely structured language with clean syntax that leads to good coding style.
Shall I guess that your only other experience with OO languages is C++? :-) Java is definitely a step up from the horrors of C++, but a survey of all the other (portable) OO languages will turn up far nicer alternatives. Heck, you don't even need to leave the C family to find Objective-C. And while some might not like the syntax of Lisp, CLOS provides a very powerful, advanced OO framework. Different tools for different tasks.
What you have quoted doesnt prove your case (Score:1)
I am specifically referring to the "Dynamo" link.
The link in question describes a method used to do run-time optimization. Clearly runtime optimization is something that statically compiled programs can benefit from too - not just JIT compiled ones. Thus I feel that the static compilation approach will still retain a speed advantage.
Thanks for the link, BTW! It was very educational.
Web sites that do not use JSP (Score:1)
Real web sites don't use JSP.
it's not the hits (Score:2)
These days, i'm doing a stint in operations - designing network & server (ie physical) architecture. Some other guy is heading the team doing the software. He's a Java guy so it's all servlets, jsps' & ejbs'.
I'm not convinced Java gives you *any* performance or scalability improvements, we spent time making sure we had failover redundancy in place - the same technique works equally well whatever the technology. Things getting slow? Add another server to the load balanced pool. The problems are to do with state & session synchronisation - the bottlenecks here are network & database related. The answer? faster networks, bigger databases.
Java costs a *lot* more to develop than some scripting language like Perl. Seen the cost of a Java coder recently? Seen how long it takes to change a jsp and recompile the project? So it would be cheaper and easier to develop in some scripting language right?
That holds true for simple projects, problems appear when you start doing something more complex. Java provides a strong, well designed framework for complex engineering projects and that's its real benefit - it scales across multiple engineers. Volume can be addressed cheaply with hardware, complexity cant.
Re:Speed is not Java's biggest problem (Score:2)
Which JVM did you use? One with jit or one without?
Do you know that tomcat is(was at lest for a long time) the slowest java servelet engine?
Its a reference implementation, you know?
On a standard linux box a modern java only EJB/Servlet server like resin: http://www.caucho.com/ or orion: http://www.orionserver.com/ outperform PHP by magnitudes (factor five allready measured).
Memory footprint: less then 10MB.
Regards,
angel'o'sphere
Re:Oh the day.... (Score:1)
based hosing architecture called LeXml (which is
not yet ready to release to the public) that is
quite fast. Servlets are quite fast.
JSP is an ugly hack. There are two things you
should not judge the Java platform on: JSP and
applets. (Not that applets are a bad idea.. they
are just badly implemented in most browsers..)
Java on the other hand is an extremely nice
very well structured language that facilitates
elegant programming, readability (unlike Herl
which looks more like what comes *out* of a
compiler), massive code reusability, and has
an amazing amout of ready-made functionality in
it's core libraries.
Java is great for server-side development and
development of cross-platform client software.
Re:forget JSP (Score:2)
Anybody who's used WebObjects should understand what I mean. This is, in fact, an open source project. It's currently fairly mature, quite stable and feature-ful, but I have not had time to set up a site, clean up the code and make it 'presentable'. If you're interested in helping, please send me an email.
a better book: design, technique, theory (Score:1)
if not, let me mention it. this book only covers JSP, not java, not jdbc, not servlets, not somebody half baked propiertary servlet library.
this book is good! we just did a major (4 month) upgrade of our commerical website moving from an ASP site running on NT, to a JSP, Servlet, and Java middleware running on Solaris and Linux boxes. this required retraining for a huge swath of our technical infrastructure, not just developers, but qa, project managers, tech support etc.
this book was great for that. chapter 1 should be read by anybody involved with building web apps, its a theoretical overview of what web development, including what is and isn't possible, availabe technologies and how they relate, etc, etc.
the next several chapters give a good overview of jsp, and proper design methdology. i reccomend the people i work with on non-jsp (php, and perl w/ template toolkit) web apps read these chapters. if you want to understand deep down how the MVC design pattern relates to web development this is the best intro i've found.
its also the only book i found with a strong intro to tag libraries. (though this might have changed since june)
all in all "Web Development with JavaServerPages" changed the way I think about web development. and it, combined w/ the OO perl book by Damien Conway, made Manning my new favorite publisher of tech books.
kellan
Re:it's not the hits (Score:2)
Re:An Alternative (Score:1)
Which I did. I've found that Mr. Notebook makes a very nice ebook reader. Manning Publications has put out several of their books in PDF format.
Aww shoot... it looks like they're switching over to a new ebook format for their newer books (like Up to Speed with Swing, 2nd Edition [manning.com], see the "cyberbook" link), and they're not saying what yet. This could be bad...
Re:Java is fine, but drop the speed claims (Score:1)
I don't know what you mean by "hasn't made it". It's widely used by the business world from fortune 100 down to mom and pop type businesses. There are millions of programmers with increasing demand (and corresponding increasing salaries). It's embedded as a language in most databases. It's become the most used language to teach progamming in schools. It's got several magazines and hundreds of web sites dedicated to it. It's got a whole bookshelf on barnes and noble.
By what measure are saying that it hasn't made it? It's an industry that's worth billions of dollars for goodnes sake. Just because there are no games or packaged apps it does not mean it hasn't made it. I'd say that java has done in 5 years what most languages never even dreamed of.
Re:Oh the day.... (Score:1)
Re:forget JSP (Score:2)
That's the old style of writing servlets, not what I am referring to.
If you build your web application out of XML and servlets, there is no markup or content in methods. The whole point of using XML (including XHTML and DOM) is to separate processing from presentation. In such a system, servlets only contain logic.
Re:An Alternative (Score:1)
Java is fine, but drop the speed claims (Score:2)
As for your qualms about the JRE download issue, get used to it - Sun and Microsoft are never going to see eye to eye, and Microsoft is always going to make it at least a token effort to run Java programs on windows. One could argue that there is no excuse for not including Sun's 1.3 JDK on linux distros - I don't know who is to blame for this, Sun or the distro vendors. One could offer that RedHat has done an end-run around this issue with gcj, but this technology is still somewhat flaky and arguably if you aren't compiling to the JVM, you should probably be using C++ anyway.
Its interesting to note that after five years, Java still hasn't "made it" - Microsoft stalling tactics and general bad attitude may have stalled Java adoption long enough to keep it from becoming a de facto standard.
Re:Since many 'disable Java/JS' why code in it? (Score:1)
Thank you your insightful comment(but what did I said which cased you to write. ^_^).
The book review is about JSP and servlet. As a matter of fact a good JSP (which in turn compiled into java servlet) doesn't really require the client must have java enable.
Java has moving its focus from client-side to server-side year ago. In my opinion disabling Java applet wouldn't stop JSP and servlet, but it's bad thing indeed.
Any which way you can (Score:2)
For most of the slashcode sites out there, and most others that might be discussed, people need to realize that any old technology will do. Even the most braindead architecture will adequately push out pages for a site that gets around 100k hits a day or less - for such a site, any which way you want to generate pages is certainly adequate.
Things get interesting when you start climbing above the ten million hits a day range, when a lot of these technologies really start to fall apart. As intuition would bear out, the simpler technologies do better under greater loads.
It would be interesting to get better simulated load testing for these technologies - I would love to see how PHP, JSP, and mod_perl stack up to old standbys like SSI when the hits peak over 100 million a day or more. Such testing would be beneficial to folks who have to have the functionality of a full programming language, and ultimately need an answer to the question: "how many servers do I need to keep page rendering times under three seconds given this technology?"
Re:Since many 'disable Java/JS' why code in it? (Score:2)
The user does not require any special plug-ins or software, other than a normal HTML Browser to view Servlet and JSP generated HTML.
Re:forget JSP (Score:2)
JSPs, more than ASP, PHP or any of the other tag-based languages encourage you to shift the processing to servlets/java classes and simply use the JSP as a container for the HTML that frames your content.
Just invoke methods in your classes/servlets from your JSPs, instead fo writing any actual functional code in the JSP at all.
And considering that JSPs are compiled to servlets at run time, it seems odd to recommend using servlets over JSPs, since theyre both really the same thing.
Java introspection gives JSPs the cleanest way to handle form elements i have yet seen from a web-oriented language.
One line of code in your JSP invokes setter methods for all your elements on receipt of a form. Magic!
Servlets are far worse because you end up embedding chunks of HTML in your methods.
You can get around this in various ways, but there aren't many moe elegant ways to get around this than simply using JSPs.
shockwave.com uses .JSPs (Score:1)
Servlets are one of the most unrecognized things in the world. thousands of site's use them for backend processing but nobody knows it. It's that transparent.
Re:forget JSP (Score:1)
i think this is a very powerful model.
in fact its the same model that is trying to be accomplished with XSLT and Cocoon (for Java) or AxKit (for Perl)
however, XSLT is hard! its hard for developers to learn, its hard to debug, its hard to tune for performance. and it is very very very hard for your web designers to learn. I've done both, and I've tried to teach people both, and categorically (except for one brave soul) the designers who i showed XSLT plain out refused to work with it, while a few of them could be coaxed to do a simple if, and while in java.
i think style-sheets and projects like cocoon are going to start being really powerful in the next 6-18 months (especially combined with some of the really neat new xml technologies, like XPath, and Topic Maps) but for right now nobody really knows what they're doing, while JSP already has a set of reccomended (and documented) best practices.
kellan
ps. a true geek test. how do you pronounce the word "coax"?
Re:Speed is not Java's biggest problem (Score:1)
I'm not sure why they bother posting Java articles on slashdot at all, since this the readers of this page are nothing more than a bunch of perl zealots.
BTW, next time try using a completed java J2EE container in testing servlets, etc.. Tomcat is probably the slowest engine available.
Re:Since many 'disable Java/JS' why code in it? (Score:1)
Since 95% of browsers come with Flash, that was really not fair to your wannabe.
All new browsers that common folk use (IE and NN) come with Flash. And the people using older stuff are not likely to be the disposable cash demographic that WebRetail caters to.
I don't like flash myself, but people judge your image on pretty pictures. They will trust your site more when it comes with Flashy nonsense. -Brian
Re:Wrong (Score:2)
Exactly so. In fact, it's possible to build a much more reliable and maintainable solution by trying to avoid having code in the JSP at all where possible. Three elements that go towards achieving this goal are:
Put control code into a servlet, which then uses a JSP (or a series of JSPs) to provide the presentation side of things. The servlet can then trivially carry out pre- and post-processing on the request, as well as carrying out the actual logic behind the operation (or more likely delegating this to EJBs...)
There's a reason they put that <jsp:usebean> tag in there, you know. If you wrap the data to be displayed in a JavaBean, then you don't even need any Java experience to access it - just use the property get and set actions. Avoid <jsp:setproperty property="*"> like the plague, though.
Take that final step towards separating style from content by using well-designed custom tags. This way you can hide the Java implementation from people whose sole concern is the HTML view.
Tomcat is terrible. Resin is Great (Score:2)
Tomcat is a reference implementation that is moving toward being a viable product for small self maintained sites. I use it for testing because I find that its instability and open development strategy are plusses.
There are real commercial Servlet Containers that are much faster and more stable. Resin [caucho.com] is blazing fast, includes lost of fun gadgets (but start with plain servlets, please) and is OPEN SOURCE. It's free for small installations, but costs US$500 for commercial licenses. I use it.
What I really like about Resin is that it is rock solid. And nicely supported.
Servlets are at their best with complicated, large, or frequently updated sites. Consider a framework like Turbine [apache.org] or a templating engine like WebMacro [webmacro.org] or both to build a good quality maintainable site.
JSP is designed to emulate ASP. It's a great transition path. Now some taglibs exist to make it a viable platform for development, too. But a real framework is better, so consider one.
-B. Earl
Re:Java is fine, but drop the speed claims (Score:1)
Re:Web sites that do not use JSP (Score:1)
And by like token, i guess "real" websites dont use perl or php either. Zealot.
Re:Since many 'disable Java/JS' why code in it? (Score:1)
Re:forget JSP (Score:2)
You don't need to use XSLT to use the XML related standards for building web applications. You can implement transformations using a DOM API, you can take the xmlc approach used by Enhydra, or you can take any of a number of other approaches.
The essence of such an approach is that both the presentation (possibly in the form of XHTML) and the content are represented as data structures. XSLT is only one way of putting the two together. Manipulating the two data structures via a custom-written servlet is another, which is what I was suggesting.
nobody reccomends that you use JSP like PHP or ASP.
There is nothing in JSP, after all, that restricts people from doing full programming, including conditionals and loops. In fact, many JSP examples do just that, just the same way ASP and PHP programmers do it. That's fine for quick hacks (PHP is great for that), but it isn't good for large projects in my opinion.
Re:it's not the hits (Score:1)
cp my_jsp.jsp $IAS_HOME/APPS/my_app
That's in iPlanet, a pretty brutal J2EE app server not known for developer-friendliness. It doesn't get much easier...
JdV!!
nonstandard (Score:2)
Since XML/XHTML and the DOM give you a widely-used and pretty well defined way of doing just that, why not just build tools that conform to those standards?
Re:Since many 'disable Java/JS' why code in it? (Score:1)
Re:Java is fine, but drop the speed claims (Score:1)
One could offer that RedHat has done an end-run around this issue with gcj
Many feel there ought to be a free Java. Kaffe is one, gcj is another, yet the free VMs haven't caught on, presumably because they lag behind the Sun releases (inevitably so).
but this technology is still somewhat flaky
Nothing flaky about gcj... it's just not released yet. (Ignoring the 2.95 release for a moment, 3.0 will be much more complete.) The code is about what you'd expect from a development snapshot.
and arguably if you aren't compiling to the JVM, you should probably be using C++ anyway.
You think the VM is the only benefit of Java? Regardless, gcj has a rather nice bytecode interpreter in its runtime, and offers a nice hybrid of bytecode with compiled core classes. You'd be surprised how well it performs without a JIT, especially the load time.
Actually....(Amazon.com does) (Score:2)
Amazon.com does [bea.com]. So does eTrade and Priceline
Of course, some of these sites might be using more servlets than JSP's, but since JSPs are compiled to servlets there is no performance difference, anyway.
Read Sun's dot-com-builder website on how priceline [sun.com] was built sometime. It's pretty interesting (although full of marketing rubbish).
Re:nonstandard (Score:2)
Re:Wrong (Score:1)
Fast forward to a year later... we began looking at our pages and saying to ourselves, "What a bunch of convoluted garbage this is!" And then we set about doing it right, using servlets and JSP and beans in conjunction with each other. And behold, the heavens shined down upon us, and we had one kick a** piece of software.
The moral: use JSP, and use it right the first time.
Re:JSPs are simple (Score:1)
Instead, a JSP should have very little code in it. A few useBean: or getValue: tags, and possibly a for-loop or two. Leave the rest of the code in your Java classes.
Re:Since many 'disable Java/JS' why code in it? (Score:1)
I never said I would kill you for invading Japan. I said Ifd have to kill you to avoid the embarrassment of having the whole world believe a cretin such as yourself was the best my race could come up with for representation. Now that you mention attacking Japan, considering the grandiose mental prowess you have displayed here (and on other of my posts), I think they have nothing to worry about. A Ford F-150 will go many places, but unfortunately the ocean isnft one of them.
I donft know why youfre thanking me for showing you the light. The only thing I said was that you are a rube, a coward and an idiot. If thatfs the light you sought after your whole life in vain and you are finally able to have peace knowing that this is what you are, Ifm glad I could help.
Ifm not Canadian, but Ifm happy for you that you have the skills to detect those bastard Moose. Good for you.
Ifm not French either, but in another effort to keep you from looking foolish, thatfs a hat their wearing, not the shape of their heads.
Ifm not German, but congratulations on a spirited effort in spelling KRAUT correctly.
Also, since wefre talking about spelling, if you insist on contracting words like drinking, fucking, tipping, and other common, easy-to-spell words ending in gingh in order to avoid that elusive letter gGh that seems to trip you up so much, at least spell the parts you CAN type correctly. Adding the apostrophe would be a nice touch too. Ifve included the gcorrecth contractions for you to help you at least look like the town clod instead of the town fool. Here they are. Ifm typing slowly for you so you can keep up. Drinkinf, fuckinf, tippinf, and so on. Of course, you realize these arenft really words when you do this, but at least people will know what you are attempting to say.
Finally, congratulations on your commendable progress with gHooked on Phonicsh I could almost make out some of what you were trying unsuccessfully to say. Also, thank you so much for the copious amounts of appreciation you have shown my ass throughout all of Slashdot. I hope your hunting buddies wonft mind.
Java Server Programming (Score:1)
This is a good sources book which covers a lot of examples in JSP and servlet.
Besides, if you want to study Java, JSP and servlet from the ground up, Wrox's [wrox.com] Java Server programming [wrox.com] and Professional JSP [wrox.com] are pretty good books.
Oh the day.... (Score:2)
Oh the day when we see a java related story on slashdot without some java bashing. ooh... The internet is on computers now... Good for it
--Homer Simpson
I bought this book a month ago. (Score:3)
It is a nice overview of the technologies, and gives you a good sense of how things fit together, but I really recommend getting the two O'Reilly books Java Servlet Programming [bookpool.com] and JavaServer Pages [bookpool.com] if you need a more in-depth coverage.
Be warned, though, the Servlet book talks some about specific versions of the various servlet engines, and so it is getting a little long in the tooth in those sections.
Re:Since many 'disable Java/JS' why code in it? (Score:2)
Java, while not the fastest, easiest, or smallest language around, is a decent, universal language for coding web applications. NOT APPLETS, but server-side things. just like perl or c.
that is all.
----- go to www.questionexchange.com.
Speed is not Java's biggest problem (Score:1)
When it comes to heavy-duty bit manipulations, such as in cryptographics or graphical algorithms, Java doesn't do too well, but with JDK1.3 and HotSpot, I think the speed of Java is great for all other purposes.
The biggest problem IMO is the download. To make a client or standalone application, you still need the multi-megabyte JRE download. I guess it's like Netscape vs. MSIE; if you write a Windows or Linux app in C you get to use libraries that most people have already installed, just like MSIE is pre-installed.
But for servlets, Java is great since your users don't need the download. Easy to program, many libraries included and since they're standard, you don't have three third-party components using three different libraries that do about the same. You get increased security for free; no need to worry about buffer-overflow or formatting string attacks. An ASP that knows a bit about Java2 security (okay, it's too complicated for non-experts IMO) can easily put servlets from different customers in different sandboxes where they cannot interfere..
Now when gcj, japher or Kaffe and Classpath [gnu.org] are complete, I hope all the major Linux distributions will carry a full GPL-ed Java implementation so every Linux developer can depend on Java being pre-installed.
Too bad I signed Sun's non-disclosure license for jdk1.1 a few years ago, since Classpath wants to make a clean-room implementation.
EjB
JSPs are simple (Score:1)
Re:shockwave.com uses .JSPs (Score:1)
tomcat is terrible. (Score:1)
Anyways, the speed of a jsp and servlet depends on the software serving it. I've seen some software out there (orion i believe it was called?) that specs up to the speed of php serving.
Re:shockwave.com uses .JSPs (Score:1)
forget JSP (Score:2)
Consider using some form of XML or template system instead. For Java, you can get several servlet-based template systems, as well as a number of XML implementations (check xml.apache.org [apache.org]).
Java Servlet Programming (Score:2)
.technomancer
Excite uses home-grown variant of JSP. (Score:1)
mahlen
I hope he [Steve Martin] wins an Oscar [for Roxanne], because he has prepared
a tremendously funny acceptance speech. If the Academy members want to hear
it, they know what to do.
--Martin Short
Using JSP - real world example (Score:1)
Where I work uses Server-side java for all its business logic: Worldlingo.com [worldlingo.com]
Like any language, java has its caveats and benefits. We have found it exceptional for our purposes. We even farmed al lot of the core processing away from 3rd party software systems we use into a pure-java back end because we could do things far more reliably (and surprisingly, no performance hit). We also use a TurboLinux cluster to serve up our wares.
While java may not be for everyone, in my opinion, Linux, Apache and Java are a darn good combination (and don't get me started on databases ;)
AcidDan - 4 sleeps to the Space Odyssey :)
Re:Java is fine, but drop the speed claims (Score:2)
Benchmark here [javalobby.org]
I am sure there are a boatload of tests out there which "prove" just the opposite. The plain truth is that this really isn't an area where there is a definitive answer. Sometimes one is the better and faster tool, sometimes the other is. For those of you who seem to feel that the only way to get speed is to statically compile something (a la c/c++), you might want to have a look at an alternative approach. The following link goes to an article which outlines a different way of measuring the benefits and drawbacks of the static compile vs. VM speed question.
Dynamo [arstechnica.com]
Re:The coffee cup (Score:1)
Re:Speed is not Java's biggest problem (Score:1)
I'm working a lot with JAVA and recently with Servelets/JSP.
Perl is definitly NOT faster than JAVA.
If at all the environment under which PERL or JAVA runs make a difference. E.g. Apache holding the compiled perl script in its cache makes perl fast in conjunction with modperl.
OTOH, a descent Webserver for servlets is itself only a java program running on a VM, so Webserver and Servlet all remain as active (compiled) classes inside of the same process, just alike Apache and modperl. Not to forgett that a server JVM is something VERY different than those Win32/Linux client side JVMs.
There are a lot of descent webpages out here running with java technologie, e.g. amazon, or sun itself.
Well, for many circumstances the critics about the JVM speed was right, the first JVMs where incredible slow. And perl was from the first version quite fast, especialy in relation to shell scripts.
angel'o'sphere
Re:Tomcat is terrible. Resin is Great (Score:1)
Yes, true! And applets where designed to emulate ActiveX.
And PHP was designed to emulate perl and HTML.
Hm
Probably it was me, sorry then.
Regards,
angel'o'sphere
Re:Web sites that do not use JSP (Score:2)
Spread out over three or four machines, you could use almost any technology to do run a site that gets under a million hits. Hell, Tcl on one Pentium II could meet the demands for a hundred thousand hits a day.
Re:Web sites that do not use JSP (Score:1)
*one* Sun ET 10000 Server, hardware (plus some failover servers)
Solaris, Sun Microsystems Inc.
Oracle 8i(probably newer) data base server, Oracle Inc
WebLogic, Enterprice Java Beans Application Server , BEA Systems Inc
Sun JVM 1.3 Server, Solaris, Sun Microsystems Inc.
All three companies use amazon as their showcase for the underlying technologie.
If you go to the website of bea on the part industries you find several interesting sites running java enterprise solutions http://www.bea.com/solutions/industries.shtml
The first half year of 2000 I consulted at one of the bigest heavy industies company in europe, they replace all the old COBOL software for manufactoring control by Enterprise Java Beans, well this are not servlets, but its java.
Java is a subversive movement, everybody uses java except those you believe in M$ sales people.
And in german universities everybody teaches JAVA, I'm sure in the topic severside comuting M$ will be dead soon (lack of people willing to work with the technology).
Regards,
angel'o'sphere
Re:JSPs are simple (Score:1)
A. often reused code (such as creating a connection to the database)
B. Often reused code that does not generate output.
Beans are a pain in the ass. (ever forgotten to recompile when you've changed them? then spent half an hour hunting down that bug you fixed..) whereas jsp's recompile automatically. *shrugs* i see both sides of the situation, and its plain incorrect to say that one and ONLY one way is the right one.
Re:Web sites that do not use JSP (Score:1)
Re:it's not the hits (Score:1)
With Java (unlike mod_perl) you need that assymetrical harmonic converging parallel processing cluster.
Re:Speed is not Java's biggest problem (Score:1)
JSP and PHP is basicly the same, only the syntax of the in HTML embedded language is different:
a) in case of PHP it loooks perlish
b) in case of JSP its JAVA
Everything else is just the same, you have a server written in what languge you like, accessing DBs as you like.
If your server is written in JAVA, JSP is to be favored because you have no technologie or language barrier/gap.
I find it astonishig that all people ever programmed in PHP think JAVA is EVIL. Strange.
If you take a C++ programmer who has never seen PHP or JSP, he will not even see a difference (except the $ signs in front of variables in case of PHP) between PHP an JSP.
And further more: for each failed project done in JAVA/JSP, done by clueless people, I point out a failed PHP project done be equaly clueless people.
Regards,
angel'o'sphere
Wrong (Score:1)
An Alternative (Score:2)
"Web Development with Java Server Pages" by Duane K. Fields, Mark A. Kolb.
This provides a much clearer description of the technology, and some interesting discussion of architecture as well. My only complaint with this is that it does not cover servlets as deeply as it should - so get Core Servlets too.
Two words....Chapter 15 (Score:1)
The 'put everything in one file' goes right out the window with a good servlet and many 'view' JSPs.
While I agree with you that coverage of security is lacking, this is a topic better covered by a webmaster or site architecture book rather than a programming book.
Re:shockwave.com uses .JSPs (Score:1)
Delta Airlines Waterstone Consulting
Axtive Software Corporation MetaMarkets.com, Inc
Cambridge Interactive NMG New Media Group
Epicentric, Inc. PostalWorks LLC
Flashline.com, Inc. TheWorksUSA.com
Klicman Incorporated TouchNet Information Systems, Inc.
Linnebank IT Tradiant
Brainbench Home Depot
Re:forget JSP (Score:1)
Re:Since many 'disable Java/JS' why code in it? (Score:1)
Take your post for example. The Japanese language doesnft have gingh, stand alone ggh, and glh sounds in it. Also, the people of Japan donft eat dogs (besides, donft knock it until youfve tried it. I hear dogs taste great). Japan creates most of the best video games for morons such as yourself to lust after since you canft attain a job willing to pay you enough to afford one of these games. Let alone the systems to play them on. So, if you are going to make fun of someone's culture, try to at least know what you're talking about first so you don't prove to everyone reading your tripe that you are a fool.
As for starting a war with Japan, I think not. If a group of town idiots such as yourself gathered together to war against other races to defend the Caucasian race, I would have to kill you myself to avoid the embarrassment of having the rest of the world think that you were the best we could come up with as representatives.
So, my final request to you is this: Make yourself known coward, or shut the hell up!!!
Re:Oh the day.... (Score:2)
Hey, I'd rather not bash Java. It looks like a nicely structured language with clean syntax that leads to good coding style. Now, can you point me to a site that performs well that uses JSP? Because all the ones I've seen so far are just dog slow. [booksense.com]
I watch the sea.
I saw it on TV.
Disappointing (Score:1)
I learned a lot more from O'Reilley's book Servlet Programming with the tea kettle on the cover than I did from this book. Once you realize how the special tags work for JSP it's all Java from there, no real special tricks.
I would have like to have seen this book expound more on using Taglib and stuff like that. It just wasn't all it's cracked up to be. There's a Professional JSP book, anyone care to review that?
A book for servlets? bah. (Score:2)
I don't know JSP pages, so they might be worthy of an entire book.. but servlets were something I picked up in a day or two.
My site [half-empty.org] runs Glasscode, a Slash/Scoop like engine and then some written in servlets. The abstraction you can provide with OOP made certain features pretty easy, such as droppable components and "Glassboxes" similar to slash's slashboxes. The OOP Java provides also makes it rather expandable.
It's going GPL sometime around new years.