Comments on Jon Stevens Article
I enjoyed Jon Stevens article ["JSP, You Make the Decision," Vol. 6, issue 7].
I'm frustrated by all the limitations outlined in the article. I am interested in the Velocity template solution; where can I find more information on the Velocity/Turbine project? I'm tired of "fighting" with JSP and all its marketing hype; it's not really a good MVC solution for complex Web applications!
Mark A. Sellers
P.S. The above is my opinion so don't blame WorldCom!
I hated the article from Jon Stevens on JSP alternatives [Vol. 6, issue 7].
He did not discuss Velocity or its intended purpose, but jumped into picking apart JSP against Velocity. He focused solely on the benefits of Velocity, and then hoped we enjoyed his tour of "alternatives." I felt like I was reading one giant anti-JSP gripe-fest.
His examples of JSP code are contrived, purposely written poorly to make JSP look weak.
Having worked in ASP, Perl, ColdFusion, and JSP, I can say that JSP cuts my coding time by more than half, through the use of tag libraries, etc.
My biggest beefs are:
1. Jon talks about the transform->compile process in JSP, saying that it has to recompile the JSP each time a request is made, which is blatantly untrue on many platforms. Maybe when Jon was still coding JSP in 1998 that was true.
2. Jon also says that JSP breaks the vaunted MVC design and you have to embed HTML in the code, but then goes on to show us Listing 7 in Velocity, which clearly has HTML embedded in the middle of his code. What's with the double standard?
3. Jon speaks about how HTML programmers won't understand notions of scope, or grasp complex programming issues. True, most HTML designers don't know about coding more complex applications. So don't let them do it! Many shops I've worked with complete the design and HTML framework, the basic templates of the site, and then the back-end programmers complete the inclusion of the page logic.
Next time if you're going to talk about alternatives to JSP and discuss the problems in JSP, include Cocoon, Velocity, and other Java solutions, and get someone with a more open mind to evaluate them.
I just read Jon Stevens article about JSP, Struts, Velocity, etc. I was really pleased that I'm not the only one that doesn't like JSPs that much. Great article!
Couldn't have said it better... :-)
The article by Jon Stevens on JSP was the most unbelieveable and unadulterated rubbish that I have ever read! (perhaps excluding Microsoft press releases). Not only were his arguments vacuous and just plain wrong, he showed he had absolutely no understanding of the issues surrounding the two concepts (push versus pull) whatsoever. I am very, very disappointed in this article.
I am interested in what exactly you think is unbelievable about what I wrote. I attempted to stay very technical and detailed and the points against JSP are actually valid points. What parts of my statements did you find vacuous?
I'm also interested in what part of the Pull versus Push model you think I don't understand. I wrote a document that has been available on the Jakarta Turbine Web site (http://jakarta.apache.org/turbine/pullmodel.html) for over seven months now that clearly shows my understanding of the Pull model. If there's something inaccurate about what I said, I would appreciate you clueing me into what is wrong so that I can correct it.
Last, I would appreciate it if you would take a few minutes and evaluate Velocity. The reason is, I understand that it's difficult to have someone stand up and point out faults in a technology that corporate marketing is telling everyone they should be using. However, I believe it's always good to keep an open mind, an open view, and a lookout for other technologies that may actually do a better job than the ones pushed on us.
Jon [email protected]@latchkcy.com
Build to Spec" by Liz Blair is a wonderful article [JDJ, Vol. 6, issue 7]. It provided excellent insight into differentiating between and architecting with the many components of J2EE.
Need an Investor?
I enjoyed Jason Briggs's article, "A Beginner's Guide to Writing Applications for the MID Profile" [Vol. 6, issue 7]. I would like to know if you're planning on having a second, third, or nth part to the above article with more practical and realistic examples? If the answer is no, could you recommend a book on this subject?
And good luck on your new Java-enabled device to take over the new generation. Let me know if you need an investor.
JavaOne Show Review
Ajit Sagar's article was very well balanced and nicely done. I attended both 2000 and 2001 and had the exact same impressions. His review was in sharp contrast to that of a competing Java periodical, which was so rosy as to make me wonder whether they had been at the same conference at all.
Thanks, Mike. The effects of the economy were fairly obvious. Besides the attendees, I also chatted with the folks at my hotel and a couple of cab drivers. They are the best sources for sensing the pulse of such events. I'm also glad to hear that JDJ was able to cover the event to the satisfaction of readers like you. Letters such as yours make it all worthwhile.
Ajit [email protected]@sys-con.com
Insignia on Jeode
The review of the Jeode platform [JDJ, Vol. 6, issue 8] is welcome exposure for Insignia Solutions, but the context in which our product was evaluated doesn't give your readers a representative picture of the product's true performance attributes. While pitting the Jeode Embedded Virtual Machine (EVM) against four JVMs employing Just-in-Time (JIT) compilers in a memory-rich NT desktop environment makes for an interesting race, it doesn't reflect the real choices developers have when deploying a JVM in a memory-constrained device.
Jeode technology works well on NT but is not intended for the desktop environment. However, in constrained environments, the dynamic adaptive compilation (DAC) approach that the EVM employs has proven to be much more effective than interpreter-only or JIT compilation approaches.
In benchmark tests where memory resources are freely available - like those conducted by JDJ - JIT-based JVMs will shine because they can fully compile a small application at start-up so that the whole application runs as native code. But this is not representative of real applications, which are much bigger and dynamic. So while JIT-based solutions can deliver fast performance for some small applications, particularly benchmarks, they do not scale to larger, real-world applications on resource-constrained devices.
DAC technology delivers the best possible performance in memory-constrained devices, because it compiles the most frequently executed code without incurring the overhead penalties associated with compiling infrequently executed code. It's competitive with desktop JVMs employing JIT compilers in a NT environment, but its performance attributes are best observed in the native resource-constrained environment for which it was designed.
Gary M. Katz, APR
Senior Manager, Corporate Communications
While I might agree with Insignia's arguments regarding comparisons between DAC and JIT technologies, I stand by the review. Jeode was also tested on a Compaq iPAQ (as part of the iPAQ review) - exactly the type of resource-constrained environment mentioned - so it was an interesting comparison to look at its performance against JVMs in a completely open environment (memory-wise, that is). I think the fact that Jeode held its own against the "big-boys," in an environment it is not suited for can only be seen as a selling point.
Jason [email protected]@sys-con.com
Helen Thomas's Article
I read Helen Thomas's article "Accelerating Java Web Application Environments" [Vol. 6. issue 7] and wanted to tell you how I enjoyed it. Although her article focused on wired dynamic Web sites as apposed to the wireless Internet, I'm very interested to see how these spaces evolve together as Internet standards continue to develop and true 3G technologies catch up with developer's applications.
The new look of JDJ doesn't work.
1. Many articles no longer include listings, which makes reading the articles impossible unless [you are] seated next to a monitor.
2. The new tendency to print text in "artistic" colors like lavender, olive, and pale gray results in text that's nearly illegible.
My favorite monthly magazine has "evolved" into a chore to read. Please stick to high-contrast color schemes.
Thank you for that and I will pass on your comments to the production department. But you mention nothing of the quality of content, which has gone up. How has that fared with you?
Alan [email protected]@sys-con.com
But I Love the Content
I was trying to keep my note short and sweet. I love the content, and recognize the changes in having essentially three separate magazines between the covers. There's no question about it being at the top of my "to read" pile, and I get one of everything, including JOOP and the lesser-known mags.
You used to do a fantastic job of printing edited listings that illustrated the article. It used to be a joy to read the only magazine that printed enough code to support the context of the articles.
I do like the color schemes for various articles. Just use high-contrast combinations for the text/code.
The views and opinions are those of the readers and do not necessarily represent the views and opinions of their employers.