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 >> >>
