Hi all, I'm thinking about the possibility of making a "Geode public API" module, mostly containing interfaces that Geode implements.
Why would one do this, you may ask? Here are some reasons. * It makes clear what is our public API (as opposed to "internal" type packages). * Users only have to compile against the API package. * Avoiding cyclic dependencies for modules that are internal parts of Geode. For cyclic dependencies, consider the case of the geode-protobuf module. It needs to be able to perform operations on the Cache and Locator, which means it needs to depend on geode-core. We can't have cyclic dependencies, so we have to use a ServiceLoader to get the service in core, which feels like a bit of a hack. If geode-core could depend on the geode-protobuf module, we could have a tighter connection, and not have to worry (as we currently do) that anything we expose must be visible from core.[1] Using ServiceLoader this way feels like a hack, because it's not really something that we would expect a user to provide a service for, and we can't handle the presence of more than one service. [2] Maybe there's a better way to do this. Maybe Java 9 packages can make it nicer. Maybe the ServiceLoader can be done better. I'd like to solicit comment from the devs. What are your thoughts? What's the best way to handle this? There are (AFAIK big, unanswered) questions about how to handle varying levels of public vs. internal API [3]. Do you have any answers? Thanks, Galen [1] as an aside, it's actually kind of nice to have everything hidden from core. It's resulted in an interface that creates an opaque object to manage connection state, with a single `processMessage` method on it. Nevertheless, other modules may with to expose more, and using ServiceLoader feels like a hack. [2] Actually, we do have to handle this case, and it's hard to do right, because we have to blow up (abort the caller, throw a RuntimeException) or ignore it and try to carry on (by closing connections made with the new protocol). Blowing up breaks tests in geode-core, so we log a message, but this maybe makes it easier to start up an incomplete cache.... [3] Maybe we could have multiple packages, one stable for public API, one internal (and potentially unstable) for things that are shared between modules?
