The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun.
Let alone the IDE support. I think it's truly amazing that I can make a project with 3 different JVM languages and get instant IDE autocompletion and warnings when calling methods between those languages. The source -> .class -> .jar thing has turned out to be a remarkably visionary design (or just a very lucky hit). For comparison, C# still compiles and "tools" that much slower because .class files are missing in the pipeline.
It's a testament to some of the true goodness of Java, despite its unpopularity in hipper circles, that they don't think a Maven-managed folder full of JARs is good enough.
Of course, this is really a JVM thing and you'll also get it if you use a different JVM language so you can actually get the best of both worlds.
Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes most simple things impossible and a few challenges trivial. "Hamstrung" is the word that comes to mind. Coupling a declarative, own-the-world, XML programming language with innumerable slap-dash/poorly maintained plugins is the pits.
All that said, maven repositories and the groupId:artifactId:version:type:classifier organization of modules are really genius. As you say, this genius shines in IDE's where, as just one example, you get nice binary/source .jar distributions automatically downloaded to your local repo. Having an IDE's debugger be able to seamlessly and accurately step through 1st party java sources and 3rd party source .jar sources is always so impressive to me.
Gradle (and Ivy before it) help paper over the pain and expose the good parts of the maven ecosystem. I have some gripes with Gradle, but after seeing it in action (and now that IDE's can grok its project configs) I'm so happy to be ditching maven/plugins and hand-written pom's for the most part.
Java needs a holistic dependency management/dependency injection/artifact repository/publishing workflow rethink where well-defined concepts like semver are enforced in the version numbering scheme, making it easier to express "safe" legal version ranges in transitive dependencies.
By the time Java 10 gets out, they can see how libraries that make use of modules, reified generics, value types, GPGPU integration, JIT plugins are out of reach.
Worse even, having library devs writing two versions of their libraries.
Google's fork of Java is leading to a Python 2 - 3 scenario.
Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility.
I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.
That's a naive solution. OSGi has a very specific target of embedded applications. Thanks to its classloader, its a headache to port existing libraries which weren't written with its classloader in mind. This leads to duplicate osgi safe versions in custom artifact repos.
In the end, not a solution, but a very nice environment and development choice if you are greenfield and in the target audience.
According to the article: "A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications."
I'm surprised by this as well. I was somewhat expecting Java 9 to tackle the dependency version problem.
My reading is it's hard enough as is because of backwards compatibility. They seem to be under massive pressure to deliver something for JDK 9 and can't push the deadline much longer.
If memory serves me correctly I remember Mark Reinhold saying to do it "right" they would have to run a linear equation solver like Eclipse/P2.
It will allow a group of jars to be exposed as a single entity, with internal APIs that can be exposed across jars, but not accessible outside the module.
Java modules, which happen to exist in other languages like .NET, Delphi and Ada, are akin to having a set of dynamic libraries exposed as a single library. With the ability of having symbols that are only visible to the dynamic libraries that are part of the same module.
I believe older java versions are already incompatible with newer jvms. I couldn't find it explicitly stated but i'd be surprised if 1.4 code worked 100% correct on a 1.7 jvm.
My experience so far is that the list of incompatibilities (http://www.oracle.com/technetwork/java/javase/compatibility-...) between versions makes it nearly impossible to just drop code between versions. It will run, but often implementation details have changed causing significant bugs. Your mileage may vary
If you watch talks like The Secret History and Tragic Fate of sun.misc.Unsafe ( https://www.youtube.com/watch?v=4HG0YQVy8UM ) you'll see that there is a move to isolate unsupported APIs and to slowly remove them once they are replaced by supported ones, but in general code that uses public APIs should continue to work without recompilation for a long time.
[+] [-] skrebbel|10 years ago|reply
Let alone the IDE support. I think it's truly amazing that I can make a project with 3 different JVM languages and get instant IDE autocompletion and warnings when calling methods between those languages. The source -> .class -> .jar thing has turned out to be a remarkably visionary design (or just a very lucky hit). For comparison, C# still compiles and "tools" that much slower because .class files are missing in the pipeline.
It's a testament to some of the true goodness of Java, despite its unpopularity in hipper circles, that they don't think a Maven-managed folder full of JARs is good enough.
Of course, this is really a JVM thing and you'll also get it if you use a different JVM language so you can actually get the best of both worlds.
[+] [-] EdSharkey|10 years ago|reply
All that said, maven repositories and the groupId:artifactId:version:type:classifier organization of modules are really genius. As you say, this genius shines in IDE's where, as just one example, you get nice binary/source .jar distributions automatically downloaded to your local repo. Having an IDE's debugger be able to seamlessly and accurately step through 1st party java sources and 3rd party source .jar sources is always so impressive to me.
Gradle (and Ivy before it) help paper over the pain and expose the good parts of the maven ecosystem. I have some gripes with Gradle, but after seeing it in action (and now that IDE's can grok its project configs) I'm so happy to be ditching maven/plugins and hand-written pom's for the most part.
Java needs a holistic dependency management/dependency injection/artifact repository/publishing workflow rethink where well-defined concepts like semver are enforced in the version numbering scheme, making it easier to express "safe" legal version ranges in transitive dependencies.
[+] [-] aabbccdd|10 years ago|reply
[+] [-] pjmlp|10 years ago|reply
By the time Java 10 gets out, they can see how libraries that make use of modules, reified generics, value types, GPGPU integration, JIT plugins are out of reach.
Worse even, having library devs writing two versions of their libraries.
Google's fork of Java is leading to a Python 2 - 3 scenario.
[+] [-] uxcn|10 years ago|reply
I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.
[+] [-] wiradikusuma|10 years ago|reply
[+] [-] wener|10 years ago|reply
[+] [-] smrtinsert|10 years ago|reply
In the end, not a solution, but a very nice environment and development choice if you are greenfield and in the target audience.
[+] [-] desdiv|10 years ago|reply
[+] [-] mateuszf|10 years ago|reply
[+] [-] dj-wonk|10 years ago|reply
I'm surprised by this as well. I was somewhat expecting Java 9 to tackle the dependency version problem.
[+] [-] iso8859-1|10 years ago|reply
[+] [-] needusername|10 years ago|reply
If memory serves me correctly I remember Mark Reinhold saying to do it "right" they would have to run a linear equation solver like Eclipse/P2.
[+] [-] norswap|10 years ago|reply
[+] [-] dj-wonk|10 years ago|reply
JEP 261: Module System http://openjdk.java.net/jeps/261
Java Platform Module System (JSR 376) http://openjdk.java.net/projects/jigsaw/spec/
[+] [-] smithkl42|10 years ago|reply
[+] [-] iso8859-1|10 years ago|reply
and http://stackoverflow.com/q/90578/309483
[+] [-] pjmlp|10 years ago|reply
It will allow a group of jars to be exposed as a single entity, with internal APIs that can be exposed across jars, but not accessible outside the module.
[+] [-] hitlin37|10 years ago|reply
[+] [-] pjmlp|10 years ago|reply
C++ modules are more like packages.
Java modules, which happen to exist in other languages like .NET, Delphi and Ada, are akin to having a set of dynamic libraries exposed as a single library. With the ability of having symbols that are only visible to the dynamic libraries that are part of the same module.
[+] [-] pc2g4d|10 years ago|reply
[+] [-] wener|10 years ago|reply
[+] [-] codingvelocity|10 years ago|reply
My experience so far is that the list of incompatibilities (http://www.oracle.com/technetwork/java/javase/compatibility-...) between versions makes it nearly impossible to just drop code between versions. It will run, but often implementation details have changed causing significant bugs. Your mileage may vary
[+] [-] aardvark179|10 years ago|reply
[+] [-] krzyk|10 years ago|reply
[+] [-] jonnw|10 years ago|reply