Slashdot Mirror
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.
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.
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.
Nullius in verba
java medium security come back! lot's of IPMI and network hardware needs it.
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.
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...
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
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).
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.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
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.
You are not alone. This is not normal. None of this is normal.