On 07/03/2018 15:14, Stephen Colebourne wrote:
Configuration and code are two very different things. Asking projects
and end users to write code for something that should be config is a
huge no-no.

My view is that JPMS has made using configuration files, especially
for libraries, a lot harder. This is a step back in usability. Just so
we are clear, for leap seconds I will now have to ask users to
manually register them using an API where previously they just added a
file. But for OpenGamma Strata, the configuration files are much more
complex and certainly unsuited to be code, even if the backwards
compatibility issues were acceptable. (This is a pattern I've used for
configuration for many years)
It's usually cleaner to encapsulate that configuration but if you don't want to change anything then you can continue to use ClassLoader.getResources to search for resources as it works exactly as it did before. Also if you move the configuration file to somewhere like META-INF/config then it can never be encapsulated.


PS. ServiceLoader is a pain to use in Java 9 too. As a library doesn't
know whether it will run as a named module or on the classpath, I have
to duplicate the service loader configuration - once in
META-INF/services and once in module-info.java, which is horrible.

Tooling should be able help with cases where you are creating a library that may be deployed on the class path in some environments and the module path in others. The `jar` tool does some sanity check in this area but it could do more.


Reply via email to