Assuming you've heard of "design patterns" I'm guessing you can figure out what an anti-pattern would be.  The website http://www.antipatterns.com/thebook.htm refers to them simply as "what does not work".

Googling for "monolithic jsp" leads one to the conclusion that this is not only a anti-pattern, but a particularly egregious one.  So you wouldn't think that the Java Developer's Journal would advocate their usage, would you?

But that is precisely what they do in an article titled "Back to Two Tiers and Plain JSP" in their July 2005 issue.  What was the author thinking?

For one thing it seems he is conflating "architecture" and "design pattern".  Over and over he refers to "MVC Architecture", but Model-View-Controller -- MVC -- is not only generally recognized as a design pattern (rather than an architecture), but as THE design pattern for overcoming the monolithic JSP anti-pattern.

Furthermore it seems he is conflating the notion of tiers with each of the facets of MVC.  Just because "model" plus "view" plus "controller" makes three, does NOT mean that MVC can only be implemented in an N-tier (more than two) architecture.    

Although the view invariably displays in one tier -- the client -- there is nothing precluding the use of a simple, 2-tier, client-server architecture, with both model (data) and controller (business logic) residing on the same tier.  On the other hand, there is also nothing precluding you coding an n-tier (three or more) application in nothing but JSP, replete with scriptlet code using the java.net library for communicating with other servers/tiers -- nothing, that is, except the reinventing-the-wheel anti-pattern, considering that this is what EJB remoting addresses.

Lest you cringe, I let the EJB genie out of the bottle for a reason, because I suspect that EJB-backlash might be the motivation for advocating "plain JSP".  Over and over the author uses the adjective "complicated" in association with Java, and I don't entirely disagree with him.  It's gotten so bad there is a new acronym -- POJO, or Plain Old Java Objects -- and if POJO's are simpler than EJB's, then Plain JSP must be simpler than most Java web development, right?

Not so fast.  After all, Einstein, who never programmed a lick of Java, knew that "everything should be as simple as it is, but not simpler."  And plain JSP is just too simple.  Why?

Rather than a rehash of the "monolithic JSP" anti-pattern, let me just point out that to use nothing but JSP is to sacrifice the underlying power of the Java web development platform, the servlet engine.  After all, all JSP's in the end are servlets, but not all servlets are JSP's.

A remarkably powerful feature of servlets you sacrifice if using plain JSP's is the RequestDispatcher object.  Per the servlet API's specification, these are created by the servlet engine, and they allow you to forward requests to other resources, including JSPs.  This capability allows even the beginning Java developer to avoid the monolithic jsp anti-pattern and move toward the MVC design pattern, by coding the model and controller in the servlet layer, and using JSPs only for what they shine at, view logic.

Plain JSPs, with business, data access, and view logic rolled into one, should never be used for anything but the quickest and dirtiest prototype.  Period.