4 ms·

How have you dealt with the current situation in Java where several new and important language features are still "preview" and are subject to being withdrawn?

How have you dealt with the current situation in Java where several new and important language features are still "preview" and are subject to being withdrawn? The possibility that these features might ultimately disappear is not theoretical: String Templates has been removed[1] from 23 as what would have been the "third preview," for example. The (likely debatable) list of features in 23 that a.) remain preview/incubator and b.) appear relevant to a work on data oriented Java programming are: Primitive Types in Patterns, instanceof, and switch (Preview) – JEP 455 Implicitly Declared Classes and Instance Main Methods (Third Preview) – JEP 477 Flexible Constructor Bodies (Second Preview) – JEP 482 Vector API (Eighth Incubator) - JEP 469 Scoped Values (Third Preview) – JEP 481 [1] https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A... "So, to be clear: there will be no string template feature, even with --enable-preview, in JDK 23." - Gavin Bierman

goostavos 2y ago
I've thought a lot about this quite a bit. In my day to day life, which is a cog in the machine at $Megacorp, I regularly work on embarrassingly old versions of Java (hello JDK 8!). So, not having the latest and greatest language features is a topic close to my heart. As such, the book takes a very tool agnostic approach. If we cover something that's only available advanced JDKs, we also cover what to do if you don't have it. Data oriented programming is about building around the data in your domain. The latest tools are nice, but they're just tools.
- topspin 2y ago
  I appreciate your conundrum. While it has been good to see Java language designers attempt to advance the language, they've been extremely conservative and non-committal. This is a problem because tooling is costly to develop and tool developers are forever facing the problem of whether to invest the work needed to integrate these language features when they take years to be realized, and may yet vanish. Likewise for authors, such as yourself.
whartung 2y ago
I can't say I'm completely on top of the Java world, but I think the String Templates are one of the very few preview features that have been actually withdrawn and removed, right? Are there others? I know some drift a bit on their implementations over time, but have not be wholesale yanked out. Obviously the solution to this is to not rely on these preview functions for production code. The way to do that is to run production in an LTS version of Java. I don't think that's an extreme point of view, frankly. The new stuff is interesting and cool, and in time, it ends up in the LTS version. Having lived through Java 5, 6, and 8, these are halcyon times for Java. It's moving VERY fast, and has been for some time. Are there preview capabilities in the LTS versions? Yes, there are. But they're not under the LTS tent. Don't use them. The demarcation between the development releases and the LTS releases are a smart program to get features out into the world, and set some real lines in the sand for advancement. It helps keep preview items from staying in preview mode for an indeterminate amount of time. And the two year LTS release cycle for a notoriously conservative eco-system is ample.
- topspin 2y ago
  > Are there others? String Literals (JEP 326) made it to preview and got pulled. > I don't think that's an extreme point of view, frankly. Can't see where I suggested otherwise. I just wondered how the author was handling all the "in-flight" (An OpenJDK term there, not mine) features that Java currently has outstanding. > It's moving VERY fast, and has been for some time. They've been fast at creating new preview features. Actually landing finalized features though? In my view they're taking too long. When I compare Java and Python in this respect -- and I do as a working programmer in both on a frequent basis -- Java is still slow.
  - perrylaj 2y ago
    > When I compare Java and Python in this respect -- and I do as a working programmer in both on a frequent basis -- Java is still slow. I feel this as well, but I also think it's desirable. Java is slower to add features because the bar is quite a bit higher (especially with regard to backwards-compatibility). I'd much rather have long previews and occasional removal of previews than have a language that becomes bloated and kneecapped by past rushed decisions. There's Kotlin, Scala, Groovy, etc, if you want to run on the JVM with languages that offer more features (and footguns). I find the balance OK, personally. I'd much rather them pull the `STR.` templates than push it forward knowing its not ergonomic in practice.

goostavos 2y ago

I've thought a lot about this quite a bit. In my day to day life, which is a cog in the machine at $Megacorp, I regularly work on embarrassingly old versions of Java (hello JDK 8!). So, not having the latest and greatest language features is a topic close to my heart. As such, the book takes a very tool agnostic approach. If we cover something that's only available advanced JDKs, we also cover what to do if you don't have it. Data oriented programming is about building around the data in your domain. The latest tools are nice, but they're just tools.

topspin 2y ago
I appreciate your conundrum. While it has been good to see Java language designers attempt to advance the language, they've been extremely conservative and non-committal. This is a problem because tooling is costly to develop and tool developers are forever facing the problem of whether to invest the work needed to integrate these language features when they take years to be realized, and may yet vanish. Likewise for authors, such as yourself.

whartung 2y ago

I can't say I'm completely on top of the Java world, but I think the String Templates are one of the very few preview features that have been actually withdrawn and removed, right? Are there others? I know some drift a bit on their implementations over time, but have not be wholesale yanked out. Obviously the solution to this is to not rely on these preview functions for production code. The way to do that is to run production in an LTS version of Java. I don't think that's an extreme point of view, frankly. The new stuff is interesting and cool, and in time, it ends up in the LTS version. Having lived through Java 5, 6, and 8, these are halcyon times for Java. It's moving VERY fast, and has been for some time. Are there preview capabilities in the LTS versions? Yes, there are. But they're not under the LTS tent. Don't use them. The demarcation between the development releases and the LTS releases are a smart program to get features out into the world, and set some real lines in the sand for advancement. It helps keep preview items from staying in preview mode for an indeterminate amount of time. And the two year LTS release cycle for a notoriously conservative eco-system is ample.

topspin 2y ago
> Are there others? String Literals (JEP 326) made it to preview and got pulled. > I don't think that's an extreme point of view, frankly. Can't see where I suggested otherwise. I just wondered how the author was handling all the "in-flight" (An OpenJDK term there, not mine) features that Java currently has outstanding. > It's moving VERY fast, and has been for some time. They've been fast at creating new preview features. Actually landing finalized features though? In my view they're taking too long. When I compare Java and Python in this respect -- and I do as a working programmer in both on a frequent basis -- Java is still slow.
- perrylaj 2y ago
  > When I compare Java and Python in this respect -- and I do as a working programmer in both on a frequent basis -- Java is still slow. I feel this as well, but I also think it's desirable. Java is slower to add features because the bar is quite a bit higher (especially with regard to backwards-compatibility). I'd much rather have long previews and occasional removal of previews than have a language that becomes bloated and kneecapped by past rushed decisions. There's Kotlin, Scala, Groovy, etc, if you want to run on the JVM with languages that offer more features (and footguns). I find the balance OK, personally. I'd much rather them pull the `STR.` templates than push it forward knowing its not ergonomic in practice.