Settings

Theme

Java 9 Enters First Bug Fixing Round

infoq.com

61 points by youknownothing 9 years ago · 53 comments

Reader

struppi 9 years ago

Good! I am really looking forward to jshell, yet I appreciate that the Java team at Oracle is taking it's time to get this right. With their very strict backwards compatibility requirements (still compatible with Java 1.0 AFAIK), everything they release to the public, they must maintain forever.

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

Traubenfuchs 9 years ago

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.

  • SanderMak 9 years ago

    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.

    • needusername 9 years 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.

    • agumonkey 9 years ago

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

  • pjmlp 9 years 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 9 years 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 9 years 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.

      • pjmlp 9 years ago

        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.

      • cle 9 years 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.

        • virmundi 9 years ago

          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.

          • lemming 9 years ago

            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.

          • pjmlp 9 years ago

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

  • coldtea 9 years 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".

    • Traubenfuchs 9 years 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 9 years 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 9 years 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 9 years ago

          I believe Bouncycastle supports it, but am not sure.

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

          • needusername 9 years 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

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

    • mkesper 9 years ago

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

    • needusername 9 years 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 9 years 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 9 years ago

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

      • geodel 9 years 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.

      • pjmlp 9 years ago

        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.

      • lemming 9 years ago

        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.

  • manyxcxi 9 years 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.

  • royjacobs 9 years 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.

  • cle 9 years 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.

  • kartickv 9 years 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).

    • Traubenfuchs 9 years 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.")

    • ionised 9 years ago

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

      • kartickv 9 years ago

        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.

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

      • kartickv 9 years 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.

sgt 9 years ago

Java's quite exciting these days. I wish I could say the same about the state of Java EE though.

  • on_and_off 9 years ago

    I wish it would mean anything for android ... at this point I am all in the kotlin boat though :

    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.

    • smrtinsert 9 years ago

      Something exciting for Android? Just look for the latest component-replacing-fragment of the day, I'm sure hundreds came out yesterday.

      • on_and_off 9 years ago

        That's not exactly exciting ..

        A part of the android community has been complaining about fragments for years that's not really news.

  • Traubenfuchs 9 years ago

    Java EE is dead. Long live Spring (Boot)!

    They are planning to wait nearly one more year until Java EE 8 is released. This is unacceptable in todays fast moving world.

  • needusername 9 years ago

    I hope they bring a modular Java EE 9 that allows you to pick and choose Java EE APIs. I'm not confident but one can still hope.

  • youknownothingOP 9 years ago

    Although still young, and technically not Java EE, the MicroProfile initiative seems pretty promising. That might lighten things up.

exabrial 9 years ago

Jigsaw is an incredible language feature! Can't wait to use it.

virtualwhys 9 years ago

In other words, Java 10, godspeed.

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection