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