Jdbi: 不鼓励和弃用 StringTemplate4 支持

让我们从文档中的一个通知开始，即 StringTemplate 项目处于非活动状态。

我会让其他项目成员参与讨论弃用 Jdbi 的 ST 集成的问题。 我个人认为我们应该继续支持它至少一段时间。 我们刚开始支持 ST4。

我认为我们需要一个替代方案。 没有办法为 sql 创建复杂的模板是不行的。 我需要能够在不同模板之间共享 sql 位和部分，并且能够将常见的东西分解为模板方法。 对我来说，删除 stringtemplate 是让我寻找另一个替代框架。 如果没有，我将被迫制作大量重复的 sql 文件。

现在让我们添加一个NOTICE 。 一旦我们有了可行的替代品，我们就可以弃用它。

有没有人最喜欢的模板引擎可以很好地融入 jdbi？ 我已经使用了mustache一点，它很好，但我远非专家......

谢谢@jarlah ，这正是我所期望的。

不幸的是 StringTemplate 被上游忽视了，但只要人们在使用它并且它有效，我们就没有理由撤回支持。

我们对我工作的 FreeMarker 非常满意。 小胡子也是一个不错的选择。

同意@jarlah - 需要替代方案。 我也在积极使用模板，如果没有 ST，重复将是大量的。 替代应该简单而富有表现力 - 我喜欢当前的 ST。 我很久以前使用过 Freemarker，如果我没记错的话 - SQL 模板看起来并不简单。

顺便说一句，这是我与 ST 的最后一个问题，我应该将它与 jdbi 集成级别的解决方法代码一起发布在这里吗？

如果有一个简单的解决方法jdbi可以在不使事情复杂化的情况下完成，我们当然会考虑它。

额外的模板引擎如何捆绑在 jdbi 中？ 它们都引入了我们在core不想要的外部依赖项，并且既不创建 1 类模块也不设置 \

不过 IIRC stringtemplate 有自己的 mvn 模块，所以也许我们应该继续这样做？ 无论如何，对于用户来说，这听起来不像可选依赖项那么麻烦。

我有兴趣贡献一个 StringSubstitutor 引擎（如果我还没有的话），而且 Mustache 看起来也很有趣。

如果它是一个具有单个<optional>依赖项的自包含单个类，或者类似的轻量级，它可以进入核心。 否则，让我们启动一个模块。 我的偏好是一个指导方针，而不是一个不可能通过的障碍:)

不过，这会破坏 stringtemplate4 模块设置的模式。 而且我知道作为用户，除了必须弄乱 maven 之外，我最讨厌的事情很少，尤其是我的依赖项的依赖项...

我看到 stringtemplate 得到了@UseStringTemplateEngine尽管@UseTemplateEngine存在。 对于每个模板引擎来说，这是一种理想的便利，还是我们只是从现在开始坚持使用通用注释，除非有必要？

就我个人而言，我更愿意将它们拆分为模块，这样您甚至无法在 IDE 中看到一个类，而如果类路径中不包含其依赖项。 NoClassDefFoundError可能是一个真正的痛苦。

我过去曾与 freemarker 合作过很多次。 实施对它的支持可能是一项有趣的努力。 它不是直接针对它的。 但这是可能的。 必须好好看看性能。

如果没有别的，我可以让它飙升

目前正在研究它。 在我有一个合理的工作概念证明之前，不会打开拉取请求。 使用Configuration有一个问题，因为模板加载不是静态的，必须是动态的。 所以每个模板都必须手动加载和缓存。 我已经克隆了 stringtemplate4 模块并重命名了类等。如果有人感兴趣，那么我正在我的 jdbi 分支上的主分支上工作。

我认为导致此问题的情况是以下几种情况的组合：

• StringTemplate 4 在单线程使用中通常工作得非常好（如果不出意外的话，可以预测）
• StringTemplate 4 的设计并没有特别强调并发使用，这导致了在不破坏现有用户的情况下难以解决的错误，因此它们大多保持原样

如果创建了 StringTemplate 5，我希望安全并发（可能是不变性）在基本设计中发挥重要作用。