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.
-Alan
