5 ms·

IMO Java modules feature is failure. I'm using Java and I've yet to find a single library using modules. I know that they allowed to modularize JVM, yet I've ye

IMO Java modules feature is failure. I'm using Java and I've yet to find a single library using modules. I know that they allowed to modularize JVM, yet I've yet to find any advantage of this fact either. Everyone still downloads and runs an entire JVM. And it's not like JVM become slim and tiny, it's still hundreds of megabytes. Those who need slim apps, use GraalVM which does some kind of tree shaking, AFAIK, rather than relying on modules. All that work, which broke plenty of Java applications, violating main Java mantra of backward compatibility, all for nothing.

vips7L 5y ago
I agree it hasn’t gotten adoption, but you get a pretty slim JVM if you properly modularize. Another poster in this thread said he got his image down to 30mb. Helidon is probably the only library I know that is modularized [0]. I think once the community finally moves past jdk 8 (I’m hoping spring making 17 the base next year will help) we’ll see more adoption as more libraries modularize. [0] https://github.com/oracle/helidon https://github.com/oracle/helidon
native_samples 5y ago
Half agreed, but, there are some mitigating things to consider. One is that native code is really verbose compared to bytecode, and jlink optimizes bytecode to shrink it when it's modularized (collapses the string tables and other things). For tiny hello world apps native-image can produce smaller downloads. It doesn't take long before a jlinked JVM is smaller, because the JIT compiler is kind of "decompressing" native code on the fly. A minimal jlinked JVM can be small-ish, like 20mb or less, and if you compile a custom JVM with configure flags for size it can be even smaller still. The smallest jlinked hello world I managed to get when I tried this was a 7mb download. Not small for a program that only prints something, but, obviously, most of that is one time cost. Another is that jlink+modules is way easier to use and configure than native-image. Tree shaking breaks stuff all over the place. You end up needing complex config files, agent-based config auto generation and/or lots of runtime testing to ensure you got everything. The point of "reliable configuration" is to avoid all this by building a less aggressive form of tree shaking into the language itself. Quite a few libraries support modules at this point, but you may not actually have noticed. It depends on your build tool and things. One thing that's slowed it down is that a lot of widely used libraries that sit at the bottom of the dependency stack aren't actually well maintained. And, modules can only depend on other modules. SLF4J, Guava etc have been slowing things down a lot. My feeling is that the module system is kind of underrated and waiting for better tooling to be fully exploited. Quite a few parts of Java are like this. Like, it took quite some years for the ecosystem to start using annotation processors to full advantage, and some popular libraries still have it as a pending feature (like PicoCLI).
moksly 5y ago
> Everyone still downloads and runs an entire JVM. They do? I work in the Scandinavian public sector and we abandoned Java two or three years ago because of the continued security issues it posed. Software that require an install JVM to operate doesn’t get past our IT department. I’m not sure modules would help though, as I don’t know much about them. But not everyone still installs JVM.
- fenesiistvan 5y ago
  What kind of security issues? A random native app is more secure?
- vbezhenar 5y ago
  I had in my mind people who use Java for their projects, not in general sense.
- dikei 5y ago
  Java in the browser (Applet) is unsecured, because it can download and run untrusted code in the user machine. Java in the server, on the other hand, is as secured as any other runtime, i.e only as good as the application written on it.
  - TeaVMFan 5y ago
    Alternatives like TeaVM let you code Java in the browser but it compiles quickly to compact JavaScript. This way you can get the best of both worlds. A typed language, full-stack refactorings, and the security of the browser JS VM. TeaVM Website: https://teavm.org/ https://teavm.org/ Tutorial in Java Magazine: https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...
    - dikei 5y ago
      Typescript has already filled the niche of a typed, OOP language in the browser for me. And it's surely much better supported than TeaVM.
