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

171–180 of 246 posts

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

#171

Post by xmcqdpt2 »

sirsinsalot wrote: post #149
kaba0 wrote: 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.

Java is a simple language even if people build gigantic piles of abstractions in it. It doesn't have multiple inheritance, it only has like eight base types, only a few well-worn ways to control flow (while, do while, for, if, switch, throw, return).

It doesn't have operator overloading, or array access overloading. Attributes and methods are instantly discernible by the presence or lack of parentheses. It doesn't have templates or macros.

I don't know many languages that are as simple as Java. If anything Java being so simple syntactically is a major reason why it's so wordy.

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

#173

Post by pron »

sitta wrote: post #169
pron wrote: post #165

Earlier quoted context omitted.

I tell you, if the longest lasting super popularity of any programming language in the history of computing (with the possible exception of C) is what failure to get anything right looks like, I hope we keep getting things wrong just like that for decades to come. But to those who ever wish to have another language that's as successful as Java, I would suggest studying what it is that Java values, which might explain…

My fear is that Java is now only popular in a professional setting, and is no longer of interest in the broader community. This is sad to me because I personally love the features that you all have been delivering in recent releases, and am very excited about the ones coming down the pike. A few circumstantial examples. If you look at the Matrix SDKs and implementations ( https://matrix.org/docs/projects/try-matrix-n…

You have a point, which is why making Java easier to learn and easier to write smaller, less "serious" software is one the areas we're focusing on at the moment. You'll see some of the relevant features appearing very soon. Some of the relevant enhancements are on the language side (e.g. https://openjdk.org/jeps/8302326 with more in that area to follow soon) and others on the tooling side. Stay tuned!

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

#174

Post by twic »

woodruffw wrote: post #102
coldtea wrote: post #99

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

The ideal is probably in the middle. Being able to see where exceptions can be thrown is very helpful if you're manipulating state which can be seen from outside the method, because you need to make sure you leave it in a valid state if an exception is thrown. But in a pure function it's mostly noise.

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

#175

Post by yxhuvud »

imtringued wrote: post #156
rcoveson wrote: post #93

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…

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

> unless the unsigned Integer is fully underflow checked at runtime.

Sure. That doesn't mean the datatype wouldn't be nice to have even with such checks. There are languages out there that fully check over- and underflow. Java could too.

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

#176

Post by [deleted] »

lenkite wrote: post #75
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.

Pity that the Streams functions don't support checked exceptions.

[deleted]

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

#177

Post by avgcorrection »

pron wrote: post #88
Kwpolska wrote: post #78

Earlier quoted context omitted.

I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might en…

Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that yo…

If I had a cent for every time pron appealed to Java’s age and “popularity” in technical arguments, I would have at least enough cents to use a dollar-sign in string template syntax.

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

#178

Post by pron »

Quekid5 wrote: post #170
lenkite wrote: post #75

Earlier quoted context omitted.

Pity that the Streams functions don't support checked exceptions.

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

> The JVM is a marvel of engineering. Java... not so much.

This was James Gosling's stated strategy and one of the secrets of Java's exceptionally-long-lasting success. While many developers like feature-rich, sophisticated languages, the vast majority of them really, really don't (although they are underrepresented on HN, certainly when it comes to language feature discussions). Many of the things people need can be hidden in the runtime, wrapped by a conservative, non-threatening language. Gosling called that "a wolf in sheep's clothing."

See the first half of this talk by Brian Goetz on this very subject: https://youtu.be/Dq2WQuWVrgQ

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

#179

Post by yxhuvud »

pron wrote: post #63
Kwpolska wrote: post #46

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…

Isn't that better solved by not allowing templates to be passed around and blanks filled in later but instead force them to be executed immediately? This is the case in Ruby and while there have been plenty cases of code injection, I've never seen one using the basic string interpolation to do that.

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

#180

Post by gergo_barany »

kaba0 wrote: post #133
rcoveson wrote: post #93

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 )

A lot of seemingly primitive Java syntax already expands to method calls: autoboxing, string conversions, string concatenation. Similarly, primitive arithmetic operators on unsigned integers could expand to calls to the corresponding Integer.{compare,divide,remainder,...}Unsigned methods. The compiler would turn these back into single machine instructions anyway. This would not need any new bytecode instructions.
Post reply on HN