Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 andreas.gudian@gmail.com does not designate 54.191.145.13 as permitted
 sender)
MIME-Version: 1.0
Date: Wed, 6 May 2015 20:17:20 +0200
Message-ID: 
 <CAK2FUK3RfJHs-XL1T+O9wZvYg=GXJnccOeyFmeex6Zx88tY_dQ@mail.gmail.com>
Subject: Supported Toolchain JDK version in Surefire / was: surefire
 refactoring done
From: Andreas Gudian <andreas.gudian@gmail.com>
To: Tibor Digana <tibor.digana@googlemail.com>
Cc: Kristian Rosenvold <kristian.rosenvold@gmail.com>,
	Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7bf0c02a490b1f05156dce56

--047d7bf0c02a490b1f05156dce56
Content-Type: text/plain; charset=UTF-8

Hi Tibor,

wow, that's a lot of work you put in there! Great!

As you also changed stuff in surefire-booter and I always wondered, I'm
cc-ing dev@ with this question:

Do we have any documentation on which JDKs we officially support to be used
in a toolchain configuration?

For quite a while now, surefire-booter and dependent modules were compiled
with target=1.5 (AFAIK). So surefire would support executing tests with
toolchain-support only if the toolchained JDK is at least 1.5. I think that
is ok, but we should keep an eye on that when going towards 1.7 for most of
the code in the future.

Do we have other plugins with this kind of dependency? I would guess that
the compiler plugin doesn't care, as it doesn't have any of its own code
executed in the toolchain JVM.

Andreas


2015-05-06 18:42 GMT+02:00 Tibor Digana <tibor.digana@googlemail.com>:

> Finished a big refactoring in surefire.
> Basically the previous code looked like Java 1.4 - no generics, no
> for-each, no var-args.
> Now it's more type safe code.
>
> These are activities in SUREFIRE-1155:
>
> Java 5 for-each instead of Iterator
> optimized loops
> optimized branching
> some conditions in if-else could not happen -> therefore was simplified
> improved loops variables
> optimized use of this pointer
> using Java Generics instead of java.util.Properties
> removed unnecessary cast
> boolean instead of Boolean
> isEmpty() instead of Collection#size() == 0
> removed unused code
> resolved warnings shown by IntelliJ IDEA
> use Arrays.asList( o ) to Collections.singletonList( o ) with single object
> @SuppressWarnings where code generics cannot be improved
> substitute Java 4 StringBuilder with String concatination for better code
> clarity. Java Compilet 5 will compile to use StringBuilder in bytecode.
> using ternary operator
> added remark @todo use try-with-resources JDK7, search in all code
> get rid of Class[] in Reflection and use var args
> caught InvocationTargetException and use exception cause in rethrown
> RuntimeException
>
> Cheers
>

--047d7bf0c02a490b1f05156dce56--