Jsonb impl will stay j7 for few years so i still dont get these arguments. Spec min version are never respected in practise Le 7 janv. 2015 00:07, "Otávio Gonçalves de Santana" < [email protected]> a écrit :
> Great!, but manager two projects with the same functions may stay difficult > with the time. > IMHO, the project is born and create a project without lost some cool > improvements such Lambda, stream, optional, etc. The Java 7 will dead on > April. The new projects such CDI 2.0, JSON-B, and another sub-components in > Java EE 8, are using the Java 8 as minimum requirement. > > On Tue, Jan 6, 2015 at 8:52 PM, Mark Struberg <[email protected]> wrote: > > > I tried to do some small tricks and it was actually really easy to > > implement a java7 version and base our java8 version in backward > compatible > > ways on it. > > > > I've pushed this to a fb-se7 branch on github. > > > > https://github.com/struberg/incubator-tamaya/tree/fb-se7 > > > > > > The idea is to basically have 2 'versions' of the spec in one go. > > > > The java7/api module provides an api which builds perfectly fine with > > Java7. > > > > The java8/api module is 'backward compatible' to the Java7 api and adds > > the Optional etc features on top of it. I just had to tweak it a little > bit. > > > > For now I just did the API, but the impl is even less of a problem. > Trying > > to check what we could reuse for the java7 impl as well. > > > > > > > > LieGrue, > > strub > > > > > > > > > > > On Tuesday, 6 January 2015, 15:35, Mark Struberg <[email protected]> > > wrote: > > > > I do see the benefits of Java8 but I also do see that not many can > use > > it in > > > production in the next 2 years. Thus it will not get adopted. We are in > > a phase > > > of transaction right now. > > > > > > That's the reason why I proposed to try out both of em and compare them > > when > > > we are done. > > > > > > Let me draft this up. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > > > > > > > >> On Tuesday, 6 January 2015, 15:23, Romain Manni-Bucau > > > <[email protected]> wrote: > > >> > ok so let fork tamaya to support java 7, who will backport to java > 8 > > >> banch - yeah nobody will use j8 branch today? > > >> > > >> > > >> Romain Manni-Bucau > > >> @rmannibucau > > >> http://www.tomitribe.com > > >> http://rmannibucau.wordpress.com > > >> https://github.com/rmannibucau > > >> > > >> > > >> > > >> 2015-01-06 15:18 GMT+01:00 Anatole Tresch <[email protected]>: > > >>> Hi all > > >>> > > >>> I still think it is a real big mistake to go for Java 7. Do it in 8 > > > and > > >>> provide a backport for 7. Not the other way round! > > >>> Some additional remarks inline: > > >>> > > >>> Cheers > > >>> Anatole > > >>> > > >>> > > >>> 2015-01-06 14:26 GMT+01:00 Mark Struberg <[email protected]>: > > >>> > > >>>> I'm also still not convinced. > > >>>> > > >>>> Let's step back a few meters and simply compare the benefits > > > vs the > > >>>> downsides > > >>>> > > >>>> > > >>>> - PRO > > >>>> * more 'modern' > > >>>> * Optional > > >>>> * Functions > > >>>> * default methods in interfaces > > >>>> > > >>> + Streams > > >>> + extended functions on collections > > >>> + date time API > > >>> + concurrent improvements > > >>> > > >>> > > >>> > > >>>> - CON > > >>>> * not backward compatible > > >>>> * blocks adoption in current containers > > >>>> > > >>> -> no. the EE7 TCK is not running on Java 7, but the containers do! > > > Even > > >>> bigger companies like Credit Suisse are thinking on replacing the > JDK > > >>> during next year. > > >>> > > >>> > > >>> > > >>>> * blocks adoption in many user projects > > >>>> > > >>> But as well is a prop compared to other libraries existing and will > > > for > > >>> sure boost support by other well known JUGs such as SouJava and > LJC.. > > >>> > > >>> > > >>> > > >>>> * we actually don't really need any of it's features > > >>>> > > >>> Of course, you can build things without it. But as I said, it is as > > > you > > >>> would build code in Java 1.4 without generics. One year later you > > will > > > have > > >>> to overhaul your API, or somebody else will come and do it in its > own > > >>> project. And most important: a JSR based on Java 7 will never be > > > accepted > > >>> by the EC. So stop crying for the past, go for the future (and > > provide > > > a > > >>> backport - should be doable in 2-3 hours for a release). > > >>> > > >>> > > >>> > > >>>> Let's face it: JDK8 is still not production ready. It is > > > somewhat > > >> slower > > >>>> than Java7 still and I honestly know no single big project which > > > runs > > >> on > > >>>> Java8. Not even the JavaEE7 TCK passes on Java8.. > > >>> > > >>> As I said before, I know also bigger companies that probably will > go > > > to > > >>> Java 8 rather soon. And honestly I do not care. I wanted to build > > with > > > you > > >>> guys a modern API, not an outdated one ;) > > >>> > > >>> > > >>> Ad Optional: > > >>>> > > >>>> The discussion we had was around Optional. The only impact it has > > > on me > > >>>> now is that instead of > > >>>> > > >>>> > > >>>> if (blabla != null) {...} > > >>>> > > >>>> I've seen > > >>>> > > >>>> if (blabla.isPresent()) {..} > > >>>> > > >>> > > >>> Please read my blog as stated in one of my first mails related to > the > > >>> topic. > > >>> > > >>> Instead of > > >>> > > >>> Optional<T> get(String) > > >>> > > >>> you get > > >>> > > >>> T get(String key); > > >>> T getOrDefault(String key); > > >>> T getOrThrow(String key, ExceptionFactory<T>) throws T; > > >>> > > >>> Also all this must be done on your own, no fluent API for it ;( > > >>> > > >>> Most code I've seen simply don't use the ?. chain notation > > > because > > >> it only > > >>>> works for 'navigation' use cases. Which we barely have > > > (except > > >> for > > >>>> programmatic default values, but there are perfectly valid > > > alternative > > >>>> solutions as well). > > >>>> > > >>> I think its more that many programmers still did not have really > > > worked > > >>> with Java 8. For me it sounds like "the farmer only eats what he > > >> knows". > > >>> After having worked with Java 8 for some months now, I will never > go > > > back, > > >>> if not necessary, really. > > >>> > > >>> > > >>>> Ad Functions: > > >>>> I've not yet seen a benefit in our current API. Actually the > > > only > > >> thing we > > >>>> use it for currently is to replace 2 Comparator instances. I > > > don't > > >> think > > >>>> this is something we could't do with SE7 as well ;) > > >>>> > > >>> There are several cases where it has benefits, eg the additional > > > property > > >>> function in Filter. Without Java 8 you have to create an additional > > >>> interface for it. MOst advantages beside the new abstraction > > > possibilities > > >>> are in the implementation. Several things are so much easier with > > Java > > > 8... > > >>> > > >>> Ad default methods in interfaces: > > >>>> Actually I'm not a huge fan of all those convenience functions > > > in > > >> our > > >>>> Configuration interface anyway. It just makes it harder to read. > > >>>> > > >>> SE is different than EE. You don't have CDI that helps a lot. > > >> That's a > > >>> fact as it is. I as well wish there will be more. Perhaps we get > with > > >>> Jigsaw some additional features, but I will not ask for going for > > Java > > > 9 as > > >>> a base for the API ;) > > >>> Harder to read is to some part also a matter of taste. When these > > > things > > >>> feel cumbersome, my personal reaction is, you should work more with > > > Java 8 > > >>> and you will love that you have to write less abstract classes, you > > > dont > > >>> have to expose additional singletons for accessing things and you > can > > >>> greatly help SPI implementors out of the API instead of providing > > > abstract > > >>> classes and create deps on your implementation... > > >>> > > >>> > > >>> > > >>>> What about adding either a branch or a module for java7? > > >>>> > > >>> Could be an option, as I always said. > > >>> > > >>> > > >>> > > >>> That way we could continue trying implement our core functionality > > > with > > >>>> both. And at the end of the day we do a resume and weight up the > > > pros > > >> and > > >>>> cons again. > > >>>> > > >>> No, go for 8 and provide 7 in parallel by the colleagues that wants > > > it. > > >>> Since you state it is so important for the next decade there will > be > > > people > > >>> that do the work, I assume. And don't complain if it is more work > > > than > > >>> expected, because you have to write much more code because you are > > now > > > in > > >> 7. > > >>> But again, stop doing things for an outdated Java version, when you > > > are > > >>> building an API for a future JSR from scratch. It is simply useless > > > IMO. > > >>> > > >>> > > >>> > > >>>> > > >>>> LieGrue, > > >>>> strub > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > On Friday, 2 January 2015, 14:02, Werner Keil > > >> <[email protected]> > > >>>> wrote: > > >>>> > > Romain, > > >>>> > > > >>>> > That's a good point. I flagged this with e.g. JavaMoney. > > > Given > > >> it aims > > >>>> more > > >>>> > at future platforms and e.g. java.util.Currency (or ICU4J) > > > are > > >> already > > >>>> > available for Java 7 or even 6 and before, that seemed of > > > less > > >> concern to > > >>>> > the EG or Anatole. Oracle stated, Lambdas may come to ME 8.x > > > or 9, > > >> so a > > >>>> > theoretical ME usage of the API could work in a future > > > version of > > >> Java > > >>>> > (ME), too. > > >>>> > > > >>>> > Here it's more about backward-compatibility, and looking > > > at > > >> other Apache > > >>>> > projects like DeviceMap, etc. a majority requires at most > > > Java 6 > > >> as > > >>>> minimum > > >>>> > version today. Some may have shifted to 7, but I couldn't > > > > > >> think of an > > >>>> > Apache project that was Java 8 minimum. CDI 2 plans to do > > > that, so > > >> some > > >>>> > modules in DeltaSpike could eventually graduate to CDI 2 and > > >> require > > >>>> Java > > >>>> > SE 8, but a prior version of the same projects or modules > > > will > > >> still work > > >>>> > with CDI 1.x and Java 7. > > >>>> > > > >>>> > There are a few "functional" aspects, but if you > > > need to > > >> declare a > > >>>> > "Functional Interface" that works in Java 7 and 8 > > > all > > >> you have to do > > >>>> > is > > >>>> > forget about the SE 8 annotation. It'll still work in 8 > > > if > > >> declared > > >>>> right. > > >>>> > So we might have to declare some of the interfaces without > > > the > > >>>> > @FunctionalInterface annotation (or comment it out for now) > > > and > > >> refrain > > >>>> > from reusing those Java SE 8 provides. Stubbing them out with > > > > > >> either > > >>>> config > > >>>> > specific or the same method names would be a solution. > > >>>> > > > >>>> > Optional was discussed in a hangout last night, and I > > > wasn't > > >> under the > > >>>> > impression we would have to use it in places where a simple > > >> "null > > >>>> > check" > > >>>> > also works, so that doesn't look like a Java SE 8 feature > > > to > > >> be seen as > > >>>> > mandadory or inevitable either. > > >>>> > > > >>>> > If the API was mostly portable, then some implementations or > > > > > >> modules > > >>>> could > > >>>> > be SE 8 Specific. I heard, that is somehow like Spring does > > > it, > > >> too;-) > > >>>> > > > >>>> > > > >>>> > Werner > > >>>> > > > >>>> > > > >>>> > On Fri, Jan 2, 2015 at 12:03 PM, Romain Manni-Bucau > > >>>> > <[email protected]> > > >>>> > wrote: > > >>>> > > > >>>> >> Hi guys, > > >>>> >> > > >>>> >> I know we said java 8 is good to start a project but > > > this is > > >> a blocker > > >>>> >> to make of tamaya built in config solution in project > > > bound > > >> to java 7 > > >>>> >> like JavaEE 7 containers for instance. > > >>>> >> > > >>>> >> Since Java 8 doesn't bring anything on implemtation > > > point > > >> of view we > > >>>> >> mandate/cant replace by java 7 can we rethink about it? > > >>>> >> > > >>>> >> > > >>>> >> Romain Manni-Bucau > > >>>> >> @rmannibucau > > >>>> >> http://www.tomitribe.com > > >>>> >> http://rmannibucau.wordpress.com > > >>>> >> https://github.com/rmannibucau > > >>>> >> > > >>>> > > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> *Anatole Tresch* > > >>> Java Engineer & Architect, JSR Spec Lead > > >>> Glärnischweg 10 > > >>> CH - 8620 Wetzikon > > >>> > > >>> *Switzerland, Europe Zurich, GMT+1* > > >>> *Twitter: @atsticks* > > >>> *Blogs: **http://javaremarkables.blogspot.ch/ > > >>> <http://javaremarkables.blogspot.ch/>* > > >>> > > >>> *Google: atsticksMobile +41-76 344 62 79* > > >> > > > > > > > > > -- > Otávio Gonçalves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: *http://about.me/otaviojava <http://about.me/otaviojava>* > 55 (11) 98255-3513 >
