Java 9 Delayed Due To Modularity Controversy (infoworld.com) 79
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.
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.
Java? (Score:1, Troll)
That's still a thing? I thought we were all supposed to move to WebAssembly?!
Re: (Score:2)
Re: (Score:2)
Webassembly is supposed to replace javascript.
Java is still used for serverside technologies.
Re: (Score:1)
Found the millennial.
Re: (Score:2)
Hum... swiss cheese...
Re: (Score:1)
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)
I only have an A.S. degree in programming... (Score:2, Interesting)
Re: (Score:2)
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: (Score:2, 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 mak
Re: (Score:3)
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: (Score:2)
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
Re: (Score:3)
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]
Re: (Score:2)
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)
Re: (Score:3)
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)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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)
java medium security come back! lot's of IPMI and network hardware needs it.
Re: Are people still seriously using Java? (Score:1)
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? (Score:1)
People that make money use Java.
Re: Are people still seriously using Java? (Score:2, Insightful)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
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 Jav
Re: (Score:1)
Re: (Score:3)
Re: (Score:2)
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: (Score:1)
Duh. That's what happens when Sun is involved (Score:5, Informative)
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.
Re: (Score:2)
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)
In contrast, modern approaches put the trust boundary at the process level and simply disallow access to anything that is not
Re: (Score:2)
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)
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
Re: (Score:2)
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)
Re: (Score:2)
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)
In the example above I assumed that listFiles() was somehow made callable with untrusted data (
Re: (Score:2)
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)
Re: (Score:2)
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)
However, if ProcessBuilder.start() is called from the code inside the JRE then it WILL ALWAYS RUN, according to the policy file I gave
Re: (Score:2)
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)
No it won't. That makes no sense.
Yes it will. And yes, it doesn't make much sense.
Re: (Score:2)
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)
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]
Re: (Score:3)
Re: (Score:2)
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)
Not too surprising... (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.