4 ms·
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 enab
by 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.
- tempguy9999 7y agoUtterly dumb question but why is tail recursion necessary in the JVM given that the compiler is better placed simply to turn recursion into a loop. TR removal should be done best at the highest level I'd think.
- pron 7y agoThe compiler can only make this transformation in special cases, in particular, when it doesn't break any of the JVM's semantics (also, not all recursion is self-recursion, i.e. a tail call to the subroutine you're in). You can't just discard a frame of a call in a tail position, because some security mechanisms require knowing the full call-stack (plus, developers might hate you when their stack traces start missing crucial frames). So we're talking about explicit tail calls, in places that can be checked for the safety of the optimization.
- chrisseaton 7y ago> the compiler is better placed simply to turn recursion into a loop How do you think it should do this? While keeping the semantics of Java.
- apta 7y ago> For instance, Java 8 enabled new ways of programming via Lambdas and structural typing What does structural typing refer to in this context?