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* >> >
