The biggest problem with a backport is, that unless both are done in parallel if you start even after a first "milestone-incubator" release of an artifact was out, the backport is likely outdated by then. See ThreeTenBP, who with a sane mind would even use that. Either they use Java SE 8 and get it as part of the JDK or they likely used JodaTime already;-) I only saw one or two projects personally where JodaTime was actively used, but as long as those remain with Java 7 neither of them will waste their time and budget to switch to this BP before they may eventually move to Java 8.
If we have enough resources who are willing to develop these in parallel, then it could be an option, otherwise it seems like a risk. Werner On Tue, Jan 6, 2015 at 3:18 PM, Anatole Tresch <[email protected]> wrote: > 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* >
