This is one feature I have wanted in Java for a long time. String::format is close but feels clunky.
Anonther feature I would like to see added is operator overloading so we can do away with ugly method calls for BigDecimal arithemetic.
JEP 430: String Templates (Preview) Proposed to Target Java 21
131–140 of 246 posts
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#132Earlier quoted context omitted.
You-the- user can make C#'s safe, you-the- library-developer can make Java's safe. All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. I'd usually be the first to point out how C# did it earlier and better, but in this case Java's manages to surpass even Rust's, which I didn't think was possible.
Can you not make an analyzer that raises an error if you try to pass anything but a literal-as-format string?
At that point Java is completely null-safe. But sure, static analysis and tooling is a great advantage of bigger languages.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#133Earlier quoted context omitted.
We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. The extensibility and power of string templates were a requirement; security experts quite simply vetoed adding string interpolation as it's just too dangerous, especi…
> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. You (collectively) have this wrong; C, C++, C#, Rust, Go, et al. have it right. As long as we're just stating our beliefs outright instead of justifying them, that is. (That's not a request to justify your opinion; I'm sure it's been argued to death already.) > security experts quite simply…
Java still sits very close to JVM byte code, which is typed - adding unsigned ints would duplicate a huge deal of instructions.
So this feature has to wait for primitive classes, where it can be as simple as
primitive class unsigned {
int value;
}
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#134Earlier quoted context omitted.
We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. The extensibility and power of string templates were a requirement; security experts quite simply vetoed adding string interpolation as it's just too dangerous, especi…
> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. What disadvantages do unsigned ints have?
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#135Earlier quoted context omitted.
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…
> 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
StringTemplate t = RAW.”My name is \{name}”;
STR.process(t)Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#136I thought the choice of STR was ugly at first but as you continue reading and see how that allows multiple options that provide more than generic string joining it really starts to make sense. Unlike many here I do like the choice of \{}, although personally I would have preferred \() like Swift. I can’t wait.
I wonder if lowercase "str." will work. Should be easier to type. I didn't find anything about that.
final var str = STR;Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#137Earlier quoted context omitted.
I wonder if lowercase "str." will work. Should be easier to type. I didn't find anything about that.
STR seems to function like a class name, where you’re calling a static method. In fact that’s literally what you’re doing, but it seems to be syntactic sugar that you don’t have to write the method name and the parentheses. Since class names start with a capital it fits. At least I think that was the reasoning they stated. Why not Str? Perhaps they thought this would be less likely in existing code. I’m not sure I do…
STR is a static field, and the syntax sugar is equivalent of
StringTemplate t = RAW.”Hello, \{name}.”
STR.process(t);Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#138I wonder if annotations and annotation pre-processors could have been an alternate way to approach this had they been applicable to String constants. String name = "Joan"; PreparedStatement query = @SQL "select * from users where firstname = \{name}";
This also made me think of prepared statements. It would be more readable to have all the values in their respective place in the SQL string, rather than have a bunch of question marks followed by all the values bunched together at the end. e.g. this: PreparedStatement query = SQL."SELECT * FROM users WHERE firstname=\{firstName} and lastname=\{lastName} and email=\{email}"; rather than: query = client.prepare("SELEC…
This literally even has examples in the JEP, one can create custom template processors which don’t even have to return a String, but can return a PreparedStatement instead.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#139Does any one know what are the advantages of STR."templ" syntax vs STR("templ")?
“templ” would be an ordinary string literal in the second case, in the former case the parser can already distinguish between the two.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#140Earlier quoted context omitted.
“${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.
That's why JS use ` and not reuse ". 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.
Isn’t the STR.” prefix enough to distinguish traditional strings from format strings?