brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Macartney <geoff.macart...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] Remove java 7 support
Date Fri, 12 May 2017 09:41:01 GMT
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 <aled.sage@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 <robert.moss@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 <aled.sage@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
>> >>>
>> >>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message