Thanks Geoff, much appreciated! Sent from my iPhone
> On 12 May 2017, at 10:41, Geoff Macartney <[email protected]> > 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 < > [email protected]> wrote: > >> hi Aled, >> >> sure, I'll have a look at that. >> >> cheers >> Geoff >> >>> On Mon, 6 Mar 2017 at 18:26 Aled Sage <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 >>>>>> >>>>>> >>> >>>
