7 ms·

Java 8 brought us lambda methods and streams that allow Java as a language to somewhat compete on the same stage as C#. I use them on a daily basis and they rad

Java 8 brought us lambda methods and streams that allow Java as a language to somewhat compete on the same stage as C#. I use them on a daily basis and they radically changed the way I do some things. It was a revolution for the Java world. What killer feature does Java 9 bring us? Jigsaw looks to me like a mere organizational feature, something I don't want to spend my time with unless I have to to get things working. Besides that, private interface methods are a nice idea, but I have never missed them before. Everything else leaves me unimpressed.

coldtea 10y ago
>Jigsaw looks to me like a mere organizational feature, something I don't want to spend my time with unless I have to to get things working. It's not for your typical use cases, it's for people running Java in lesser devices. That said, a REPL and HTTP 2.0 support are big in themselves. And the revised process management API too. Not every release needs to be a "revolution".
- mkesper 10y ago
  HTTP/2 is not officially in as the article says, only accessible via incubator.
- Traubenfuchs 10y ago
  Official Java REPL is not big. I know I will never use it and I don't know anyone who will. Those who get excited by live scripting/REPL probably won't be using Java. In any case, there is even a Java REPL solution available already if you really miss it. (java-repl) "Native" HTTP 2.0 support is nice and something that's expected to arrive eventually but also not big. A lot of people currently use alternative HTTP libraries anyways. As a Spring developer I usually use Resttemplate to do HTTP/REST calls and you can feed that with a RequestFactory that produces HTTP2 enabled requests, like OkHttp and Jetty. I don't know about Apache HttpClient. As for the process management API: That's actually quite nice, but the last time I touched processes was when I was writing horrible winforms applications years ago. Yes, certainly, not every release needs to be a revolution, but if you ask "What does it add that I will enjoy to use on a daily basis?" and the answer is "Nothing really, but take a look at ..." it's a bit disappointing. Some Java 10 features look like they could be big. If Java 9 is the Windows Vista of Java, Java 10 hopefully will be the Windows 7. (;
  - coldtea 10y ago
    >Official Java REPL is not big. I know I will never use it and I don't know anyone who will. Those who get excited by live scripting/REPL probably won't be using Java. That's a chicken and egg problem. They wouldn't be using Java because it didn't have one. Now it does.
  - needusername 10y ago
    > A lot of people currently use alternative HTTP libraries anyways. True, but because ALPN is only available in Java 9 the only ways to offer HTTP/2 is either through horrible hacks or using OpenSSL.
    - wbl 10y ago
      I believe Bouncycastle supports it, but am not sure. Java crypto has lagged for years for the residual effects of legal restrictions.
      - needusername 10y ago
        > I believe Bouncycastle supports it, but am not sure. Yeah I know Jetty, Tomcat and Undertow all support it. But they are either terrible hacks or bypass Java crypto entirely. See https://www.youtube.com/watch?v=1I2Uo_HfmGU https://www.youtube.com/watch?v=1I2Uo_HfmGU > Java crypto has lagged for years for the residual effects of legal restrictions. Nope, long keys were (and still are) are disabled per default. It is and always was just a config change. I agree with you that's is lagging a bit (e.g. TLS 1.3 will likely have to wait for Java 10 or later) but legal restrictions are not the cause.
- needusername 10y ago
  > It's not for your typical use cases, it's for people running Java in lesser devices. Are you sure? Modules add additional runtime and startup overhead. Classloading has always been lazy so if anything your footprint would be bigger. Not to mention the additional runtime checks. Sure you could build a smaller JDK but you'll likely depend on the java.desktop module anyway even for server applications. You may safe a few megabytes on disk because you may not need the cobra and some other small modules but I don't see how this makes a big difference.
ianopolous 10y ago
One huge feature in my opinion is the JVM compiler interface (JVMCI), which allows you to use Graal (which is used by Truffle) with an unmodified JRE.
- Traubenfuchs 10y ago
  All of those are things the majority of professional Java developers will never ever hear about, let alone actively use.
  - geodel 10y ago
    This Graal/Truffle/Maxine etc effort is going on for a decade or so, I think. Some folks first at Sun and then Oracle are trying to prove that Java is low level/performant enough to write JVM runtime/compilers etc. I believe this effort is still not production ready. Meanwhile Oracle has put some bits on github, and other made closed source to see if some business can be generated out of it.
    - ianopolous 10y ago
      Graal and Truffle are already open source. The other related (but not necessary for many uses) component is SubtrateVM, and that will be open sourced in a few months too.
    - pjmlp 10y ago
      Actually Graal is capable of more optimizations than Hotspot, for example it has more aggressive escape analysis heuristics. Twitter is reporting their experience in production at FOSDEM https://fosdem.org/2017/schedule/event/graal/ https://fosdem.org/2017/schedule/event/graal/
      - Traubenfuchs 10y ago
        That sounds very interesting indeed.
  - pjmlp 10y ago
manyxcxi 10y ago
I do agree that streams and lambdas finally got Java in the same decade as C#, and I love them. But, there have been a number of times where a private interface method would have been nice (getLogger or something) but instead you end up implementing the interface with an abstract class and basically get the same thing in practice. Since the methods are private you shouldn't have to write anything that knows about the abstract base class, but it's still just another one of those contortions that Java was putting us through. I'll be happy to have it, even if it's rarely used.
SanderMak 10y ago
I'm biased (currently authoring http://shop.oreilly.com/product/0636920049494.do http://shop.oreilly.com/product/0636920049494.do), but I believe categorising the new module system as just something organisational is a bit too dismissive. The module system brings two essential features: reliable configuration and strong encapsulation. Both are a boon for modular development and I believe all but trivially small codebases can benefit. Reliable configuration means every module explicitly describes its dependencies on other modules. This is consistently available throughout all phases: compilation, run-time and even a new phase, link-time (for more information about linking see http://openjdk.java.net/jeps/282 http://openjdk.java.net/jeps/282). No more classpath hell, and the explicit dependency information allows for new use-cases like linking. Strong encapsulation brings new tools to truly modularise your application. Combine it with the services mechanism for maximum benefit (see for an example http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/ http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/). As a side-effect, the platform becomes more secure by virtue of strong encapsulation of 'dangerous' platform internal classes.
- agumonkey 10y ago
  I tend to believe that it will allow for better reuse and ... modularity. But that's all guessfest on my side.
- needusername 10y ago
  > reliable configuration How can you say this when versioning is not covered? What have you gained when you know that your dependencies are present but you don't know whether the versions match? Asked to comment about this the JDK architects respond with "well you always have build system that verifies you dependency graph including the versions anyway", with this attitude why do you even need validation at runtime when the validation was already done at build time.
pjmlp 10y ago
Just out of my head, at least for me. A Java linker, allowing to reduce the JRE size to set of classes that really matter to deliver with the application. The first steps of having an AOT compiler to native code, hopefully to be finalized in Java 10, instead of having to buy one of the available third party JDKs that offer it. A REPL. A pluggable JIT architecture written in Java (Graal), which Twitter already experimented in production as replacement for Hotspot and will report the experience at FOSDEM. More JVM machinery in-place to reduce the number of use cases that still rely on using Unsafe directly. Hopefully to be finalized in Java 10.
- virmundi 10y ago
  Why a REPL? I don't get it. I don't get it in Clojure. I don't get it in Python. I just make a JUnit with a little test method. Then I have the full power of the IDE: debugger, code follower, block editing. Most of that is missing in every REPL.
  - revscat 10y ago
    Other developers have different styles of developing. I have a REPL open in a tmux tab all day every day, and pipe snippets to it from vim to test how stuff works. When I was working with Java there were times I wanted that: just a quick way to verify behavior. I'm currently working with Ruby, and for me the REPL help me work faster because I can play with the code in parrallel to writing the tests or implementation code.
  - cle 10y ago
    Interactively executing code on real data, with real dependencies, is vastly different from a junit test, for obvious reasons. It's not hard to get the features you listed, e.g. Clojure REPLs have all of those features (CIDER/Cursive). Why do you think statisticians and data scientists don't write Java programs that they must recompile and rerun every time they tweak it? The statisticians I work with are obsessed with Jupyter notebook, because the iterative, fast-feedback development lets them almost touch and feel the numbers they're working with.
royjacobs 10y ago
The new module system will finally make sure you can keep your internals internal. This is a huge benefit, since it can potentially vastly reduce the surface area of Java libraries. It's weird that it has taken this long for it to finally arrive, but it will definitely help making codebases easier to grok and make it simpler to keep things backwards compatible.
kartickv 10y ago
That's a sad situation, when there are low-hanging fruit Java can pick from other programming languages, like: Type inference: Being able to say: var foo = Foo(); Or: final foo = Foo(); Keyword arguments Lazy properties / methods, like in Swift. Dynamic typing: Have a type dynamic, on which all calls are type-checked at runtime. This is similar to Objective-C's id, and could just be syntactic sugar for reflection. One should be able to define a class that can intercept all method calls and (say) forward them to another object, again like Objective-C's forwardInvocation. Performance: Things like structs, or being able to create an array of objects rather than an array of references to objects, or having a field of an object be another object rather than a reference to one. This should help bring down Java's high memory consumption compared to other languages like Go or Swift. None of these enhancements will be in conflict with Java's goals. For example, we're not talking about raw pointers (insecure) or ints with platform-dependent sizes (non-portable).
- the8472 10y ago
  > Type inference There's a proposal[0] for local variable type inference, but it's not scheduled for any specific java version. > Dynamic typing you can run dynamic languages on the JVM. groovy, javascript, ruby, ... > Performance: Things like structs, or being able to create an array of objects part of valhalla[1]. [0] http://openjdk.java.net/jeps/286 http://openjdk.java.net/jeps/286 [1] http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/projects/valhalla/
  - kartickv 10y ago
    Being able to run dynamic languages on the VM isn't a substitute for the occasional situations in which dynamic typing in Java would help, say when working with JSON.
- Traubenfuchs 10y ago
  > type inference There is a JEP (286) for that. Personally I consider it highly harmful. I regularly read C# source of unknown libraries outside of an IDE (Like on Github) and very often I don't have the faintest clue what type a var holds even it is just a type well known to me, making navigation of that code very difficult. > lazy properties This looks interesting. I don't think Java will ever offer it though. > Dynamic Why would you want to kill the static type safety we cherish so much? I only ever had to use dynamic in C# when working with horrible legacy APIs. Besides that, interface proxies and cglib proxies (bytecode manipulated classes) are heavily used in Java frameworks and do the delegation you talk about. > Structs Value types will be available in Java 10. (JEP 169: "Provide JVM infrastructure for working with immutable and reference-free objects, in support of efficient by-value computation with non-primitive types.")
cle 10y ago
It doesn't bring killer features for me personally, but I am looking forward to the Stream improvements and additions that made Streams in Java 8 feel so...half-assed.

coldtea 10y ago

>Jigsaw looks to me like a mere organizational feature, something I don't want to spend my time with unless I have to to get things working. It's not for your typical use cases, it's for people running Java in lesser devices. That said, a REPL and HTTP 2.0 support are big in themselves. And the revised process management API too. Not every release needs to be a "revolution".

mkesper 10y ago
HTTP/2 is not officially in as the article says, only accessible via incubator.
Traubenfuchs 10y ago
Official Java REPL is not big. I know I will never use it and I don't know anyone who will. Those who get excited by live scripting/REPL probably won't be using Java. In any case, there is even a Java REPL solution available already if you really miss it. (java-repl) "Native" HTTP 2.0 support is nice and something that's expected to arrive eventually but also not big. A lot of people currently use alternative HTTP libraries anyways. As a Spring developer I usually use Resttemplate to do HTTP/REST calls and you can feed that with a RequestFactory that produces HTTP2 enabled requests, like OkHttp and Jetty. I don't know about Apache HttpClient. As for the process management API: That's actually quite nice, but the last time I touched processes was when I was writing horrible winforms applications years ago. Yes, certainly, not every release needs to be a revolution, but if you ask "What does it add that I will enjoy to use on a daily basis?" and the answer is "Nothing really, but take a look at ..." it's a bit disappointing. Some Java 10 features look like they could be big. If Java 9 is the Windows Vista of Java, Java 10 hopefully will be the Windows 7. (;
- coldtea 10y ago
  >Official Java REPL is not big. I know I will never use it and I don't know anyone who will. Those who get excited by live scripting/REPL probably won't be using Java. That's a chicken and egg problem. They wouldn't be using Java because it didn't have one. Now it does.
- needusername 10y ago
  > A lot of people currently use alternative HTTP libraries anyways. True, but because ALPN is only available in Java 9 the only ways to offer HTTP/2 is either through horrible hacks or using OpenSSL.
  - wbl 10y ago
    I believe Bouncycastle supports it, but am not sure. Java crypto has lagged for years for the residual effects of legal restrictions.
    - needusername 10y ago
      > I believe Bouncycastle supports it, but am not sure. Yeah I know Jetty, Tomcat and Undertow all support it. But they are either terrible hacks or bypass Java crypto entirely. See https://www.youtube.com/watch?v=1I2Uo_HfmGU https://www.youtube.com/watch?v=1I2Uo_HfmGU > Java crypto has lagged for years for the residual effects of legal restrictions. Nope, long keys were (and still are) are disabled per default. It is and always was just a config change. I agree with you that's is lagging a bit (e.g. TLS 1.3 will likely have to wait for Java 10 or later) but legal restrictions are not the cause.
needusername 10y ago
> It's not for your typical use cases, it's for people running Java in lesser devices. Are you sure? Modules add additional runtime and startup overhead. Classloading has always been lazy so if anything your footprint would be bigger. Not to mention the additional runtime checks. Sure you could build a smaller JDK but you'll likely depend on the java.desktop module anyway even for server applications. You may safe a few megabytes on disk because you may not need the cobra and some other small modules but I don't see how this makes a big difference.

ianopolous 10y ago

One huge feature in my opinion is the JVM compiler interface (JVMCI), which allows you to use Graal (which is used by Truffle) with an unmodified JRE.

Traubenfuchs 10y ago
All of those are things the majority of professional Java developers will never ever hear about, let alone actively use.
- geodel 10y ago
  This Graal/Truffle/Maxine etc effort is going on for a decade or so, I think. Some folks first at Sun and then Oracle are trying to prove that Java is low level/performant enough to write JVM runtime/compilers etc. I believe this effort is still not production ready. Meanwhile Oracle has put some bits on github, and other made closed source to see if some business can be generated out of it.
  - ianopolous 10y ago
    Graal and Truffle are already open source. The other related (but not necessary for many uses) component is SubtrateVM, and that will be open sourced in a few months too.
  - pjmlp 10y ago
    Actually Graal is capable of more optimizations than Hotspot, for example it has more aggressive escape analysis heuristics. Twitter is reporting their experience in production at FOSDEM https://fosdem.org/2017/schedule/event/graal/ https://fosdem.org/2017/schedule/event/graal/
    - Traubenfuchs 10y ago
      That sounds very interesting indeed.
- pjmlp 10y ago

manyxcxi 10y ago

I do agree that streams and lambdas finally got Java in the same decade as C#, and I love them. But, there have been a number of times where a private interface method would have been nice (getLogger or something) but instead you end up implementing the interface with an abstract class and basically get the same thing in practice. Since the methods are private you shouldn't have to write anything that knows about the abstract base class, but it's still just another one of those contortions that Java was putting us through. I'll be happy to have it, even if it's rarely used.

SanderMak 10y ago

I'm biased (currently authoring http://shop.oreilly.com/product/0636920049494.do http://shop.oreilly.com/product/0636920049494.do), but I believe categorising the new module system as just something organisational is a bit too dismissive. The module system brings two essential features: reliable configuration and strong encapsulation. Both are a boon for modular development and I believe all but trivially small codebases can benefit. Reliable configuration means every module explicitly describes its dependencies on other modules. This is consistently available throughout all phases: compilation, run-time and even a new phase, link-time (for more information about linking see http://openjdk.java.net/jeps/282 http://openjdk.java.net/jeps/282). No more classpath hell, and the explicit dependency information allows for new use-cases like linking. Strong encapsulation brings new tools to truly modularise your application. Combine it with the services mechanism for maximum benefit (see for an example http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/ http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/). As a side-effect, the platform becomes more secure by virtue of strong encapsulation of 'dangerous' platform internal classes.

agumonkey 10y ago
I tend to believe that it will allow for better reuse and ... modularity. But that's all guessfest on my side.
needusername 10y ago
> reliable configuration How can you say this when versioning is not covered? What have you gained when you know that your dependencies are present but you don't know whether the versions match? Asked to comment about this the JDK architects respond with "well you always have build system that verifies you dependency graph including the versions anyway", with this attitude why do you even need validation at runtime when the validation was already done at build time.

pjmlp 10y ago

Just out of my head, at least for me. A Java linker, allowing to reduce the JRE size to set of classes that really matter to deliver with the application. The first steps of having an AOT compiler to native code, hopefully to be finalized in Java 10, instead of having to buy one of the available third party JDKs that offer it. A REPL. A pluggable JIT architecture written in Java (Graal), which Twitter already experimented in production as replacement for Hotspot and will report the experience at FOSDEM. More JVM machinery in-place to reduce the number of use cases that still rely on using Unsafe directly. Hopefully to be finalized in Java 10.

virmundi 10y ago
Why a REPL? I don't get it. I don't get it in Clojure. I don't get it in Python. I just make a JUnit with a little test method. Then I have the full power of the IDE: debugger, code follower, block editing. Most of that is missing in every REPL.
- revscat 10y ago
  Other developers have different styles of developing. I have a REPL open in a tmux tab all day every day, and pipe snippets to it from vim to test how stuff works. When I was working with Java there were times I wanted that: just a quick way to verify behavior. I'm currently working with Ruby, and for me the REPL help me work faster because I can play with the code in parrallel to writing the tests or implementation code.
- cle 10y ago
  Interactively executing code on real data, with real dependencies, is vastly different from a junit test, for obvious reasons. It's not hard to get the features you listed, e.g. Clojure REPLs have all of those features (CIDER/Cursive). Why do you think statisticians and data scientists don't write Java programs that they must recompile and rerun every time they tweak it? The statisticians I work with are obsessed with Jupyter notebook, because the iterative, fast-feedback development lets them almost touch and feel the numbers they're working with.

royjacobs 10y ago

The new module system will finally make sure you can keep your internals internal. This is a huge benefit, since it can potentially vastly reduce the surface area of Java libraries. It's weird that it has taken this long for it to finally arrive, but it will definitely help making codebases easier to grok and make it simpler to keep things backwards compatible.

kartickv 10y ago

That's a sad situation, when there are low-hanging fruit Java can pick from other programming languages, like: Type inference: Being able to say: var foo = Foo(); Or: final foo = Foo(); Keyword arguments Lazy properties / methods, like in Swift. Dynamic typing: Have a type dynamic, on which all calls are type-checked at runtime. This is similar to Objective-C's id, and could just be syntactic sugar for reflection. One should be able to define a class that can intercept all method calls and (say) forward them to another object, again like Objective-C's forwardInvocation. Performance: Things like structs, or being able to create an array of objects rather than an array of references to objects, or having a field of an object be another object rather than a reference to one. This should help bring down Java's high memory consumption compared to other languages like Go or Swift. None of these enhancements will be in conflict with Java's goals. For example, we're not talking about raw pointers (insecure) or ints with platform-dependent sizes (non-portable).

the8472 10y ago
> Type inference There's a proposal[0] for local variable type inference, but it's not scheduled for any specific java version. > Dynamic typing you can run dynamic languages on the JVM. groovy, javascript, ruby, ... > Performance: Things like structs, or being able to create an array of objects part of valhalla[1]. [0] http://openjdk.java.net/jeps/286 http://openjdk.java.net/jeps/286 [1] http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/projects/valhalla/
- kartickv 10y ago
  Being able to run dynamic languages on the VM isn't a substitute for the occasional situations in which dynamic typing in Java would help, say when working with JSON.
Traubenfuchs 10y ago
> type inference There is a JEP (286) for that. Personally I consider it highly harmful. I regularly read C# source of unknown libraries outside of an IDE (Like on Github) and very often I don't have the faintest clue what type a var holds even it is just a type well known to me, making navigation of that code very difficult. > lazy properties This looks interesting. I don't think Java will ever offer it though. > Dynamic Why would you want to kill the static type safety we cherish so much? I only ever had to use dynamic in C# when working with horrible legacy APIs. Besides that, interface proxies and cglib proxies (bytecode manipulated classes) are heavily used in Java frameworks and do the delegation you talk about. > Structs Value types will be available in Java 10. (JEP 169: "Provide JVM infrastructure for working with immutable and reference-free objects, in support of efficient by-value computation with non-primitive types.")

cle 10y ago

It doesn't bring killer features for me personally, but I am looking forward to the Stream improvements and additions that made Streams in Java 8 feel so...half-assed.