Besides am I the only one who prefers a more structured way of writing down requirements e.g. in JIRA over endless mailing list threads?
In smaller groups like DeviceMap there is not so much traffic, so the mailing list is OK. Real bugs like a missing device tend to come in JIRA. Unfortunately the Apache JIRA doesn't have the "User Story" type (but it should not go away like java.net) but one can easily use types like Feature, Task, Improvement or "Wish" (the latter probably best for all that's discussed here lately;-) The mailing list is fine and mandatory for a real vote, but this wasn't really a vote, so IMHO it could be better fleshed out if you (someone in this thread, everyone has JIRA access) created a ticket for major areas like API or SPI. At least API should exist as component, otherwise create. I can't log into my account right now, but it sounds better also to put a name on a task or sub-task once tasks are identified (right now I would rather call this Improvement or Wish, the exact tasks like "remove class XYZ" would follow later) On Wed, Jul 20, 2016 at 3:48 PM, Werner Keil <[email protected]> wrote: > 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 >> >> >
