Java 9 Enters First Bug Fixing Round
infoq.com
infoq.com
Side note: Can somebody please write a concise tutorial about how to use the new features (like this awesome Java 8 tutorial: https://github.com/winterbe/java8-tutorial )? If you do, contact me. I would love to help out, but I don't have much time at the moment...
Except they don't. Everything but Jigsaw has been ready for a year and Jigsaw is still not ready.
http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-r...
http://wildfly.org/news/2016/12/12/Jigsaws-Missing-Pieces/
> With their very strict backwards compatibility requirements (still compatible with Java 1.0 AFAIK)
When I checked a few weeks ago Jigsaw broke a lot of reflection code. It's debatable how much of this was a published API but a lot of things broke. I don't know how many of these changes were rolled back.
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.
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.
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.
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.
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...
Of course I do understand it is hard to grasp the power of a REPL when it is a plain old readline CLI app.
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.
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.
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".
"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. (;
That's a chicken and egg problem. They wouldn't be using Java because it didn't have one. Now it does.
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.
Java crypto has lagged for years for the residual effects of legal restrictions.
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.
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.
Twitter is reporting their experience in production at FOSDEM
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.
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.
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.
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.
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).
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.")
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...
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.
Swift does it very well. It helps, not hurts, readability.
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/
brings better solutions than the new versions of javas to its language design weaknesses (breaking code compatibility is a great asset for kotlin) is useable right now on android, not in 5 years.
A part of the android community has been complaining about fragments for years that's not really news.
They are planning to wait nearly one more year until Java EE 8 is released. This is unacceptable in todays fast moving world.
What is the appeal to you?