+1 You can still keep the SPI optional, see MEEP or JSR 363. Given any standard would not come before Java SE 9, modularity is also good to keep in mind for many other JSRs but the SPI should be there IMHO.
Werner On Tue, Jul 19, 2016 at 10:20 PM, Mark Struberg <[email protected]> wrote: > > > Am 19.07.2016 um 17:45 schrieb Anatole Tresch <[email protected]>: > > > > Not providing any kind of mechanism, but > > the API also makes us less vunerable to discussions about how > configuration > > should be organized, which ultimately is the main issue, why > standardizing > > it is so difficult. So from a political perspective it may be an > advantage > > NOT to define the mechanisms behind, but only provide the main mechanism > to > > access it, the API. > > I see the point, but I fear it falls a bit too short. > Think about JSR-330 (atinject). It only provides the ‚consumer‘ API. > Is it usable? No, it _always_ needs another spec to be usable. Be it CDI, > Guice or Spring. > It is *absolutely* impossible to provide a portable solution based on > atinject alone. > It is just the least common denominator of a few frameworks. > > Do we like to do that? > If so, how does a user build it’s applications in a *portable* way? > Without any SPI or very simple default ways to configure your app this is > imo impossible. > That’s the reason why I really would love to see the SPI as part of such a > spec. > > LieGrue, > strub > >