_old_dude_ 5y ago
Here the list of all modules on Maven Central https://github.com/sormuras/modules/blob/main/com.github.sormuras.modules/com/github/sormuras/modules/modules.properties https://github.com/sormuras/modules/blob/main/com.github.sor... > Everyone still downloads and runs an entire JVM Nope, we (i know anecdote) use jlink in docker containers, mostly to avoid useless dependencies. The problem of GraalVM native image is that it comes with a subpar GC. > which broke plenty of Java applications yes, i agree, modules did not worth the trouble.
shepherdjerred 5y ago
Java modules haven't been adopted because people are still getting off of JDK 8 as it becomes deprecated. It will only make sense for library and framework maintainers to invest in modules once there is a large user base on JDK 11. Either way, modules are still useful for application development. I used them years ago to close off internal APIs in one of my applications, which helped me to not cross levels of abstraction accidentally.
pgwhalen 5y ago
> All that work, which broke plenty of Java applications, violating main Java mantra of backward compatibility, all for nothing. How did modules break Java applications? Having recently upgraded a number of applications from 8 to 11, none of the things we had to fix were due to modules. They were largely due to libraries relying on internal implementation details of Java 8 which needed dealing with, the exact sort of thing that modules are looking to prevent going forwards (see "strong encapsulation" in TFA). We've ignored modules so far with no issues.
- krzyk 5y ago
  He probably writes about removal of some EE classes that were in JDK (but shouldn't). Or better protection of Java internals (warnings about using internal classes in JDK 11, and in JDK 17 no warnings - you need to --add-opens or don't use broken lib).
  - pgwhalen 5y ago
    Yeah, the removal of EE classes was probably the biggest burden for my team (completely unrelated to modules).
lazulicurio 5y ago
IMO the main issue with modules is that strong encapsulation is actually a bad goal. If the focus was solely on reliable configuration, I think that the transition would have gone better. WRT why I think strong encapsulation is a bad goal: I've worked extensively in .net where assembly-private members are the norm for core libraries. It has issues. Classes and methods that are theoretically extensible aren't so in practice because core logic is inaccessible. In the end, encapsulation, no matter how strong, doesn't prevent people from relying on internal implementation details. If the concern is people relying on "internal" APIs, either suck it up and make those APIs public (with all that entails) or come up with a deprecation strategy (or just freeze them and refactor around them).
pron 5y ago
1. The breaking of some libraries in JDK 9 had very little to do with modules and was mostly due to weak encapsulation. Almost all issues stemmed from libraries, written to be non-portable, hacking into JDK internals and becoming entangled with the particulars of JDK 8. When those internals changed, they broke. With modules' strong encapsulation now finally enabled, this won't happen again. In other words, modules weren't the cause of the breakages, but added to prevent them in the future. Unfortunately, they were blamed for the problems they were created to prevent because they were the most famous feature in JDK 9. 2. Modules are becoming the core of Java's security strategy. Without them, your code only does what you think it does unless any library decides it should do something else. 3. The reduction of security and maintenance concerns have already yielded tremendous dividends, as we the JDK developers have been freed to work on other stuff. Your complaint is like someone finally getting a fast internet connection, saying, all that noise and dirt of tearing up the street putting in the cable ducts have been in vain; they should have just given us fast internet, because that's all we wanted. So, we've got better security and a drastic reduction in future breakages, all for negligible backward-incompatible changes to the spec.

vips7L 5y ago

I agree it hasn’t gotten adoption, but you get a pretty slim JVM if you properly modularize. Another poster in this thread said he got his image down to 30mb. Helidon is probably the only library I know that is modularized [0]. I think once the community finally moves past jdk 8 (I’m hoping spring making 17 the base next year will help) we’ll see more adoption as more libraries modularize. [0] https://github.com/oracle/helidon https://github.com/oracle/helidon

native_samples 5y ago

Half agreed, but, there are some mitigating things to consider. One is that native code is really verbose compared to bytecode, and jlink optimizes bytecode to shrink it when it's modularized (collapses the string tables and other things). For tiny hello world apps native-image can produce smaller downloads. It doesn't take long before a jlinked JVM is smaller, because the JIT compiler is kind of "decompressing" native code on the fly. A minimal jlinked JVM can be small-ish, like 20mb or less, and if you compile a custom JVM with configure flags for size it can be even smaller still. The smallest jlinked hello world I managed to get when I tried this was a 7mb download. Not small for a program that only prints something, but, obviously, most of that is one time cost. Another is that jlink+modules is way easier to use and configure than native-image. Tree shaking breaks stuff all over the place. You end up needing complex config files, agent-based config auto generation and/or lots of runtime testing to ensure you got everything. The point of "reliable configuration" is to avoid all this by building a less aggressive form of tree shaking into the language itself. Quite a few libraries support modules at this point, but you may not actually have noticed. It depends on your build tool and things. One thing that's slowed it down is that a lot of widely used libraries that sit at the bottom of the dependency stack aren't actually well maintained. And, modules can only depend on other modules. SLF4J, Guava etc have been slowing things down a lot. My feeling is that the module system is kind of underrated and waiting for better tooling to be fully exploited. Quite a few parts of Java are like this. Like, it took quite some years for the ecosystem to start using annotation processors to full advantage, and some popular libraries still have it as a pending feature (like PicoCLI).

