Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Java Oracle

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

Posted by EditorDavid 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.
This discussion has been archived. No new comments can be posted.

Java 9 Delayed Due To Modularity Controversy More

Java 9 Delayed Due To Modularity Controversy

Comments Filter:

  • Java? (Score:1, Troll)

    by DontBeAMoran ( 4843879 )

    That's still a thing? I thought we were all supposed to move to WebAssembly?!

    • Java isn't Perl (yet).
    • They're for completely different purposes.

      Webassembly is supposed to replace javascript.

      Java is still used for serverside technologies.

    • Re: (Score:1)

      by Anonymous Coward

      For people who work for a living, yes. Ignorant social leeches like yourself aren't likely to have used it for anything besides shitty Bittorrent clients.

  • shoulda coulda (Score:3)

    by bugs2squash ( 1132591 ) on Saturday June 03, 2017 @03:05PM (#54542933)
    they should have adopted osgi, maybe with a few tweaks to allow selective inclusion of the standard library components. It's a perfectly reasonable approach that has a proven track record, tooling support and is not significantly more onerous that the idea of modularity is intrinsically.
  • What does modularity mean? Why should I care?

    • Re: (Score:2, Interesting)

      by Creepy ( 93888 )

      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 mak

      • But don't the standard access modifiers (public, protected, private and unmodified) already accomplish that...?

        Set your class to public, but your class variables to private and they cant be called by anything other than code in the class itself... if you want to set defaults and sanity check values, you create getters and setters...

        • Indeed. And there's really only two reasons I leave member variables public: they're cosmetic/convenience data that makes sense to bundle into a larger object from a data management perspective, but doesn't actually affect functionality (so it's extremely unlikely that unexpected changes will cause problems). Though I do lean away from this for anything that might conceivably eventually need validation or other special handling.

          Or alternately, when I'm writing a simple class where the internal functionali

      • From what I've read, it is a fancy way of saying modules will enforce the object oriented paradigm.

        Loooks like this might be the Java version of the Python package (a collection of modules) with a layer of access control. Being a Java implementation, it's going to be a fine mess.

        https://softwareengineering.stackexchange.com/questions/311280/why-packages-and-modules-are-separate-concepts-in-java-9 [stackexchange.com]

        • I'm not aware of anything in the Java world that is a mess :D

          The stackexchange question you link is simple to answer: because packages and modules are two different things?

          Is the trunk of your car a suitcase? Or a pocket in your jeans? Does your jeans pocket have a lock? Does your suitcase have wheels? Regardless of yes or no ... are they the same thing?

      • Re: (Score:2)

        by mark-t ( 151149 )
        What modularity in the case of Java 9 means is that it was intended to migrate away from a monolithic design, which could enable faster startup times for many programs as they would not need to wait for the entire JRE to be loaded and initialized before starting.

      • Your rant has nothing to do with Java Modularity, aka project Sigjaw or look at OSGi.

        Your reference to SmallTalk is wrong too.

        In Java you have a private attribute x, and use accessor methods like getX() and setX(). But if x was public you could write: obkect.x = balls or balls = object.x. In SmallTalk you can not even write that, because it lacks the syntax for it. Hence the SmallTalk IDE/compiler generates you the getX and setX methods ... no big deal.

        The rest about "modules" you write is utterly wrong.

        A m

    • Re: I only have an A.S. degree in programming... (Score:4, Informative)

      by ewanm89 ( 1052822 ) on Saturday June 03, 2017 @05:23PM (#54543415) Homepage

      They envisioned a way where one could package the parts of the standard library with a application without including the whole thing. Of course, to do this they decided to totally change how the classpath and classloader works (how the VM finds and loads libraries) and then break reflection (being able to inspect library code from the code using that library).

      • and then break reflection (being able to inspect library code from the code using that library).
        Inspection always ever only worked on objects and classes and not on libraries.
        So if you have a class loaded from a module, reflection works exactly the same as loaded from an ordinary jar file.

        • Okay, on the Java a library is a set of classes... And an object is just an instantiation of a class. I would point out that when loading other JVM hosted languages these semantics no-longer necessarily hold true but the reflection can still be used.

          And no it does not work the same with modules, I know because it does fun things when the way the Clojure interpreter/compiler works uses that reflection and it is a core part of LISP based languages. The reflection checks a whole new set of access control rela

    • Laymen don't need to care. For them it makes writing simple programs just more complicated.

      A module is a library, aka jar file, that exports a part of its classes, and keeps the other classes private. Unlike ordinary "private classes" non exported classes are basically invisible for everyone outside of that module.

      While you can do that with OSGi, too, OSGI is configured via the .MANIFEST file in a jar file and modules in java 9/project Sigjaw are configured via semi Java looking source code processed by the

  • java medium security come back! lot's of IPMI and (Score:4, Insightful)

    by Joe_Dragon ( 2206452 ) on Saturday June 03, 2017 @03:27PM (#54542985)

    java medium security come back! lot's of IPMI and network hardware needs it.

  • Duh. That's what happens when Sun is involved (Score:5, Informative)

    by Cyberax ( 705495 ) on Saturday June 03, 2017 @06:06PM (#54543529)
    This is what happens when architectural astronauts get involved. The module system was NOT designed to solve clients' problems, it was designed to make JVM "modular" to better support IoT and "containers".

    And because it's not a user-driven feature, Snoracle went wild. They designed a complicated system that basically will force a significant redesign of every large Java-based system, all the while ignoring experience of OSGi, Maven and other modular systems. Here's a nice breakdown: https://developer.jboss.org/bl... [jboss.org]

    I can add a couple of my own comments, Snoracle is _still_ enamored with code access security. They think that they need to mutilate the language to support running of privileged and unprivileged code within the same address space, separated only by module boundaries. To this end, they designed complicated rules of visibility with restrictions for reflective access. You can guess how useful this is going to be - just remember the great security of applets.

    • Applets where unsecure because the Java Plugins for browsers had bugs. (Because they had to implement more security restrictions than an ordinary VM)
      That has nothing to do with Java 9 modularity.

      • Re: (Score:2)

        by Cyberax ( 705495 )
        Java 9 modularity spends a lot of spec to describe ways to limit the access from untrusted to trusted modules. The justification is code access security, this model splits _code_ into trusted and untrusted with trusted code having privileged access. And it's the real reason applets were so buggy - it's easy to trick a lot of "trusted code" by carefully crafting the data it works on.

        In contrast, modern approaches put the trust boundary at the process level and simply disallow access to anything that is not

        • And it's the real reason applets were so buggy - it's easy to trick a lot of "trusted code" by carefully crafting the data it works on.
          That is nonsense.

          Java Sandboxing works based on so called Security Managers, which restrict access to certain packages, classes or modules, and have nothing to do with "data".

          Nice link though, but it looks similar vulnerable as the Java way. Only glanced over it, but will study it later, thanx.

          • Re: (Score:2)

            by Cyberax ( 705495 )
            That's what I said - Java uses code access security. It divides code into trusted and untrusted parts, so that trusted code can do privileged actions. The great problem here is that the trusted code can be called from untrusted. And then it takes just one privileged function like:
            public String listFiles(String data) {
            return call("ls -la "+data);
            }
             to ruin everything. And it turns out that the JDK is full of these.

            The modern approach is to limit the _data_ on which you can operate by restricting you

            • Sorry, I don't get what you want to say.

              If call() is a method in a package/class that can only can be accessed under certain circumstances, e.g. SecurityManager grants access, it can only be called then. Unless there is a bug.

              • Re: (Score:2)

                by Cyberax ( 705495 )
                Suppose that listFiles() is within a trusted package and was left with public access so it's granted appropriate permissions from SecurityManager. The fact that it was left with public access _is_ a bug, of course. The problem is that it's too easy to make such mistakes and it takes only one to bring down the whole system. And if you think such mistakes are rare, here's a partial CVE list: https://www.cvedetails.com/cve... [cvedetails.com] , https://www.cvedetails.com/cve... [cvedetails.com] , https://www.cvedetails.com/cve... [cvedetails.com] , https://www [cvedetails.com]

                • Suppose that listFiles() is within a trusted package and was left with public access so it's granted appropriate permissions from SecurityManager.
                  That is not how a security manager works.

                  he fact that it was left with public access _is_ a bug, of course.
                  If it was not public it could be called at all.

                  Perhaps you mean: there should be a public method that is invoking the security manager before calling the private implementation. And the example above you assumed "listFiles()" was that private implementation

                  • Re: (Score:2)

                    by Cyberax ( 705495 )
                    Security manager works exactly as I described - you whitelist code to invoke privileged actions: https://docs.oracle.com/javase... [oracle.com] It's also possible to grant privileges dynamically to the calls down the stack (that's what you're referring to), but it's not the sole model. The JRE uses the whitelisting approach for its own classes - check the jre/lib/security/java.policy file for details if you don't believe me.

                    In the example above I assumed that listFiles() was somehow made callable with untrusted data (

                    • if "listFiles()" is supposed to only work if there is no SM installed then the code inside of listFiles needs to look something like this:

                      if (System.getSecurityManager() == null) {
                      return privateListFiles();
                      } else if (System.getSecurityManager().getListFilesPermissions() == "can list files") {
                      return privateListFiles();
                      } else {
                      throw new Security

                    • Re: (Score:2)

                      by Cyberax ( 705495 )
                      The problem is, if listFiles() is inside the JDK then it doesn't NEED to look like this. It will work just fine and all the permission checks inside call() that runs a command-line utility will be green. What you're describing is a manual check inside the listFiles() which is completely beside the point.

                    • I don't understand what your point is :)
                      Java security managers work in the way I described.
                      No idea about what you are talking.

                      However I would rewrite the JDK with annotations and let the compiler weave in the calls to the security manager, or even better use proper AOP and define all security related stuff outside of the runtime, you could even use a policy file for that.

                      I guess you talk about completely different security issues then I did.

                    • Re: (Score:2)

                      by Cyberax ( 705495 )
                      NO THEY DON'T. I gave you links to actual policy files. In JVM you grant permissions to _code_, so if your code has appropriate permissions then anything will just sail through. You are confusing it with _how_ permission checks are _sometimes_ implemented in JVM. For example, FileInputStream internally has a check with the SecurityManager and so does ProcessBuilder.start()

                      However, if ProcessBuilder.start() is called from the code inside the JRE then it WILL ALWAYS RUN, according to the policy file I gave

                    • And I told you: policy files are not used that way.

                      When a security manager is installed it absolutely does not matter from where the relevant code is called. That would be completely idiotic to allow JRE calls and forbid "client side code calls".

                      So if listFiles() is inside the JRE and is public then any applet with the most strict security policy will be able to call it, and listFiles() will then be able to call ProcessBuilder.start() without any problems.
                      No it won't. That makes no sense.

                    • Re: (Score:2)

                      by Cyberax ( 705495 )
                      Seriously? Please at least read this: http://docs.oracle.com/javase/... [oracle.com] - it describes how grants work. Now read the JDK policy. You can even write a short demo - create a policy grant for one class and create a security manager that restricts everything. Run your code with this manager and try to use privileged operations with this class. It will work, I tried this. Do you want to bet against it?

                      No it won't. That makes no sense.

                      Yes it will. And yes, it doesn't make much sense.

                    • If you use a policy file to grant or restrict access to certain methods of the target object: every method on the call stack needs to have a _grant_

                      It is clearly written in the Docu you link. Or in the X-linked other pages.

                      It is completely impossible, unless there is a bug, to trick a JRE method into calling something the client code has no grant for.

                    • Re: (Score:2)

                      by Cyberax ( 705495 )

                      If you use a policy file to grant or restrict access to certain methods of the target object: every method on the call stack needs to have a _grant_

                      Grants are applied on per-location basis. A file anywhere in JDK is granted all access. If it then calls (through a callback) a code outside JDK then this code won't get any additional permissions. You're keeping inventing stuff, just read the document.

                      You're confusing the static code access security with doPrivileged stuff which is dynamically assigned to the thread context: https://docs.oracle.com/javase... [oracle.com]

              • Comment removed based on user account deletion

            • Re: (Score:2)

              by drolli ( 522659 )

              And it turns out that the JDK is full of these.

              As long as it's only JDK and not the JRE.....

              • Re: (Score:2)

                by Cyberax ( 705495 )
                I should have said "JRE", JDK is basically a JRE with a compiler, source code and examples packaged.

  • Not too surprising... (Score:5, Interesting)

    by ndykman ( 659315 ) on Saturday June 03, 2017 @10:39PM (#54544349)

    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.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close