I can agree with that, because - we focus on the API (we still are not finished) - we work on the implementation - we build and design for the future
AND - we provide support for Java 7, by backporting it. But backporting for me is crucial. By forward-porting we import all the Java 7 API style, we would not want to have in a clean Java 8 solution... I am quite sure I will be able to provide a Java 7 backport within one evening with my hackergarten colleagues... 2015-01-06 15:34 GMT+01:00 Mark Struberg <[email protected]>: > 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* > > > -- *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*