moksly 5y ago

> Everyone still downloads and runs an entire JVM. They do? I work in the Scandinavian public sector and we abandoned Java two or three years ago because of the continued security issues it posed. Software that require an install JVM to operate doesn’t get past our IT department. I’m not sure modules would help though, as I don’t know much about them. But not everyone still installs JVM.

fenesiistvan 5y ago
What kind of security issues? A random native app is more secure?
vbezhenar 5y ago
I had in my mind people who use Java for their projects, not in general sense.
dikei 5y ago
Java in the browser (Applet) is unsecured, because it can download and run untrusted code in the user machine. Java in the server, on the other hand, is as secured as any other runtime, i.e only as good as the application written on it.
- TeaVMFan 5y ago
  Alternatives like TeaVM let you code Java in the browser but it compiles quickly to compact JavaScript. This way you can get the best of both worlds. A typed language, full-stack refactorings, and the security of the browser JS VM. TeaVM Website: https://teavm.org/ https://teavm.org/ Tutorial in Java Magazine: https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...
  - dikei 5y ago
    Typescript has already filled the niche of a typed, OOP language in the browser for me. And it's surely much better supported than TeaVM.

_old_dude_ 5y ago

Here the list of all modules on Maven Central https://github.com/sormuras/modules/blob/main/com.github.sormuras.modules/com/github/sormuras/modules/modules.properties https://github.com/sormuras/modules/blob/main/com.github.sor... > Everyone still downloads and runs an entire JVM Nope, we (i know anecdote) use jlink in docker containers, mostly to avoid useless dependencies. The problem of GraalVM native image is that it comes with a subpar GC. > which broke plenty of Java applications yes, i agree, modules did not worth the trouble.

shepherdjerred 5y ago

Java modules haven't been adopted because people are still getting off of JDK 8 as it becomes deprecated. It will only make sense for library and framework maintainers to invest in modules once there is a large user base on JDK 11. Either way, modules are still useful for application development. I used them years ago to close off internal APIs in one of my applications, which helped me to not cross levels of abstraction accidentally.

pgwhalen 5y ago

> All that work, which broke plenty of Java applications, violating main Java mantra of backward compatibility, all for nothing. How did modules break Java applications? Having recently upgraded a number of applications from 8 to 11, none of the things we had to fix were due to modules. They were largely due to libraries relying on internal implementation details of Java 8 which needed dealing with, the exact sort of thing that modules are looking to prevent going forwards (see "strong encapsulation" in TFA). We've ignored modules so far with no issues.

krzyk 5y ago
He probably writes about removal of some EE classes that were in JDK (but shouldn't). Or better protection of Java internals (warnings about using internal classes in JDK 11, and in JDK 17 no warnings - you need to --add-opens or don't use broken lib).
- pgwhalen 5y ago
  Yeah, the removal of EE classes was probably the biggest burden for my team (completely unrelated to modules).

lazulicurio 5y ago

IMO the main issue with modules is that strong encapsulation is actually a bad goal. If the focus was solely on reliable configuration, I think that the transition would have gone better. WRT why I think strong encapsulation is a bad goal: I've worked extensively in .net where assembly-private members are the norm for core libraries. It has issues. Classes and methods that are theoretically extensible aren't so in practice because core logic is inaccessible. In the end, encapsulation, no matter how strong, doesn't prevent people from relying on internal implementation details. If the concern is people relying on "internal" APIs, either suck it up and make those APIs public (with all that entails) or come up with a deprecation strategy (or just freeze them and refactor around them).

pron 5y ago

1. The breaking of some libraries in JDK 9 had very little to do with modules and was mostly due to weak encapsulation. Almost all issues stemmed from libraries, written to be non-portable, hacking into JDK internals and becoming entangled with the particulars of JDK 8. When those internals changed, they broke. With modules' strong encapsulation now finally enabled, this won't happen again. In other words, modules weren't the cause of the breakages, but added to prevent them in the future. Unfortunately, they were blamed for the problems they were created to prevent because they were the most famous feature in JDK 9. 2. Modules are becoming the core of Java's security strategy. Without them, your code only does what you think it does unless any library decides it should do something else. 3. The reduction of security and maintenance concerns have already yielded tremendous dividends, as we the JDK developers have been freed to work on other stuff. Your complaint is like someone finally getting a fast internet connection, saying, all that noise and dirt of tearing up the street putting in the cable ducts have been in vain; they should have just given us fast internet, because that's all we wanted. So, we've got better security and a drastic reduction in future breakages, all for negligible backward-incompatible changes to the spec.