Live data from Hacker News

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

openjdk.org

51–60 of 246 posts

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

#52
post #29

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

It’s not as bad as people make it out to be. Swift without any backwards compatibility constraints chose “\(val)”. It does need a slight getting used to but it is not any worse than ${}.

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

#53
post #13
post #7

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…

Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now.

Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).

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

#54
post #13

Earlier quoted context omitted.

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…

Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).

[deleted]

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

#55
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...

[deleted]

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

#56
post #13

Earlier quoted context omitted.

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…

Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).

Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings.

Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.

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

#57
post #6
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.

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.

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.

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

#58
post #17

That database stuff looks horrible. Why do they feel the need to introduce DB query templating into string templates? No matter what you do on the client side, the database engine itself should escape/validate the data. Didn't we learn that lesson with PHP? In addition to that, not every database needs prepared statements for safe queries e.g. "Parametrized queries" in PostgreSQL (available in libpq as PQExecParams a…

The database stuff looks like an example, and shows how you could extend the template system in a way that doesn't introduce security problems.

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

#59
post #4

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…

I think I’ve discussed this on and off with people for almost six years at this point. I’m so glad to see it’s finally happening.

Now we just need to combine this, the constants work that has been done over the last few years, and regular expressions, to make the regexp API so much nicer.

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

#60
post #13
post #7

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…

Thanks for choosing only tried and proven tech like pervasive nullable pointers.
Post reply on HN