8 ms·

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 secon

by mabbo 4y ago

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.

lstamour 4y ago
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.
- kaba0 4y ago
  Why would you have to escape ‘{‘? I don’t get your examples. The JEP meant that they can be used inside not, in-between, so: \{ “a” + “b” + 3 } could work.
archgoon 4y ago
[dead]
v-erne 4y ago
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.
pron 4y ago
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.
- Bjartr 4y ago
  > So STR would only be used -- hopefully rarely If that's the hope, why have it automatically imported statically for all files?
  - pron 4y ago
    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.
- zaphirplane 4y ago
  > STR."My name is \{name}"; What is the method call ? Agree with grandparent this looks too inconsistent for Java STR.format(“”) would be more Java with import as Alias
  - kaba0 4y ago
    StringTemplate t = RAW.”My name is \{name}”; STR.process(t)
    - zaphirplane 4y ago
      That’s special magic if I recall my Java syntax correctly System.out.print.”hello” isn’t a thing
      - kaba0 4y ago
        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)
- optician_owl 4y ago
  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.
Alupis 4y ago
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.
sonicgear1 4y ago
Agree. Java can't even get the simplest things right. This stuff makes me want to cry.
- pron 4y ago
  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.
  - sitta 4y ago
    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/ 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.
    - pron 4y ago
      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 https://openjdk.org/jeps/8302326 with more in that area to follow soon) and others on the tooling side. Stay tuned!
waynesonfire 4y ago
completely agree. terrible.

by mabbo 4y ago

lstamour 4y ago

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.

kaba0 4y ago
Why would you have to escape ‘{‘? I don’t get your examples. The JEP meant that they can be used inside not, in-between, so: \{ “a” + “b” + 3 } could work.

archgoon 4y ago

[dead]

v-erne 4y ago

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.

pron 4y ago

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.

Bjartr 4y ago
> So STR would only be used -- hopefully rarely If that's the hope, why have it automatically imported statically for all files?
- pron 4y ago
  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.
zaphirplane 4y ago
> STR."My name is \{name}"; What is the method call ? Agree with grandparent this looks too inconsistent for Java STR.format(“”) would be more Java with import as Alias
- kaba0 4y ago
  StringTemplate t = RAW.”My name is \{name}”; STR.process(t)
  - zaphirplane 4y ago
    That’s special magic if I recall my Java syntax correctly System.out.print.”hello” isn’t a thing
    - kaba0 4y ago
      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)
optician_owl 4y ago
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.

Alupis 4y ago

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.

sonicgear1 4y ago

Agree. Java can't even get the simplest things right. This stuff makes me want to cry.

pron 4y ago
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.
- sitta 4y ago
  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/ 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.
  - pron 4y ago
    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 https://openjdk.org/jeps/8302326 with more in that area to follow soon) and others on the tooling side. Stay tuned!

waynesonfire 4y ago

completely agree. terrible.