News for hackers. Stuff that matters.
Re:Rating 26 years of Java changes by alex_smart on Sunday October 12, 2025 @02:48AM (#45555881)
I have a company with ~20 developers only. And already I have an ArchUnit test stating that public classes within "com.companyname.module.somepackage.internal" cannot be used anywhere outside "com.companyname.module.somepackage".

Surely almost everyone who has worked in a large enough codebase and thought about large-scale modularity can see the use case for a unit of abstraction in java higher than a package?

Re:Rating 26 years of Java changes by nmadden on Sunday October 12, 2025 @04:01AM (#45556255)
Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.

Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.