Saturday, September 01, 2012

The Dave Super Duper AJAX Exception Handler

This is a write up I did for a client when they were having a hard time troubleshooting an ajax application. I think this info would be generally useful so I thought i would throw it up on my blog.


We are observing intermittent errors through the jmeter tests and also through interactive tests. The errors are in a format such that:

  1. The AJAX client cannot respond appropriately to the error.
  2. They provide no useful information (to the client programmer or the user).
  3. Load test failures are hard to interpret
  4. Its difficult or impossible for the ajax client to know for certain if there was an error.


Server-side error handlers that log a message but do not inform the caller that anything went wrong.


All JSON calls should return one of two things:
  1. a valid response or
  2. a deliberate json error message, one that that the ajax client can make use of (i.e. try again, inform the user, send an email to cpd, etc). Also, it should aid in debugging.

Unintended AJAX Responses
As it currently stands (in the app we are troubleshooting) the JSON calls sometime return a third thing: an indeterminate, unintended response. A response that was not deliberate but rather accidental. This type of response cannot be handled appropriately by the AJAX client.

The unintended ajax responses that we have observed (using jmeter, interactively with firebug and looking at the code) include:

  1. ajax calls returning html
  2. ajax calls returning status code 200 and no response body (html, json or otherwise)
  3. unintended json: an error occurs server-side, and is only half handled: i.e. its logged to the server logs, but then a half-completed json response is returned to the client.

All three of these make it hard for the the ajax client to respond to errors. They make it hard for the ajax client to even know if there was an error. Its not enough to just log errors, they must be handled as well.

The Ultimate Awesome AJAX error handler

This secret tip will save you 1000s of hours of requesting and dealing with log files, especially when used in conjunction Firebug-like tools or with jmeter. This is one of the most useful tips ever, especially in this client's environment.

Also, its very difficult to associate a message in the error log with the bug detected by a UAT tester. It's even harder to connect an error in a load test with a line in the error log. Even if everyone has perfectly synchronized clocks.

