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

91–100 of 246 posts

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

#91

Post by dmitriid »

kothar wrote: post #28
Noe2097 wrote: post #22

Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.

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

#92

Post by _old_dude_ »

pron wrote: post #45
_old_dude_ wrote: post #25

It seems the design team has lost its mojo. First, the lesson of Log4Shell have not been learnt. Allowing more libraries to do formatting, what can go wrong ? And String.format() is slow because every values are boxed. This JEP repeats the same mistake with the templates.

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 why it's a macro in Rust.

This JEP tries to solve a harder problem, user defined template processors but do not provide the tool to make them efficient and never will. Are you suggesting that there is a JEP about macros in the making ?

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

#93

Post by rcoveson »

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.

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 vetoed adding string interpolation as it's just too dangerous

Laughable. In an alternate universe where it didn't already exist, this could have been a JEP for StringBuilder and they would have vetoed that too.

> As to `STR.` -- which you won't need to use most of the time

Except for when you're trying to... make a String? Which is what ~everybody who ever asked for string interpolation in Java wanted to do?

What year would you estimate it will be when, at the average Java job, I can expect that most of the library APIs available to me which were often invoked with the form `func(String.format(...))` will have similar APIs that behave as JEP 430 template processors? Maybe after it's been full release for 3 years? 2, optimistically? Because during those years, in order to use this thing at all, people will be using `STR."\{}"`

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

#94

Post by vips7L »

layer8 wrote: post #85
ninkendo wrote: post #68

One thing I'm not sure is possible in this proposal, is there a way to make the interpolation "lazy", such that the string (and the evaluation of its interpolated components) can be skipped if the string isn't ultimately used? In swift, there's some nice quasi-laziness you can add to function parameters, so that (say) a logging function that can fully skip evaluating a string sent to it with the `@autoclosure` syntax…

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

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

#97

Post by zelphirkalt »

taftster wrote: post #33
pron wrote: 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…

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.

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

#98

Post by coldtea »

The_Colonel wrote: post #53
pron wrote: 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).

I, for one, like checked exceptions.

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

#99

Post by coldtea »

tialaramex wrote: post #83
kaba0 wrote: post #56

Earlier quoted context omitted.

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.

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.

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

#100

Post by zelphirkalt »

dmitriid wrote: post #91
kothar wrote: post #28

Earlier quoted context omitted.

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.

PHP never stood out as a language with very clean syntax. It is very PHPesque to put the burden on the user of the language instead of going the extra mile and implement something that might be harder to parse, but would be more consistent. Inonsistency in general is one of PHP's issues.
Post reply on HN