I don't follow Java too closely and the world "module" is so hopelessly generic that I had a hard time understanding what the article was talking about. It links to this document [1] though, which is a long read, but does an excellent job of describing of describing all the ins and outs of the module system.
(tl;dr Packages can now declare themselves as modules instead of simple namespaces, and they get to choose exactly what they export and what other modules they require. Projects can now resolve their types from within modules with a module path instead of on a per-type basis from the class path. It's a huge step forward for Java modularity and dependency management.)
I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust), but acknowledge just how monumental of an effort it was to design the new system and then build it into Java's core in a way that's mostly backwards-compatible. Java's going to be around for a long time, and this is a big long-term gain for the ecosystem.
I'd really love to see languages like Ruby tackle this next. It's sorely needed.
> ...because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust)
Haha...I love Rust, but you must not have been following the recent saga over modules in the community. Two things became abundantly clear:
1) There are definite issues with the current way that Rust does modules and they create problems for newcomers that don't know all the intricacies.
2) There's very little consensus in the community about the best way to fix those problems.
Initially, a couple of different, somewhat major proposals were made that would largely overhaul the system. Over the course of a few iterations, those were whittled down to a few, much smaller changes that mostly keep the current system but remove some of the stumbling blocks. It's a credit to the Rust team that they've handled it in such an open manner, but it's also creating a bit of a "design by committee" feel that's probably going to create something that everyone can live with and very few will think is close to perfect.
> I have a hard time being too impressed because more modern languages are doing this out of the gates
The problem with Java is that it's an already established and very popular platform and it's been so for the past decade at least. When starting from scratch, it's easy to just throw it all away and start fresh, it's easy to fix mistakes that were made in the past.
The irony though is that we still have a hard time learning from history. Just look at Go. Sometimes this industry feels like Groundhog Day, the movie.
Also, no platform or language that I know of has gotten "modules" right, with Java being one of the platforms that has gotten closest to fixing the problem actually (by means of OSGi). To see why modules are still a big problem and why we won't have a fix for the foreseeable future, I invite you to watch this keynote by Rich Hickey: https://www.youtube.com/watch?v=oyLBGkS5ICk
> I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks
Well of course - it's easier to build something like this into a clean-slate language isn't it? It's harder to build it into an existing language and VM spec with an incomprehensibly large volume of existing code to be compatible with. It's backwards to say it's not impressive because someone else with zero constraints to work with also managed it.
> I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling
I'm not so sure about that. Java (both the language and the VM) is relatively unique in its mix of static (mostly in the sense of being typed) and dynamic (all linking is dynamic; code is often be loaded, unloaded and generated at runtime; reflection and general introspection of the runtime is pervasive). It's a blend of, say, ML, Smalltalk and Erlang. The module system is therefore more impressive than it may look at first glance. While not all the tooling is there yet, through the use of what it calls "layers", it makes it possible to dynamically load plugins or even upgrades to components in the system, each depending on different versions of the same library, while enforcing customizable levels of isolation between them. Whether or not there are any conflicts requiring a separation of "layers", can also be determined at runtime by introspection.
With the raging debate going on in Rust community about module system, it is clear they are still far from having well understood and usable module system for wider Rust community.
The meaning of “module” is pretty concrete and specific. A module is:
(0) A unit of encapsulation: Modules can export abstract types whose representation is hidden from the rest of the program.
(1) A unit of type-checking: Modules can be type-checked without knowing anything other than the interface of their dependencies.
(2) A unit of translation: Modules can be translated to target machine code separately from each other. (That being said, whole-program compilation is fine if you want it. The semantics of the module system shouldn't make it mandatory, though.)
Most programming languages don't have module systems at all. And most programming languages that do have module systems, have module systems that suck. Including Rust.
>I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling
I'm curious, is there another language that allows you to streamline its runtime by choosing only what modules your app needs?
I think it's going to take me a while to learn about the module system in Java 9, I'm probably going to bank on watching other projects do it first to see if any best practises emerge as developers get used to the new way of working.
One thing I will say though is Java 9 has had a definite improvement on Java applications that run on my Raspberry Pi 3, I think because this got included http://openjdk.java.net/jeps/297
One application used to take 55s to start up, now it takes around 15s!
Still sounds ridiculous. Assuming this is how much time it takes to initialize the VM, I wonder if it would be possible to have a pool of VM processes that are already running and ready to accept an application code.
The improvement is good, of course, but isn't the whole thing a bit of a straw man? The previous version taking 55 seconds on a Pi 3 seems utterly unacceptable to me, it's actually a pretty capable processor, and even a 15 second startup is pretty slow. Why put up with that when there are modern options (Go and Rust spring to mind) which would do so much better?
I think its very exciting they were able to get the number of discrete modules up to 26. That's extremely impressive to me given the age and complexity of Java! I went to a talk a few years back from one of the contributors to this project (forget the name, sorry!) and I think if my memory serves me they had significantly fewer discrete modules at that time -- perhaps 6?
Anyhow, I think this is a great step forward for Java.
Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
> Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal.
That was only a few weeks. If you check the official release schedule http://openjdk.java.net/projects/jdk9/ Jigsaw was supposed to be feature complete a year before that vote happened. Jigsaw was simply not close to ready when it was merged to master. And yes, Oracle still claims it hit every milestone on that schedule.
> It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Not much really. Basically Oracle called their bluff. At that point is was really too late as Jigsaw was already merged to master and more or less touched every part of the JDK.
> Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
Not really, it was really just Oracle making things up as they went. For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different. For example they have no good explanation while they mashed the module declaration into a .class file, basically everybody except Oracle thinks it's a bad idea but the just went with it anyway. They claim "reliable configuration" as a goal but without versioning that's meaningless.
I'm still not sure of the practical benefits? Seems to be purely for IOT and nothing else. Am I correct?
Edit: To add to my question, jar hell was solved by tooling which generates your classpath for you. So it hasn't been an issue for me in years. And they refused to add versioning, so you still need to use those tools. Strong encapsulation just means they disabled reflection access to non public members, which I consider a regression on functionality. Either way, not a particularly useful feature to me, in fact it breaks some of my code. So I'm left with being able to have small JVMs which don't bundle the full standard lib, which seems to be mostly of use for memory constrained environments like IOT. But I'm actually hopeful there's some bigger practical benefits I'm not thinking of, so I'd love to hear from people who know more about jigsaw.
Before Java 9, the only way to hide private APIs would be to have everything in the same JAR.
If a library is splinted across multiple JARs, then private APIs only to be used internally by library become exposed to everyone, and there will always exist someone making use of them even if explicitly marked as internal.
This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept.
In the organization I work for, we're contemplating a move from Oracle JDK to OpenJDK, when we move from 8 to 9. I'm still nervous about OpenJDK from some historical scary stories of things not working well in OpenJDK or at least different. I've not found much on the subject, or even on OpenJDK as a functioning open source project. (Or is it just a code drop of the Oracle JDK?) If anyone has good insights, or links to some realistic comparisons, I'd be thrilled.
Note: Oracle is my employer, the following statements are my own — (insert Safe Harbor notification)
Good news regarding any trepidation on the differencesa between the runtimes — recently we announced that there will no longer be a difference between OpenJDK and OracleJDK [1]
To quote: “The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018)”
The biggest pain for me was that it felt like there was no good way to create a library with some internal structure in the form of packages without exposing parts of your internal implementation as public.
When Jigsaw was delayed I was playing with the idea to create a project called shitty-jigsaw, which would just merge all of the packages in a module and change the access modifiers to be more restrictive according to some module definition.
yes.
especially since in the future you can actually compile modules as libraries and aot load them.
at the moment this is experimental and should probably only work for java.base
I remember this from... 11 or so years ago, i think. I was making some Java applet based game and the slow startup time and big JVM download was something that an issue among people making such games (which by the time i was into were dying - although they'd soon get a short lived shot in the arm thanks to Minecraft, but that was later). There were some posts in javagaming.org forums from some people who were talking with Sun (that was before Oracle - Sun at the time was actually interested into uses of Java in gaming and talked with devs, including from smaller/indie developers) about a new improvement for the VM to modularize the packages so that only things that are required would be loaded (faster startup) and the default JVM download would be much smaller (sort of comparable to Flash) which was a big issue at the time for those making web-based games (that niche for Java games would soon die with the introduction of Flash Player 9 and ActionScript 3, although it took a bit for people to actually upgrade).
I remember it was released at some point, but at the end it didn't amount to much since most of the JVM's actual implementation relied on everything else and the "optional" bits were only a small part, so it didn't help almost at all with applets. And by that time Java applet gaming was dead (it never reached Flash gaming's heights, but for a few years in the early/mid 2000s it was still something you could make a living off - if you didn't expect much).
I never heard about it much after that and personally moved away from Java with Flash becoming dominant on the web game scene and soon with Oracle being an dick to everyone. The only reason i used Java was for NetBeans' GUI editor for my tools but with Lazarus [0] becoming very stable by that time and NetBeans looking and behaving weird in my -then- brand new iMac, i abandoned Java for good (the only active Java project i still have is a tilemap editor [1] but this only if you stretch "active" to "hack on it a little every few years").
I also never liked Java much after Java 1.4 - it moved further away from its "simple language" roots and i liked how everything was solved in the library instead of adding extra stuff to the language. Well, that, and things like generics felt very "bolted on" while annotations like `@override` felt unnecessary verbosity (and ugly syntax-wise).
My favorite Java was probably around 1.1 or so (i have a book on that too), some times i think i should make a new language and VM after it but i lose interest quickly - i think i have a bunch of parsers for Java-1.1-like languages lying around in my backups, from every time i get that urge :-P.
Thanks for the good memories. I remember those days of Java 1.4 start up times and the first talks of modularization coming out. It was so exciting! Then 1.5 came and startup speeds boosted a lot. I recently gave Java another try with a Kotlin project and am fairly impressed. Have not worked with Java in years, mostly in Python recently.
clra|8 years ago
(tl;dr Packages can now declare themselves as modules instead of simple namespaces, and they get to choose exactly what they export and what other modules they require. Projects can now resolve their types from within modules with a module path instead of on a per-type basis from the class path. It's a huge step forward for Java modularity and dependency management.)
I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust), but acknowledge just how monumental of an effort it was to design the new system and then build it into Java's core in a way that's mostly backwards-compatible. Java's going to be around for a long time, and this is a big long-term gain for the ecosystem.
I'd really love to see languages like Ruby tackle this next. It's sorely needed.
---
[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
curun1r|8 years ago
Haha...I love Rust, but you must not have been following the recent saga over modules in the community. Two things became abundantly clear:
1) There are definite issues with the current way that Rust does modules and they create problems for newcomers that don't know all the intricacies.
2) There's very little consensus in the community about the best way to fix those problems.
Initially, a couple of different, somewhat major proposals were made that would largely overhaul the system. Over the course of a few iterations, those were whittled down to a few, much smaller changes that mostly keep the current system but remove some of the stumbling blocks. It's a credit to the Rust team that they've handled it in such an open manner, but it's also creating a bit of a "design by committee" feel that's probably going to create something that everyone can live with and very few will think is close to perfect.
bad_user|8 years ago
The problem with Java is that it's an already established and very popular platform and it's been so for the past decade at least. When starting from scratch, it's easy to just throw it all away and start fresh, it's easy to fix mistakes that were made in the past.
The irony though is that we still have a hard time learning from history. Just look at Go. Sometimes this industry feels like Groundhog Day, the movie.
Also, no platform or language that I know of has gotten "modules" right, with Java being one of the platforms that has gotten closest to fixing the problem actually (by means of OSGi). To see why modules are still a big problem and why we won't have a fix for the foreseeable future, I invite you to watch this keynote by Rich Hickey: https://www.youtube.com/watch?v=oyLBGkS5ICk
chrisseaton|8 years ago
Well of course - it's easier to build something like this into a clean-slate language isn't it? It's harder to build it into an existing language and VM spec with an incomprehensibly large volume of existing code to be compatible with. It's backwards to say it's not impressive because someone else with zero constraints to work with also managed it.
pron|8 years ago
I'm not so sure about that. Java (both the language and the VM) is relatively unique in its mix of static (mostly in the sense of being typed) and dynamic (all linking is dynamic; code is often be loaded, unloaded and generated at runtime; reflection and general introspection of the runtime is pervasive). It's a blend of, say, ML, Smalltalk and Erlang. The module system is therefore more impressive than it may look at first glance. While not all the tooling is there yet, through the use of what it calls "layers", it makes it possible to dynamically load plugins or even upgrades to components in the system, each depending on different versions of the same library, while enforcing customizable levels of isolation between them. Whether or not there are any conflicts requiring a separation of "layers", can also be determined at runtime by introspection.
geodel|8 years ago
catnaroek|8 years ago
(0) A unit of encapsulation: Modules can export abstract types whose representation is hidden from the rest of the program.
(1) A unit of type-checking: Modules can be type-checked without knowing anything other than the interface of their dependencies.
(2) A unit of translation: Modules can be translated to target machine code separately from each other. (That being said, whole-program compilation is fine if you want it. The semantics of the module system shouldn't make it mandatory, though.)
Most programming languages don't have module systems at all. And most programming languages that do have module systems, have module systems that suck. Including Rust.
bitmapbrother|8 years ago
I'm curious, is there another language that allows you to streamline its runtime by choosing only what modules your app needs?
ksec|8 years ago
Could you expand on that? Why Ruby?
djhworld|8 years ago
One thing I will say though is Java 9 has had a definite improvement on Java applications that run on my Raspberry Pi 3, I think because this got included http://openjdk.java.net/jeps/297
One application used to take 55s to start up, now it takes around 15s!
Koshkin|8 years ago
Still sounds ridiculous. Assuming this is how much time it takes to initialize the VM, I wonder if it would be possible to have a pool of VM processes that are already running and ready to accept an application code.
thcsa|8 years ago
foota|8 years ago
pebers|8 years ago
fndrplayer13|8 years ago
Anyhow, I think this is a great step forward for Java.
morecoffee|8 years ago
Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
needusername|8 years ago
That was only a few weeks. If you check the official release schedule http://openjdk.java.net/projects/jdk9/ Jigsaw was supposed to be feature complete a year before that vote happened. Jigsaw was simply not close to ready when it was merged to master. And yes, Oracle still claims it hit every milestone on that schedule.
> It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...
http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...
http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05...
Not much really. Basically Oracle called their bluff. At that point is was really too late as Jigsaw was already merged to master and more or less touched every part of the JDK.
> Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
Not really, it was really just Oracle making things up as they went. For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different. For example they have no good explanation while they mashed the module declaration into a .class file, basically everybody except Oracle thinks it's a bad idea but the just went with it anyway. They claim "reliable configuration" as a goal but without versioning that's meaningless.
didibus|8 years ago
Edit: To add to my question, jar hell was solved by tooling which generates your classpath for you. So it hasn't been an issue for me in years. And they refused to add versioning, so you still need to use those tools. Strong encapsulation just means they disabled reflection access to non public members, which I consider a regression on functionality. Either way, not a particularly useful feature to me, in fact it breaks some of my code. So I'm left with being able to have small JVMs which don't bundle the full standard lib, which seems to be mostly of use for memory constrained environments like IOT. But I'm actually hopeful there's some bigger practical benefits I'm not thinking of, so I'd love to hear from people who know more about jigsaw.
pjmlp|8 years ago
Before Java 9, the only way to hide private APIs would be to have everything in the same JAR.
If a library is splinted across multiple JARs, then private APIs only to be used internally by library become exposed to everyone, and there will always exist someone making use of them even if explicitly marked as internal.
This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept.
sverhagen|8 years ago
tjfontaine|8 years ago
Good news regarding any trepidation on the differencesa between the runtimes — recently we announced that there will no longer be a difference between OpenJDK and OracleJDK [1]
To quote: “The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018)”
[1] https://blogs.oracle.com/java-platform-group/faster-and-easi...
puppetmaster30|8 years ago
mschwaig|8 years ago
When Jigsaw was delayed I was playing with the idea to create a project called shitty-jigsaw, which would just merge all of the packages in a module and change the access modifiers to be more restrictive according to some module definition.
jswizzy|8 years ago
smegel|8 years ago
merb|8 years ago
sscarduzio|8 years ago
brianwawok|8 years ago
badsectoracula|8 years ago
I remember it was released at some point, but at the end it didn't amount to much since most of the JVM's actual implementation relied on everything else and the "optional" bits were only a small part, so it didn't help almost at all with applets. And by that time Java applet gaming was dead (it never reached Flash gaming's heights, but for a few years in the early/mid 2000s it was still something you could make a living off - if you didn't expect much).
I never heard about it much after that and personally moved away from Java with Flash becoming dominant on the web game scene and soon with Oracle being an dick to everyone. The only reason i used Java was for NetBeans' GUI editor for my tools but with Lazarus [0] becoming very stable by that time and NetBeans looking and behaving weird in my -then- brand new iMac, i abandoned Java for good (the only active Java project i still have is a tilemap editor [1] but this only if you stretch "active" to "hack on it a little every few years").
I also never liked Java much after Java 1.4 - it moved further away from its "simple language" roots and i liked how everything was solved in the library instead of adding extra stuff to the language. Well, that, and things like generics felt very "bolted on" while annotations like `@override` felt unnecessary verbosity (and ugly syntax-wise).
My favorite Java was probably around 1.1 or so (i have a book on that too), some times i think i should make a new language and VM after it but i lose interest quickly - i think i have a bunch of parsers for Java-1.1-like languages lying around in my backups, from every time i get that urge :-P.
[0] http://www.lazarus-ide.org/ [1] http://runtimeterror.com/rep/mapas
pjmlp|8 years ago
http://www.oracle.com/technetwork/java/javase/kernel-135055....
http://openjdk.java.net/jeps/148
vturner|8 years ago