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
