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

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

#201

Post by cesarb » Sat, Mar 04, 2023, 3:37 PM UTC

pron wrote: post #186

TheCycoONE wrote: post #183

Earlier quoted context omitted.

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…

> Oracle's "license change" was to open source the entire JDK for the first time in Java's history

The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricing/), or IIRC an earlier change to require a paid license for newer releases of Oracle JDK 8 (which AFAIK is the version most companies use). It's true that it's easy to avoid all of that by exclusively using OpenJDK instead of the Oracle JDK (but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK, and then you find out that it's no longer called AdoptOpenJDK, and now has an even weirder name), but it's also true that it's easy for an employee to end up downloading the Oracle JDK (especially when it's someone who learned Java back when the recommendation was to prefer the Sun JDK instead of an open alternative), which could expose the company to huge licensing costs. It can be less risky to just forbid the use of Java outside of carefully curated environments.

> and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace.

It doesn't matter who is at fault; all the users see is a pointless namespace change, which breaks both source and binary compatibility for something which had been part of the JDK for many releases. To make things worse, it's not something which can be easily be worked around; when providing a library which can run with either the old or the new namespace, you have to provide two separately compiled JARs, and I've seen several popular projects take that path. It's very similar to the Python 2 to Python 3 transition, except that Python allows you to dynamically import a module at runtime (so you can easily create a compatibility shim), while with Java, the package names are fixed in the bytecode. The best workaround I've seen so far (though I haven't played with it yet) manipulates the class bytecode at load time to change the package names (https://github.com/eclipse/transformer).

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

#202

Post by pron » Sat, Mar 04, 2023, 4:00 PM UTC

cesarb wrote: post #201

pron wrote: post #186

Earlier quoted context omitted.

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…

> Oracle's "license change" was to open source the entire JDK for the first time in Java's history The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricin…

> things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license

AFAIK, the change to the pricing model for support was done at the request of Oracle's support customers, as it's easier for them to track. I don't know why non support customers would care one way or another.

> but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK

The OpenJDK website's downloads link links here: https://jdk.java.net

Of course, you can download any of the other builds if you prefer.

> which could expose the company to huge licensing costs

That's incorrect. The Oracle JDK is free to use.

> all the users see is a pointless namespace change

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. Allowing a library that chooses not to be an official Java standard to pretend that it is is also unfair. The maintainers of that library have decided that it would be better to inflict that change on their users rather than remain a Java standard, and maybe they know what's best for their users.

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

#203

Post by avgcorrection » Sat, Mar 04, 2023, 4:07 PM UTC

pron wrote: post #181

avgcorrection wrote: post #177

Earlier quoted context omitted.

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

Well, I’ll agree that one shouldn’t be naive about the “technically superior” arguments. One has to look at why certain things succeeded. In an honest and non-ideological way (e.g. don’t blind yourself on the “technically superior” talking points, whatever that means).

I don’t really have a problem with a backslash over a dollar-sign. I just couldn’t resist...

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

#204

Post by cesarb » Sat, Mar 04, 2023, 4:09 PM UTC

pron wrote: post #197

gergo_barany wrote: post #192

Earlier quoted context omitted.

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

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

That's a dangerous argument. The values might be small, until an attacker provides a large one. Your code has to work properly with all possible values, regardless of which ones are more "likely" or "common". In my experience, unsigned makes this simpler, since there are only two cases to consider (zero or positive) instead of four (zero, positive, negative, and INT_MIN); I've expanded on this in a comment here an year ago (https://news.ycombinator.com/item?id=29770689).

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

#205

Post by layer8 » Sat, Mar 04, 2023, 4:19 PM UTC

vips7L wrote: post #121

layer8 wrote: post #113

Earlier quoted context omitted.

That would require explicit support by each template processor implementation. The Object#toString approach works independently of the template processor (assuming they all call toString() on the parameters). Since the string template interface is untyped (parameters are arbitrary Objects), having case distinctions based on the type parameter is fiddly. What if you pass an instance of a class that has a genuine toStr…

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.

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

#206

Post by Symbiote » Sat, Mar 04, 2023, 4:24 PM UTC

qw wrote: post #147

lenkite wrote: post #77

Earlier quoted context omitted.

What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)

They are ok to use I press ⌥ + 8 for square brackets and SHIFT + 8 for parentheses. It's probably not possible to find better alternatives for Mac keyboards that could be used for a language based on Lisp syntax. The Mac keyboard simply doesn't have any dedicated keys that are not used for normal text, except for "@". For some unknown reason, they have a dedicated key for umlauts ("¨") that we don't use in our langua…

I think the umlaut key exists on Norwegian and Danish keyboard so occasional Swedish and German names can be typed.

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

#207

Post by pron » Sat, Mar 04, 2023, 4:27 PM UTC

cesarb wrote: post #204

pron wrote: post #197

Earlier quoted context omitted.

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

> True yet less likely because most integer values appearing in programs are small, and so underflows are more common than overflows. That's a dangerous argument. The values might be small, until an attacker provides a large one. Your code has to work properly with all possible values, regardless of which ones are more "likely" or "common". In my experience, unsigned makes this simpler, since there are only two cases…

That's one way of looking at it; another is that the common bugs due to underflow with small numbers themselves create more exploitable vulnerabilities. Anyway, I think your point of view is valid, but it will have to become much closer to a consensus before Java considers changing the status quo and adding unsigned types to the core language.

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

#208

Post by Symbiote » Sat, Mar 04, 2023, 4:29 PM UTC

_old_dude_ wrote: post #32

kaba0 wrote: post #29

Earlier quoted context omitted.

“${val}” is a legal string literal that is certainly used in plenty of existing programs. In current Java you would have to escape \, so only “\\{val}” could have existed before.

That's why JS use ` and not reuse ". You want the lexer to be able to make the difference between a constant string and a template string and you want users to be able to read the code. This JEP solves the former not the later.

` would be even more difficult to type, and is easily confused with '.

On European (other than British/Irish) keyboards where it exists, it will often be a dead key.

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

#209

Post by pron » Sat, Mar 04, 2023, 4:30 PM UTC

cesarb wrote: post #196

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…

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

Java does allow you to work with unsigned types efficiently (look at the methods with unsigned in their names in the Integer or Long classes: https://docs.oracle.com/en/java/javase/19/docs/api/java.base...). But those uses are relatively specialised and the vast majority of Java users don't need that. So it's best to keep them as APIs rather than in the core language.

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

#210

Post by cesarb » Sat, Mar 04, 2023, 4:33 PM UTC

pron wrote: post #202

cesarb wrote: post #201

Earlier quoted context omitted.

> Oracle's "license change" was to open source the entire JDK for the first time in Java's history The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricin…

> things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license AFAIK, the change to the pricing model for support was done at the request of Oracle's support customers, as it's easier for them to track. I don't know why non support customers would care one way or another. > but then you find out that you have to download from AdoptOpenJD…

> 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, and Oracle did have control over them, until one day they decided they didn't want them anymore. As a part of Java, users did expect them to keep working (other than small changes like adding or removing a couple of methods, which became even less of a risk of breakage once Java 8 introduced default methods). The use of these libraries is pervasive all over the Java ecosystem, which leads to the complaint mentioned in the comment above: by first removing them on Java 11, and then forcing their new maintainer to rename the packages (instead of grandfathering them as an exception, or even better, providing an aliasing mechanism so that the renaming wouldn't break binary compatibility), Oracle broke some of the faith people had on Java's stability and backwards compatibility.