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*
