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* > > >
