3 ms·

One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language co

by pron 7y ago

One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful -- HN notwithstanding, most developers don't like too much change in the language. Still, many developers focus on language changes that affect them, rather than major changes than can affect their customers and their business. Recent versions have seen major improvements to the GCs, startup time, and there's an exciting new Java Flight Recorder (low-overhead, deep in-production profiling) feature in 14 that allows streaming flight recorder events. Also, the bit about LTS is problematic. While the multiple LTS update paths have their place (although the widely in their offerings and intended audiences), they are not less risky than the default path. The default path is designed to be the cheapest and easiest, but requires a little bit more agility. The effort required to update to a new feature release is not much bigger than the effort required to update to a patch release, especially as some of the LTS programs have major new features in their "patches." An LTS program should be chosen only once it's been established that the default, recommended update path is not right for your organization, and even then you'll need to compare the different LTS programs, as they differ from one another in about as much as LTS differs from the regular update path. LTS should not be the default choice.

nordsieck 7y ago
> One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful. I think people have taken note of the success of Kotlin, and decided that judiciously chosen language features will help user retention/adoption.
kjeetgill 7y ago
I agree. I find the VM stuff the most facinating too, but I think you're underestimating the incredible impact language changes have had and continue to. Language changes don't aren't just bells and whistles. Lambdas changed how nearly every API works and record types have the opportunity to make a huge difference. Sure var was smaller, but it's been refreshing. I also think you're underselling how conservative the old minor patches used to be. With major versions this frequent LTS atleast sets a reasonable cadence for planning and movement. 6 months is hectic.
- pron 7y ago
  6 months is not hectic, because the new feature releases are not major releases. In fact, major releases are gone, the last one ever being 9. Up until JDK 9, there used to be patch releases every couple of months, and big feature releases (which used to be called "limited updates") every six months. In addition to bug and security fixes, those included large, potentially disruptive features — like JavaFX and support for Linux on Arm in 7u6, Java Flight Recorder and Mission Control in 7u40, AppCDS in 8u40, and even support for Mac OS and a new GC algorithm in 7u4. Those releases also stopped getting patches after six months, when the new one was released, i.e. there were no more patches for 8u20 once 8u40 came out. Now, despite having major, disruptive features, those "limited update" releases were not allowed to change the Java SE spec, so they couldn't change the language or the library API. There were serious problems with the old model, so Oracle decided to do away with major releases altogether. To do that, they relaxed the limitation on spec changes in the six-monthly feature releases, and also changed their name. Instead of 8u40, 8u60 etc., they now get a new integer number. If you don't want to use new API and language features (you can even turn them off with the --release flag), those releases are almost the same as they used to be. If their six-month cadence between 8u40 and 8u60 was good enough for you back then, there's no reason it shouldn't be now. (I work on OpenJDK at Oracle, but speak only for myself)
  - heelix 7y ago
    Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work systems, however. (Did a decade+ at Oracle, and now at a shop three times its size. You should understand inflexibility and moving at the speed of business. :P ) There still are quarterly patches to the LTS releases (7u241, 8u231, 11.0.5), with the next batch due the second week of January for all the LTS versions - 7/8/11 on the Oracle side, 8/11 on the Adopt OpenJDK, and other OpenJDK implementations possibly supporting all three. Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around. (and hearing the woes of all the folks still trying to get past JDK 8)
