JEP 430: String Templates (Preview) Proposed to Target Java 21 • Hacker News Board

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

#181

Post by pron » Sat, Mar 04, 2023, 1:51 PM UTC

avgcorrection wrote: post #177

pron wrote: post #88

Earlier quoted context omitted.

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.

That's cute, but that appeal is crucial because technical arguments that are divorced from empirical results in the field are a great way to spend a lot of time solving the wrong problems. For example, you can make technical arguments in favour of either VHS or Betamax, but while they both had superior solutions to two separate technical problems, one of those problems (recording time) ended up being a much more important one for more people than the other. The purpose of engineering is not to enjoy intellectual puzzles, but to solve problems for people. You can only insist that the team that's at or near the top of the charts for so many years don't know what they're doing so many times. After a while, you may want to reconsider your beliefs about what the right approach is.

Those who misunderstand that will forever be puzzled by why it is that the VHSes usually win over the Betamaxes, and will continue betting on the wrong horses.

The relatively new concept of preview features helps us gather information on what problems people actually encounter when working with a new feature as opposed to what problems some speculate they'll run into. The best way to influence Java's direction is not to speculate, but to report problems you've actually encountered to the relevant OpenJDK mailing list (amber-dev in this case). If the use of the \ or $ character turns out to be a real problem, we expect to find that out during the preview process (which will begin in JDK 21, out this September) and we'll reconsider, only we'll do it based on reports, not speculation.

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

#182

Post by Arathorn » Sat, Mar 04, 2023, 1:56 PM UTC

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…

fwiw, the team that created Matrix almost exclusively used Java serverside from 2003-2014 (when we switched to creating Matrix). The last gen of Java servers we wrote were super efficient and nice to maintain thanks to netty.

The only reason we switched to Python and Twisted for the first gen Matrix server (synapse) was for rapid prototyping using a platform that we reasoned the open source and selfhosting community would already have installed and be comfortable with. Java felt way too enterprisey and non-open-source-friendly, making quick tweaks to the codebase a huge pain, not to mention the verbosity of the language. The team agreed that expecting casual folks to install and use a JVM just for a chat server would be a major turn-off, and we continue to feel that was the right call.

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

#183

Post by TheCycoONE » Sat, Mar 04, 2023, 1:56 PM UTC

pron wrote: post #109

zelphirkalt wrote: post #97

Earlier quoted context omitted.

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.

Java innovates a lot in the runtime, where it's ahead of virtually all other languages in its combination of performance and observability. But the language very much tries to be conservative and not to innovate (compared to others, that is) for the simple reason that the vast majority of programmers prefer it that way, and Java is a mass-market language. The language itself is not supposed to excite or to challenge…

Perhaps it's not fair to blame the language, but the javax -> jakarta EE transition and Oracles license changes have broken a lot of faith in stability that must be frustrating as a language researcher with that goal.

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

#184

Post by gergo_barany » Sat, Mar 04, 2023, 2:00 PM UTC

optician_owl wrote: post #129

pron wrote: post #11

Earlier quoted context omitted.

STR is not some special syntax, just a receiver for a method call. You would only need STR to interpolate a template into a String, but any receiver can specify that interpretation of the template -- or a different one. So, for example, a logger could use: log.info."x: \{x}"; and similarly for other uses that don't produce strings but JSON, SQL etc. So STR would only be used -- hopefully rarely -- for old APIs that h…

As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing. What about another symbol? #,%,|, Of course, $ is ideal because it's already everywhere and familiar. I guess a typographer of a font designer would be helpful to find a good solution.

> As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing.

No, it is the escape symbol and works just like the escape symbol because it is the escape symbol.

The escape symbol \ means that whatever follows should not be treated literally but interpreted in some special way. So "\n" means "not the letter n but rather a newline", and "\u1234" means "not the letter u followed by the digits 1, 2, 3, 4, but rather the unicode character U+1234". And in exactly the same way, "\{...}" means "not the opening curly brace followed by some stuff and then a closing curly brace, but rather special semantics for the expression (not variable) within the curly braces".

> Of course, $ is ideal because it's already everywhere and familiar.

It is already everywhere, including in existing Java strings in existing Java code, and the semantics of that existing code must not change. The very fact that it is already everywhere means that it is not ideal in the context of retrofitting this feature onto Java.

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

#185

Post by sitta » Sat, Mar 04, 2023, 2:12 PM UTC

Arathorn wrote: post #182

sitta wrote: post #169

Earlier quoted context omitted.

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…

