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 <[email protected]> wrote: > 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 > >>>>>> > >>>>>> > >>> > >>> >
