Unlike many here I do like the choice of \{}, although personally I would have preferred \() like Swift.
I can’t wait.
31–40 of 246 posts
Unlike many here I do like the choice of \{}, although personally I would have preferred \() like Swift.
I can’t wait.
Earlier quoted context omitted.
I'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?
“${val}” is a legal string literal that is certainly used in plenty of existing programs. In current Java you would have to escape \, so only “\\{val}” could have existed before.
You want the lexer to be able to make the difference between a constant string and a template string and you want users to be able to read the code.
This JEP solves the former not the later.
Earlier quoted context omitted.
I guess it's an advantage of playing catch-up. You can learn from other languages their experience and mistakes. Still props for the Java team for doing a good job.
Back in 1997, when James Gosling outlined his vision for Java, he said it should be a conservative language (wrapping a very innovative runtime) that would ideally only adopt features that have proven themselves, for some time, in other languages. Being a last mover is at the very core of Java's evolution strategy. It's not playing catch-up because we're not trying to adopt all features other, more "adventurous", lan…
What happens if I already have a field called STR or FMT? > STR is a public static final field that is automatically imported in every Java source file.
Then your STR would be used, and if you want to use this string template STR you would have to use it’s qualified name.
public static final ValidationProcessor $ = ….STR;
$.“My name is \{name}“ String name = "Joan";
PreparedStatement query = @SQL "select * from users where firstname = \{name}";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 h…
If that's the hope, why have it automatically imported statically for all files?
I am legit impressed, and I say this as one who has been very hard on string interpolation in other languages; see https://www.jerf.org/iri/post/2942/ and the matching https://pkg.go.dev/github.com/thejerf/strinterp#section-read... for instance. I have criticisms most developers don't even think about. This isn't exactly what I laid out, of course, but I think it achieves the goals I was looking for, which is the rea…
Indeed. Please no more log4shell hell
Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.
If any of you design a language or a DSL, please, please - avoid the backslash - for the reasons stated above. Hard to type, introduces unseen problems, most will hate it. It (backslash) is unbecoming, of anything elegant.
Earlier quoted context omitted.
I guess it's an advantage of playing catch-up. You can learn from other languages their experience and mistakes. Still props for the Java team for doing a good job.
Back in 1997, when James Gosling outlined his vision for Java, he said it should be a conservative language (wrapping a very innovative runtime) that would ideally only adopt features that have proven themselves, for some time, in other languages. Being a last mover is at the very core of Java's evolution strategy. It's not playing catch-up because we're not trying to adopt all features other, more "adventurous", lan…