Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 430: String Templates (Preview) Proposed to Target Java 21

openjdk.org

Post reply on HN
Print view View original

111–120 of 246 posts

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#111

Post by MBCook »

GoToRO wrote: post #105
MBCook wrote: post #31

I 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.

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 don’t think they mentioned the reason.

They could have also just put it on the String class. Again I didn’t see a discussion as to why that wasn’t suggested.

String.”Hello, \{name}.”

Seems like it would have been reasonable. But this is a proposal so it may change before officially joining the JDK.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#112

Post by knightofmars »

ko27 wrote: post #42

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString as the param type, for example in EF you can do this without worrying about SQL injection: FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}") https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

There's a history that partially explains why this is.

https://news.ycombinator.com/item?id=16353398

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#113

Post by layer8 »

vips7L wrote: post #94
layer8 wrote: post #85

Earlier quoted context omitted.

You probably would pass the equivalent of new Object() { public String toString() { return ; } } You can wrap that into a helper function that takes a lambda, so you can write STR."\{lazy(() -> )}"

Supplier

That would require explicit support by each template processor implementation. The Object#toString approach works independently of the template processor (assuming they all call toString() on the parameters).

Since the string template interface is untyped (parameters are arbitrary Objects), having case distinctions based on the type parameter is fiddly. What if you pass an instance of a class that has a genuine toString() but also happens to implement Supplier for some reason? Or if you pass a Supplier>, will it recurse? What if you pass a Callable or a Future? Will those work as well? This only creates the opportunity for opaque “magic” behavior.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#114

Post by pie_flavor »

ko27 wrote: post #42

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString as the param type, for example in EF you can do this without worrying about SQL injection: FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}") https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

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.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#115

Post by comex »

Someone wrote: post #89
Kwpolska wrote: post #71

Earlier quoted context omitted.

Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.

For another n=1 opinion, I like Swift’s choice, even though it’s different from convention. It’s lighter, typographically. ‘${‘ draws more attention to the delimiters than ‘\(‘. And yes, the delimiters could be made less obtrusive using syntax coloring, but not all tools will do that (e.g. when using grep on a code base)

Swift’s choice has the advantage of visually unifying the two cases where text in a string literal is interpreted as something other than the text itself. One is backslash escapes like \n and \\. The other is string interpolation.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#116

Post by chlorion »

pron wrote: post #26
rcoveson wrote: post #21

> Gosling: For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you…

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

#118

Post by rossjudson »

cbeach wrote: post #95

Java: String info = STR."My name is \{name}"; Scala: val info = s"My name is $name" Why does Java ALWAYS use unnecessary verbosity? I don’t get it. They’ve had years to learn from succinct languages.

I think you mean

Java: var info = STR."My price is $\{price}_";

Scala: val info = s"My price is $$${price}_"

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#119

Post by zaphirplane »

pron wrote: post #11
mabbo wrote: post #3

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…

> 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

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#120

Post by zaphirplane »

MBCook wrote: post #111
GoToRO wrote: post #105

Earlier 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…

+1

The syntactic sugar should be a feature then used used here rather than invent a special cased syntax for a feature

just use a conventional calling syntax. Java is a fairly verbose language with a highly verbose popular patterns

Post reply on HN