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 >> >>> >> >>> >> >>
