The 0.2 API JAR of Tamaya including the SPI counts roughly 20 elements. Compared to ~60 in JCache. The JAR size doesn't necessarily reflect the size or complexity of a JSR. JSR 330 consisting only of half a dozen annotations can't be taken as a "reference" for every JSR, as you mentioned without CDI, Spring or some other DI container it has no real value of its own.
JSR 354 which targets 2 different environments and in theory the while "convert" part could be a separate module at the very least in its current 1.0 Final state comes close to 60 types including the SPI so a tiny bit more than JCache, the JAR is also 20k bigger. CDI API 1.2 consists of nearly 100 types! A somewhat comparable JAR size as Money-API 1. Should CDI 2 be better modularized because of that, yes, do you think it'll be just 3, 5 or 10 elements even in the SE "minimal" module, think for yourself. So modularization before even thinking of the standards part is clearly a good idea. CDI 1 or Java 5-8 were not created with that in mind, which is why it's now so tedious to break them down into small pieces, but API anorexia is neither clean nor useful either;-) Cheers, Werner On Tue, Jul 19, 2016 at 11:57 PM, Mark Struberg <[email protected]> wrote: > Let’s not drift from one extreme to the other. > > One extreme: (userland api only) 3 classes > Other extreme:(tamaya current api): ~25 classes > > The middle ground I did propose (userland api + spi) has 5 classes. That’s > merely 2 more than the minimal BUT it is usable, extensible and flexible. > > LieGrue, > strub > > > > Am 19.07.2016 um 23:14 schrieb Anatole Tresch <[email protected]>: > > > > 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* > >
