I’m coming at this from the perspective similar to you in that I’ve tried to read a lot about OSGi and JPMS and I still understand neither.
I think you miss the point about the binary format of module info and needing JDK 9 tools, which led to the tweet from Tatu Saloranta… Since module info is a class file, it would need to be Java 9 format. It means you can’t have Jigsaw support and Java 8 support at the same time. It’s not the fact the format is binary — it’s the fact that you need a compiler at all. Were it a text file, you could just include it in a Manifest or similar file like how Spring and ServiceLoader work. And if your users aren’t using Jigsaw, then it works just like a normal JAR.
I agree in general with your assessment that there are some low blows in there. Anyone that disillusioned with a product will add in some weak jabs in with the strong ones. But I see a lot of strong ones in there.
So far I see hardly any benefits to JPMS. I see how it will break my current code. I’ve yet to see the “killer use case” where I can do something with JPMS that I couldn’t do before. And I’m still confused on how to even use it. Your list of benefits to JPMS is the best list I’ve seen so far, because I’ve kept trying to find them. But some of the benefits you list are as theoretical as the weak blows you point out in the JPMS critique.
I was most excited about jlink and AOT more than any other feature. But even the most minimal JDK with hello world and java.base still exceeds the fully featured installs of almost every other dev environment I’ve seen. It looks like it will be about 30 MB or so, plus your code and dependencies. That’s not small enough to be compelling for a download of a small tool. OK, so the massive undertaking to modularize JDK is done but the benefit isn’t compelling enough for me to say it was worth it. 100MB to 30MB is helpful but not game changing or enables any use case. The target use case I see is a desktop user who wants to use your app but doesn’t want to install Java. In a server environment, this is useless as the JDK install is a one-time deal and the size of J2EE server like Weblogic dwarfs the JDK anyway. The full installer of NodeJS is 13MB. Python 3.6.1 64 bit installer for Windows is less than 30MB. But, I am relying on web reports of this as I’ve yet to actually figure it out.
You mention AOT as if it is a real thing. It still appears to be theoretical. From what I’ve read so far, it’s experimental, works on Linux x86 only, and you need to manually exclude a bunch of classes it just can’t work with. That sounds like “theoretically supports AOT compliation” still applies to JPMS.
If AOT works on Windows and if the minimal JRE size can be reduced perhaps to single-digit MB, then it would probably be sufficient to compel users to use more Java desktop applications that don’t need 100MB download of an installer that wants to also do browser plugins and ads, and doesn’t need half a minute to start up. THAT would be worth it, but I don’t see that yet.
The only other benefit mentioned is that it is well-documented and well-tooled. This may be true and makes things nicer but it only complements the technical use cases that need to exist.