> I am quite sure I will be able to provide a Java 7 backport within one > evening with my hackergarten colleagues...
Hackergarten is always nice. But please forget that in that case we would need an iCLA [1] on file for each of them. Or if the change is trivial the respective author of each change could also add it as patch to our JIRA [2]. In any case you must not commit stuff to any Apache SCM which you didn't write yourself and we don't have any written grant [3] (thus the JIRA patch). For multi author work we need a grant + an IP clearance [4]. This might sound like a bureaucratic burden but it is there for a good reason. Oracle vs Google anyone? The ASF simply doesn't like to get sued ;) LieGrue, strub [1] http://www.apache.org/licenses/icla.txt [2] https://issues.apache.org/jira/browse/TAMAYA [3] http://apache.org/licenses/software-grant.txt [4] http://incubator.apache.org/ip-clearance/ip-clearance-template.html > On Tuesday, 6 January 2015, 15:55, Anatole Tresch <[email protected]> wrote: > > 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* >