BossingAround 7y ago
> One thing I find a bit disappointing is the focus on language features Overall, I wouldn't underestimate the importance of syntax features. After all, if a developer likes writing your language, they'll more likely choose it over a different language.
dkersten 7y ago
I agree because I use the JVM but I do not use Java. So I care about changes to the JVM and ecosystem but changes to the Java language itself don’t mean anything to me.
sreque 7y ago
Language changes are super important when they enable you to program in a new way, or in that way with significantly less boilerplate. For instance, Java 8 enabled new ways of programming via Lambdas and structural typing. You could code in that way before, but anonymous class boilerplate was so high that few bothered, and those that did were hard-pressed to convince their colleagues of its value. The problem with language changes is that to make use of them, your developer community has to educate themselves on the new features and how to use them. Certain VM changes like new GC algorithms often don't require this, as the basic interface of the GC is the same (clean up garbage for me, thanks!). I think the next big programming style Java may enable is what I call data-oriented programming, which is enabled via sealed types and pattern matching. This enables you to code the dual of OO, where you have a fixed number of sub-types but an unbounded number of operations. I believe this style of programming is useful far more often than it is used, simply because Java doesn't make it easy to code in this style. Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are: * Improved native code interop. I consider this to be both a language and VM change. * Improved memory layout control, including stack-allocated types and inlined objects inside of other objects. * project loom for golang-style I/O programming. * full tail recursion. Why was this feature rejected from the VM?
- pron 7y ago
  > Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are: Most if not all of them will land in the next few years. In fact, working on those precise features is what most of the OpenJDK team does. > Improved native code interop. I consider this to be both a language and VM change. That would be Project Panama, making its initial, partial delivery in JDK 14 (GA next March, EA available now). > Improved memory layout control, including stack-allocated types and inlined objects inside of other objects. Project Valhalla. The most complicated of the bunch. Just had a recent major breakthrough, and you can work with the EA release already. > project loom for golang-style I/O programming. Working on it :) > full tail recursion. Why was this feature rejected from the VM? Not at all rejected. It's still a goal for Loom. We'll just do lightweight concurrency first. Cost/benefit prioritization etc.
kllrnohj 7y ago
The thing I find disappointing is the lack of bytecode changes. The language changes are all just trivial tweaks to javac. Appreciated niceties, sure, but nothing meaty. The VM changes are then likewise focused mostly on the GC. Again, appreciated, but it's entirely disconnected from the language. Where's the long-overdue improvements to the bytecode? Where's value types? Where's runtime generics?
- pron 7y ago
  It's not true that the VM changes focus mostly on the GCs. There have been significant changes to startup time and low-overhead profiling. And there are constant improvements in the JIT compilers. Project Loom's lightweight concurrency also involves big VM changes, but without any bytecode changes. Reified runtime generics for reference types is a bad idea; it destroys language interop for very little gain. Value types and specialized generics for value types, on the other hand, are in the works. You can download and play with them here: http://jdk.java.net/valhalla/ http://jdk.java.net/valhalla/

by pron 7y ago

nordsieck 7y ago

> One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful. I think people have taken note of the success of Kotlin, and decided that judiciously chosen language features will help user retention/adoption.

kjeetgill 7y ago

I agree. I find the VM stuff the most facinating too, but I think you're underestimating the incredible impact language changes have had and continue to. Language changes don't aren't just bells and whistles. Lambdas changed how nearly every API works and record types have the opportunity to make a huge difference. Sure var was smaller, but it's been refreshing. I also think you're underselling how conservative the old minor patches used to be. With major versions this frequent LTS atleast sets a reasonable cadence for planning and movement. 6 months is hectic.

