Sounds good, woll look at it tomorrow ;) Mark Struberg <[email protected]> schrieb am Di., 6. Jan. 2015 um 23:54:
> 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* > >> > > >