fwiw, the team that created Matrix almost exclusively used Java serverside from 2003-2014 (when we switched to creating Matrix). The last gen of Java servers we wrote were super efficient and nice to maintain thanks to netty. The only reason we switched to Python and Twisted for the first gen Matrix server (synapse) was for rapid prototyping using a platform that we reasoned the open source and selfhosting community…

I think this perfectly demonstrates my point. Thanks for sharing. Java was perceived as "enterprisey and non-open-source-friendly".

It's also interesting to hear that a Java deployment was thought to be more difficult than a Python deployment. My baised opinion is the exact opposite. Java services are generally incredibly simple to run, especially if you make a fat jar executable.

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

#186

Post by pron » Sat, Mar 04, 2023, 2:12 PM UTC

TheCycoONE wrote: post #183

pron wrote: post #109

Earlier quoted context omitted.

Java innovates a lot in the runtime, where it's ahead of virtually all other languages in its combination of performance and observability. But the language very much tries to be conservative and not to innovate (compared to others, that is) for the simple reason that the vast majority of programmers prefer it that way, and Java is a mass-market language. The language itself is not supposed to excite or to challenge…

Perhaps it's not fair to blame the language, but the javax -> jakarta EE transition and Oracles license changes have broken a lot of faith in stability that must be frustrating as a language researcher with that goal.

Oracle's "license change" was to open source the entire JDK for the first time in Java's history (although many people tried to make sure this was misunderstood, which wasn't helped by Oracle's poor communication -- now that's frustrating), and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. Even Oracle only uses the java/javax namespaces for JCP APIs. They claimed it was too inefficient, but Java SE churns out two specification versions a year through the JCP, despite them being bigger and more complex than Jakarta EE.

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

#187

Post by kaba0 » Sat, Mar 04, 2023, 2:15 PM UTC

gergo_barany wrote: post #180

kaba0 wrote: post #133

Earlier quoted context omitted.

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.

Sure, though I do think that the currently existing rift between the primitive and object world should be healed first, to not leave behind another construct that will only be a backwards compatibility hindrance later.

(If I’m not mistaken, the existing unsigned functions already compile down to efficient machine code, so in the meanwhile that works)

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

#188

Post by ko27 » Sat, Mar 04, 2023, 2:17 PM UTC

pron wrote: post #162

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

Whether or not a hoarder is "ahead" of you at having stuff is a matter of perspective. C# strives to be a very feature-rich language, while Java strives to be minimalistic. So it's pretty certain that any feature Java does end up adding will have been in C# first (although this one is not quite the same), but Java certainly doesn't want to go in the same direction. On the other hand, Java's GCs, JIT compilers, and ob…

The point is that Java eventually adds the same stuff as well just with worse usability than the C# counterpart.

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

#189

Post by qw » Sat, Mar 04, 2023, 2:20 PM UTC

v-erne wrote: post #148

qw wrote: post #48

Earlier quoted context omitted.

I agree. On my keyboard I need to press ⌥ + ⌘ + 7 It's actually made worse because { and } also need special combinations. To type \{X} I need to press (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9) I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.

You just made me to get my MacBook out of closet :) (I stopped using it two months ago and moved to X1 carbon right before pandemic) The ergonomic of \{X} is exactly the same on it as on my carbon x1, my keychron tls and four other keyboards I happen to have in my drawer. Are You using modified Apple II like Rebecca Heineman or some kind of super small keyboard that looks like someone forgot to put all the keys in :)…

It's a standard full sized external Mac keyboard for Norway bought directly from the Apple store. We share the keyboard with Denmark too I think. The Swedes and Finns have different keyboards, but I think they use a similar combination for backslash.

So the Mac issue applies to 4 countries in the Nordics at least. Please note that traditional PC keyboards use a different layout for some characters and may in some cases have a dedicated key for backslash too, in case you Google Norwegian keyboards. It's one of those Mac vs PC things we are used to.

Before anyone starts suggesting connecting a PC keyboard to my MacBook Pro, keep in mind that I use the built in keyboard almost 50% of the time and having two different key mappings is a hassle

Regarding backslashes and other special characters, I never said it's on Java specifically, but the US centric culture in general. K&R used curly brackets when they designed C because they fit the US teletype character set of the 60s/70s, but that doesn't mean it's the best choice today.

I'm not suggesting we use special unicode symbols like arrows and emojis, but just pause for a minute and look beyond the US keyboard and see if we can find a solution that also works ergonomically for at least some non-US countries.

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

#190

Post by MrBuddyCasino » Sat, Mar 04, 2023, 2:24 PM UTC

jillesvangurp wrote: post #160

cbeach wrote: 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.

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 multi-line strings in Kotlin vs Java. In Kotlin you usually have to call .trimIndent(), in Java the defaults are sane so you don't have to.