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

101–110 of 246 posts

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

#101

Post by brewmarche »

DaiPlusPlus wrote: post #64
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...

A major shortcoming with FormattableString is that the C# compiler is hard-coded to always prefer implicitly converting an interpolated string to a string, which makes it impossible to write extension-methods for FormattsbleString objects. …and they also always default to formatting with CurrentCulture instead of InvarintCulture. Apparently this was by-design as interpolated strings were never originally intended for…

C# 10 introduced interpolated string handlers. They allow to address some of your points (you can handle format strings however you want and you could also choose invariant culture by default, without using FormattableString.InvariantCulture) and at the same time avoid allocations.

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

#102

Post by woodruffw »

coldtea wrote: post #99
tialaramex wrote: post #83

Earlier quoted context omitted.

Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason. Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into t…

> Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. If they're checked exceptions, then the control flow is hardly "implied". If anything, it's explicit: this method potentially throws X, so if X is raised, expect this control flow consequence.

I think the "implied" part is in the callsite ambiguity: a Java method marked with "throws X" can raise X at any callsite in its method body, whereas a Rust function of type `Result` has each `Err` variant marked either directly with a return or with the `?` sugar.

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

#103

Post by thamer »

tofflos wrote: post #36

I 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("SELECT * FROM users WHERE firstname=? and lastname=? and email=?",
                           firstName, lastName, email);

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

#104

Post by pron »

_old_dude_ wrote: post #92
pron wrote: post #45

Earlier quoted context omitted.

The template instantiation itself is done by the language, not libraries, and the entire mechanism was designed for security (read the JEP); for example, templates are (virtually) limited to literals and can't come from user input. As to boxing, the built-in template processors, STR and FMT, don't do boxing (they use MethodHandle mechanisms similar to those used by lambdas) -- FMT is ~40x faster than String.format, I…

> the entire mechanism was designed for security ... I don't have the same definition of security (i've read the JEP). Unlike TypeScript, you can not type the template values. > built-in template processors, STR and FMT, don't do boxing ... but all the others user-defined template processors (think a logger) are second class citizens and will do boxing. Efficient String interpolation is hard without macros, that's wh…

> Efficient String interpolation is hard without macros

Not quite. It is hard without some compile-time computation, but what's compile-time for languages relying on AOT compilation (and requires macros or compile-time introspection as in Zig), happens at runtime in Java because that's when the optimising compilation happens, and Java has a user-exposed mechanism for defining call-sites (https://docs.oracle.com/en/java/javase/19/docs/api/java.base...). It's just that, as with most of our new features, we expose a simple API first and a sophisticated API later. No need for macros.

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

#105

Post by GoToRO »

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.

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

#106

Post by pron »

rcoveson wrote: post #93
pron wrote: post #26

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

Maybe you're right, but I think it's not so much a matter of what's right or wrong, but what's appropriate for languages with different audience size. Our experience is at evolving a language for a certain audience size, and perhaps if Java's popularity declines to the more modest market shares of the languages you mentioned, their choices may become appropriate for Java, too.

As to your other points, like I explained to someone else here, even three decades of experience evolving a language that's achieved a measure of success is still no guarantee that every feature will work well, which is why most big new features, string templates included, are first released as preview (i.e. a feature that may change). That allows us to test our hypotheses against the problems people actually encounter rather than those we or others may speculate they'd encounter, and adjust the feature accordingly before it is finalised. To the best of my knowledge, all preview features have undergone some adjustment before becoming permanent, but usually the changes required were relatively small.

Also, we try to think more long-term, because in ten years no one is going to care or even remember if a feature arrived five or seven years prior.

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

#108

Post by ec109685 »

layer8 wrote: post #82
spankalee wrote: post #44

Earlier quoted context omitted.

I don't understand this rationale either: > For the syntax of embedded expressions we considered using ${...}, but that would require a tag on string templates (either a prefix or a delimiter other than ") to avoid conflicts with legacy code. Can't the template processor expression itself function as the tag? Is STR."..." already legal now?

They want String info = "My name is \{name}."; to be a compile-time error because it is missing the template processor (e.g. the `STR.` prefix). Since existing code like String info = "My name is ${name}."; is valid, they can’t use that syntax, or any other syntax that is currently allowed, as otherwise they would lose the ability to make it an error. ——— However, what they could have done instead is to use a syntax…

Futzing around with quotes like that is worse to type and it’s nice having distinct characters for open and close.

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

#109

Post by pron »

zelphirkalt wrote: post #97
taftster wrote: post #33

Earlier quoted context omitted.

And honestly, in my opinion, that approach is just really proving itself right now. I am so happy to see Java seemingly on the right path again, adopting solid capabilities, innovating, but letting other languages take some punches first. We have had some dark days (maybe a dark decade), but full steam ahead now. Thank you pron and team!

It is not really innovating, if it has been battle-tested by other languages, is it? While modern Java sometimes makes me think about reviving and modernizing an old project of mine, if Java is simply always behind by design of its evolution process, that makes it less likely, that I want to spend time with it.

Java innovates a lot in the runtime, where it's ahead of virtually all other languages in its combination of performance and observability. But the language very much tries to be conservative and not to innovate (compared to others, that is) for the simple reason that the vast majority of programmers prefer it that way, and Java is a mass-market language. The language itself is not supposed to excite or to challenge but to inspire confidence that you can build a 100KLOC-10MLOC piece of software in it and your investment would be safe 10, 15, 20 years from now.

This strategy has worked really well for Java, and it's worked really well for those who choose Java. Those companies who 10, 15, 20 years ago picked more exciting languages like PHP and Ruby are generally not as happy with their choices now as those who picked Java.

We fully understand that a minority of developers want more feature-rich, adventurous languages, and we're happy that the platform offers them such choices.

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

#110

Post by layer8 »

ec109685 wrote: post #108
layer8 wrote: post #82

Earlier quoted context omitted.

They want String info = "My name is \{name}."; to be a compile-time error because it is missing the template processor (e.g. the `STR.` prefix). Since existing code like String info = "My name is ${name}."; is valid, they can’t use that syntax, or any other syntax that is currently allowed, as otherwise they would lose the ability to make it an error. ——— However, what they could have done instead is to use a syntax…

Futzing around with quotes like that is worse to type and it’s nice having distinct characters for open and close.

It makes perfect sense to have the expressions outside of the string literals, exactly because they are expressions and not literal. Quotes express literalness, the opposite of evaluation.

This is simply replacing the existing

  "My name is " + name + "."
by

  "My name is " (name) "."
by eliminating the plusses, and adding parentheses to make expressions like

  "My name is " ("John") "."
unambiguous (a string template with one parameter that happens to be a string literal). The parentheses also indicate that this is a parameter, like for a function call, that is immediately evaluated. (The whole string template feature is really just syntactic sugar for a function call.)

That way you don’t have to “interrupt” string literals with an expression. Instead you end the string literal normally and then comes an expression.

A string template would be defined as any sequence of string literals and parenthesized expressions.

Post reply on HN