Hi as Gerhard mentioned Java 8 guarantees not necessarily a better API, but Java 7 makes it definitively harder! And remember the original incubation proposal says we want to create a modern and functional API. Also I would like to mention (I will mention it exactly once, since it is only one aspect of the work we plan to do here) that if we want to be part of some kind of future standards, regardless if for Java SE and/or EE, Java 8 is a precondition. Oracle will never accept an API proposal that is built on Java 7.
Adding the use case aspect does not help related to that topic, so please let that things out as of now. We have to sort out the basics first. On which Java version things are build is for me an absolute crucial decision, we cannot postpone. I did a proposal how to sort that out, still leaving a door open for Java 7 support: - * Design for the future (Java 8) and provide a (maximal) compatible backport for Java 7 once the first release is out and a majority of the team members want to do so. * So I tend to do a vote on that and see what is the outcome. Be aware also, that if we decide for Java 7, we must have to check if the existing supporters are still are on board, since the original incubation proposal was IMO clearly targeted for Java 8 (though not explicit). If we have a decision here, I hope we can start to focus on the problems we want to solve (aka use cases and requirements). WDYT? -Anatole 2014-11-29 20:00 GMT+01:00 Gerhard Petracek <[email protected]>: > imo we should focus on the api first. using java 8 is no guarantee to get a > better api. > > as mentioned in a previous thread, we need to re-visit the existing parts > anyway. > e.g. at deltaspike it was quite challenging to merge the existing > approaches until we switched to an use-case based procedure. > we started to write tests to reflect the different use-cases starting with > the most trivial one. > that increases the test-coverage and users can have a look at those tests > to see the usage of the different parts. > furthermore, it ensures that more advanced use-cases won't impact simpler > uses-cases. > in the test-suite we use packages which follow the following format: > [project-package].[area].uc[number]. > the use-case numbers don't reflect the priority, however, usually the lower > numbers reflect the most common usages. > > i would prefer to try such an approach also for tamaya. it might be a bit > more time-consuming, but we can do everything step-by-step. > moreover, we don't start with random discussions. even if we would end up > with almost no api-changes (which i don't expect), we would get a nice > test-coverage at the end. > > regards, > gerhard > > > > 2014-11-29 11:42 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > I still think api is broken (access shouldnt be static like that, maybe > we > > can take inspiration from jcache), default method just shows api should > be > > split in 2 interfaces (provider and analyzer maybe?) etc... > > > > If solution is commons configuration and tamaya reason is j8 then why > > creating a new project? > > Le 29 nov. 2014 11:32, "Anatole Tresch" <[email protected]> a écrit : > > > > > Dear all > > > > > > I miserably failed to send you feedback on the Java 8 topic due to the > > f... > > > spam checks: > > > > > > - in html > > > - linked to Google Docs > > > - as PDF > > > - as link to the blog > > > > > > I now published a blog on it at: > > > javaeeconfig.blogspot.com/2014/11/configapi-java-7-vs-java-8.html > > > > > > Hope you can read it ;) > > > > > > Cheers, > > > Anatole > > > > > > PS: Can please anybody change this spam levels here for the dev list - > I > > do > > > not want to happen such a mess once more! > > > > > > -- *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*
