Saw some changes about java7 in a dedicated module, any planned moves from current impl to j7 and then just add what is missing in j8 module? Then serious things can start.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-07 0:18 GMT+01:00 Romain Manni-Bucau <[email protected]>: > 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
