You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Anatole Tresch <an...@apache.org> on 2014/11/29 11:31:13 UTC
Java 8
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!
Re: Java 8
Posted by Gerhard Petracek <ge...@gmail.com>.
we could change that over time and start e.g. with anatole.
regards,
gerhard
2014-11-29 20:12 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> +1 Who drives it?
> Le 29 nov. 2014 20:02, "Gerhard Petracek" <ge...@gmail.com> a
> écrit :
>
> > 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 <rm...@gmail.com>:
> >
> > > 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" <an...@apache.org> 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!
> > > >
> > >
> >
>
Re: Java 8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 Who drives it?
Le 29 nov. 2014 20:02, "Gerhard Petracek" <ge...@gmail.com> a
écrit :
> 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 <rm...@gmail.com>:
>
> > 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" <an...@apache.org> 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!
> > >
> >
>
Re: Java 8
Posted by Anatole Tresch <at...@gmail.com>.
@Gerhard
fair enough. My opinion on the topic is now well known ;)
This will change with EE8. It is different, SE 8 is a real major release of
the platform similar to SE 4 to 5 which has impact on how you build things.
CDI 2.0 will be based on Java 8 features for sure as well alss the other EE
8 JSRs ;)
Best
Anatole
2014-11-29 22:44 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @anatole:
> with my comment i haven't favoured one.
> my point was that the version of java shouldn't be the central question.
> let's just start to discuss the api based on use-cases and we can do
> whatever is needed to get a concise and powerful api.
>
> @specs. - just fyi:
> e.g. cdi built on top of java 6 features, however, owb as well as weld
> supported java 5.
> in case of other specs. (e.g. jsf) it's similar.
>
> regards,
> gerhard
>
>
>
> 2014-11-29 22:11 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> > Let speak about the api. Well decide after when complete in terms of
> > feature/design. If we can stay j7 great otherwise if we have real reasons
> > it is good as well.
> > Le 29 nov. 2014 22:00, "Anatole Tresch" <at...@gmail.com> a écrit :
> >
> > > 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 <
> gerhard.petracek@gmail.com
> > >:
> > >
> > > > 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 <rmannibucau@gmail.com
> >:
> > > >
> > > > > 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" <an...@apache.org> 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*
> > >
> >
>
--
*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*
Re: Java 8
Posted by Gerhard Petracek <ge...@gmail.com>.
@anatole:
with my comment i haven't favoured one.
my point was that the version of java shouldn't be the central question.
let's just start to discuss the api based on use-cases and we can do
whatever is needed to get a concise and powerful api.
@specs. - just fyi:
e.g. cdi built on top of java 6 features, however, owb as well as weld
supported java 5.
in case of other specs. (e.g. jsf) it's similar.
regards,
gerhard
2014-11-29 22:11 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Let speak about the api. Well decide after when complete in terms of
> feature/design. If we can stay j7 great otherwise if we have real reasons
> it is good as well.
> Le 29 nov. 2014 22:00, "Anatole Tresch" <at...@gmail.com> a écrit :
>
> > 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 <gerhard.petracek@gmail.com
> >:
> >
> > > 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 <rm...@gmail.com>:
> > >
> > > > 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" <an...@apache.org> 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*
> >
>
Re: Java 8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Let speak about the api. Well decide after when complete in terms of
feature/design. If we can stay j7 great otherwise if we have real reasons
it is good as well.
Le 29 nov. 2014 22:00, "Anatole Tresch" <at...@gmail.com> a écrit :
> 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 <ge...@gmail.com>:
>
> > 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 <rm...@gmail.com>:
> >
> > > 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" <an...@apache.org> 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*
>
Re: Java 8
Posted by Anatole Tresch <at...@gmail.com>.
Yes. Hopefully we can now focus on the use cases...
2014-11-29 22:52 GMT+01:00 Andres Almiray <aa...@gmail.com>:
> Whar about this: let's continue in the JDK8 route and ser how far the new
> syntax and APIs can take us. It may be the case that after exploration we
> discover JDK8 holds little to no advantages to Tamaya's cause OR (as I have
> high hopes) JDK8 is instrumental to Tamaya's success.
>
> Bottom line is we wont be able to tell which path is best if we don't try
> JDK8.
>
> Sent from my primitive Tricorder
>
> > On 29/11/2014, at 21:58, Anatole Tresch <at...@gmail.com> wrote:
> >
> > 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 <gerhard.petracek@gmail.com
> >:
> >
> >> 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 <rm...@gmail.com>:
> >>
> >>> 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" <an...@apache.org> 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*
>
--
*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*
Re: Java 8
Posted by Anatole Tresch <an...@apache.org>.
Yep, I am already working on it...
2014-11-29 23:15 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> @anatole:
> it would be nice if you can select the simplest and most central use-case,
> push a test for it and start an own "[DISCUSS] ..." thread on this list.
>
> regards,
> gerhard
>
>
>
> 2014-11-29 23:00 GMT+01:00 John D. Ament <jo...@apache.org>:
>
> > Makes sense to me. +1
> >
> > On Sat, Nov 29, 2014, 16:53 Andres Almiray <aa...@gmail.com> wrote:
> >
> > > Whar about this: let's continue in the JDK8 route and ser how far the
> new
> > > syntax and APIs can take us. It may be the case that after exploration
> we
> > > discover JDK8 holds little to no advantages to Tamaya's cause OR (as I
> > have
> > > high hopes) JDK8 is instrumental to Tamaya's success.
> > >
> > > Bottom line is we wont be able to tell which path is best if we don't
> try
> > > JDK8.
> > >
> > > Sent from my primitive Tricorder
> > >
> > > > On 29/11/2014, at 21:58, Anatole Tresch <at...@gmail.com> wrote:
> > > >
> > > > 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 <
> > gerhard.petracek@gmail.com
> > > >:
> > > >
> > > >> 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 <
> rmannibucau@gmail.com
> > >:
> > > >>
> > > >>> 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" <an...@apache.org> 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*
> > >
> >
>
Re: Java 8
Posted by Gerhard Petracek <ge...@gmail.com>.
@anatole:
it would be nice if you can select the simplest and most central use-case,
push a test for it and start an own "[DISCUSS] ..." thread on this list.
regards,
gerhard
2014-11-29 23:00 GMT+01:00 John D. Ament <jo...@apache.org>:
> Makes sense to me. +1
>
> On Sat, Nov 29, 2014, 16:53 Andres Almiray <aa...@gmail.com> wrote:
>
> > Whar about this: let's continue in the JDK8 route and ser how far the new
> > syntax and APIs can take us. It may be the case that after exploration we
> > discover JDK8 holds little to no advantages to Tamaya's cause OR (as I
> have
> > high hopes) JDK8 is instrumental to Tamaya's success.
> >
> > Bottom line is we wont be able to tell which path is best if we don't try
> > JDK8.
> >
> > Sent from my primitive Tricorder
> >
> > > On 29/11/2014, at 21:58, Anatole Tresch <at...@gmail.com> wrote:
> > >
> > > 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 <
> gerhard.petracek@gmail.com
> > >:
> > >
> > >> 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 <rmannibucau@gmail.com
> >:
> > >>
> > >>> 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" <an...@apache.org> 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*
> >
>
Re: Java 8
Posted by "John D. Ament" <jo...@apache.org>.
Makes sense to me. +1
On Sat, Nov 29, 2014, 16:53 Andres Almiray <aa...@gmail.com> wrote:
> Whar about this: let's continue in the JDK8 route and ser how far the new
> syntax and APIs can take us. It may be the case that after exploration we
> discover JDK8 holds little to no advantages to Tamaya's cause OR (as I have
> high hopes) JDK8 is instrumental to Tamaya's success.
>
> Bottom line is we wont be able to tell which path is best if we don't try
> JDK8.
>
> Sent from my primitive Tricorder
>
> > On 29/11/2014, at 21:58, Anatole Tresch <at...@gmail.com> wrote:
> >
> > 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 <gerhard.petracek@gmail.com
> >:
> >
> >> 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 <rm...@gmail.com>:
> >>
> >>> 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" <an...@apache.org> 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*
>
Re: Java 8
Posted by Andres Almiray <aa...@gmail.com>.
Whar about this: let's continue in the JDK8 route and ser how far the new syntax and APIs can take us. It may be the case that after exploration we discover JDK8 holds little to no advantages to Tamaya's cause OR (as I have high hopes) JDK8 is instrumental to Tamaya's success.
Bottom line is we wont be able to tell which path is best if we don't try JDK8.
Sent from my primitive Tricorder
> On 29/11/2014, at 21:58, Anatole Tresch <at...@gmail.com> wrote:
>
> 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 <ge...@gmail.com>:
>
>> 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 <rm...@gmail.com>:
>>
>>> 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" <an...@apache.org> 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*
Re: Java 8
Posted by Anatole Tresch <at...@gmail.com>.
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 <ge...@gmail.com>:
> 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 <rm...@gmail.com>:
>
> > 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" <an...@apache.org> 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*
Re: Java 8
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <rm...@gmail.com>:
> 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" <an...@apache.org> 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!
> >
>
Re: Java 8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <an...@apache.org> 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!
>