Proposal: #CompileTimeDependences: `requires static`
scolebourne at joda.org
Wed Jun 29 13:12:34 UTC 2016
There are three use cases that I have used personally for this:
1) The dependency contains an annotation that is not required at
runtime (classes load fine if annotations are not available). For
example, Joda-Time  dependency on Joda-Convert.
2) The main module has reflective code that checks whether a
dependency exists and auto-configures if it is available. For example,
Joda-Beans  dependency on Joda-Collect and Guava. (If Joda-Collect
is available then any data structure type the library can be
serialized using Joda-Beans).
3) The main module has isolated classes that can only be used if the
option dependency exists. For example, ElSql  dependency on Spring.
(If you use ElSql class as the main entry point you do not need
Spring, but if you use the ElSqlBundle class you do)
The issue and resolution are designed to support the flexible approach
to modules that applications have made use of for 20 years. While it
might be possible to migrate (2) to a service, that would block
adoption. Items (1) and (3) are not feasible via a service.
Note that I do not believe command line options satisfy this issue -
because they are unwieldy, unfriendly and a barrier to adoption. In
addition, they fail DRY. In this case, the library author knows that
the dependency is optional, and the library user is warned of that.
Adding a command line flag is just unnecessary noise that the system
should deal with.
On 29 June 2016 at 10:30, Tim Ellison <Tim_Ellison at uk.ibm.com> wrote:
> For some reason I can't quite explain, this feels like we are giving up
> on one of the fundamental completeness assurances of a coherent modular
> application. Is this a new failure mode for link/run time modular systems
> that has not previously existed?
> Another option would be to provide a command-line option that explicitly
> the linker/launcher to ignore missing modules that are required where
> there is
> an assurance that it will not actually be required in the particular
> that is, if I design a single module with "requires" or "requires static"
> dependencies if it is used in a stand-alone or container context, for
> I'd prefer to fail because of an explicit -ignoremods option on the
> line rather than a missing -addmods.
More information about the jpms-spec-observers