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

221–230 of 246 posts

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

#221

Post by Kwpolska »

zelphirkalt wrote: post #154
pron wrote: post #63

Earlier quoted context omitted.

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.

Beginners tend to shoot themselves in the foot fairly often.

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

#222

Post by Quekid5 »

pron wrote: post #178
Quekid5 wrote: post #170

Earlier quoted context omitted.

It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrap…

> Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as…

> The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned.

Happy to hear something might be getting done about it, but users have suffered for 20+ years. I'm probably not going back to Java anyway :).

Any technical details you can share about a potential redesign? AFAICT checked-exception-like-things will always be at odds with the variance requirements on method signatures, so I'm a bit curious. (Outside of the natural solutions where variance isn't a problem, e.g. polymorphic variants or row types.)

Regardless, I'm waaay more interested in the JVM-level improvements that you & co. have been doing! Kudos! Btw, any inside tips on TCO? ;)

> [Gosling]

I have seen that talk, and I largely agree with the philosophy (assuming the goal is correct), but in this particular case, I think it was a mistake to let the problems fester for 20+ years rather than just admitting defeat and removing the checked-ness. If it's going to take that long to implement a solution to a constant pain point... the solution might as well not exist. (Perfect = enemy of good and all that.)

EDIT: Just to add: I definitely don't mean to cast aspersions on anybody in the Java language design team or anything like that -- if that's how my original comment came across. Everybody makes mistakes and predicting the future is hard at the best of times :). I just wish they'd reevaluated some things along the way...

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

#223

Post by kuhsaft »

pie_flavor wrote: post #114
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.

> All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong.

That would cause a compilation error. `DbSet.FromSql(FormattableString sql)` [0] does not have a string overload. Therefore, if a user assigned the interpolated string to a SQL query to a `var` beforehand, then there would be an implicit conversion to a `string` [1] which will be a type mismatch for the `FromSql` call. The user would have to assign the interpolated string to a `FormattableString` instead of `var` for the program to compile. There is also no implicit conversion for a `string` to a `FormattableString`.

There is a `DbSet.FromSqlRaw(string sql, params object[] parameters)` [2] method that explicitly documents that it is vulnerable to SQL injection.

> You-the-user can make C#'s safe, you-the-library-developer can make Java's safe.

You-the-library-developer can make C# safe.

[0] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit...

[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

[2] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit...

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

#224

Post by redeeman »

pron wrote: post #211
cesarb wrote: post #210

Earlier quoted context omitted.

> That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Java ecosystem is decentralised and Oracle has no control over third-party libraries. The libraries which did the namespace change are things like JAXB and JAX-RS and JAX-WS, which have been part of Java since Java 6. It's not some random third-party library, an…

> and then forcing their new maintainer to rename the packages Their new maintainers were not forced to rename the package; they chose to do it. That the java/javax namespaces are governed by the JCP (which will turn 25 years old this year), is well-known to anyone familiar with Java's governance, and I can't see a reason why an exception would be warranted if the maintainers had the choice of staying in the JCP; the…

we should probably also not blow this "problem" out of proportion. If you actively maintain your things, you can probably handle swapping a few strings out that are garantueed to give buildtime errors. If you dont maintain your application and run on antiquated runtimes? well good news, it keeps totally unchanged...

edit: okay, i guess if you do some funky stuff like reflection or having stuff in various config files, it might not give compiletime errors.. still though, recursive search and you'll find the spots in practically all cases

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

#225

Post by vips7L »

layer8 wrote: post #205
vips7L wrote: post #121

Earlier quoted context omitted.

I think you're thinking about it too much. log.info(() -> STR."template \{here}");

The question was whether string templates will support laziness, not whether whatever the string template is eventually used for supports laziness. String templates supporting laziness would make you independent from what the point-of-use supports.

I think that's the wrong question. String templates don't need to support laziness. It's a well established pattern in Java that laziness is done via Supplier's and it directly solves op's question about logging where the level isn't enabled. This is exactly how logback and other logging implementations handle it now.

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

#226

Post by ec109685 »

layer8 wrote: post #110
ec109685 wrote: post #108

Earlier quoted context omitted.

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…

I get that, but it’s hard to type accurately.

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

#227

Post by nunobrito »

imtringued wrote: post #155
nunobrito wrote: post #126

Earlier quoted context omitted.

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.

Still don't get the need for it.

You could always use the + operator to join strings. Even a external library would do just fine when you want to insert some kind of variable name inside strings for that purpose.

Don't really get the need for this to be a core function with such a java-unlike grammar.

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

#228

Post by nunobrito »

kaba0 wrote: post #130
nunobrito wrote: post #126

Earlier quoted context omitted.

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…

> 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 the Arduino platform. Which are entirely unrelated projects to this one with very different engineers working on it. Those are easily parallelized, if you will. I don’t see why having progress completely elsewhere by different people…

Because this thing here adds complexity to the language.

I'll be fine and ignore it completely like I've done with lambdas. I just pity the fools who enter Java world to learn the language and will suffer trying to learn what they believe is something normal programmers use.

Poor souls.

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

#229

Post by jillesvangurp »

MrBuddyCasino wrote: post #190
jillesvangurp wrote: post #160

Earlier quoted context omitted.

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.

It helps to actually read the article. There will be multiple template processors, not just one. This proposal goes beyond simple string interpolation and adds security measures against injection attacks. I'm mostly developing in Kotlin btw., but usually when Java introduces its take on a feature that has existed for a while in other languages, they improve on it. One such example: handling whitespace/indentation in…

The article in this case is a longish specification. I skimmed through it. It looks over engineered to me. That's my honest first impression. A dead give away for that is that it needs a longish specification.

And I indeed missed the bit about a pluggable template engine. Just one question related to that: why? I don't see the big use case for this. Maybe a bit less flexibility and a more sane syntax would be better?

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

#230

Post by cesarb »

redeeman wrote: post #224
pron wrote: post #211

Earlier quoted context omitted.

> and then forcing their new maintainer to rename the packages Their new maintainers were not forced to rename the package; they chose to do it. That the java/javax namespaces are governed by the JCP (which will turn 25 years old this year), is well-known to anyone familiar with Java's governance, and I can't see a reason why an exception would be warranted if the maintainers had the choice of staying in the JCP; the…

we should probably also not blow this "problem" out of proportion. If you actively maintain your things, you can probably handle swapping a few strings out that are garantueed to give buildtime errors. If you dont maintain your application and run on antiquated runtimes? well good news, it keeps totally unchanged... edit: okay, i guess if you do some funky stuff like reflection or having stuff in various config files…

It's more involved than just "swapping a few strings". You also need to make sure that all the libraries you depend on are on the same side of the divide, that is, you have to "swap a few strings" and update all your dependencies at the same time (and these updates could bring unrelated breaking changes with them). And some of these dependency changes might be unexpected; you might not expect a general-purpose logging library to depend on that, yet one popular logging library has to be upgraded from 1.3.x to 1.4.x when changing the namespace from javax to jakarta.

It's even worse when your software can load plugins written by third parties, and your API allows these plugins to expose servlets or similar. You'd have to not only "swap a few strings" and update the dependencies in your software, but also make all these third parties update all plugins at the same time, with no chance of a gradual transition. It's a large amount of pain, for a completely unnecessary naming change.

Post reply on HN