It’s impossible. Just use C#. But if you’re forced into using Java, say a university course requires it.

Let’s build a better Java, a superset adding proper string interpolation and much more. But with a focus on producing pure Java after processing. So what do we add? Start simple, fix the lack of string interpolation.

So we can write something simple, more civilised in C# to print a variable:

var name = "Az";
var age = 22;
Console.WriteLine($"{name} is {age} years old.");

But in Java, we have two both kinda bad options.

Option A - String.format with C styled string formatting:

String name = "Az";
int age = 22;
System.out.println(String.format("%s is %d years old.", name, age));

Or the classic way of manually appending the string by paw with a series of concatenations:

String name = "Az";
int age = 22;
System.out.println(name + " is " + age + " years old.");

Neither of which are ideal. STR. has been in preview for years with little sign of becoming a viable option and even if it did, would require using the bleeding edge version of Java. So let’s design our own system.

So why not just implement C#’s string interpolation? Oh Java makes that difficult too, ‘$’ is a legal symbol in Java for naming variables, methods, etc. Okay, that’s a non-starter if we insist on backwards compatibility.

So let’s copy Kotlin’s implementation instead with "$name" to insert a variable into the string and using "${name + age}" for expressions. Seems reasonable but I don’t like that there are two different methods of implementation depending on whether it is an expression or not. I propose we use "${}" for both expressions and variables directly. This requires fully parsing whole expressions just for variables so is more upfront work but ultimately worth it in the end for simplified syntax.

Our Java superset already looks much better than regular Java code:

String name = "Az";
int age = 22;
System.out.println("${name} is ${age} years old.");

Implementation time and we have one immediate design choice in our processed code - do we use String.format or the more tradional var + var + var approach. Easy, I do not want to evaluate what type each variable can be and have support for expressions, +++ hell it is.

Okay, now the design choice which is hardest to get right. Do we use a “simple” find and replace regex or build a rudimentary parser to perform more complex expansions for future additions? I say for now, find and replace to experiment.

50 lines of Python, it works but replacing text in comments? That won’t work… 70 lines, it works but embeds () for variables in e.g. ‘(var)’ when it should only for expressions. That won’t do either. 100 or so lines later, I think I have a working solution, it’s not pretty but it works and the code produced has no hall marks of being processed.

I can write something relatively clean like this:

/*
* "${name} is ${age} years old."
*/

// "${name} is ${age} years old."

public class Main {
    public static void main(String[] args) {
        String name = "Az";
        int age = 22;
        System.out.println("${name} is ${age} years old.");
        System.out.println("Next year, ${name} will be ${age + 1}.");
    }
}

And process it into pure, clean java code:

/*
* name + " is " + age + " years old."
*/

// name + " is " + age + " years old."

public class Main {
    public static void main(String[] args) {
        String name = "Az";
        int age = 22;
        System.out.println(name + " is " + age + " years old.");
        System.out.println("Next year, " + name + " will be " + (age + 1) + ".");
    }
}

So now I can run string-it.py on any file and get vanilia java from it. Not perfect but for files which require heavy use of string interpolation, I can at least use this script. But every little change, needed to re-process before compilation… Less than ideal but maybe that’s a problem to fix in part 2.

So many options for what I could build next, a full C-styled preprocessor since a lot what I intend to do would require that functionality? Maybe, being able to write string instead String sounds nice.