As Java CDI 2 and EE 8 (some or all of its components will require Java SE 8 as prerequisite) have just started, none of them even produced an EDR, I would also prefer starting with Java (EE) 7 for now.
If there are official releases during the incubator these allow the use with stable, official and (Java EE 6 or 7) certified containers rather than just an RI or even preview and Beta containers. Let's see, how much it takes to graduate, maybe if Java EE 8 or CDI 2 are also final or close to final, we could always switch to Java 8 then. For a pure SE 8 standalone library like JavaMoney it may be worth starting with SE 8, but Tamaya aims at Enterprise containers "first" so we should stick to the final Enterprise standards IMHO not the next version that's not going to be final till 2016/17. Werner On Tue, Jan 6, 2015 at 2:26 PM, Mark Struberg <[email protected]> wrote: > 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 > > > - CON > * not backward compatible > * blocks adoption in current containers > * blocks adoption in many user projects > * we actually don't really need any of it's features > > > 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... > > > > 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()) {..} > > 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). > > > > 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 ;) > > > > 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. > > > > What about adding either a branch or a module for java7? > > 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. > > 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 > >> > > >
