Using functional interfaces for tags and JSP

[Jeremy Boynes <jb...@apache.org>]

After the recent thread around taglibs future, I wanted to explore the possibility of using Java8’s functional interfaces to implement tags. http://svn.apache.org/r1663366 is a straw man I used.

To explain the approach here, I started with the thought that the SimpleTag model in JSP2.0 was a kind of functional implementation. Rather than having to define a class for each tag and a XML description of it, could we represent it as a single method and gain all the needed information through annotation and introspection. Basically I wanted to be able write a tag as something like

   void tagName(String attribute1, int attribute2, JspFragment body)

TagLibrary describes the semantics I came up with, and BasicTagLibrary attempts to demonstrate how the various patterns used by today’s tags could be implemented with the new model.

I think this can be supported on JSP2.x engines by using an annotation processor to generate SimpleTag implementations and the XML descriptor for the library. We could also use a ServletContainerInitializer to locate TagLibrary classes during webapp startup and pass the information to Jasper.

However, I started to wonder if there was a more efficient model that could also be used for the JSPPage itself, one that might avoid generation for all cases not involving scriptlets. The thought was that a page can be represented by a series of fragments that are either:
  * text
  * text produced by EL ValueExpressions
  * tag invocations
  * scriptlets (but current best practices tend discourage that)

The servlet samples contain various alternatives for representing such a page.

I tried to make these work with the existing JSP APIs as much as possible but ran into a couple of impedance mismatches:
  * the JSP interfaces ofter have additional methods which prevent them being FunctionalInterfaces
    for example, JSPFragment is a abstract class and exposes two operations
  * JSP generally uses checked exceptions (JspException) whereas the j.u.function APIs do not. I introduced AbortException as a way to tunnel the checked exceptions to the higher levels
  * JSP historically has relied on life-cycle methods e.g. JspFactory’s get/releasePageContext. I explored using try-with-resources to control life-cycle instead

The interfaces in o.a.jsp.functional try to address these issues.

The code builds but I’ve not verified that it actually works as intended - that’s the next step :)

Cheers
Jeremy