Live data from Hacker News

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

openjdk.org

151–160 of 246 posts

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

#151
post #127

Earlier quoted context omitted.

Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java. I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost ev…

It isn't often I see Java described as simple.

It has quite a few keywords, you have primitives and objects and you call methods on those. Compare it to C#, Swift or C++, and it is insanely tiny compared to those.

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

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

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

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

#153

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. There’s nothing wrong with implied control flow. > All of Java's user defined types insisted on living on the heap. Just want to make a pair of integers? Sorry, that's an Object now and so it lives on the heap, whereas just one integer is fine, those are just local stack variable…

[deleted]

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

#154
post #63

Earlier quoted context omitted.

Python is also widely used server-side, and they introduced f-strings with simple and friendly syntax a few years ago. JS added template literals in 2015’s ES6, when Node.js was very much a thing. Why is Java special here?

Java's syntax is just as friendly and simple -- see my other comments on the subject -- it just requires the receiver to define a policy, which is essential for security. You only need to use STR when the receiver does not define a template processor and works with strings. I have no idea what Python's or JS's security experts advised, but that code injection is one of the most common vulnerabilities in memory-safe l…

When I want to write a query, I will use a prepared statement or read the docs of a library I am using to interact with a database, whether that library automatically creates a prepared statement. If I use a prepared statement and later read that code, I never again have to ask myself, whether it is safe. Quite frankly, who does not know about injection and prepared statements should not work with databases.

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

#155
post #27

Earlier quoted context omitted.

I'm not a fan either. Java seems to be declining in prevalence in my corner of industry, I'm sure these changes are made by wiser minds than mine, but I'm sceptical about whether such a choice is really right for users.

I remain to be convinced and program daily in Java for a long time. It seems just as difficult to remember/useless as lambda expressions that look fine as vanity one-line expressions and then get difficult to write for most programmers. We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to…

JavaScript basically has the same functionality but with ${}. Anyone who uses named parameters in HQL or SQL queries would be very grateful for this feature as it means you no longer have to type out the same name three times for each parameter.

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

#156
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…

The problem with unsigned is the ridiculous underflow behavior. Unsigned integers are inherently unsafe without underflow checking at runtime. When you are using signed integers for a positive number, then seeing a negative number tells you everything you need to know (the program is wrong and it will most likely crash soon). However, when you are using unsigned to mean a number that can never be negative, then you can't just expect people to never underflow it even just to -1 because it will turn into a large positive number by accident. There is a semantic gap between the meaning of the type and what invariants it guarantees at runtime and that means having no unsigned integers is better for most code unless the unsigned Integer is fully underflow checked at runtime.

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

#157
post #133

Earlier quoted context omitted.

> 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; } (Though it would need operator overloading to be used as a+b, which is not really liked in Java designer niches (with many good reasons against it) :D )

Just take the operator overloading from Ceylon which has been designed to only allow mathematical use cases and harder to abuse for anything else. When you see an expression a + b it might not be two numbers but it will most likely be associative, distributive and commutative.

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

#158
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…

>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?

You apparently didn't learn any lesson from PHP. The impossibility of the database engine to distinguish a code from a data character is what lead to SQL injections in the first place.

It doesn't matter whether you replace the template expression with a ? or with $1. The database receives the parameters outside the SQL query and treats them as user input either way.

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

#159
post #73

Earlier quoted context omitted.

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.

That is exactly the point, you should not use general string templating system for SQL queries, together with "roll your own" escape and validation mechanisms. I really don't see why they included that part, if not to show how to shoot yourself in the foot.

I am very confused by your comments. PHP developers thought "sanitizing" strings aka escaping and validating strings is enough to get rid of SQL injections and that is how they ended up with multiple iterations of escaping functions. The problem, which is the separation of code from data, has not been solved and that is why it is a bad idea. The SQL example template in the article uses positional parameters via JDBC and is therefore completely safe to use. It is impossible to get it wrong except by using STR which is obviously the wrong template processor.

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

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

Kotlin:

    val info = "My name is $name"
All strings are templatable in Kotlin. No need to have different types of syntax for that. What purpose does this s or STR. prefix serve serve? Seems completely redundant to me to have that.
Post reply on HN