It may leave room for interpretation, but https://jcp.org/en/jsr/detail?id=365 clearly says >The Java(TM) SE support of the spec will be based on Java(TM) SE 8.
That sounds a bit wider than saying the RI will be based on Java(TM) SE 8 to me. I know some here are in the CDI 2 EG, so to clarify whether the API "cdi-spec" has mandatory dependencies on Java SE 8 or just the RI (Weld) is up to that EG;-) We made it very clear, that JSR 363 API will support at least Java SE 6 simply because the Realtime and Embedded world has so many Long-term requirements and I know personally (as does another fellow Spec Lead who worked in another part of the same enterprise once) that a lot of critical Embedded solutions are based on Java SE 6 (Embedded or not) and will remain for many years or even decades. Also ME 8 is only compatible with SE 7, so the question of SE 8 in the API wasn't even valid to 363;-) Werner On Tue, Jan 6, 2015 at 2:46 PM, Romain Manni-Bucau <[email protected]> wrote: > CDI 2 will hopefully not mandates j8 from implementation point of > view. And pretty sure spec will finally support j7 as well. It is not > cause you support j8 features that you need it in your APIs. > > About tamaya I'd start as easy as possible and only ask the question > when we'll hit java 8 need. Today all usages we have of j8 are just to > add noise to our usages IMO > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-06 14:41 GMT+01:00 Werner Keil <[email protected]>: > > 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 > >> >> > >> > > >> >