pron 7y ago
6 months is not hectic, because the new feature releases are not major releases. In fact, major releases are gone, the last one ever being 9. Up until JDK 9, there used to be patch releases every couple of months, and big feature releases (which used to be called "limited updates") every six months. In addition to bug and security fixes, those included large, potentially disruptive features — like JavaFX and support for Linux on Arm in 7u6, Java Flight Recorder and Mission Control in 7u40, AppCDS in 8u40, and even support for Mac OS and a new GC algorithm in 7u4. Those releases also stopped getting patches after six months, when the new one was released, i.e. there were no more patches for 8u20 once 8u40 came out. Now, despite having major, disruptive features, those "limited update" releases were not allowed to change the Java SE spec, so they couldn't change the language or the library API. There were serious problems with the old model, so Oracle decided to do away with major releases altogether. To do that, they relaxed the limitation on spec changes in the six-monthly feature releases, and also changed their name. Instead of 8u40, 8u60 etc., they now get a new integer number. If you don't want to use new API and language features (you can even turn them off with the --release flag), those releases are almost the same as they used to be. If their six-month cadence between 8u40 and 8u60 was good enough for you back then, there's no reason it shouldn't be now. (I work on OpenJDK at Oracle, but speak only for myself)
- heelix 7y ago
  Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work systems, however. (Did a decade+ at Oracle, and now at a shop three times its size. You should understand inflexibility and moving at the speed of business. :P ) There still are quarterly patches to the LTS releases (7u241, 8u231, 11.0.5), with the next batch due the second week of January for all the LTS versions - 7/8/11 on the Oracle side, 8/11 on the Adopt OpenJDK, and other OpenJDK implementations possibly supporting all three. Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around. (and hearing the woes of all the folks still trying to get past JDK 8)

BossingAround 7y ago

> One thing I find a bit disappointing is the focus on language features Overall, I wouldn't underestimate the importance of syntax features. After all, if a developer likes writing your language, they'll more likely choose it over a different language.

dkersten 7y ago

I agree because I use the JVM but I do not use Java. So I care about changes to the JVM and ecosystem but changes to the Java language itself don’t mean anything to me.

sreque 7y ago

Language changes are super important when they enable you to program in a new way, or in that way with significantly less boilerplate. For instance, Java 8 enabled new ways of programming via Lambdas and structural typing. You could code in that way before, but anonymous class boilerplate was so high that few bothered, and those that did were hard-pressed to convince their colleagues of its value. The problem with language changes is that to make use of them, your developer community has to educate themselves on the new features and how to use them. Certain VM changes like new GC algorithms often don't require this, as the basic interface of the GC is the same (clean up garbage for me, thanks!). I think the next big programming style Java may enable is what I call data-oriented programming, which is enabled via sealed types and pattern matching. This enables you to code the dual of OO, where you have a fixed number of sub-types but an unbounded number of operations. I believe this style of programming is useful far more often than it is used, simply because Java doesn't make it easy to code in this style. Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are: * Improved native code interop. I consider this to be both a language and VM change. * Improved memory layout control, including stack-allocated types and inlined objects inside of other objects. * project loom for golang-style I/O programming. * full tail recursion. Why was this feature rejected from the VM?

pron 7y ago
> Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are: Most if not all of them will land in the next few years. In fact, working on those precise features is what most of the OpenJDK team does. > Improved native code interop. I consider this to be both a language and VM change. That would be Project Panama, making its initial, partial delivery in JDK 14 (GA next March, EA available now). > Improved memory layout control, including stack-allocated types and inlined objects inside of other objects. Project Valhalla. The most complicated of the bunch. Just had a recent major breakthrough, and you can work with the EA release already. > project loom for golang-style I/O programming. Working on it :) > full tail recursion. Why was this feature rejected from the VM? Not at all rejected. It's still a goal for Loom. We'll just do lightweight concurrency first. Cost/benefit prioritization etc.

kllrnohj 7y ago

The thing I find disappointing is the lack of bytecode changes. The language changes are all just trivial tweaks to javac. Appreciated niceties, sure, but nothing meaty. The VM changes are then likewise focused mostly on the GC. Again, appreciated, but it's entirely disconnected from the language. Where's the long-overdue improvements to the bytecode? Where's value types? Where's runtime generics?

pron 7y ago
It's not true that the VM changes focus mostly on the GCs. There have been significant changes to startup time and low-overhead profiling. And there are constant improvements in the JIT compilers. Project Loom's lightweight concurrency also involves big VM changes, but without any bytecode changes. Reified runtime generics for reference types is a bad idea; it destroys language interop for very little gain. Value types and specialized generics for value types, on the other hand, are in the works. You can download and play with them here: http://jdk.java.net/valhalla/ http://jdk.java.net/valhalla/