Jdbi: Discourage and deprecate StringTemplate4 support

Let's start with a notice in the docs that the StringTemplate project is inactive.

I'll let the other project members weigh in on the question of deprecating Jdbi's ST integration. Personally I think we should keep supporting it for at least a little while. We only just started supporting ST4 in the first place.

I think we need an alternative. Not having a way to create complex templates for sql is a no go. I need to be able to share sql bits and parts between different templates, and to be able to factor out common stuff into template methods. For me, removing stringtemplate is making me look for another alternative framework. If not I would be forced to make sql files with a lot of duplication.

Let's add a NOTICE now. We can deprecate it once we have a viable replacement.

Does anyone have favorite templating engines that would fit nicely into jdbi? I've used mustache a bit and it was fine, but I'm far from an expert...

Thanks @jarlah, that was kind of what I expected.

It's unfortunate StringTemplate is being neglected upstream, but as long as people are using it and it works, there's no reason for us to withdraw support.

We've been pretty happy with FreeMarker where I work. Mustache is a good option too.

Agree with @jarlah - alternative is needed. I'm also actively using templates and duplication will be massive without ST. Alternative should be simple and expressive - what I like about current ST. I used Freemarker long time ago and if I remember it correctly - it doesn't look simple for SQL templating.

BTW Here is my last issue with ST, shall I post it here with workaround code on jdbi integration level?

If there is a simple workaround that jdbi can do without complicating things too much, we would certainly consider it.

How would additional templateEngines be bundled in jdbi? They all bring in external dependencies we don't want in core, and neither making a 1-class module nor setting an \

IIRC stringtemplate got its own mvn module though, so maybe we should just keep doing that? It sounds like less of a hacky hassle for users than optional dependencies anyway.

I'd be interested in contributing a StringSubstitutor engine (if I haven't already), and Mustache seems pretty fun to do too.

If it's a self contained single class with a single <optional> dependency, or similarly lightweight, it can go in core. Otherwise let's spin up a module. My preference was meant to be a guideline, not an impossible bar to pass :)

That would break with the pattern set by the stringtemplate4 module though. And I know as a user there's little more that I hate than having to mess with maven, especially the dependencies of my dependencies...

I see stringtemplate got a @UseStringTemplateEngine despite @UseTemplateEngine existing. Is this a desirable convenience thing for every template engine or do we rather just stick to the generic annotation only from now on unless necessary?

Personally I would rather have have them split off into modules, so that you can't even see a class in your IDE without its dependencies transitively included on the classpath. NoClassDefFoundError can be a real pain.

I have worked with freemarker alot in the past. It could be a fun endavour to implement support for it. It's not directly meant for it. But it's possible. Have to take a good look on performance.

I could make a spike of it if nothing else

currently working on it. Not going to open a pull request before I have a reasonable working proof of concept. There is a problem with using Configuration, because template loading is not static, it must be dynamic. So each template must be loaded and cached manually. I have cloned the stringtemplate4 module and renamed the classes etc. If someone is interested then i am working on the master branch on my fork of jdbi.

I think the situation that led to this issue is a combination of the following:

• StringTemplate 4 generally works exceptionally well (predictable if nothing else) in single-threaded usage
• StringTemplate 4 wasn't designed with a particular emphasis on concurrent usage, which led to bugs that are difficult to resolve without breaking existing users, so they mostly just stayed as they were

If a StringTemplate 5 were created, I would expect safe concurrency (and likely immutability) to play a large role in the base design.