On Tue, Nov 7, 2023, at 15:05, Matt Sicker wrote:
> I’m not going to backport the DI system. It relies on Java 11 in all
> sorts of random places, first of all. I had to update numerous plugins
> and tests along the way, especially things that set up or manipulate
> static state, much of which has been cleaned up in main. It’s hard to
> describe all the little things that went into that.
The DI system is, for me, one of the best reasons for having a new major
version. I would be totally confused if we would backport it and we would need
strong reasons for such a move.
While I want to learn more about the benefits of the next iteration, my main
concern would be more “when” rather than “if”.
For me it is clear 3.x will happen. It seems there are different ideas on the
distinction between 2.x and 3.x, so we should make this distinction clear and
define when the one version starts and the other stops.
We can draw that line on Sunday together.
That said, thanks Ralph for the insight. I also found the question valuable,
because they need to be asked.
> —
> Matt Sicker
>
>> On Nov 7, 2023, at 05:31, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
>>
>> Hi Ralph,
>>
>>> On Tue, 7 Nov 2023 at 05:05, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> Next, there is a good chance that users really using JPMS won’t be able to
>>> access any plugins outside of log4j-core. See
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String).
>>> This is precisely why 3.x uses ServiceLoader to locate all plugins.
>>
>> The `META-INF` directory is not encapsulated, so `getResource` should
>> work fine. Nevertheless using `ServiceLoader` is a much cleaner
>> solution and would allow us to greatly simplify our OSGi-specific
>> code.
>>
>> Piotr
