> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > No I guess it was right, "that are" ;) = fork @G only when we need to > change some impl/default provider.
Right. A few things in my mind at least: - Industry health: we (Apache) are the only other implementations of Activation, JavaMail, JACC and similar "impl" specs. If we give up on the impls we have, the industry collapses down to one impl and then what is the point of a spec? - Competitiveness: we have seen performance issues reported against our impls. I distinctly remember one for JACC several years ago. Where there are issues, there are also potential advantages. If we can handle it, let's keep our impls and be competitive. Where there is no actual impl I don't see any gain for the effort even if small. - Unavoidable EPL dependence: We're not likely to write a new Java compiler any time soon, so we're stuck with the EPL forever. - Likelyhood of increased EPL dependence: Given it is the default choice in Jakarta, more things will be created under it we may need. - Decreasing helping hands: Projects at Apache are switching over to the EPL libraries, so we will have fewer people willing to type in APIs for already-thin legal reasons. -David
