+1 Le 6 janv. 2015 19:36, "Anatole Tresch" <[email protected]> a écrit :
> I think the best will be to setup a Google form on this topic. If we agree > on its content, we can spread it through Twitter and our SE, EE expert > community and see what is the outcome... > Werner Keil <[email protected]> schrieb am Di., 6. Jan. 2015 um 18:37: > > > Ideally while a bit biased (by JUGs although I think the more EE centric > > ones probably care much less about SE 8 yet;-) there you should try a > > realistic survey of how many participants, their clients/companies or > > projects have fully switched to Java SE 8 yet, how many would do if a > Java > > 6/7 app has a strong configuration need and how many can't afford that > for > > whatever reason;-) > > > > I'll submit something for CodeMotion, if accepted I probably won't make > it > > to JL this year as mentioned, otherwise let's see. > > Are all of you doing talks there or some sent by their companies? (I know > > for either JBoss or Tomitribe it is quite likely they have a sponsor > > package;-) > > Seen something on Mark doing a talk and of course Anatole. > > > > The JCP EC has a rather concrete plan now to meet before DevoXX UK. So EC > > Members including former Apache rep Geir Magnusson (I assume either his > > company sends him there or he might get support by Oracle) should be at > the > > F2F and many sound like they are eager to stay for an Adopt-a-JSR Summit, > > too. This is no JSR of course, but if there's a Hackergarten at DevoXX UK > > it might be another opportunity. Possibly colliding with a Hackergarten > > Nuremberg, but in a larger project maybe not everyone will speak at > DevoXX > > UK or go there anyway?;-) > > > > Werner > > > > On Tue, Jan 6, 2015 at 5:36 PM, Anatole Tresch <[email protected]> > wrote: > > > > > 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* > > > > > >
