Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java 9 Delayed Due To Modularity Controversy (infoworld.com)

Posted by EditorDavid on from the see-you-in-September dept.

An anonymous reader quotes InfoWorld: Java 9 won't be released on July 27 after all. Oracle has proposed that Java 9 Standard Edition be delayed until September 21 so the open source community that is finalizing Java 9 can address the ongoing controversy over a planned but later rejected approach to modularity, said Georges Saab, vice president of software development in the Java platform group at Oracle and chairman of the OpenJDK governing board...

The [Java Platform Module System] measure was sent back to the proposal's expert group for further discussion. Since then, the group has reached consensus on addressing the modularity concerns, Saab said. But they cannot rework Java 9 in time for the original July 27 release date... If the revised JSR 376 approved, as expected, work can proceed on implementing it in the official version of Java 9 SE. This setback for Java 9s upcoming upgrade, however, should just be temporary, with Oracle expecting a more rapid cadence of Java SE releases going forward, Saab said.

3 of 79 comments (clear)

  1. I only have an A.S. degree in programming... by __aaclcg7560 · · Score: 1, Interesting

    What does modularity mean? Why should I care?

    1. Re:I only have an A.S. degree in programming... by Creepy · · Score: 1, Interesting

      From what I've read, it is a fancy way of saying modules will enforce the object oriented paradigm. In true object oriented languages like SmallTalk you can't change anything inside the object without accessor functions into the object, but languages like java and c++ have the idea of 'public,' which allows access and even changing things inside an object (and the reasoning is that it is much faster to just change x than have accessor functions like setValue(x) and getValue(x)). Not having modular code makes modular testing difficult because any other class can change values in the class you want to test without the class knowing about it, so problems with a module may not be caused by your module. For example, if some other class (module) tries to set the resolution to 3840 × 2160 but the monitor doesn't support that, you can have your class (module) enforce the maximum resolution and refuse the new setting. Enforcement of those settings can therefore be entirely contained to the module and tested within the module.

  2. Not too surprising... by ndykman · · Score: 5, Interesting

    The JSR process has become massively slow with tons of large companies fighting by proxy. Honestly, I think .Net Core may find a bigger place in the overall ecosystem alongside Go and NodeJS. Sure, Java isn't going anywhere, but some of the issues that Java 9/Jigsaw are trying to deal with don't exist in .Net, and C# has adopted some very useful language features.

    Also, the .Net Core is simplifying some complex use cases that Java 9 is trying to adopt. They are depreciating AppDomains in favor of OS level isolation (processes, threads) while still allowing for unloading/replacement of assemblies. Similarly, they are backing off the code trust model, moving again to OS level mechanisms. Their reasoning is pretty sound, it was complicated, didn't really work as expected and why not simplify and just support what most people actually do.

    It's not prefect and there's work to be done, but it might really gain traction. .Net has great APIs for the kind of strongly typed data transformations enterprise apps do. They still have build chain issues and cross platform tooling needs to mature, but really, if all the major players in the JSR keep butting heads like this, Java will face even more competition than it already does.

    Also, this all impacts other languages. Scala and Kotlin have to jump some hoops to support certain features, but they are still tied to the JVM and its core mechanisms, which why this was a part of Java 9 in the first place.