StringTemplate - why it is an unsealed interface?

[Jim Laskey]

Yes, it was left intentionally unsealed to allow for other implementations. I may be odd-thinking, but my thought was that other languages or DSLs might want their template objects to interact with Java template processors. That is, assuming that 3rd party template processors will become ubiquitous.

An implementation might implement a parser that would parse a file and result in a specialized StringTemplate, maybe parsing on the fly so the whole file doesn’t need to be read in. Note the parser could also use any style embedded expression it wanted.

Ex:

Department of Agriculture

«DATE»

«FIRSTNAME» «INITIAL». «SURNAME»
«ADDRESS»
«CITY», «STATE», «COUNTRY»
«POSTAL»

Dear «FIRSTNAME»,

I wish to inform you that your application for
a sunflower seed permit has been approved. You
should receive said permit within three weeks.
Do not hesitate to enquire on any issue.

Sincerely,

Joan Smith
Director

The embedded expressions here might be the names of fields in a DB and the target processor retrieves the actual value based on the embedded expression. Loosely something like:

while (resultSet.hasNext()) {

...

    StringTemplate.Processor<String, RuntimeException> dbFill = st -> {
        List<String> fragments = st.fragments()
        List<Object> values = st.values().stream()
            .map(Object::toString)
            .map(v -> resultSet.getString(v))
            .toList();
        return StringTemplate.interpolate(fragments, values);
    };


    String result = dbFill.process(temple);
...

}

Since the processing here is somewhat generic, someone else could apply the same processor using templates generated by Kotlin.

Bottom line is to create an ecosystem that has a lot of template processors with the potential for a variety of template sources.

Cheers,

— Jim




On Oct 20, 2023, at 9:09 AM, Patrik Duditš <pato at dudits.net> wrote:

Hello,

I've been experimenting with StringTemplates recently for a few weeks. One thing that appeared odd to me is that StringTemplate is defined as an unsealed interface, as if it would make sense for users of the API to create their own implementations of it.

I would like to ask whether that is an omission, or there is some other underlying reason for that.


Patrik Duditš

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231020/a45ff14c/attachment.htm>