There's nothing inherently wrong with using a private module - except that WildFly will not guarantee API compatibility (referring to the part about "may be changed") for private modules across releases. Don't worry - Infinispan as a module won't be going away anytime soon.
Thanks for the response, Paul. I wasn't worried about Infinispan going away in any near-to-mid term releases, but I was surprised to see that it went from "public" to "private". If the criteria for marking something private is just a possible API change in the future, wouldn't that mean that everything should be private?
Greg Jewell wrote:
If the criteria for marking something private is just a possible API change in the future, wouldn't that mean that everything should be private?
From what I remember, the goal/usage of marking a module "private" was more from a paid support perspective (EAP) where you need some kind of an assurance that if you are relying on certain libraries then some level of backward compatibility and such will be maintained for those modules/libraries. "private" modules don't have those guarantees.
Edit: Just to clarify, the backward compatibility aspect also applies to the community edition i.e. WildFly.
Declaring a module as "public" doesn't mean that its API can't change - only that a specific level of compatibility is maintained across releases (e.g. module name consistency, backwards compatibility, deprecation prior to removal, etc.). Private modules make no such guarantees.