String name = "Joan";
String info = STR."My name is \{name}";
I don't love it, to be honest. `STR` is a bit much. Requiring the \ for the first but not second brace. I want string templates in Java, but this feels ugly.
STR is not some special syntax, just a receiver for a method call. You would only need STR to interpolate a template into a String, but any receiver can specify that interpretation of the template -- or a different one. So, for example, a logger could use:
log.info."x: \{x}";
and similarly for other uses that don't produce strings but JSON, SQL etc. So STR would only be used -- hopefully rarely -- for old APIs that have not determined their own template interpretation strategy and only accept String.
The use of the backslash is important to distinguish between a string literal and a template literal because "x: \{x}" is not a valid string literal today. Swift uses \(...), BTW.
Because it doesn't hurt, and because it will take some time until all relevant libraries expose their chosen template processor, reducing the need for STR, the tax on less restrained uses needs to be neither too high nor too low.
As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing. What about another symbol? #,%,|,<...
Of course, $ is ideal because it's already everywhere and familiar.
I guess a typographer of a font designer would be helpful to find a good solution.
> As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing.
No, it is the escape symbol and works just like the escape symbol because it is the escape symbol.
The escape symbol \ means that whatever follows should not be treated literally but interpreted in some special way. So "\n" means "not the letter n but rather a newline", and "\u1234" means "not the letter u followed by the digits 1, 2, 3, 4, but rather the unicode character U+1234". And in exactly the same way, "\{...}" means "not the opening curly brace followed by some stuff and then a closing curly brace, but rather special semantics for the expression (not variable) within the curly braces".
> Of course, $ is ideal because it's already everywhere and familiar.
It is already everywhere, including in existing Java strings in existing Java code, and the semantics of that existing code must not change. The very fact that it is already everywhere means that it is not ideal in the context of retrofitting this feature onto Java.
Yes, it is a very tiny new syntax so that templates can be distinguished from string literals (so string templates can never stand without a template processor, hence the RAW)
It is indeed ugly. Having switched full-time to Kotlin a little less than a year ago, I honestly prefer their approach to String interpolation using `${var}`.
I understand Java has a backwards compatibility issue that Kotlin does not though, which would make breaking changes to all the hard-coded strings containing `$` that would now need to be escaped. This is discussed in the JEP.
Backwards compatibility - simultaneously Java's strongest and weakest asset.
Im guessing that the second backslash was deemd unecessary (and in my opinion it is - no need for additional key strokes in the name of some arbitral consistancy).
Besides you are probably looking at this wrong - backslash here is equivalent of hash or dolar sign - it denotes begining of expression (just like most languages do). And they literally could not use another one because of backward compatibilty it they want to keep the "no STR"/simple versuon of interpolation possible. They will just add new escape sequence /{ - its kinda brilliant if you think about it.
I tell you, if the longest lasting super popularity of any programming language in the history of computing (with the possible exception of C) is what failure to get anything right looks like, I hope we keep getting things wrong just like that for decades to come.
But to those who ever wish to have another language that's as successful as Java, I would suggest studying what it is that Java values, which might explain why is it that almost twenty years after having died at the hands PHP, and some years later being finished off again for good measure by Ruby, and then had its coffin nailed shut by Node, Java is still more lively than its supposed heirs.
My fear is that Java is now only popular in a professional setting, and is no longer of interest in the broader community. This is sad to me because I personally love the features that you all have been delivering in recent releases, and am very excited about the ones coming down the pike.
A few circumstantial examples. If you look at the Matrix SDKs and implementations (https://matrix.org/docs/projects/try-matrix-now/), Java's presence is sorely lacking. The initial server implementation was written in Python of all things and the rewrite in Go. This is baffling as a Java implementation seems like a no-brainer to me.
In addition to working for a variety of corporations, I have also done some work for academic institutions, specifically in the library space. They have a lot of old tools from the 2000-2010ish range that are predominantly in Java. However, now, these institutions are primarily using Python and Javascript, and are even struggling to find Java developers to maintain their old infrastructure.
fwiw, the team that created Matrix almost exclusively used Java serverside from 2003-2014 (when we switched to creating Matrix). The last gen of Java servers we wrote were super efficient and nice to maintain thanks to netty.
The only reason we switched to Python and Twisted for the first gen Matrix server (synapse) was for rapid prototyping using a platform that we reasoned the open source and selfhosting community would already have installed and be comfortable with. Java felt way too enterprisey and non-open-source-friendly, making quick tweaks to the codebase a huge pain, not to mention the verbosity of the language. The team agreed that expecting casual folks to install and use a JVM just for a chat server would be a major turn-off, and we continue to feel that was the right call.
I think this perfectly demonstrates my point. Thanks for sharing. Java was perceived as "enterprisey and non-open-source-friendly".
It's also interesting to hear that a Java deployment was thought to be more difficult than a Python deployment. My baised opinion is the exact opposite. Java services are generally incredibly simple to run, especially if you make a fat jar executable.
There is no longer any need to download a JDK (which, BTW, also no longer requires any installation) to use Java. Applications are now encouraged to bundle a custom runtime which, thanks to jlink, can be quite small; usually smaller than a Python runtime (~40MB for a runtime suitable to many or most servers).
You have a point, which is why making Java easier to learn and easier to write smaller, less "serious" software is one the areas we're focusing on at the moment. You'll see some of the relevant features appearing very soon. Some of the relevant enhancements are on the language side (e.g. https://openjdk.org/jeps/8302326 with more in that area to follow soon) and others on the tooling side. Stay tuned!
Yeah, the choice of \{ to create an expression instead of printing a literal { character is an odd one when you compare how you output a double-quote character:
> To aid refactoring, double-quote characters can be used inside embedded expressions without escaping them as \".
I would expect for consistency that \"{expression}\" outputs an expression and \"\{expression}\" would not.
