I didn’t realize that java.base was that limited. Are these all required at run time or only build? For example, the annotation processor is not used when log4j is running so I would suspect it is required to be present in the build and I would think it would have to be present when the compiler is running.
Where are we using JNDI? While scripting support certainly could be optional, it would probably uglify the code to do that. I have mixed feelings about whether it makes sense for JMX to be optional or not. I really can’t see how the xml could be optional. Whatever we decide, it will need to be documented. Ralph > On Jan 28, 2018, at 9:35 PM, Matt Sicker <boa...@gmail.com> wrote: > > That's rather limiting. Here's what we're already using: > > * java.compiler: annotation processing (could potentially be split, but > this situation is already confusing enough for users) > * java.management: JMX > * java.naming: JNDI > * java.scripting: javascript/groovy/etc plugins > * java.xml: XML configuration parsing > > I may have missed some others, but it may be difficult to trim it down to > just java.base. Even with some of the simpler ones, we'll end up with > several additional modules to detangle that. > > If we could include multiple logical modules in a single physical module, > then this wouldn't be as tedious. > > On 27 January 2018 at 20:01, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> Also, in Java 9 it must only require the java.base module. >> >> Ralph >> >>> On Jan 27, 2018, at 6:49 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> On 27 January 2018 at 16:18, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>> >>>> The requirement is that log4j-core have no required dependencies. I >> should >>>> have as few optional dependencies as possible. >>>> >>> >>> That sounds perfectly reasonable. LMAX and Jackson are good examples. >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >> >> >> > > > -- > Matt Sicker <boa...@gmail.com>