So here is a generic version of the error handler (for use with Spring):

} catch (Exception e) {
model.addObject("errorCode", e.getClass().getSimpleName());
model.addObject("errorMessage", e.getMessage());        model.addObject("stackTrace", Util.serializeStackTrace(e));

If you add the error handling changes that I suggested in the last email, UAT testers and keynote test scripts will instantly know "it was a cmllink" problem or "it was a dod problem", without having to:

  • request log files
  • wait for log files
  • spend hours sifting through megabytes of irrelevant information in the log files
  • spend hours trying to correlate one of the million log messages to what happened in the browser.

The key point is that the actual error (the relevant error, the one that happened 8 layers down in the app) must bubble to the top level error handler and get send back to the client in a format the client can process.

Saturday, August 04, 2012

Multiple Concurrent Versions

Multiple Concurrent Versions is the term I use to describe a practice for deploying multiple versions of a web app at the same time. Technically, the concept applies to any kind of deployment bundle, but Java web apps make a good example.

Here are the basic precepts of the practice:
  1. We assume that the thing being deployed, the deployment bundle, is represented as files and folders.
  2. Physically moving the deployment bundle to the deployment target (the runtime environment) is a distinct step from activating a particular version.
  3. The deployment target will, at any given time, contain multiple versions of the same deployment bundle: 
    • old versions that used to be in production 
    • old versions that never made it to production 
    • the current production version 
    • future versions that are very close to production ready
  4. Multiple versions are concurrently deployed and accessible at the same time via version specific urls:

    The current or default version can be accessed via a version independent url:
  5. Activation is the process of marking a particular version as the default version. 
    • Changing the default version from an older to a newer version is called a rollout. 
    • Changing the default version from a newer to an older version is called a rollback.
  6. Each deployment bundle version should have a cryptographic identity (i.e. sha).
  7. Concurrent versions should be isolated. That is, a bug in version 8 shouldn't be able to kill version 7. 

Jar Hell

I recently was called in to help troubleshoot an application. It was a java web app: a war. When I looked inside the WEB-INF/lib directory, here is what I saw:
  1. activation-1.1.jar
  2. asm-3.1.jar
  3. axiom-api-1.2.12.jar
  4. axiom-dom-1.2.12.jar
  5. axiom-impl-1.2.12.jar
  6. axis-1.1.jar
  7. axis2-adb-1.6.1.jar
  8. axis2-codegen-1.6.1.jar
  9. axis2-kernel-1.6.1.jar
  10. axis2-mtompolicy-1.6.1.jar
  11. axis2-transport-http-1.6.1.jar
  12. axis2-transport-local-1.6.1.jar
  13. axis2-xmlbeans-1.6.1.jar
  14. commons-beanutils-1.7.0.jar
  15. commons-beanutils-core-1.7.0.jar
  16. commons-codec-1.3.jar
  17. commons-collections-3.2.jar
  18. commons-configuration-1.2.jar
  19. commons-digester-1.7.jar
  20. commons-discovery-0.2.jar
  21. commons-fileupload-1.2.jar
  22. commons-httpclient-3.0.1.jar
  23. commons-lang-2.1.jar
  24. commons-logging-1.0.4.jar
  25. commons-logging-api-1.0.4.jar
  26. dac-client.jar
  27. dealer-locator-pojos.jar
  28. DealerLocatorWebServices-client-1.1.4.jar
  29. dom4j-1.4.jar
  30. ehcache-core-2.3.0.jar
  31. ehcache-web-2.0.3.jar
  32. ejb-api-3.0.jar
  33. httpcore-4.0.jar
  34. isorelax-20020414.jar
  35. jackson-core-asl-1.7.1.jar
  36. jackson-jaxrs-1.7.1.jar
  37. jackson-mapper-asl-1.7.1.jar
  38. jackson-xc-1.7.1.jar
  39. javax.ejb_3.0.1.jar
  40. javax.jms.jar
  41. jaxb-api-2.2.2.jar
  42. jaxb-impl-2.2.3-1.jar
  43. jaxen-1.1.1.jar
  44. jaxrpc.jar
  45. jersey-core-1.6.jar
  46. jersey-json-1.6.jar
  47. jersey-server-1.6.jar
  48. jettison-1.1.jar
  49. log4j-1.2.8.jar
  50. mex-1.6.1-impl.jar
  51. msv-20020414.jar
  52. neethi-3.0.1.jar
  53. ojdbc6.jar
  54. opensaml-2.2.3.jar
  55. pagination-lib.jar
  56. quartz-1.6.6.jar
  57. quartz-1.7.2.jar
  58. rampart-core-1.6.1.jar
  59. rampart-policy-1.6.1.jar
  60. rampart-trust-1.6.1.jar
  61. relaxngDatatype-20020414.jar
  62. saxpath-1.0-FCS.jar
  63. service-pojos.jar
  64. slf4j-api-1.5.11.jar
  65. slf4j-jdk14-1.6.1.jar
  66. stax-api-1.0-2.jar
  67. stax-api-1.0.1.jar
  68. tbgv2util.jar
  69. TMSFramework-2.2.46.jar
  70. TMSIntegrationFramework-0.0.216.jar
  71. TMSMessagingFramework-0.0.11.jar
  72. TMSUserMgmtFramework-
  73. warranty-maintainence-pojos.jar
  74. wiztools-commons-lib-0.2.0.jar
  75. woden-api-1.0M9.jar
  76. woden-impl-dom-1.0M9.jar
  77. wsdl4j-1.6.2.jar
  78. wss4j-1.5.12.jar
  79. xalan-2.7.0.jar
  80. xercesImpl-2.2.1.jar
  81. xml-apis-1.0.b2.jar
  82. xmlbeans-2.2.0.jar
  83. XmlSchema-1.4.7.jar
  84. xmlsec-1.4.5.jar
  85. xmltooling-1.2.0.jar
I, myself, have never created an application that uses 85 jars.

Making things worse, the app was running on a heavy weight app server (Web Logic) that added many more classes to the classpath, classes that do not show up in the above list. These included the entire stack of J2EE classes. Plus other classes that WebLogic thinks you might need.

Problem: Any app with this many classes in the classpath will surely have some accidental duplicate classes, possibly even multiple versions of the same class. This can be the source of very hard to track bugs.

This was, in fact, the source of the bugs in this particular application.

Moving forward, I would recommend the following:
  1. Add libraries and jars to your app very judiciously.
  2. Be careful of build tools that might recursively suck in unneeded library dependencies.
  3. Beware of any 3rd party libraries that require a whole bunch of other 3rd party libraries to work.
  4. When a 3rd party library comes with 10 other 3rd party libraries that it depends on, those other libraries might be optional libraries and not needed for your app.
  5. Avoid app servers that litter the classpath with unneeded libraries. 
  6. Be especially cautious of putting classes in your app servers global (cross-web-app) lib folder.
  7. This entire problem starts to goes away as we move toward a more micro-service style architecture.

Thursday, July 19, 2012

The Semi-Swallowed Exception

I am often brought in to help a team track down super-hard-to-find bugs. One situation that results in the super-hard-to-find bug is what I call the semi-swallowed-exception.

Most java developers know that it's a very bad idea (99% of the time) to completely swallow an exception like this:

}catch(Exception e){}

