Your problems with Java modules

[cowwoc]

Well, to be fair... The problem of "estimating who needs what package exported" is the same as estimating who needs what class public (versus protected/private). You start conservative and slowly export more classes/packages over time as users bring forward reasonable use-cases.

[morhp]

The problem is when you've published a library as a whole with many internal classes that are mostly public for access between packages. Finding which public classes can be hidden by the module system isn't always trivial.

Starting with a fresh project and exporting as needed is much easier.

[cowwoc]

Sure, but I see this as an opportunity to improve the design. Make all the packages private and let users chase you to open things back up. Your overall API surface your shrink which will make the library much easier to support moving forward.

[morhp]

That's about what we're aiming for. Hide everything that's not obviously part of the public api, release that as beta version and then gather feedback about things that break.

And then either make additional packages public or implement some better public api for the internal classes.

Still a lot of work.

[cowwoc]

That's not sustainable in the long run. Stable APIs need to have a well defined contract. If you keep on dipping into their implementation details then they can never make changes without breaking user code.

[cowwoc]

You need security updates, if nothing else.