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

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.

Comments

Re:Java?

[__aaclcg7560]

Java isn't Perl (yet).

shoulda coulda

[bugs2squash]

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.

I only have an A.S. degree in programming...

[__aaclcg7560]

What does modularity mean? Why should I care?

Re:I only have an A.S. degree in programming...

[Creepy]

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.

Re:I only have an A.S. degree in programming...

[Richard_at_work]

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

Re:I only have an A.S. degree in programming...

[__aaclcg7560]

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

Re: I only have an A.S. degree in programming...

[__aaclcg7560]

Weird how doing entry level jobs for 50k a year makes it so you don't learn useful things!

I haven't used Java since I got A.S. degree. These days I install Java updates on systems that won't play nice and I use Ant to automate some of my Python scripts at home. I keep hoping that I might have a reason to look at Java again but my hopes keep getting dashed by Slashdot nihilism.

Re: I only have an A.S. degree in programming...

[ewanm89]

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

Re:I only have an A.S. degree in programming...

[mark-t]

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.

Re:I only have an A.S. degree in programming...

[angel'o'sphere]

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 module is a jar file, aka a library, that exports (makes public) some of its classes and some not.

Re:I only have an A.S. degree in programming...

[angel'o'sphere]

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

Modules can have dependencies and have version numbers, so module x-1.0 can depend on module y-1.2 etc. How the dependency resolution works and how they support maven or similar repositories, I don't know. I did not bother to "learn" that stuff, as it is now postponed to be released since about 5 years .... yawn.

If you are bored: https://www.infoq.com/java9+mo...

Re:I only have an A.S. degree in programming...

[angel'o'sphere]

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: I only have an A.S. degree in programming...

[angel'o'sphere]

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.

Re: I only have an A.S. degree in programming...

[ewanm89]

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 related to these "modules" which gives important Clojure traces as unknown class, unknown method...

Finally "an ordinary jar file" is not a first order thing, it is a packaging format (really just a ZIP file of .class files with a few metadata files added), the .class files are the first order way of load classes. However more than that, there are different levels of class loading governed by calling different class loaders in the JVM, Languages like Clojure inject into the JVM at a lot earlier point than an import statement in a running program does. This difference is important allowing clojure to override certain things and do the high performance interpretation/compilation without having the overhead of the rest of the libraries loaded that the users code uses.

Re:I only have an A.S. degree in programming...

[Immerman]

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 functionality should reasonably be exposed - for example a 3D vector or quaternion type, where direct access to the data components permits access using conventional mathematical grammar, and it's impossible to place them into an inconsistent state anyway.

Re:Java?

[Lordpidey]

They're for completely different purposes.

Webassembly is supposed to replace javascript.

Java is still used for serverside technologies.

java medium security come back! lot's of IPMI and

[Joe_Dragon]

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

Re: Are people still seriously using Java?

[Anonymous Coward]

It's the #1 used language so yeah, a lot. If I want a job in Java there are near endless options. If I want a job in, say, Elixir, I would have to move.

Java is far from perfect, but Spring Boot with Java 8 does everything I need it to.

Re: Are people still seriously using Java?

[Anonymous Coward]

People that make money use Java.

Re: Are people still seriously using Java?

[Anonymous Coward]

It is easy to refactor Java with Eclipse rename and extract. It has maven which makes 3rd party lib usage simple. It has auto formatter. Using threads is simple enough. Making libs is simple. It is fast. Debugging is easy. It has good static analysis support. It is easy to find people who know the language. The language has pretty good libs for many different things like GUI, calendar, 3D, regex... , JUnit makes testing easy, auto import works with it, it will by default give good info where it crashed and why, it is OSS, it is easy to manage even large projects with it. Library support for various databases, and many other things. Many of these are because of Eclipse and similar IDEs, but considering how bad IDEs C++ has, I think it is because of the language that these tools could be made.

Re:Java?

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

Re: Are people still seriously using Java?

[mark-t]

i gave up on colon because I couldn't import my existing projects with their own working makefiles. It insisted on using cmake

Re: Are people still seriously using Java?

[mark-t]

Fucking autocorrect. I meant clion

Duh. That's what happens when Sun is involved

[Cyberax]

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

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.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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:Duh. That's what happens when Sun is involved

[Cyberax]

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 explicitly whitelisted. See: http://doc.pypy.org/en/latest/... as an example. Your code can be as buggy as you want, but it doesn't matter if it can't access the whole world.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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:Duh. That's what happens when Sun is involved

[Cyberax]

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 to operations with file descriptors you've inherited with the environment and maybe to IPC calls through a well-defined protocol. Think about this as a classic Unix suid binaries versus network servers with authentication.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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:Duh. That's what happens when Sun is involved

[Cyberax]

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... , https://www.cvedetails.com/cve... , https://www.cvedetails.com/cve... , https://www.cvedetails.com/cve... , and so on.

Re:Duh. That's what happens when Sun is involved

[drolli]

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

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

Re:Duh. That's what happens when Sun is involved

[Cyberax]

I should have said "JRE", JDK is basically a JRE with a compiler, source code and examples packaged.

