Didn't want to feel the trolls but you say too wrong statements we shouldn't let be public without corrections in this last one
2016-07-20 16:29 GMT+02:00 Werner Keil <[email protected]>: > 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. > Geronimo is NOT dead, this clearly means you don't know what G is. The server gets only very low activity but other projects are quite active for the whole ASF ecosystem. > 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) > > That's an assumption as well > 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. > > Why do you speak of EE there, what's the link you do with Tamaya? > 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 > > >> > > >> > > > > >
