4 ms·
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the modul
by SerCe 1y ago
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty.
I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Don’t be misled by the title, it’s not just about Java, it’s about software design.
[1]: https://www.youtube.com/watch?v=Gz7Or9C0TpM https://www.youtube.com/watch?v=Gz7Or9C0TpM
- paulddraper 1y agoYeah modules isn’t for end users, at least not for the most part
- adgjlsfhk1 1y agomodules get a -10 because they were massively breaking
- executesorder66 1y ago>For example, the main "customer" of the module system is the JDK itself As mentioned in TFA, "The general advice seems to be that modules are (should be) an internal detail of the JRE and best ignored in application code" So yeah, why expose it to those who are not the "main customer"?
- vips7L 1y agoIt’s just too complex. They should have went with the internal modifier.
- SerCe 1y ago> So yeah, why expose it to those who are not the "main customer"? How did modules affect you as a user? I'd guess that you had to add `--add-opens`/`--add-exports` during one of the JDK migrations at some point. And the reason you had to do it was that various libraries on your classpath used JDK internal APIs. So modules provided encapsulation and gave you an escape hatch for when you still have to use those libraries. How else would you do it while still achieving the desired goal?