Re:Duh. That's what happens when Sun is involved

[squiggleslash]

What the GP is referring to is called the Confused Deputy problem, a class of security issues where:

* A isn't trusted to access C because reasons.
* A is trusted to access B.
* B is trusted to access C.
* By exploiting a bug or design flaw in B, A can actually access C.

The fact that Security Manager prevents an application from accessing, say, the classes used to access (for example) the file system doesn't mean that an application cannot fool other built-in privileged classes from accessing the file system in the way the application wants if those privileged classes have bugs.

The proof is in the pudding, to a certain extent: if Security Manager worked, then Java applets wouldn't have a reputation almost as bad as Flash's for having the security of swiss cheese. Now, I'd agree with the view that Java isn't nearly as insecure as detractors claim - to a certain extent, we're looking at the airplane vs car problem, where people will drive because they think flying is unsafe, because car crashes aren't news whereas air crashes are reported internationally. But it's certainly had exploits over the decades its ran.

Disclaimer: I can't comment on whether anything being proposed for Java in Java 9 would actually fix this. If java.boogie.graphics.OpenContext(String prefs) throws ContextExceptionWithCompleteConfigurationInExceptionObject does a direct system call to fopen("/var/lib/java/boogie/contexts/" + prefs + ".cfg"), I don't see how any amount of sandboxing or scoping is going to fix that.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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 and left accidentally public as well?

Re:Duh. That's what happens when Sun is involved

[Cyberax]

Security manager works exactly as I described - you whitelist code to invoke privileged actions: https://docs.oracle.com/javase... 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 (perhaps not even directly).

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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 SecurityException("list files not permitted");
    }

Policy files are used for different stuff, e.g. Applets (and then read by a SecurityManager).

So: no, the system does not work the way you think it would.
However it would make more sense to have policy files for everything and have a CodeWaver that weaves in the security (manager) code.

The JavaDoc you linked has absolutely nothing to do with SecurityManagers aka calling of certain code. It is an abstraction for ACLs, Digestes and Certificates.

Perhaps you should read the links you post?

Re:Duh. That's what happens when Sun is involved

[Cyberax]

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.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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:Duh. That's what happens when Sun is involved

[Cyberax]

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

The fact that you don't understand it exactly explains why code access security is such a pile of shit.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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:Duh. That's what happens when Sun is involved

[Cyberax]

Seriously? Please at least read this: http://docs.oracle.com/javase/... - 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.

Re:Duh. That's what happens when Sun is involved

[angel'o'sphere]

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:Duh. That's what happens when Sun is involved

[Cyberax]

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

Re:Java?

[Anonymous Coward]

Found the millennial.

Re:Are people still seriously using Java?

[angel'o'sphere]

All the idiots who want stuff to get done and get payed for it.

It is surprising how ignorant /. readers are.

While the majourity of all big internet software in the USA is written in Java, thy proclaim death to Java all the time. How is the balance between C# and Java in the USA regarding serious back end software? 10% is Python and PHP and 0.5% PERL? And the rest? 60% Java versus 40% C#? No idea just wondering.

In Europe basically 90% of all industrial software on high performance back ends is written in Java. The idiots who decided for C# don't even find developers to maintain their systems. I have requests for C#/.NET developers every day. I would get $1000 for every colleague I would refer to the requesters. Unfortunately I do not know a single person who is so dumb to work with C#/.Net ... go figure.

Java is just C++ running on a VM without real templates, anyway. If that is to hard to grasp, you should not be working in the software industry.

Re:Java?

[DontBeAMoran]

Hum... swiss cheese...

Not too surprising...

[ndykman]

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.

Re:Are people still seriously using Java?

[__aanljs7351]

I've been in IT for 20 years and started coding by typing in those programs they'd print in the old tech magazines. While I've seen C# and PHP, I don't know anyone who uses Java or PERL. I myself usually refactor in Python. This is in Silicone Valley though - I don't know about Europe (don't even have a passport).

Re:Are people still seriously using Java?

[squiggleslash]

If you're in "Silicone Valley" (isn't that Beverly Hills?) then yes, you've probably never been exposed to Java. If you worked for a giant non-tech company - banks, automotive manufacturers, etc - you'd almost certainly be a Java (or possibly .NET - but not desktop application .NET) grunt, not programming in whatever it is you do.

If you're old enough to have typed in programs from computer magazines, then think back to those days, and imagine if you worked for Microsoft, or Commodore, or for that matter Activision. You'd have been exposed to a lot of assembler and BASIC, and maybe some C. You wouldn't have met anyone at all who did anything in COBOL. But in the 1980s, COBOL was still one of the world's most popular programming languages, if not the most popular. Our industry is much more specialized than most people think.

Re:Are people still seriously using Java?

[angel'o'sphere]

Perhaps ou can google which silicon valley companies mainly use Java :D
www.indeed.com lists about 2400 Java jobs in silicon valley open.

Re:Are people still seriously using Java?

[__aanljs7351]

I don't need to google, I have been in IT for 20 years. Started out video games - those weren't in Java either. All I'm saying is in my career, I have not seen Java. I am a virgual ditch digger though - not a software developer or DBA.