Btw. it partly relates to the Configuration.current() discussion, as designing a static (and default) method on an interface Configuration makes a fully compliant "drop in" backport nearly impossible.
We have a small number of RI level interfaces in JSR 363 and while it's a no-go for the API (which must work as far back as at least to Java SE 6 Embedded, in theory a LTS customer could even use it with Java 5 as of now) to put something like Unit.of() there, the Measurement interface can have this in the Java SE (8) port, but for the Reference Implementation the same method would only work in an abstract base class like AbstractMeasurement or another class. CDI is a class, so in a Java 7 or 6+ backport one would have to add current() to a concrete class implementing Configuration, not the actual interface. Same for the default implementation. Werner On Wed, Jan 7, 2015 at 11:56 AM, Werner Keil <[email protected]> wrote: > I'd rather say that's for Java 6;-D > See http://www.oracle.com/technetwork/java/eol-135779.html > What matters to most big customers would be the "Extended Support" and it > earns Oracle some money, too;-) > As you can see Java 5 ends its Extended Support this May, Java 6 won't > till the next World Cup (likely in Russia;-) and Java 7 still gets this > support level till the World Cup 2022 in Qatar. > > Among the reasons why we support the broadest range possible in the JSR > 363 API, especially in the Embedded sector where companies "bake" Java > Embedded into devices they send to Alaska, Fukushima or the bottom of the > ocean (see James Gosling's company;-) and rarely have access to them or > bother upgrading before they really have to or the customer reports a > problem with the solution. > > Werner > > On Wed, Jan 7, 2015 at 12:15 AM, Mark Struberg <[email protected]> wrote: > >> > IMHO, the project is born and create a project without lost >> >> > some cool improvements such Lambda, stream, optional, etc. >> >> The only thing we really used was Optional. This was really easy to get >> going as default method in 8 as well. Look at the code, I really didn't >> change much. >> >> >> > The Java 7 will dead on April. >> >> Hah, good joke. Oracle will not manage to hold their EOL. I expect it to >> be somewhen 2016 or 2017. >> >> Java8 is just not stable enough for production yet. >> >> >> >> LieGrue, >> strub >> >> >> >> On Wednesday, 7 January 2015, 0:05, Otávio Gonçalves de Santana < >> [email protected]> wrote: >> > >> > >> >Great!, but manager two projects with the same functions may stay >> difficult with the time. >> >IMHO, the project is born and create a project without lost some cool >> improvements such Lambda, stream, optional, etc. The Java 7 will dead on >> April. The new projects such CDI 2.0, JSON-B, and another sub-components in >> Java EE 8, are using the Java 8 as minimum requirement. >> > >> > >> >On Tue, Jan 6, 2015 at 8:52 PM, Mark Struberg <[email protected]> wrote: >> > >> >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* >> >>>> >> >>> >> >> >> > >> > >> > >> >-- >> > >> >Otávio Gonçalves de Santana >> > >> > >> >blog: http://otaviosantana.blogspot.com.br/ >> >twitter: http://twitter.com/otaviojava >> >site: http://about.me/otaviojava >> >55 (11) 98255-3513 >> > >> > >> > >> > >> > >
