<div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Aug 7, 2025 at 2:53 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On the benefit side we gain, what? The ability to copy-paste templates from existing templating engines without any processing? </blockquote></div><div><br></div><div>It's a good question.</div><div><br></div><div>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.</div><div><br></div><div>First observation: Here's my oversimplified view of Java programming:</div><div><br></div><div>1. Writing code that manipulates data being presented to you <i>already in the language's native format</i> 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 <span style="font-family:monospace">int</span> 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...).</div><div><br></div><div>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 <i>do anything</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><br><div>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 :)</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">Document doc = // read XML document</span></div><div style="margin-left:40px"><span style="font-family:monospace">for (Element child : XPATH."$doc/Users/User") {</span></div><div style="margin-left:40px"><span style="font-family:monospace"> if (XPATH."not($child/favoriteLanguage)") {</span></div><div style="margin-left:40px"><span style="font-family:monospace"> $child.appendChild(XML."<favoriteLanguage>Java</favoriteLanguage>");</span></div><div style="margin-left:40px"><span style="font-family:monospace"> }</span></div><div style="margin-left:40px"><span style="font-family:monospace">}</span></div><div style="margin-left:40px"><span style="font-family:monospace">// write out modified XML document</span></div><div><br></div><div>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?</div><div><br></div><div>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: <span style="font-family:monospace">XML.<foo bar="blah"/></span></div><br><div>Of course one could also "untemplate" or deconstruct like we do with patterns:</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">JSON json = // read JSON config</span></div><div style="margin-left:40px"><span style="font-family:monospace">String displayName = null;</span></div><div style="margin-left:40px"><span style="font-family:monospace">int verbosity = 0; // default quiet</span></div><div style="margin-left:40px"><span style="font-family:monospace">JSON."""</span></div><div style="margin-left:40px"> {</div><div style="margin-left:40px"><span style="font-family:monospace"> "config": {</span></div><div style="margin-left:40px"><span style="font-family:monospace"> "displayName": $displayName,</span></div><div style="margin-left:40px"><span style="font-family:monospace"> "verbosity": $verbosity</span></div><div style="margin-left:40px"><span style="font-family:monospace"> }</span></div><div style="margin-left:40px"><span style="font-family:monospace"> }""".deconstruct();</span></div><div style="margin-left:40px"><span style="font-family:monospace">assert displayName != null;</span></div><div style="margin-left:40px"><span style="font-family:monospace">if (verbosity > 0)</span></div><div style="margin-left:40px"><span style="font-family:monospace"> System.out.println("Using display name \"" + displayName + "\"");</span></div><div><br></div><div><div>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.</div></div></div><div dir="ltr"><br></div><div>-Archie</div><div><br></div><div dir="ltr"><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</div>