That is, you very rarely want an empty catch block.

But almost as troublesome is this:

}catch(Exception e){

The problem is, that the exception probably left the application in an invalid state. For example, some variable wasn't set correctly. Then, sometime later, you get a null pointer exception or worse, some strange hard to explain bug.

Based on the projects I have been involved with, I would say that 90% of time when you find yourself wanting to do this:

}catch(Exception e){

Instead, you probably should do this:

}catch(Exception e){
    throw new IllegalStateException("bla bla",e);

Also, if you are just catching an exception from a lower layer, there is not much value in wrapping it in a do nothing exception class. For example, I came across this the other day:

}catch(Exception ex{
    throw new MyCompanyNameException("bla bla");

Two things to note about this snippet:

  1. The MyCompanyNameException class adds no value in this case. This seems to be a popular thing to do. But I can see no point to it.
  2. This exception handler actually swallows information.The MyCompanyNameException includes a string message ("bla bla"). But it swallows the cause exception. So I would replace the above exception handler with this:
}catch(Exception ex){
    throw new RuntimeException("bla bla",ex);

Concurrent Maps for lightweight caching

Here is the Dave best practice when using a map for caching purposes in a java server environment:

Don't naively use Java maps as a global cache in a Java Server environment. 


If it's a create-once, read-many type cache.
Use a Guava ImmutableMap and ImmutableMapBuilder:

public class DaveMapDemo1 {

//note: Person is immutable
private final ImmutableMap<String,Person> map;

public DaveMapDemo1() {

       ImmutableMap.Builder<String,Person> builder =
new ImmutableMap.Builder<String,Person>();
"123",new Person("Dave","Ford"));
"222",new Person("Joe","Blow"));
       map =;


public Person getPerson(String id){
return map.get(id);


If it's a get-or-create type cache.
If the cache is populated lazily, use Guava's LoadingCache and CacheBuilder classes (these replace the Guava ConcurrentMap implementations):

public class DaveMapDemo2 {

//note: Person is immutable
final LoadingCache<String, Person> map;

public DaveMapDemo2() {

       map = CacheBuilder.newBuilder()
10, TimeUnit.MINUTES)
new CacheLoader<String, Person>() {
public Person load(String id) {
return lookupPersonFromDatabase(id);


public Person getPerson(String id) throws ExecutionException {
return map.get(id);

private Person lookupPersonFromDatabase(String id) {
// yada yada yada

Notice that both examples:

  1. Have no mutable state
  2. Do not use the keyword synchronized

Wednesday, March 28, 2012

Dart's new template engine

Dart's new template engine seems promising.
I really like the fact that the new Dart template engine generates a *tree* rather than a string. Or more specifically, an html.Element. Other than XSLT, this is the only templating system i know of that does this.
This comes very close to something i have been wanting for a long time, what i call: "typed templates" or "extensible literal types"
Whether we call them XML literals or DOM (typed) templates, the idea is the same.

Suggestions for Improvement

There are four things i think that would improve Dart's template engine:
1. Eliminate the extra compile step. i.e. with something like #source or #import. Maybe:

2. Leave the door open for other template types. i.e. provide some way to specify the returned type and/or the template engine to use. So, instead of this:
template Hello(String to) {
we would have this:
html.Element htmlTemplate Hello(String to) {
where html.Node is the return type and html is the template engine.
Or if the template engine type implies the return type you can skip that part:
htmlTemplate Hello(String to) {
Other examples:
xmlTemplate Hello(String to) {  }
sqlTemplate oldPeople(int minAge) {  }
jsonTemplate Hello(List<Person> people) {}
stringTemplate emailTemplate(Person p) {}
daveDslTemplate(Person p){}
3. An extension mechanism.
For common DSL's (initially just html) the template engine would be built-in. But one could provide a custom template engine like this:
4. In-line templates. This one is a stretch, but it would be nice if templates could be defined in a .dart file alongside other dart code:
//normal dart function
Person getPerson(){
        //yada yada
//dart template function
htmlTemplate Hello(String to) {
I know the whole language in a language (island grammars) complicates things from the dart parser/vm perspective. So this is a nice-to-have more than a must-have.

Wednesday, February 22, 2012

Internal Templates as Special Functions

In a previous post, I had proposed expanding on the concept of multi-line string literals as a way to support DSLs and templates from within Dart. Here is an alternate proposal, using function bodies instead.

Proposal: Represent internal DSL templates as a special type of function. This is similar to Closure Templates, where templates are represented as a function-like structure with a formal parameter list.
Here is what the template definitions would look like:
Sql query2(int minAge) /*-{
        select id,firstName,lastName
        from person
        where age > ${minAge} and groupId=${groupId}
Html personTable(Person p) /*-{
          <tr><td>First Name</td><td>${p.firstName}</td></tr>
          <tr><td>Last Name</td><td>${p.lastName}</td></tr>
String personTable(Person p) /*-{
        First Name ${p.firstName}
        Last Name ${p.lastName}
I stole the syntax from GWT's JSNI. It seems to work pretty well there.
Then for each supported type DSL there would be two classes:
  1. Html: a class representing the generated object, i.e. the result of executing the template
  2. HtmlTemplate: defines the dart-templatized grammar for one particular DSL

  HtmlTemplate creates Html
  SqlTemplate creates Sql
  StringTemplate creates String
  YamlTemplate creates Yaml

/// defines a dart-templatized DSL grammar
///   there will be one instance per template method
///   each DSL will have different rules regarding 
///   where ${ } expressions can be located
///   @type param T is the type of object that this 
///       template creates (i.e. Sql, Html, String)
interface Template<T>
  /// called once - to parse the template
  /// could potentially do nothing and just store the templateText
  /// but fail-fast would be preferred
  TemplateParseResult prepare(String templateText);
  /// called every time a template method is called
  T create(TemplateInvocationMirror args)
  /// optional. used by tools ???
  /// it would be nice if each ide/editor/tool didn't have to reinvent
  /// everything from scratch
  TemplateGrammar get grammar;
/// provides detailed parse error info: line #, column #
interface TemplateParseResult{

Making Tool Support Easier
It would nice if tool support for DSL templates is possible. It would be nicer, if tool support for DSL templates actually existed. Perhaps the TemplateGrammar class could provide enough information, so that tools (like IDEs) would not require 400 years in order to start supporting auto-completion, syntax high-lighting, etc.

/// optional. used by tools ???
/// it would be nice if each ide/editor/tool didn't have to reinvent
/// everything from scratch
/// one instance per DSL

interface TemplateGrammar{


Tuesday, February 21, 2012

Good Polyglot Bad Polyglot

Polyglot programming refers to a project (or maybe a team) that uses many different languages, as opposed to the opposite concept: one language for everything. The general consensus seems to be that we are moving away from single language apps and toward polyglot apps. At the very least, every web developer is already a polyglot programmer.
In my opinion, polyglot programming is one of those things that, if done right, can lead to significant gains. But if done wrong can lead to polyglot hell - something far worse than the single-language app.
Below is my description of good and bad polyglot programming. I use the terms GPL to mean general purpose language. And DSL to mean special purpose or domain specific language. Also, I am specifically addressing languages that are used by developers. Not end-user DSLs.
This post really describes how I think polyglot programming should work. It is mostly what I would like to see from the developers of frameworks and languages moving forward. Particularly Google Dart, whose development I have been tracking closely and is still under construction.

Bad Polyglot

Below is my list of polyglot smells mostly based on my experience working in the Java ecosystem.
Smell #1: The Unnecessary DSL
Creating a DSL for doing what the GPL (general purpose langaueg) can do just as easily.
There is overhead in polyglot programming. In order to justify its existence, the DSL must provide a significant advantage over just creating an API in the host GPL.
For example, suppose you wanted to instantiate an object for handling http requests. And then publish that request handler under some url. Lets call our request handler a servlet. Here is how one might do this without a DSL (using an API):
MyServlet pc = new MyServlet();
Now let's look at a Sun's DSL for doing the same thing:
If there is a significant advantage in the DSL approach, it's not obvious to me.
Now you might be saying, "Wait a minute. There is at least one benefit from this DSL. I can allow some deployer to change the values in that xml file without running the compiler." If you are saying that, then please see the Configuration DSL smell below.
Smell #2: The Hindering DSL
A DSL that makes things harder for the users.

The above servlet example is not a hypothetical. This was actually something Sun came up with. What's more, using that DSL is the only way to instantiate and publish a servlet. In addition to providing no obvious advantages, forcing users to use this DSL imposes a number of hindrances:
  1. The obvious, of course, is the fact that the amount of code seems to be triple what it would have been using an api in the GPL.
  2. Then there's the fact that we lost all type checking. If we misspell MyServlet or pc, the tools will not help me find the error. What was once the job of the compiler and ide now become the job of the servlet engine. We also loose IDE auto-completion, refactoring, debugging, etc.
  3. Injecting dependencies (manually or via a DI tool) is difficult. For example, suppose I wanted to pass a data source into the servlet's constructor like this:

    MyServlet pc = new MyServlet(myDataSource);

    The XML-based DSL makes this impossible.
Smell #3: The Configuration DSL
Framework vendors needlessly reinventing configuration DSLs.
The word configuration usually refers to some piece of data that adapts an application to its environment. As a developer, I have seen 100s of ways to externalize configuration data. We have configuration frameworks like commons configuration. We have configuration registries like the windows registry and JNDI. We have file formats like ini files, properties files, xml files, json, yaml, and so on.
We don't need every new framework that comes along needlessly reinventing a whole new configuration DSL. I am talking about frameworks like Struts or JPA. In almost every case, these configuration DSLs should never have happened. Both the framework vendor and the framework users would have been better served had the vendor simply provided a nice API instead.
These frameworks are only consumed by computer programmers. And we know how to use Java. We know how to call an API. We know how to use a compiler. We know how to use property files and xml files.
But mostly, there is no possible way that the framework vendor can know what should be hard-coded and what should be configurable for my app.  The developer of the application is much better suited to make these decisions.

For example, lets say I want to tell JPA what jdbc url to use. Here is how this might be done using an API:
And here is JPA's configuration DSL:
<property name="jdbc.url" value="jdbc:mysql://localhost/db1" />
For my app, the jdbc url does not need to be configurable. In fact, its just the opposite. I don't want that value to be changed by anyone but me (or one of my Java developers) - and I know java and know how to run a compiler. I would rather just set the value via an api call.
There are definitely applications (not this one, but others) that need to support multiple database urls and multiple database drivers. But here's a secret: none of them use this configuration mechanism to achieve this. No one in their right mind would let the client's deployer go in and start messing with the jpa file. An even worse example was the old ejb config files, where a deployer could go into a config file and start redefining transaction semantics. No one ever needed this.
In my app, I need to provide the jdbc url in two places. Why? Because I access that same database using jdbc direct (i.e. i have lots of pre-jpa code) and also using JPA (for newer code). So now I have to type in the jdbc url twice: once in JPA's config file and once in my java code where I instantiate the MysqlDataSource used by the non-jpa part of my app. If the jdbc url were to change, I'd have to change it in two places: the JPA config DSL and the place were I instantiate my non-jpa data source. The point is this: JPA's decision to force a configuration DSL on me, actually made the app harder to configure. Not easier.
Suppose I use 4 frameworks in my application (not uncommon in the java world) and each framework attempts to reinvent some elaborate configuration scheme complete with DSL. Now suppose there are a few pieces of data that I would like to externalize (not having to do with those frameworks) so i use a properties file for that. I now have 5 different configuration files. Many with duplicated data. Many with data that i never wanted to be configurable in the first place.

I don't want to expose all of those framework-specific DSLs (with their 1000s of config options) to the deployment team. So I don't. In my app there are only 5 things I wish to be configurable. So instead I expose a simple properties file (five lines). But 2 of those 5 values need to be passed down to those frameworks, the ones with no API for setting the value. Their config DSL is the only way. So now I need to figure out how to get the data out of my properties file (easy) and into their config DSL (yuck).
If I really wanted to make my JDBC url configurable, I don't need JPA's config file system. All I would have to do is something like this:

The sad news: JPA does not have this method. The only way to set the jdbcUrl is through the JPA config file. 
Suppose my company has a standard way they like to handle configuration (say yaml for example). Again, now I have to find a way to get my configuration parameters out of my yaml file and into the vendor's config DSL.
The bottom line is this: configuration is a separate concern from whatever the framework is trying to accomplish. Co-mingling the two concerns is almost always a bad idea.
Recommendation #1: framework vendors: stop reinventing configuration DSLs. Instead, provide a clean API.

Of course when setting these configuration options via an API we don't call them configuration options. They're just called properties or setters. The choice as to which properties to externalise as configuration should be left up to the application developer. If framework vendors have extra time left over, and really want to create a configuration DSL, layer it on top of an API and make it optional.
Recommendation #2: framework users: when choosing a framework, all other things being equal, prefer frameworks that provide a clean API for setting it's various configuration options.

Smell #4: GPL Creep
A DSL reimplements multiple GPL (General Purpose Programming Language) constructs.

GPL creep is when a DSL starts to redundantly implement most of the same features that are found in a GPL like branching, looping, variables, modularity, namespace, subroutines, etc. When this happens, the surface area of the DSL starts to approach that of a general purpose language. And once a DSL starts to creep into a GPL, it almost always does a bad job of it, at least compared with the GPL language.

Recommendation: moving forward, the best way to avoid DSL creep is to ensure smart integration between the host GPL and the DSL. If each DSL is an island, than it will, by necessity, end up with DSL creep. But with smart GPL/DSL integration, functionality like branching, looping, subroutines, variables, etc. are done in the GPL. And the DSL just sticks to what ever it does. See Language-in-Language.
Smell #5: Large Surface Area to Functionality Ratio
A giant DSL for a tiny task
This is when a DSL only does one tiny little thing (like transform one xml document into an other xml document) but it requires a 1300 page book on how to use it. I have already blogged about the service area to functionality ratio in a previous post.
Smell #6: Reinventing Syntax
Needles use of unfamiliar syntax
One problem I have with Unix is that every app seems to have a config file with radically different syntax (like send mail or postfix). There is no consistency. This makes it very hard to read or parse. Sometimes a new syntax is warranted but in general, building your DSL on top of some of existing syntax is preferred.
If you are thinking of creating a new DSL, your first choice should be to use the host GPL. In other words, don't create a DSL all. Create an API. Or stated another way, create an internal DSL not an external DSL. As a second choice, base your DSL on some existing file format like XML, JSON or YAML. Only as a last choice should you reinvent some completely new syntax.
Smell #7: External Template Engines
In order to use a GPL (like Java) with a DSL (like HTML) a 3rd DSL (like Velocity) is introduced.
Yes that's right, I think external template engines are a code smell. I'm talking about things like JSP, Velocity, Closure Templates, etc. Given the current crop of GPLs you really don't have much choice in the matter. You almost have to use external template engines. But moving forward with new GPLs, I think that most of that functionality should be subsumed by the GPL.
You might think of a template, at first glance, as a tool used to separate something stable (the template) from something that changes (the variables). But you could use that same definition to describe a class (as in a Java class).
Or you might think of a template as a tool for separating a view from from the non-view (whatever that means). But that's not really correct either. Because templates are often used for non-view types of things like this:
select id,firstName,lastName
from person p
where p.age > ${minAge} and${group}
In my opinion the primary use-case for template engines is polyglot programming. For example, JSP is a language for combining java and html. I would argue that the vast majority of developers use template engines for one reason: polyglot programming.
If I need a full blown template engine just so I can use a DSL (like HTML) with my GPL (like Java) than it seems like a code smell to me. Why should I need a DSL just so I can use a DSL?
The main reason this is a code smell is that virtually all template engines that I know of reinvent about 50% of a GPL (GPL Creep).

Update - 3/28/2012: I may be changing my mind on this issue. The Dart team is developing a template engine that comes close to addressing some these concerns.
Smell #7: The Religious Template Engine
A template engine that attempts to enforce separation of concerns
The whole "scriptlets are evil" thing is a bunch of malarkey. A template engine that is too powerful is not the cause of your spaghetti code. Your spaghetti code can't be blamed on JSP. Only a human can really know what concerns should be separated.

Also, reinventing a GPL inside a template DSL still allows you to mix business logic with UI. Here is an example of business logic written in a template DSL:

  {if $age > 65}
     {if veteran}
         Benefit 1
         Benefit 2
    {if $iq > 100}
         Benefit 3
         Benefit 4
I'm pretty sure i could write an entire app, business logic and all using only a Closure Template (the template DSL) and no JavaScript (the GPL).

The main thing is this: GPL stuff (like branching, looping and variables) and DSL stuff (HTML) will need to be woven together in sometimes complex ways. There is no getting around it. The more seamless and easy this is the better life will be for web developers. The line separating concerns is often blurry and subjective.
Smell #8: Too Many GPLs
A project requires multiple GPLs
I am the kind of guy who likes to learn new languages while everyone else watches football. But still, I can't be an expert at more than a few large general purpose languages. The whole "use the right tool for the job" concept only makes since for DSLs, not GPLs. GPLs take years to master. I call this idea the "right tool for the right job" myth.
If your project involves multiple general purpose languages than you better have some really smart people on your team to deal with that.
Smell #9: GPL not general enough
Minor differences in GPLs justify having more than one of them.
My guess is that the reason Google standardised on only  4 GPLs (and not 12) is due to the Too Many GPLs principle stated above.  But the reason they have 4 (and not 1) is because today's GPLs are not quite general enough. They are close, but not close enough. This is sad considering Java, C++, JavaScript and Python are at least 90% redundant. They are all general purpose languages. Sure C++ might be better for systems programming and python might be better for shell scripting. But they are all basically general purpose programming languages.

For all our talk about code reuse, the place we seem to stink at code reuse the most is in programming languages.
Perhaps this is one of the reasons Google is creating the new Dart language. Dart can be used for:
  1. shells scripts like Perl or Python
  2. the client-side of a web app (like JavaScript)
  3. the server half of a web app
  4. writing an http server or a database engine (like java or C++)
  5. native Android apps ??? (we'll have to wait and see on this one)
  6. Unlike Sun, Google is not leaving it up to others to provide VMs for the major platforms. They already have VMs for Mac, Windows and Linux
In general, trying to create a single piece of software to solve all the worlds problems is not a good idea, but with GPLs, I think the differences are minor enough that the need for multiple GPLs (per team or per project) should mostly go away.
Even though they don't seem to be promoting Dart this way, I have a feeling that Dart may end up fulfilling the run anywhere promise better that Java.

GPL/DSL Integration Moving Forward

In my opinion, DSL integration is such an important thing (especially for Dart whose primary purpose in life is to build html apps) that it should be an integral part of the language.
With older languages, like Java, you pretty much have to use an external template engine. There are two features that many newer languages have but Java lacks in this regard. And the presence of these 2 features in a language almost (but not quite) eliminates the need for an external template engine.  Those two features are:
  1. Multi-line strings.
  2. String interpolation (embedded ${} expressions within the string)
For example in Google dart you can have a string like this:
Person p = getPersonFromSomewhere();
String html = '''
    <tr><td>First Name</td><td>${p.firstName}</td></tr>
    <tr><td>Last Name</td><td>${p.lastName}</td></tr>
If you haven't already noticed, the above multi-line string is a template. I call them internal templates. With internal templates we are very close to eliminating the external template engine completely.
By enhancing the GPL's internal template mechanism just a bit more, I believe we could make external template engines obsolete. Specifically, internal templates need to be beefed up with the following new functionality:
  1. branching and looping
  2. optional template types
  3. escaping
Branching and Looping in Templates
First, we need some way to do branching and looping within the template. I see two ways to add branching and looping to internal templates.
Branching and Looping Expressions
First, since Dart internal templates already support embedded expressions, we could just expand Dart's expression capability to include functional style if/then/else and loops (notice we're talking if and loop expressions not statements).
Html html = Html'''
    <tr><td>First Name</td><td>${p.firstName}</td></tr>
    <tr><td>Last Name</td><td>${
if(foo) p.lastName1
else p.lastName2
This brings up the issue of nesting. Nesting must be supported.
Html html = Html'''
    <tr><td>First Name</td><td>${p.firstName}</td></tr>
    <tr><td>Last Name</td><td>${
if(gold) Html'''<b>p.lastName</b>'''
else Html'''<i>p.lastName</i>'''
DSLs and internal templates aside, I would like to see if/then/else functions and loop functions added to Dart anyway. I prefer the functional style of programming.
The above functional solution seems elegant to me. But I realize that if and loop functions may blow some peoples minds.
There is a more conservative solution that would work just as well. And it may appeal to that broader market Dart is after. I'm talking scriptlets! That is, allow nested statement blocks via something like scriptlet tags: <%  %>. We know it works because this pattern has been proven in practice for years.
In a JSP template I can declare, at the top of my template, the type of the thing i am generating:

<%@ page contentType="text/html" %>

So now i'm not generating a string, i'm generating HTML. By doing this, the IDE (at least in IntelliJ) can give me world-class HTML assistance. Adding something like this to a GPL might look something like this:
Html html = Html'''
    <tr><td>First Name</td><td>${p.firstName}</td></tr>
    <tr><td>Last Name</td><td>${p.lastName}</td></tr>
Once you add template types, you can start to think of internal templates more like extensible literal types. This is similar to the complex literal types built into other languages like:

Map Literals
Map map = {

List literals
List list = [2,5,4,2]

Xml Literal (found in Scala and ActionScript)
Xml xml = <person>
For typed templates, there should be a modified version of the ${} tag, perhaps:
${ } include as is - no escaping
#{ } strings are escaped, escaping rules are determined by the templates type
Note: my solution of typed templates presented here has not been vetted or thoroughly thought out. I leave that to the brilliant folks at Google. When you start to combine the branching, the looping, the type safety and escaping all together, there are edge cases that arise. Even if the above mentioned solution is not feasible, I hope at least that helps to frame the problem.

Good Polyglot

In a perfect world, this is what polyglot programing would look like::
  1. One GPL (per team or project). This GPL can be adapted to multiple use-cases by simply using the appropriate libraries, internal DSLs or internal templates. It can be adapted to different platforms and environments by offering different levels of library support for different platforms, providing multiple VMs for various devices and platforms and multiple compilers that target various platforms.
  2. Multiple DSLs like SQL, HTML, CSS, RegEx, etc.
  3. Clean integration between the host language and the DSL with well defined boundaries, proper encapsulation and context sharing as needed.
  4. Switching from GPL to DSL and back again should be seamless with no loss of tool support or type checking.
  5. The GPL's ability to create nice API's (or internal DSLs) should be sufficient to eliminate many of those nasty external DSLs from the Java ecosystem.
  6. The GPL's internal templates (or extensible, typed literals) should
  1. Be sufficient to eliminate the need for an external template engine
  2. Provide for typed templates