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

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

#191

Post by pron » Sat, Mar 04, 2023, 2:24 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…

There is no longer any need to download a JDK (which, BTW, also no longer requires any installation) to use Java. Applications are now encouraged to bundle a custom runtime which, thanks to jlink, can be quite small; usually smaller than a Python runtime (~40MB for a runtime suitable to many or most servers).

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

#192

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

pron wrote: post #161

chlorion wrote: post #116

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. What disadvantages do unsigned ints have?

Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfiel…

> E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1].

95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit.

The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well.

> not many advantages for a language like Java.

Agreed.

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

#193

Post by Arathorn » Sat, Mar 04, 2023, 2:31 PM UTC

pron wrote: post #191

Arathorn wrote: post #182

Earlier quoted context omitted.

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…

There is no longer any need to download a JDK (which, BTW, also no longer requires any installation) to use Java. Applications are now encouraged to bundle a custom runtime which, thanks to jlink, can be quite small; usually smaller than a Python runtime (~40MB for a runtime suitable to many or most servers).

I know. I’m not sure this was the case in 2014 though when we made the decision to switch to Python.

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

#194

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

ko27 wrote: post #188

pron wrote: post #162

Earlier quoted context omitted.

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.

It doesn't eventually add the same stuff (even in this case, the feature is quite different from C#'s) as it will never add most of the stuff C# has because we want to keep Java as minimal as possible. But if your point is that Java usually only adds features that other languages already have, that is absolutely true and we'd like to keep it that way. We believe most programmers generally prefer languages with fewer features over languages with many features. As to it having worse usability, that's usually a matter of personal aesthetic preference, and there's no evidence to suggest that's the case by some objective metric.

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

#195

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

Arathorn wrote: post #193

pron wrote: post #191

Earlier quoted context omitted.

There is no longer any need to download a JDK (which, BTW, also no longer requires any installation) to use Java. Applications are now encouraged to bundle a custom runtime which, thanks to jlink, can be quite small; usually smaller than a Python runtime (~40MB for a runtime suitable to many or most servers).

I know. I’m not sure this was the case in 2014 though when we made the decision to switch to Python.

Right, it wasn't. This was done in 2017-18.

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

#196

Post by cesarb » Sat, Mar 04, 2023, 2:36 PM UTC

pron wrote: post #161

chlorion wrote: post #116

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. What disadvantages do unsigned ints have?

Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfiel…

> and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware

And with network protocols and file formats, which also often use unsigned types. As an example, one of the many pain points when implementing JGit was the lack of unsigned types (https://marc.info/?l=git&m=124111702609723&w=2). Another heavy user of unsigned types would be cryptographic algorithms, but I expect these to be mostly implemented in other languages (like C, C++, or Rust), with a sprinkling of assembly or SIMD intrinsics in performance-critical loops, and called through JNI.

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

#197

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

gergo_barany wrote: post #192

pron wrote: post #161

Earlier quoted context omitted.

Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfiel…

> E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Over…

> 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit.

Yes and no. As Stroustrup's document says, this is an inevitable result of allowing arithmetic on unsigned integers (i.e. subtracting an unsigned int variable with the value 2 from an unsigned variable with the value 1 has the same effect as explicitly mixing it with a signed integer by adding a -2). The only way to avoid that is to add runtime underflow checks to unsigned arithmetic. Once we have user-defined value types, people can choose to do just that, but there seems to be little point in adding it to the core language; the cost/benefit just isn't there.

> overflowing your signed integer is almost certainly wrong as well.

True yet less likely because most integer values appearing in programs are small, and so underflows are more common than overflows.

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

#198

Post by colejohnson66 » Sat, Mar 04, 2023, 2:43 PM UTC

sirsinsalot wrote: post #150

dmitriid wrote: post #91

Earlier quoted context omitted.

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

if you ever had the misfortune of seeing the code for the parser and lexer of earlier versions of PHP youd see that it wasnt due to parsing simplicity but rather the author making poor syntax decisions due to a lack of understanding. Then being walled in by backwards compatibility

Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?

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

#199

Post by zarzavat » Sat, Mar 04, 2023, 3:13 PM UTC

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…

I think you are confused. Unsigned arithmetic is modular. Unsigned integers are both positive and negative.

0b1111_1111 is congruent to both -1 and 255 (mod 256). We simply choose the value 255 as being the principle value for coercions, but you could equally well choose -1.

Is 3pm tomorrow or yesterday? Yes.

Unsigned != non-negative.

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

#200

Post by pron » Sat, Mar 04, 2023, 3:26 PM UTC

yxhuvud wrote: post #179

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…

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.

It's not a better solution but one part of this solution (which also requires templates to originate in the program rather than as input by requiring literals). The rest is done to ensure proper, context-specific quoting/escaping for machine-interpretable constructs, such as JSON and SQL.

As to the dangers of simple string interpolation, here's a warning against using C#'s string interpolation in favour of a safer C# construct: https://bengribaudo.com/blog/2021/04/13/5596/intercepting-st...

We want to make the safe choice the easiest choice, and certainly not the trickier choice. We do that by adding a small tax to the dangerous choice -- i.e. string interpolation. When this feature previews we'll know more about how well this works and can then adjust based on people's actual experience.