Hacker News Reader

Comment by Traubenfuchs | Hacker News Reader

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.

View on HN

I'm biased (currently authoring 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). 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/). As a side-effect, the platform becomes more secure by virtue of strong encapsulation of 'dangerous' platform internal classes.

I tend to believe that it will allow for better reuse and ... modularity. But that's all guessfest on my side.

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

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.

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.

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.

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.

Jupyter notebooks make sense since you can modify the whole block. When I used Python or Clojure, the REPL is singles line. So small changes necessitated modifying out of repl and pasting.

Have a try at using Emacs/Cider or Cursive with Clojure.

Have a look at https://cursive-ide.com/userguide/repl.html under "Using the REPL" - there's a little demo there of what this looks like in Cursive. The editor is fully multi line and can be stretched out as large as you would like.

It's also easy in pretty much any Clojure environment to be able to send forms easily from your editor to the REPL, and many people prefer to work this way.

Only because you think in UNIX terms.

A REPL is an extension of the IDE, that is how it was born.

http://franz.com/products/allegro-common-lisp/acl_ide.lhtml

https://github.com/squeak-smalltalk/squeak.org/blob/master/i...

https://cursive-ide.com/

Of course I do understand it is hard to grasp the power of a REPL when it is a plain old readline CLI app.

>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".

HTTP/2 is not officially in as the article says, only accessible via incubator.

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. (;

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

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

I believe Bouncycastle supports it, but am not sure.

Java crypto has lagged for years for the residual effects of legal restrictions.

> 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

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

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

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.

All of those are things the majority of professional Java developers will never ever hear about, let alone actively use.

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.

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.

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/

That sounds very interesting indeed.

Sure they will, unless they don't care about performance.

This the first step to eventually replace Hotspot with Graal.

Twitter already experimented with it and is giving a presentation at FOSDEM this weekend.

https://fosdem.org/2017/schedule/event/graal/

So any Java developer conscious of what to make the most out of the JVM will need to learn it.

So are many of the existing underlying JVM features today - most developers don't use them directly. However they do use the features they enable all the time.

Personally I think Truffle/Graal are by far the most exciting features in Java 9. They'll enable really amazing innovation in all sorts of JVM languages.

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.

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.

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.

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).

> 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 [1] http://openjdk.java.net/projects/valhalla/

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.

> 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.")

How is it harmful to say:

var foo = new Foo();

as opposed to:

Foo foo = new Foo();

As for "killing the static type safety we cherish so much", that's a one-sided view. There are situations when dynamic typing works better, say when working with JSON, and in any case, static typing has many problems: https://kartick-log.blogspot.in/2016/05/statically-typed-lan...

> Type inference: Being able to say: > var foo = Foo();

I don't want that in my Java.

A developer we used to have used the 'val' feature of Lombok to implement type-inference in a lot of the repos he was responsible for and we took a collective decision to remove every last instance of it from the code base.

I don't see the problem — look at the right-hand side of the expression to find out the type.

Swift does it very well. It helps, not hurts, readability.

Reply on news.ycombinator.com