karianna

They are highly motivated by internal (Oracle cloud) and external factors (Oracle as A technology leader) factors as well as professional pride (core Java folks are ex Sun) so I'm personally highly confident

Java EE 9 - so 2018 at the earliest

Hi all,

Martijn Verburg here - London Java Community (LJC) representative on the Java Community Process (JCP) Executive Committee (EC) (dear Cthulu, the acronyms) otherwise known as the Java standards body.

Here's our reasoning for voting "Yes" the 2nd time around:

https://londonjavacommunity.wordpress.com/2017/06/28/our-yes...

This is a great step forwards for Java as a platform as it lays the foundation for a smaller, more secure and lightweight footprint. There is still more to tackle on the modularity story (expect to see further updates in Java 9.1 and beyond).

It's very important to note that you can still run your normal Java classpath based application with Java 9. The Classpath and Classloader mechanism is still there, although you'll see a few more warnings pop up if your application or its dependencies are relying on a deprecated API or dangerous internal lib.

If you choose to port an existing project to the new module system and module path way of loading then you can gain some of the benefits but of course there will be a learning curve and I'd argue that unless you're really needing that modular help then wait for Java 9.1 or even 10 until some of the edges have been ironed out.

Any other Q's throw my way!

Hi all - interested in early access builds and / or helping out? Head to OpenJDK.java.net and join the Valhalla project and the Adoption Group.

Disclaimer - I help run the adoption group and maintain the Valhalla wiki.

I'll prefix this with "I'm not a language design or modularity design expert". I personally would have preferred that JPMS was treated as an internal JVM/API concern. This still would have meant changes for IDE and tools vendors (rt.jar going away required rework for sure) but would have given more flexible options for a user space modular system to be build on top.

An example is that the Module definition file (Module-info.java) is in Java source code. Despite the compile time benefits (performance, security etc) this brings, it really locks down how user level module systems need to interact with this. I personally would have gone for a straight XML/JSON/Manifest.MF/YAML/Whatever format which wasn't tied to the Java compiler so tightly.

See http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201... - I think this is a decent compromise and a majority of the Maven folsk seem to agree. We're hoping to take it for a test drive this Saturday at another Hackday.

I think the JSR did over reach itself. Hindsight is a wonderful thing but I think if the scope had been to just modularise Java itself and then have a separate JSR for a user space module system on top of that, it would have worked out better.

Well I don't think even my nearest or dearest would call me adorable, but hey :-). The module system proposal did state that the user module system was a non goal, but the design of it means that it does impact existing user module systems (OSGi, JBoss) as well as the defacto build / package system (Maven) and so several EC members felt that more interop work is required.

Hi Mike, yep - you've found one of the relevant threads.

This is correct and possibly seems crazy from some other language communities :-), but Java is fairly venerable (20 yrs) and is a backbone platform for many risk averse entities and this strong social contract has I believe added to its longevity and relevance.

We have been in close contact with the developers throughout - we're the Java User Group that runs the Adopt a JSR and Adopt OpenJDK programmes that test these things out as early as we're able. The blog post details one of our global hack days for example.

No, there are still substantive issues on the table, we just expect that they'll be cleared up in the next 30 days. But since this is so deeply fundamental to the core platform we're only going to vote yes when we're really certain. If it was a library JSR (say a new Collections implementation) then we may have been more lenient.

We believe that that the Java specification for a new module system does need to have an interoperability story with the package management system that Gradle/Maven provides. In particular, the module system needs to be able to bridge/utilise the packages provided by Maven Central (>1 Million IIRC) and allow the Java ecosystem to transition over time. A hard 'break' from the Maven Central world would have meant two separate Java's (a bit like Python 2/3), which for us meant a No vote. These issues are being ironed out, but they weren't at the time of the voting period, so we erred on the side of caution

There were concerns raised by the Eclipse JDT team (ecj authors) - starting here: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

We think those issues will be resolved, but we'd prefer to see them resolved before voting yes. In particular:

