JPlates Inc has announced the general availability of JPlates 3.0. The JPlates 3.0 template language supports complete object-oriented template processing with template objects and template methods. JPlates 3.0 offers an alternative to JSP and XSLT and Velocity for Java programmers and Struts developers.

For more information, visit http://www.jplates.com.

JPlates 3.0 is a fully object-oriented template processing language designed to be used by Java programmers, along with Java, for building template-based applications. It offers the most usable and powerful technology for dynamic content generation on the web, for XML transformation, for source code generation, for generating personalized email, or for any other application involving template-based text generation.

JPlates 3.0 syntax extends Java 1.4 syntax with JPlates template methods. Template methods are called just like other methods, but use JPlates template syntax for their method bodies. The template syntax combines template literal text with substitution and i18n, control flow statements, declarations, and output format control statements. JPlates classes can use 100% of Java, plus JPlates template methods.

JPlates classes are compiled into Java to ensure 100% compatibility with Java. The JPlates compiler is fast and robust, and maintains line numbers to support easy debugging. The JPlates 3.0 runtime provides high performance template processing support for Servlets, J2EE, and J2SE applications.

Use JPlates 3.0 in place of JSP, XSLT, and other template processors, wherever you generate stylized text, whether in a web-application, a code-generator, or any other kind of Java application.

Could we have a straight feature-comparison document about how it stacks up against eg. Velocity?

In terms of both syntax and functionality, JPlates is a proper superset of Java that compiles into Java. JPlates adds template methods whose bodies are expressed using JPlates template syntax. The rest is exactly the same as Java.

Other template languages treat templates as interpreted data. JPlates treats them as executable methods of JVM classes. As a result, the design and programming process for JPlates applications is the same as it is for Java, and you still get the benefit of a powerful template-language syntax where you need it.

-- Dan

this product came up before and there where a lot of people waving their middle finger at it as I recall

see :

https://www.theserverside.com/home/thread.jsp?thread_id=20059#87394

In that thread somebody brought up if there was anyone who would be willing to vouch for it, the authors never responded to that, pretty much says it all I guess

Yes, we recognized the shortcomings of the second release, and re-engineered the product entirely. Release 3.0 solves the same problems, but in a much better way.

JPlates 3.0 adds template processing to Java. That's the product statement, and that's what the product does. I am confident that we have addressed the objections raised about the previous release.

instead of spending my time on understanding & writing the template language - which i know is "similar" to java - why not i just write my own code - it will be much eaiser for me to maintain later on -
there has never been a automation tool on earth which can generate exaclty the required code - it always needs some changes and mantenance - and changing a auto generated code is the worst thing u can do - Better write ur own simple MVC pattern code
anyway - All the best to you...

There's also a new template engine called StringTemplate here:

http://www.antlr.org/stringtemplate/index.tml

From the first look I like it. It comes from Terence Parr of jGuru and ANTLR.

-- Andreas

Why does people continue to develop such proprietary template languages/frameworks? I know diversity is good, but why not innovate on top of the standard, which in this case is JSP?

Sure, JSP had and still may have some flaws, but it is widelly known and used, and is not going away. (Another J2EE subset, EJB, may very well be going away in its current form, but I see no real reason why JSP should go.)