Hi Mark fair enough, I am aware of that. Some of my colleagues already signed the ICLA and are a member of the project. The others will either be, or I will add the patch. So this should be fine so far.
I am curious how many will join after the next Hackergarten, since the interest was quite high and we are getting a real nice and small solution here, so probably many of them will help us improving things as well... 2015-01-06 17:28 GMT+01:00 Mark Struberg <[email protected]>: > > 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* > > > -- *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*