The grammar for the module-info.java with its "restricted keywords" is highly problematic, since the language it defines is not processable by established compiler technology. Hacks are possible, but they are costly and prevent established error recovery techniques from working.

The JCP's mandate is to ensure that competing implementations can be built and at time of spec submission this was very unclear (better now).

Hi all, I'm the EC representative for the London Java community (~6000 Java developers, have lots of global outreach programmes etc) - here's our more detailed post on why we voted "No". https://londonjavacommunity.wordpress.com/2017/05/09/explana... - Happy to answer further questions although I've probably found this thread too late :-)

We're working on versions of Java, Nginx, MySQL etc that can run inside the secure enclaves, it's interesting and challenging work! http://www.serecaproject.eu/

Disclaimer: I'm the CEO of jClarity who produces Censum.

For those who are looking to read the arcane output of a Java GC log, you can grab a 7-day free trial of Censum (https://www.jclarity.com/product/censum-free-trial/) - it parses GC logs (Java 6-9 all collectors) and gives you a host of analytics and graphs to help you figure out what's going on. We've also got blog posts on GC (https://www.jclarity.com/blog) and our slideshare http://www.slideshare.net/jclarity

We helped test out the RI and TCK - it was in the end up built for Java EE in mind (that's not to say someone couldn't provide a stripped down version that could work for SE - but I don't think anyone has or will).

There maybe some small ones, but the (and I think correct) decision was made to focus on the JVM for Java 9. Java 8 bought in enough language features to keep Joe/Jane Java developers happy (most bleeding edge folks moved to Scala or other languages).

It will depend on howe small a profile the JVM language can run on. In theory you could run some JVM languages on the compact profile resulting in a n overall faster startup time.

Likely delivery timeframe for value types in Java 10. Definitely not Java 9. Source - many conversations with Brian Goetz et al.

I'd be cautious of a 2013 report. G1 has had significant work put into it over the past year and is much improved in its latest incarnations. We've seen best results with Java 8u5+ (Disclaimer: I run a company that sells a GC analysis tool).

Shenandoah is unlikely to see the light of production release until Java 10. I ran a very early piece on this - http://www.jclarity.com/2014/03/12/shenandoah-experiment-1-w... - really glad to see more experiments in this space. I'll add that G1 from Java 8u5 onwards is pretty darn good out of the box.

ZeroTurnaround have a payware product (that's highly acclaimed in this space) called JRebel. It swaps out bytecode directly as opposed to using Java's (somewhat broken) classloader mechanism.

The project to watch here is project Valhalla - valhalla-dev AT openjdk DOT java DOT net. Indeed the full solution of value types will not land until Java 10, but Java 9 will hopefully contain the very useful Collection of primitives enhancement (you can currently only have Collections of Objects, primitives are auto boxed into their Object equivalents at much greater overhead).

Project Jigsaw (modularising Java itself and introducing a module system) will be a serious attempt at solving a part of this problem but may not land in its entirety for Java 9 (modularising the source code landed today on trunk). OSGi claims to solve the application layer part, but many developers I speak to have mixed results, primarily due tooling support etc.

That's a Java EE API. I've been working with the Java SE and Java EE folks to make sure that a new version of that will sit on top of the core JDK 9 one.

I don't think it will crush the alternatives, but it may stop them from becoming one of the top mainstream languages (latest RedMonk analysis had Scala at the top of the chasing pack for example).

The process was reasonably random - the survey was distributed to the global Java User Groups & I'd say over 2000 responses is something worth paying attention to statistically (yeah, I know - out of x Million Java developers it's still a tiny sample set).

Yeah - it seems like the principle has been around forever, yet everyday I see a Java code base in particular I see the principles lying in a shattered pile of procedural code. So it's definitely worth repeating the message!

Really good to see more products/tools in this space. I don't mind the whole Docker/Chef/Puppet + scripts approach, but it's not for everyone.

The good old build tools war! Was interesting to see the massive drop in Ant/Ivy as part of the modern Java build set. I wonder if Maven will be able to hold on - it's polyglot POM version needs to come out quickly methinks.