Don't think most extensions have to be standardized. If there are SPI or API elements like "SomeProvider" then it's the idea that extensions use them. Zalando and other users of JSR 354 create their own ExchangeRateProvider, modules extending JSR 363 define SI, ISO, Unicode or UCUM systems based on its SPI. Actually those are also standardized by ISO or others but that's another story;-)
On Tue, Jul 19, 2016 at 11:14 PM, Anatole Tresch <[email protected]> wrote: > But we provide a bit more than annotations only. Our API is still complete > and basically usable. And the same discussion goes into the extensions > part: without extensions there is not si much benefits, but getting > extensions standardized might be even more difficult... > > 2016-07-19 22:20 GMT+02:00 Mark Struberg <[email protected]>: > > > > > > 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 > > > > > > > -- > *Anatole Tresch* > PPMC Member Apache Tamaya > JCP Star Spec Lead > *Switzerland, Europe Zurich, GMT+1* > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > *Twitter: @atsticks, @tamayaconf* >
