> IMHO, the project is born and create a project without lost > some cool improvements such Lambda, stream, optional, etc.
The only thing we really used was Optional. This was really easy to get going as default method in 8 as well. Look at the code, I really didn't change much. > The Java 7 will dead on April. Hah, good joke. Oracle will not manage to hold their EOL. I expect it to be somewhen 2016 or 2017. Java8 is just not stable enough for production yet. LieGrue, strub On Wednesday, 7 January 2015, 0:05, Otávio Gonçalves de Santana <[email protected]> wrote: > > >Great!, but manager two projects with the same functions may stay difficult >with the time. >IMHO, the project is born and create a project without lost some cool >improvements such Lambda, stream, optional, etc. The Java 7 will dead on >April. The new projects such CDI 2.0, JSON-B, and another sub-components in >Java EE 8, are using the Java 8 as minimum requirement. > > >On Tue, Jan 6, 2015 at 8:52 PM, Mark Struberg <[email protected]> wrote: > >I tried to do some small tricks and it was actually really easy to implement a >java7 version and base our java8 version in backward compatible ways on it. >> >>I've pushed this to a fb-se7 branch on github. >> >>https://github.com/struberg/incubator-tamaya/tree/fb-se7 >> >> >>The idea is to basically have 2 'versions' of the spec in one go. >> >>The java7/api module provides an api which builds perfectly fine with Java7. >> >>The java8/api module is 'backward compatible' to the Java7 api and adds the >>Optional etc features on top of it. I just had to tweak it a little bit. >> >>For now I just did the API, but the impl is even less of a problem. Trying to >>check what we could reuse for the java7 impl as well. >> >> >> >>LieGrue, >>strub >> >> >> >> >> >>> On Tuesday, 6 January 2015, 15:35, Mark Struberg <[email protected]> wrote: >>> > 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* >>>> >>> >> > > > >-- > >Otávio Gonçalves de Santana > > >blog: http://otaviosantana.blogspot.com.br/ >twitter: http://twitter.com/otaviojava >site: http://about.me/otaviojava >55 (11) 98255-3513 > > > >
