String templates

[Archie Cobbs]

On Thu, Aug 7, 2025 at 2:53 PM Ron Pressler <ron.pressler at oracle.com> wrote:

> On the benefit side we gain, what? The ability to copy-paste templates
> from existing templating engines without any processing?


It's a good question.

Put aside that half-baked idea for adding "literal processors" to the
compiler for now - as you note, there are practical issues, but more
importantly, discussion of implementation mechanisms is putting the cart
before the horse. Instead we first need to ask why such a thing would be
helpful. I'm sure other folks have researched this more than me but fwiw
I'll throw out a couple of thoughts.

First observation: Here's my oversimplified view of Java programming:

1. Writing code that manipulates data being presented to you *already in
the language's native format* is "easy". That is, working solely with Java
primitive values, Strings, Sets, Maps, Lists, graphs of objects, etc., is
easy. You are doing all of your work within the "pure Java world" where the
basic operations are well understood, they never fail, an int is always 32
bits, you never run out of memory (i.e., we always just give up if that
happens), there are no transactions, no networks that might drop packets or
disconnect randomly, no race conditions (except the ones you create
yourself), etc. (for me this is the "fun" part of programming, in contrast
to #2...).

2. Getting data into and out of this pure Java world is "hard" - or at
least, tedious and boring. The pure Java world is the only place you can
actually *do anything* in a Java application, so we spend a bunch of time
and effort getting data into and out of the pure Java world. In fact, this
constitutes the vast majority of the code in most enterprise applications.
I'm talking about code for user interfaces, config files, various
integrations, database modeling & querying, data (de)serialization,
sending/receiving REST API queries, logging, etc.

Second observation: Almost all of the non-Java stuff in #2 has
corresponding domain-specific models: INI files, HTML/CSS, XML, HTTP/TLS,
JSON, SQL, row sets, etc.

Because we spend so much time writing Java code to deal with all the
non-Java-stuff, it's worth exploring how the language can help make our
lives easier.

Java's already going in this "data first" direction, with record classes,
value classes, the "standard" JSON classes, etc. Those are nice but they
are staying very close to the original language. I think it would be OK and
not blasphemous for Java to be more flexible and "open minded" at the
language lexical level in the service of the "data first" effort also.

I'm not sure what that would mean exactly.... but it would be nice to be
able to more seamlessly manipulate different data domains directly in Java
somehow.

Here's a tiny motivating example that's not revolutionary but hopefully
gives a taste of the idea (ignore for a moment the fact that kids don't use
XML anymore :)

Document doc = // read XML document
for (Element child : XPATH."$doc/Users/User") {
    if (XPATH."not($child/favoriteLanguage)") {
        $child.appendChild(XML."<favoriteLanguage>Java</favoriteLanguage>");
    }
}
// write out modified XML document

The point is we try to accept and embrace the domain models we're working
with, instead of effectively saying that everything must always be fully
converted to Java before we can work with it. In the example, it appears as
if you're working with XPATH and XML directly, which probably more closely
matches how you really think about the problem. The mashed-up syntax is
actually intuitive. In other words, whenever I'm writing Java code that
manipulates an XML document, I'm thinking about the XML document as a data
structure, not the programming language - the language being used to do the
manipulation is just a means to an end. Why not make it easy to use the
most natural language for that particular problem?

Side note: those "extension literal" examples are normal Java literals
prefixed by NAME DOT but you could support arbitrary literals if we
required them to be self-delimiting, at the cost of a more complex
parser/extension interface. Example: XML.<foo bar="blah"/>

Of course one could also "untemplate" or deconstruct like we do with
patterns:

JSON json = // read JSON config
String displayName = null;
int verbosity = 0;  // default quiet
JSON."""
    {
    "config": {
        "displayName": $displayName,
        "verbosity":   $verbosity
    }
  }""".deconstruct();
assert displayName != null;
if (verbosity > 0)
    System.out.println("Using display name \"" + displayName + "\"");

There are limits to what we could do - in the end, everything would still
really be Java under the covers -  and this would definitely be major
compiler surgery. But I think it's at least worth the thought experiment.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250808/708c74bc/attachment.htm>