You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@gmail.com> on 2017/02/27 13:08:47 UTC
[PROPOSAL] Remove java 7 support
Hi all,
I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
remove support for using Java 7 when running Brooklyn).
This will make our testing simpler, improving coverage (e.g. we don't
currently test everything with Brooklyn running both on Java 7 and Java
8). It will make our lives easier as developers (e.g. don't need to
worry about Java 7 versus Java 8 when compiling, running tests and
manually testing Brooklyn; and we can use Java 8 features).
Java 7 reached end of life in April 2015 [1]; Java 8 was released March
2014.
We can do this in three stages:
* Switch to Java 8 as "official target"
o Update our jenkins etc to always build/run with Java 8.
o All developers/testers switch to Java 8 locally.
o Add to the next release notes that Java 7 is no longer supported.
* Update our poms so they don't compile/check for Java 7 compatibility
[3,4,5].
* Developers free to start using Java 8 language features!
Stage 1 would be the bare minimum for the next release; I think we
should do all three stages before the 0.11.0 release.
Aled
[1] https://java.com/en/download/faq/java_7.xml
[2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
[3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
[4]
https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
[5]
https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
Re: [PROPOSAL] Remove java 7 support
Posted by Valentin Aitken <va...@cloudsoftcorp.com>.
+1.
However because of intense usage of Lambdas in Java 8, we should bring
up guide lines for writing persistable code [1]
and elaborate more on the paragraph from [1]
"Never use anonymous inner classes - even in static contexts. The
auto-generated class names are brittle, making backwards compatibility
harder.".
The above is especially true for config values.
Valentin.
[1]
https://brooklyn.apache.org/v/latest/ops/persistence/index.html#writing-persistable-code
\u041d\u0430 27/02/17 \u0432 16:06, Thomas Bouron \u043d\u0430\u043f\u0438\u0441\u0430:
> Like the others: +1
>
> On Mon, 27 Feb 2017 at 13:47 Mark Mc Kenna <m4...@gmail.com> wrote:
>
>> +1
>>
>> *Mark McKenna*
>>
>> *Web :: markmckenna.ie <http://markmckenna.ie/>*
>>
>> *Work :: mark.mckenna@cloudsoft.io <ma...@cloudsoft.io>*
>>
>> *PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
>> <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>*
>>
>> On 27 February 2017 at 13:42, Andrea Turli <andrea.turli@cloudsoftcorp.com
>> wrote:
>>
>>> +1
>>>
>>> Il 27/feb/2017 14:35, "Geoff Macartney" <
>> geoff.macartney@cloudsoftcorp.com
>>> ha scritto:
>>>
>>>> +1
>>>>
>>>> I have been hoping we could get round to this soon, think it's a good
>>> idea.
>>>>
>>>>
>>>> On Mon, 27 Feb 2017 at 13:09 Aled Sage <al...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java
>> 8;
>>>>> remove support for using Java 7 when running Brooklyn).
>>>>>
>>>>> This will make our testing simpler, improving coverage (e.g. we don't
>>>>> currently test everything with Brooklyn running both on Java 7 and
>> Java
>>>>> 8). It will make our lives easier as developers (e.g. don't need to
>>>>> worry about Java 7 versus Java 8 when compiling, running tests and
>>>>> manually testing Brooklyn; and we can use Java 8 features).
>>>>>
>>>>> Java 7 reached end of life in April 2015 [1]; Java 8 was released
>> March
>>>>> 2014.
>>>>>
>>>>> We can do this in three stages:
>>>>>
>>>>> * Switch to Java 8 as "official target"
>>>>> o Update our jenkins etc to always build/run with Java 8.
>>>>> o All developers/testers switch to Java 8 locally.
>>>>> o Add to the next release notes that Java 7 is no longer
>>> supported.
>>>>> * Update our poms so they don't compile/check for Java 7
>>> compatibility
>>>>> [3,4,5].
>>>>> * Developers free to start using Java 8 language features!
>>>>>
>>>>> Stage 1 would be the bare minimum for the next release; I think we
>>>>> should do all three stages before the 0.11.0 release.
>>>>>
>>>>> Aled
>>>>>
>>>>> [1] https://java.com/en/download/faq/java_7.xml
>>>>> [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-
>>> 7Public-Updates
>>>>> [3]
>> https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
>>>>> [4]
>>>>>
>>>>> https://github.com/apache/brooklyn-server/blob/master/
>>>> parent/pom.xml#L557-L558
>>>>> [5]
>>>>> https://github.com/apache/brooklyn-server/blob/master/
>>>> parent/pom.xml#L950
>>>>>
--
Valentin Aitken
Software Engineer
Cloudsoft Corporation Ltd.
www.cloudsoft.io
Re: [PROPOSAL] Remove java 7 support
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
Like the others: +1
On Mon, 27 Feb 2017 at 13:47 Mark Mc Kenna <m4...@gmail.com> wrote:
> +1
>
> *Mark McKenna*
>
> *Web :: markmckenna.ie <http://markmckenna.ie/>*
>
> *Work :: mark.mckenna@cloudsoft.io <ma...@cloudsoft.io>*
>
> *PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
> <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>*
>
> On 27 February 2017 at 13:42, Andrea Turli <andrea.turli@cloudsoftcorp.com
> >
> wrote:
>
> > +1
> >
> > Il 27/feb/2017 14:35, "Geoff Macartney" <
> geoff.macartney@cloudsoftcorp.com
> > >
> > ha scritto:
> >
> > > +1
> > >
> > > I have been hoping we could get round to this soon, think it's a good
> > idea.
> > >
> > >
> > >
> > > On Mon, 27 Feb 2017 at 13:09 Aled Sage <al...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java
> 8;
> > > > remove support for using Java 7 when running Brooklyn).
> > > >
> > > > This will make our testing simpler, improving coverage (e.g. we don't
> > > > currently test everything with Brooklyn running both on Java 7 and
> Java
> > > > 8). It will make our lives easier as developers (e.g. don't need to
> > > > worry about Java 7 versus Java 8 when compiling, running tests and
> > > > manually testing Brooklyn; and we can use Java 8 features).
> > > >
> > > > Java 7 reached end of life in April 2015 [1]; Java 8 was released
> March
> > > > 2014.
> > > >
> > > > We can do this in three stages:
> > > >
> > > > * Switch to Java 8 as "official target"
> > > > o Update our jenkins etc to always build/run with Java 8.
> > > > o All developers/testers switch to Java 8 locally.
> > > > o Add to the next release notes that Java 7 is no longer
> > supported.
> > > > * Update our poms so they don't compile/check for Java 7
> > compatibility
> > > > [3,4,5].
> > > > * Developers free to start using Java 8 language features!
> > > >
> > > > Stage 1 would be the bare minimum for the next release; I think we
> > > > should do all three stages before the 0.11.0 release.
> > > >
> > > > Aled
> > > >
> > > > [1] https://java.com/en/download/faq/java_7.xml
> > > > [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-
> > 7Public-Updates
> > > > [3]
> https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> > > > [4]
> > > >
> > > > https://github.com/apache/brooklyn-server/blob/master/
> > > parent/pom.xml#L557-L558
> > > > [5]
> > > > https://github.com/apache/brooklyn-server/blob/master/
> > > parent/pom.xml#L950
> > > >
> > > >
> > >
> >
>
--
Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
http://www.cloudsoftcorp.com/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron
Re: [PROPOSAL] Remove java 7 support
Posted by Mark Mc Kenna <m4...@gmail.com>.
+1
*Mark McKenna*
*Web :: markmckenna.ie <http://markmckenna.ie/>*
*Work :: mark.mckenna@cloudsoft.io <ma...@cloudsoft.io>*
*PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
<https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>*
On 27 February 2017 at 13:42, Andrea Turli <an...@cloudsoftcorp.com>
wrote:
> +1
>
> Il 27/feb/2017 14:35, "Geoff Macartney" <geoff.macartney@cloudsoftcorp.com
> >
> ha scritto:
>
> > +1
> >
> > I have been hoping we could get round to this soon, think it's a good
> idea.
> >
> >
> >
> > On Mon, 27 Feb 2017 at 13:09 Aled Sage <al...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
> > > remove support for using Java 7 when running Brooklyn).
> > >
> > > This will make our testing simpler, improving coverage (e.g. we don't
> > > currently test everything with Brooklyn running both on Java 7 and Java
> > > 8). It will make our lives easier as developers (e.g. don't need to
> > > worry about Java 7 versus Java 8 when compiling, running tests and
> > > manually testing Brooklyn; and we can use Java 8 features).
> > >
> > > Java 7 reached end of life in April 2015 [1]; Java 8 was released March
> > > 2014.
> > >
> > > We can do this in three stages:
> > >
> > > * Switch to Java 8 as "official target"
> > > o Update our jenkins etc to always build/run with Java 8.
> > > o All developers/testers switch to Java 8 locally.
> > > o Add to the next release notes that Java 7 is no longer
> supported.
> > > * Update our poms so they don't compile/check for Java 7
> compatibility
> > > [3,4,5].
> > > * Developers free to start using Java 8 language features!
> > >
> > > Stage 1 would be the bare minimum for the next release; I think we
> > > should do all three stages before the 0.11.0 release.
> > >
> > > Aled
> > >
> > > [1] https://java.com/en/download/faq/java_7.xml
> > > [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-
> 7Public-Updates
> > > [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> > > [4]
> > >
> > > https://github.com/apache/brooklyn-server/blob/master/
> > parent/pom.xml#L557-L558
> > > [5]
> > > https://github.com/apache/brooklyn-server/blob/master/
> > parent/pom.xml#L950
> > >
> > >
> >
>
Re: [PROPOSAL] Remove java 7 support
Posted by Andrea Turli <an...@cloudsoftcorp.com>.
+1
Il 27/feb/2017 14:35, "Geoff Macartney" <ge...@cloudsoftcorp.com>
ha scritto:
> +1
>
> I have been hoping we could get round to this soon, think it's a good idea.
>
>
>
> On Mon, 27 Feb 2017 at 13:09 Aled Sage <al...@gmail.com> wrote:
>
> > Hi all,
> >
> > I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
> > remove support for using Java 7 when running Brooklyn).
> >
> > This will make our testing simpler, improving coverage (e.g. we don't
> > currently test everything with Brooklyn running both on Java 7 and Java
> > 8). It will make our lives easier as developers (e.g. don't need to
> > worry about Java 7 versus Java 8 when compiling, running tests and
> > manually testing Brooklyn; and we can use Java 8 features).
> >
> > Java 7 reached end of life in April 2015 [1]; Java 8 was released March
> > 2014.
> >
> > We can do this in three stages:
> >
> > * Switch to Java 8 as "official target"
> > o Update our jenkins etc to always build/run with Java 8.
> > o All developers/testers switch to Java 8 locally.
> > o Add to the next release notes that Java 7 is no longer supported.
> > * Update our poms so they don't compile/check for Java 7 compatibility
> > [3,4,5].
> > * Developers free to start using Java 8 language features!
> >
> > Stage 1 would be the bare minimum for the next release; I think we
> > should do all three stages before the 0.11.0 release.
> >
> > Aled
> >
> > [1] https://java.com/en/download/faq/java_7.xml
> > [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
> > [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> > [4]
> >
> > https://github.com/apache/brooklyn-server/blob/master/
> parent/pom.xml#L557-L558
> > [5]
> > https://github.com/apache/brooklyn-server/blob/master/
> parent/pom.xml#L950
> >
> >
>
Re: [PROPOSAL] Remove java 7 support
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
+1
I have been hoping we could get round to this soon, think it's a good idea.
On Mon, 27 Feb 2017 at 13:09 Aled Sage <al...@gmail.com> wrote:
> Hi all,
>
> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
> remove support for using Java 7 when running Brooklyn).
>
> This will make our testing simpler, improving coverage (e.g. we don't
> currently test everything with Brooklyn running both on Java 7 and Java
> 8). It will make our lives easier as developers (e.g. don't need to
> worry about Java 7 versus Java 8 when compiling, running tests and
> manually testing Brooklyn; and we can use Java 8 features).
>
> Java 7 reached end of life in April 2015 [1]; Java 8 was released March
> 2014.
>
> We can do this in three stages:
>
> * Switch to Java 8 as "official target"
> o Update our jenkins etc to always build/run with Java 8.
> o All developers/testers switch to Java 8 locally.
> o Add to the next release notes that Java 7 is no longer supported.
> * Update our poms so they don't compile/check for Java 7 compatibility
> [3,4,5].
> * Developers free to start using Java 8 language features!
>
> Stage 1 would be the bare minimum for the next release; I think we
> should do all three stages before the 0.11.0 release.
>
> Aled
>
> [1] https://java.com/en/download/faq/java_7.xml
> [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
> [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> [4]
>
> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
> [5]
> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
>
>
Re: [PROPOSAL] Remove java 7 support
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
hi all,
I have put in a couple of pull requests to switch to Java 8:
https://github.com/apache/brooklyn-server/pull/684
https://github.com/apache/brooklyn-ui/pull/44
hopefully some of you can get the chance to fetch and test this out.
regards
Geoff
On Fri, 12 May 2017 at 13:10 Aled Sage <al...@gmail.com> wrote:
> Thanks Geoff, much appreciated!
>
> Sent from my iPhone
>
>
> > On 12 May 2017, at 10:41, Geoff Macartney <
> geoff.macartney@cloudsoftcorp.com> wrote:
> >
> > hi all,
> >
> > just picking up this thread again; as mailed back in March (!) [1] our
> > Jenkins builds are now using Java 8.
> >
> > Has everyone switched to Java 8 and is it now time to update Brooklyn to
> > build with 8 rather than 7?
> >
> > If no-one objects, I'll try to get some time to do this later next week.
> >
> > regards
> > Geoff
> >
> >
> > [1]
> >
> https://lists.apache.org/thread.html/6d50d242d1ed8e98776eb871c397de1aac06d3baf600edecc53415ff@%3Cdev.brooklyn.apache.org%3E
> >
> > On Mon, 6 Mar 2017 at 19:48 Geoff Macartney <
> > geoff.macartney@cloudsoftcorp.com> wrote:
> >
> >> hi Aled,
> >>
> >> sure, I'll have a look at that.
> >>
> >> cheers
> >> Geoff
> >>
> >>> On Mon, 6 Mar 2017 at 18:26 Aled Sage <al...@gmail.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> There have been six +1s (including myself) and no negatives, so let's
> do
> >>> this.
> >>>
> >>> ---
> >>>
> >>> For Robert's question, I did some investigation for use of lambdas as
> >>> config key values. They don't persist correctly unfortunately [1], so
> we
> >>> shouldn't use them anywhere that could end up in persisted state.
> >>>
> >>> ---
> >>>
> >>> I suggest we separate this into multiple stages (and ensure that
> >>> discussion of later stages does not block the earlier stages):
> >>>
> >>> * Stage one: switch to Java 8 as "official target"
> >>> 1. Update our jenkins etc to always build/run with Java 8.
> >>> 2. All developers/testers switch to Java 8 locally.
> >>> 3. Add to the next release notes that Java 7 is no longer
> supported.
> >>> * Stage two: update our poms so they don't compile/check for Java 7
> >>> compatibility [2,3,4].
> >>> * Stage three: update our docs to say not to use lambdas for config
> >>> keys (similar to what we already say for anonyous inner classes [5])
> >>> * Stage four: developers free to use Java 8 language features *where
> >>> it does not affect APIs or end up in persisted state*
> >>> * Stage five: discuss/improve use of Java 8 (e.g. perhaps fix [1];
> >>> should we keep using guava classes that are now in Java 8's
> >>> java.util.function.* ?)
> >>>
> >>> ---
> >>>
> >>> Geoff: if you're volunteering, it would be awesome if you could pick up
> >>> stage 1.1 (and then stage 2).
> >>>
> >>> Aled
> >>>
> >>> [1] https://issues.apache.org/jira/browse/BROOKLYN-448
> >>> [2] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> >>> [3]
> >>>
> >>>
> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
> >>> [4]
> >>>
> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
> >>> [5]
> >>>
> >>>
> https://brooklyn.apache.org/v/latest/ops/persistence/index.html#writing-persistable-code
> >>>
> >>>
> >>>> On 06/03/2017 14:35, Geoff Macartney wrote:
> >>>> hi all,
> >>>>
> >>>> any more thoughts on this? What concrete steps do we want to take,
> and
> >>>> when? What can I do to help out?
> >>>>
> >>>> Plus, has anyone any views on Robert's question?
> >>>>
> >>>> cheers
> >>>> Geoff
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, 27 Feb 2017 at 14:21 Robert Moss <ro...@cloudsoft.io>
> >>> wrote:
> >>>>
> >>>>> Aled,
> >>>>>
> >>>>> WRT Java 8 features. Is it still recommended to use named inner
> >>> classes
> >>>>> over anonymous inner classes? Can we now simplify those areas to use
> >>>>> lambdas? There are a number of classes now built into Java that were
> >>>>> previously provided by Guava etc. e.g. Optional, Predicate - should
> we
> >>>>> start using the Java 8 classes instead where possible?
> >>>>>
> >>>>> Robert
> >>>>>
> >>>>>> On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java
> >>> 8;
> >>>>>> remove support for using Java 7 when running Brooklyn).
> >>>>>>
> >>>>>> This will make our testing simpler, improving coverage (e.g. we
> don't
> >>>>>> currently test everything with Brooklyn running both on Java 7 and
> >>> Java
> >>>>> 8).
> >>>>>> It will make our lives easier as developers (e.g. don't need to
> worry
> >>>>> about
> >>>>>> Java 7 versus Java 8 when compiling, running tests and manually
> >>> testing
> >>>>>> Brooklyn; and we can use Java 8 features).
> >>>>>>
> >>>>>> Java 7 reached end of life in April 2015 [1]; Java 8 was released
> >>> March
> >>>>>> 2014.
> >>>>>>
> >>>>>> We can do this in three stages:
> >>>>>>
> >>>>>> * Switch to Java 8 as "official target"
> >>>>>> o Update our jenkins etc to always build/run with Java 8.
> >>>>>> o All developers/testers switch to Java 8 locally.
> >>>>>> o Add to the next release notes that Java 7 is no longer
> >>> supported.
> >>>>>> * Update our poms so they don't compile/check for Java 7
> >>> compatibility
> >>>>>> [3,4,5].
> >>>>>> * Developers free to start using Java 8 language features!
> >>>>>>
> >>>>>> Stage 1 would be the bare minimum for the next release; I think we
> >>> should
> >>>>>> do all three stages before the 0.11.0 release.
> >>>>>>
> >>>>>> Aled
> >>>>>>
> >>>>>> [1] https://java.com/en/download/faq/java_7.xml
> >>>>>> [2]
> >>> https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
> >>>>>> [3]
> https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> >>>>>> [4] https://github.com/apache/brooklyn-server/blob/master/parent
> >>>>>> /pom.xml#L557-L558
> >>>>>> [5] https://github.com/apache/brooklyn-server/blob/master/parent
> >>>>>> /pom.xml#L950
> >>>>>>
> >>>>>>
> >>>
> >>>
>
Re: [PROPOSAL] Remove java 7 support
Posted by Aled Sage <al...@gmail.com>.
Thanks Geoff, much appreciated!
Sent from my iPhone
> On 12 May 2017, at 10:41, Geoff Macartney <ge...@cloudsoftcorp.com> wrote:
>
> hi all,
>
> just picking up this thread again; as mailed back in March (!) [1] our
> Jenkins builds are now using Java 8.
>
> Has everyone switched to Java 8 and is it now time to update Brooklyn to
> build with 8 rather than 7?
>
> If no-one objects, I'll try to get some time to do this later next week.
>
> regards
> Geoff
>
>
> [1]
> https://lists.apache.org/thread.html/6d50d242d1ed8e98776eb871c397de1aac06d3baf600edecc53415ff@%3Cdev.brooklyn.apache.org%3E
>
> On Mon, 6 Mar 2017 at 19:48 Geoff Macartney <
> geoff.macartney@cloudsoftcorp.com> wrote:
>
>> hi Aled,
>>
>> sure, I'll have a look at that.
>>
>> cheers
>> Geoff
>>
>>> On Mon, 6 Mar 2017 at 18:26 Aled Sage <al...@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> There have been six +1s (including myself) and no negatives, so let's do
>>> this.
>>>
>>> ---
>>>
>>> For Robert's question, I did some investigation for use of lambdas as
>>> config key values. They don't persist correctly unfortunately [1], so we
>>> shouldn't use them anywhere that could end up in persisted state.
>>>
>>> ---
>>>
>>> I suggest we separate this into multiple stages (and ensure that
>>> discussion of later stages does not block the earlier stages):
>>>
>>> * Stage one: switch to Java 8 as "official target"
>>> 1. Update our jenkins etc to always build/run with Java 8.
>>> 2. All developers/testers switch to Java 8 locally.
>>> 3. Add to the next release notes that Java 7 is no longer supported.
>>> * Stage two: update our poms so they don't compile/check for Java 7
>>> compatibility [2,3,4].
>>> * Stage three: update our docs to say not to use lambdas for config
>>> keys (similar to what we already say for anonyous inner classes [5])
>>> * Stage four: developers free to use Java 8 language features *where
>>> it does not affect APIs or end up in persisted state*
>>> * Stage five: discuss/improve use of Java 8 (e.g. perhaps fix [1];
>>> should we keep using guava classes that are now in Java 8's
>>> java.util.function.* ?)
>>>
>>> ---
>>>
>>> Geoff: if you're volunteering, it would be awesome if you could pick up
>>> stage 1.1 (and then stage 2).
>>>
>>> Aled
>>>
>>> [1] https://issues.apache.org/jira/browse/BROOKLYN-448
>>> [2] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
>>> [3]
>>>
>>> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
>>> [4]
>>> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
>>> [5]
>>>
>>> https://brooklyn.apache.org/v/latest/ops/persistence/index.html#writing-persistable-code
>>>
>>>
>>>> On 06/03/2017 14:35, Geoff Macartney wrote:
>>>> hi all,
>>>>
>>>> any more thoughts on this? What concrete steps do we want to take, and
>>>> when? What can I do to help out?
>>>>
>>>> Plus, has anyone any views on Robert's question?
>>>>
>>>> cheers
>>>> Geoff
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, 27 Feb 2017 at 14:21 Robert Moss <ro...@cloudsoft.io>
>>> wrote:
>>>>
>>>>> Aled,
>>>>>
>>>>> WRT Java 8 features. Is it still recommended to use named inner
>>> classes
>>>>> over anonymous inner classes? Can we now simplify those areas to use
>>>>> lambdas? There are a number of classes now built into Java that were
>>>>> previously provided by Guava etc. e.g. Optional, Predicate - should we
>>>>> start using the Java 8 classes instead where possible?
>>>>>
>>>>> Robert
>>>>>
>>>>>> On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java
>>> 8;
>>>>>> remove support for using Java 7 when running Brooklyn).
>>>>>>
>>>>>> This will make our testing simpler, improving coverage (e.g. we don't
>>>>>> currently test everything with Brooklyn running both on Java 7 and
>>> Java
>>>>> 8).
>>>>>> It will make our lives easier as developers (e.g. don't need to worry
>>>>> about
>>>>>> Java 7 versus Java 8 when compiling, running tests and manually
>>> testing
>>>>>> Brooklyn; and we can use Java 8 features).
>>>>>>
>>>>>> Java 7 reached end of life in April 2015 [1]; Java 8 was released
>>> March
>>>>>> 2014.
>>>>>>
>>>>>> We can do this in three stages:
>>>>>>
>>>>>> * Switch to Java 8 as "official target"
>>>>>> o Update our jenkins etc to always build/run with Java 8.
>>>>>> o All developers/testers switch to Java 8 locally.
>>>>>> o Add to the next release notes that Java 7 is no longer
>>> supported.
>>>>>> * Update our poms so they don't compile/check for Java 7
>>> compatibility
>>>>>> [3,4,5].
>>>>>> * Developers free to start using Java 8 language features!
>>>>>>
>>>>>> Stage 1 would be the bare minimum for the next release; I think we
>>> should
>>>>>> do all three stages before the 0.11.0 release.
>>>>>>
>>>>>> Aled
>>>>>>
>>>>>> [1] https://java.com/en/download/faq/java_7.xml
>>>>>> [2]
>>> https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
>>>>>> [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
>>>>>> [4] https://github.com/apache/brooklyn-server/blob/master/parent
>>>>>> /pom.xml#L557-L558
>>>>>> [5] https://github.com/apache/brooklyn-server/blob/master/parent
>>>>>> /pom.xml#L950
>>>>>>
>>>>>>
>>>
>>>
Re: [PROPOSAL] Remove java 7 support
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
hi all,
just picking up this thread again; as mailed back in March (!) [1] our
Jenkins builds are now using Java 8.
Has everyone switched to Java 8 and is it now time to update Brooklyn to
build with 8 rather than 7?
If no-one objects, I'll try to get some time to do this later next week.
regards
Geoff
[1]
https://lists.apache.org/thread.html/6d50d242d1ed8e98776eb871c397de1aac06d3baf600edecc53415ff@%3Cdev.brooklyn.apache.org%3E
On Mon, 6 Mar 2017 at 19:48 Geoff Macartney <
geoff.macartney@cloudsoftcorp.com> wrote:
> hi Aled,
>
> sure, I'll have a look at that.
>
> cheers
> Geoff
>
> On Mon, 6 Mar 2017 at 18:26 Aled Sage <al...@gmail.com> wrote:
>
>> Hi all,
>>
>> There have been six +1s (including myself) and no negatives, so let's do
>> this.
>>
>> ---
>>
>> For Robert's question, I did some investigation for use of lambdas as
>> config key values. They don't persist correctly unfortunately [1], so we
>> shouldn't use them anywhere that could end up in persisted state.
>>
>> ---
>>
>> I suggest we separate this into multiple stages (and ensure that
>> discussion of later stages does not block the earlier stages):
>>
>> * Stage one: switch to Java 8 as "official target"
>> 1. Update our jenkins etc to always build/run with Java 8.
>> 2. All developers/testers switch to Java 8 locally.
>> 3. Add to the next release notes that Java 7 is no longer supported.
>> * Stage two: update our poms so they don't compile/check for Java 7
>> compatibility [2,3,4].
>> * Stage three: update our docs to say not to use lambdas for config
>> keys (similar to what we already say for anonyous inner classes [5])
>> * Stage four: developers free to use Java 8 language features *where
>> it does not affect APIs or end up in persisted state*
>> * Stage five: discuss/improve use of Java 8 (e.g. perhaps fix [1];
>> should we keep using guava classes that are now in Java 8's
>> java.util.function.* ?)
>>
>> ---
>>
>> Geoff: if you're volunteering, it would be awesome if you could pick up
>> stage 1.1 (and then stage 2).
>>
>> Aled
>>
>> [1] https://issues.apache.org/jira/browse/BROOKLYN-448
>> [2] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
>> [3]
>>
>> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
>> [4]
>> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
>> [5]
>>
>> https://brooklyn.apache.org/v/latest/ops/persistence/index.html#writing-persistable-code
>>
>>
>> On 06/03/2017 14:35, Geoff Macartney wrote:
>> > hi all,
>> >
>> > any more thoughts on this? What concrete steps do we want to take, and
>> > when? What can I do to help out?
>> >
>> > Plus, has anyone any views on Robert's question?
>> >
>> > cheers
>> > Geoff
>> >
>> >
>> >
>> >
>> > On Mon, 27 Feb 2017 at 14:21 Robert Moss <ro...@cloudsoft.io>
>> wrote:
>> >
>> >> Aled,
>> >>
>> >> WRT Java 8 features. Is it still recommended to use named inner
>> classes
>> >> over anonymous inner classes? Can we now simplify those areas to use
>> >> lambdas? There are a number of classes now built into Java that were
>> >> previously provided by Guava etc. e.g. Optional, Predicate - should we
>> >> start using the Java 8 classes instead where possible?
>> >>
>> >> Robert
>> >>
>> >> On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com> wrote:
>> >>
>> >>> Hi all,
>> >>>
>> >>> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java
>> 8;
>> >>> remove support for using Java 7 when running Brooklyn).
>> >>>
>> >>> This will make our testing simpler, improving coverage (e.g. we don't
>> >>> currently test everything with Brooklyn running both on Java 7 and
>> Java
>> >> 8).
>> >>> It will make our lives easier as developers (e.g. don't need to worry
>> >> about
>> >>> Java 7 versus Java 8 when compiling, running tests and manually
>> testing
>> >>> Brooklyn; and we can use Java 8 features).
>> >>>
>> >>> Java 7 reached end of life in April 2015 [1]; Java 8 was released
>> March
>> >>> 2014.
>> >>>
>> >>> We can do this in three stages:
>> >>>
>> >>> * Switch to Java 8 as "official target"
>> >>> o Update our jenkins etc to always build/run with Java 8.
>> >>> o All developers/testers switch to Java 8 locally.
>> >>> o Add to the next release notes that Java 7 is no longer
>> supported.
>> >>> * Update our poms so they don't compile/check for Java 7
>> compatibility
>> >>> [3,4,5].
>> >>> * Developers free to start using Java 8 language features!
>> >>>
>> >>> Stage 1 would be the bare minimum for the next release; I think we
>> should
>> >>> do all three stages before the 0.11.0 release.
>> >>>
>> >>> Aled
>> >>>
>> >>> [1] https://java.com/en/download/faq/java_7.xml
>> >>> [2]
>> https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
>> >>> [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
>> >>> [4] https://github.com/apache/brooklyn-server/blob/master/parent
>> >>> /pom.xml#L557-L558
>> >>> [5] https://github.com/apache/brooklyn-server/blob/master/parent
>> >>> /pom.xml#L950
>> >>>
>> >>>
>>
>>
Re: [PROPOSAL] Remove java 7 support
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
hi Aled,
sure, I'll have a look at that.
cheers
Geoff
On Mon, 6 Mar 2017 at 18:26 Aled Sage <al...@gmail.com> wrote:
> Hi all,
>
> There have been six +1s (including myself) and no negatives, so let's do
> this.
>
> ---
>
> For Robert's question, I did some investigation for use of lambdas as
> config key values. They don't persist correctly unfortunately [1], so we
> shouldn't use them anywhere that could end up in persisted state.
>
> ---
>
> I suggest we separate this into multiple stages (and ensure that
> discussion of later stages does not block the earlier stages):
>
> * Stage one: switch to Java 8 as "official target"
> 1. Update our jenkins etc to always build/run with Java 8.
> 2. All developers/testers switch to Java 8 locally.
> 3. Add to the next release notes that Java 7 is no longer supported.
> * Stage two: update our poms so they don't compile/check for Java 7
> compatibility [2,3,4].
> * Stage three: update our docs to say not to use lambdas for config
> keys (similar to what we already say for anonyous inner classes [5])
> * Stage four: developers free to use Java 8 language features *where
> it does not affect APIs or end up in persisted state*
> * Stage five: discuss/improve use of Java 8 (e.g. perhaps fix [1];
> should we keep using guava classes that are now in Java 8's
> java.util.function.* ?)
>
> ---
>
> Geoff: if you're volunteering, it would be awesome if you could pick up
> stage 1.1 (and then stage 2).
>
> Aled
>
> [1] https://issues.apache.org/jira/browse/BROOKLYN-448
> [2] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> [3]
>
> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
> [4]
> https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
> [5]
>
> https://brooklyn.apache.org/v/latest/ops/persistence/index.html#writing-persistable-code
>
>
> On 06/03/2017 14:35, Geoff Macartney wrote:
> > hi all,
> >
> > any more thoughts on this? What concrete steps do we want to take, and
> > when? What can I do to help out?
> >
> > Plus, has anyone any views on Robert's question?
> >
> > cheers
> > Geoff
> >
> >
> >
> >
> > On Mon, 27 Feb 2017 at 14:21 Robert Moss <ro...@cloudsoft.io>
> wrote:
> >
> >> Aled,
> >>
> >> WRT Java 8 features. Is it still recommended to use named inner classes
> >> over anonymous inner classes? Can we now simplify those areas to use
> >> lambdas? There are a number of classes now built into Java that were
> >> previously provided by Guava etc. e.g. Optional, Predicate - should we
> >> start using the Java 8 classes instead where possible?
> >>
> >> Robert
> >>
> >> On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
> >>> remove support for using Java 7 when running Brooklyn).
> >>>
> >>> This will make our testing simpler, improving coverage (e.g. we don't
> >>> currently test everything with Brooklyn running both on Java 7 and Java
> >> 8).
> >>> It will make our lives easier as developers (e.g. don't need to worry
> >> about
> >>> Java 7 versus Java 8 when compiling, running tests and manually testing
> >>> Brooklyn; and we can use Java 8 features).
> >>>
> >>> Java 7 reached end of life in April 2015 [1]; Java 8 was released March
> >>> 2014.
> >>>
> >>> We can do this in three stages:
> >>>
> >>> * Switch to Java 8 as "official target"
> >>> o Update our jenkins etc to always build/run with Java 8.
> >>> o All developers/testers switch to Java 8 locally.
> >>> o Add to the next release notes that Java 7 is no longer
> supported.
> >>> * Update our poms so they don't compile/check for Java 7
> compatibility
> >>> [3,4,5].
> >>> * Developers free to start using Java 8 language features!
> >>>
> >>> Stage 1 would be the bare minimum for the next release; I think we
> should
> >>> do all three stages before the 0.11.0 release.
> >>>
> >>> Aled
> >>>
> >>> [1] https://java.com/en/download/faq/java_7.xml
> >>> [2]
> https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
> >>> [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> >>> [4] https://github.com/apache/brooklyn-server/blob/master/parent
> >>> /pom.xml#L557-L558
> >>> [5] https://github.com/apache/brooklyn-server/blob/master/parent
> >>> /pom.xml#L950
> >>>
> >>>
>
>
Re: [PROPOSAL] Remove java 7 support
Posted by Aled Sage <al...@gmail.com>.
Hi all,
There have been six +1s (including myself) and no negatives, so let's do
this.
---
For Robert's question, I did some investigation for use of lambdas as
config key values. They don't persist correctly unfortunately [1], so we
shouldn't use them anywhere that could end up in persisted state.
---
I suggest we separate this into multiple stages (and ensure that
discussion of later stages does not block the earlier stages):
* Stage one: switch to Java 8 as "official target"
1. Update our jenkins etc to always build/run with Java 8.
2. All developers/testers switch to Java 8 locally.
3. Add to the next release notes that Java 7 is no longer supported.
* Stage two: update our poms so they don't compile/check for Java 7
compatibility [2,3,4].
* Stage three: update our docs to say not to use lambdas for config
keys (similar to what we already say for anonyous inner classes [5])
* Stage four: developers free to use Java 8 language features *where
it does not affect APIs or end up in persisted state*
* Stage five: discuss/improve use of Java 8 (e.g. perhaps fix [1];
should we keep using guava classes that are now in Java 8's
java.util.function.* ?)
---
Geoff: if you're volunteering, it would be awesome if you could pick up
stage 1.1 (and then stage 2).
Aled
[1] https://issues.apache.org/jira/browse/BROOKLYN-448
[2] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
[3]
https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L557-L558
[4]
https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L950
[5]
https://brooklyn.apache.org/v/latest/ops/persistence/index.html#writing-persistable-code
On 06/03/2017 14:35, Geoff Macartney wrote:
> hi all,
>
> any more thoughts on this? What concrete steps do we want to take, and
> when? What can I do to help out?
>
> Plus, has anyone any views on Robert's question?
>
> cheers
> Geoff
>
>
>
>
> On Mon, 27 Feb 2017 at 14:21 Robert Moss <ro...@cloudsoft.io> wrote:
>
>> Aled,
>>
>> WRT Java 8 features. Is it still recommended to use named inner classes
>> over anonymous inner classes? Can we now simplify those areas to use
>> lambdas? There are a number of classes now built into Java that were
>> previously provided by Guava etc. e.g. Optional, Predicate - should we
>> start using the Java 8 classes instead where possible?
>>
>> Robert
>>
>> On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
>>> remove support for using Java 7 when running Brooklyn).
>>>
>>> This will make our testing simpler, improving coverage (e.g. we don't
>>> currently test everything with Brooklyn running both on Java 7 and Java
>> 8).
>>> It will make our lives easier as developers (e.g. don't need to worry
>> about
>>> Java 7 versus Java 8 when compiling, running tests and manually testing
>>> Brooklyn; and we can use Java 8 features).
>>>
>>> Java 7 reached end of life in April 2015 [1]; Java 8 was released March
>>> 2014.
>>>
>>> We can do this in three stages:
>>>
>>> * Switch to Java 8 as "official target"
>>> o Update our jenkins etc to always build/run with Java 8.
>>> o All developers/testers switch to Java 8 locally.
>>> o Add to the next release notes that Java 7 is no longer supported.
>>> * Update our poms so they don't compile/check for Java 7 compatibility
>>> [3,4,5].
>>> * Developers free to start using Java 8 language features!
>>>
>>> Stage 1 would be the bare minimum for the next release; I think we should
>>> do all three stages before the 0.11.0 release.
>>>
>>> Aled
>>>
>>> [1] https://java.com/en/download/faq/java_7.xml
>>> [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
>>> [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
>>> [4] https://github.com/apache/brooklyn-server/blob/master/parent
>>> /pom.xml#L557-L558
>>> [5] https://github.com/apache/brooklyn-server/blob/master/parent
>>> /pom.xml#L950
>>>
>>>
Re: [PROPOSAL] Remove java 7 support
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
hi all,
any more thoughts on this? What concrete steps do we want to take, and
when? What can I do to help out?
Plus, has anyone any views on Robert's question?
cheers
Geoff
On Mon, 27 Feb 2017 at 14:21 Robert Moss <ro...@cloudsoft.io> wrote:
> Aled,
>
> WRT Java 8 features. Is it still recommended to use named inner classes
> over anonymous inner classes? Can we now simplify those areas to use
> lambdas? There are a number of classes now built into Java that were
> previously provided by Guava etc. e.g. Optional, Predicate - should we
> start using the Java 8 classes instead where possible?
>
> Robert
>
> On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com> wrote:
>
> > Hi all,
> >
> > I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
> > remove support for using Java 7 when running Brooklyn).
> >
> > This will make our testing simpler, improving coverage (e.g. we don't
> > currently test everything with Brooklyn running both on Java 7 and Java
> 8).
> > It will make our lives easier as developers (e.g. don't need to worry
> about
> > Java 7 versus Java 8 when compiling, running tests and manually testing
> > Brooklyn; and we can use Java 8 features).
> >
> > Java 7 reached end of life in April 2015 [1]; Java 8 was released March
> > 2014.
> >
> > We can do this in three stages:
> >
> > * Switch to Java 8 as "official target"
> > o Update our jenkins etc to always build/run with Java 8.
> > o All developers/testers switch to Java 8 locally.
> > o Add to the next release notes that Java 7 is no longer supported.
> > * Update our poms so they don't compile/check for Java 7 compatibility
> > [3,4,5].
> > * Developers free to start using Java 8 language features!
> >
> > Stage 1 would be the bare minimum for the next release; I think we should
> > do all three stages before the 0.11.0 release.
> >
> > Aled
> >
> > [1] https://java.com/en/download/faq/java_7.xml
> > [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
> > [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> > [4] https://github.com/apache/brooklyn-server/blob/master/parent
> > /pom.xml#L557-L558
> > [5] https://github.com/apache/brooklyn-server/blob/master/parent
> > /pom.xml#L950
> >
> >
>
Re: [PROPOSAL] Remove java 7 support
Posted by Robert Moss <ro...@cloudsoft.io>.
Aled,
WRT Java 8 features. Is it still recommended to use named inner classes
over anonymous inner classes? Can we now simplify those areas to use
lambdas? There are a number of classes now built into Java that were
previously provided by Guava etc. e.g. Optional, Predicate - should we
start using the Java 8 classes instead where possible?
Robert
On 27 February 2017 at 13:08, Aled Sage <al...@gmail.com> wrote:
> Hi all,
>
> I propose we switch to Java 8 for Apache Brooklyn (i.e. require Java 8;
> remove support for using Java 7 when running Brooklyn).
>
> This will make our testing simpler, improving coverage (e.g. we don't
> currently test everything with Brooklyn running both on Java 7 and Java 8).
> It will make our lives easier as developers (e.g. don't need to worry about
> Java 7 versus Java 8 when compiling, running tests and manually testing
> Brooklyn; and we can use Java 8 features).
>
> Java 7 reached end of life in April 2015 [1]; Java 8 was released March
> 2014.
>
> We can do this in three stages:
>
> * Switch to Java 8 as "official target"
> o Update our jenkins etc to always build/run with Java 8.
> o All developers/testers switch to Java 8 locally.
> o Add to the next release notes that Java 7 is no longer supported.
> * Update our poms so they don't compile/check for Java 7 compatibility
> [3,4,5].
> * Developers free to start using Java 8 language features!
>
> Stage 1 would be the bare minimum for the next release; I think we should
> do all three stages before the 0.11.0 release.
>
> Aled
>
> [1] https://java.com/en/download/faq/java_7.xml
> [2] https://www.infoq.com/news/2015/05/Oracle-Ends-Java-7Public-Updates
> [3] https://github.com/apache/brooklyn-server/blob/master/pom.xml#L91
> [4] https://github.com/apache/brooklyn-server/blob/master/parent
> /pom.xml#L557-L558
> [5] https://github.com/apache/brooklyn-server/blob/master/parent
> /pom.xml#L950
>
>