Why that's not true. JPA historically has more ties to TopLink including the RI now at EclipseLink I also said that earlier. You said Hibernate became a de-facto blueprint. Which is not the case, it may have become a bit more popular for various reasons (Spring supporting it, then major competitor Red Hat buying its team and taking over development) but it was never a 1:1 blue print or starting point for an Oracle-led JSR.
Structurally maybe JSR 330 is closest to what was and still is at Google Guice. See https://github.com/google/guice/wiki/JSR330, though JavaDoc suggests they're also not 1:1 copies. After seemingly panic that Tamaya could become a RI for a future spec (and as of now it looks like the best option, take Pluto and others in the past) you suddenly pulled out the "dead" Geronimo card. A few patches here and there seem to exist http://svn.apache.org/viewvc/geronimo/ but not a single release since 2013, sorry, but that's as dead as it can be. Tomitribe works a lot on TomEE right now in the EE space the de facto only real place of activity at Apache other than e.g. Pluto (following Portlet 3, but it'll run on any Tomcat or TomEE container, no need for Geronimo there) Geronimo makes no effort for Java EE 7 compatibility for "religious" or other ideological reasons I know from the EC discussions or those in the EE umbrella EGs. The lack of activity also would not qualify it for EE 7 compliance, so it's dead you can't ignore that. With initial contributions sometimes based on an entire projects or parts of it JSR 354 is also not JodaMoney, though Stephen probably would have hoped for that. Nevertheless it's incompatible parallel final structures and missing API (BigMoney vs. Money no common denominator like TemporalUnit or TemporalAmount were created behind 310) and total lack of conversion or an SPI just disqualify it for a standard. And you see the extension points are what's used of JSR 354 ever since it went Public Draft. Cheers, Werner On Wed, Jul 20, 2016 at 4:06 PM, Mark Struberg <[email protected]> wrote: > This now seems to directly contradict to what you said multiple times > before in this thread. > > Quoting mails from you : > "A JSR is rarely just a single framework or project only changing its > package name. JSR 363 was probably one of the few exceptions“ > "Hibernate vs. JPA is also an interesting read …“ > You literally mentioned dozen examples where open source projects did > _not_ become a JSR 1:1 and don’t care about backwards compatibility with > existing solutions. > > > > > The other points are valid but everyone still just keeps talking around > > "Yes we need an SPI" nobody so far talked about what it may contain or > what > > could be added/removed. > > Even my initial mail DID contain exactly that. As did dozen subsequent > posts… > > LieGrue, > strub > > > > > > Am 20.07.2016 um 15:48 schrieb Werner Keil <[email protected]>: > > > > You asked about a possible JSR "not bothering about existing stuff" and > > based on what a vast majority of EC members agree on I told you that's > not > > the case. Question answered. > > > > Plus popular examples where existing open source projects ended up as 90% > > blueprint for a JSR/JDK part like > > https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html > > based on > > http://www.joda.org/joda-time/apidocs/org/joda/time/Duration.html > > > > Ok there's also another Duration class added with JavaFX, but let's not > go > > there;-) > > > > > > The other points are valid but everyone still just keeps talking around > > "Yes we need an SPI" nobody so far talked about what it may contain or > what > > could be added/removed. > > > > Werner > > > > > > On Wed, Jul 20, 2016 at 3:39 PM, Mark Struberg <[email protected] > > > > wrote: > > > >> Why do none of your mails seem to direcly reply to the question asked in > >> the mail before? > >> Most of them seem totally out of context to me. > >> Or is it just me who feels offended by that? > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 20.07.2016 um 15:06 schrieb Werner Keil <[email protected]>: > >>> > >>> Not exactly, because it's a broad consensus among JCP EC members (I am > >> just > >>> one Individual) that an idea should get the "reality check" in most > cases > >>> via an established Open Source project. > >>> > >>> > >>> So while the codebase of a new JSR (see 375) would normally be a green > >>> field contribution from scratch, if EG members did a lot in an existing > >>> open source project, then there are often significant similarities with > >>> those projects. > >>> > >>> JSR 354 was started by Victor by more or less accepting JodaTime as a > >>> template. A few types remained almost unchanged (and everyone > especially > >>> Stephen is mentioned as authors) while others were refactored, removed > or > >>> new ones added. java.time although it is highly inspired by JodaTime on > >> the > >>> "developer facing front" with types like Duration, LocalDate, etc. did > >> get > >>> an "API/SPI in a closet" mostly thanks to Roger Riggs by Oracle. The > >> names > >>> changed significantly, the term "Temporal*" was only introduced at a > >>> relatively late stage. IMHO the biggest design mistake in the API is to > >>> directly reference the concrete implementation Duration in > >>> > >> > https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalUnit.html > >> . > >>> There is no logical reason why not to use the "API" element > >> TemporalAmount > >>> here and call the damn thing "getAmount()" or similar. Baking the RI > into > >>> an API is a no-go. You won't see this in any other JSR I reviewed or > >> voted > >>> on. Of course it was tightly embedded into OpenJDK and Stephen himself > >>> claims there will never be a need for an independent implementation, > but > >>> then why not stop the JSR and just turn it into a JEP that also > existed. > >> It > >>> was silly and unfortunate in this case, but just because something is > in > >>> the JDK doen't mean it has to be a bad or useless API, take Collections > >> for > >>> example. There's an independent implementation of it now at Eclipse by > >>> Goldman Sachs. > >>> > >>> JSR 354 may not have a full implementation yet, but large players like > >>> Zalando created exchange rate providers and extended it with Jackson > >>> Binding or Bean Validation support, so I guess the extension mechanisms > >>> created there worked;-) > >>> > >>> JSR 275 was an interesting case because Open Geospatial Consortium did > >> not > >>> bother that it was stopped. It's part of another standard GeoAPI by OGC > >>> till a new version replaces it with 363. It is almost Final, but I > guess > >>> the OGC wants to be on the safe side and wait till 1.0 is really out > this > >>> time?;-) > >>> > >>> Werner > >>> > >>> > >>> On Wed, Jul 20, 2016 at 2:47 PM, Mark Struberg > <[email protected] > >>> > >>> wrote: > >>> > >>>>> > >>>>> Am 20.07.2016 um 13:10 schrieb Werner Keil <[email protected]>: > >>>>> > >>>>> > >>>>> That's where I suggested, that the minimum an SPI must provide is the > >>>>> equivalent to PropertySource and maybe PropertySourceProvider. > Allowing > >>>>> those extensions to still work with a future design. > >>>> > >>>> Yes, there is finally something we agree on ;) > >>>> > >>>> I probably do care less about existing extensions than you. Any new > JSR > >>>> imo doens’t need to bother about existing stuff. I think we agree on > >> this > >>>> part as well, right? > >>>> > >>>> The main reason why I think we need an SPI is because the application > >>>> otherwise has no way to plug in the stuff they need. > >>>> > >>>> That would be like bean-validation without custom > >>>> Constraint+ConstraintValidator. Such a spec would not be worth the > >> energy > >>>> imo. > >>>> > >>>> LieGrue, > >>>> strub > >> > >> > >
