maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Gudian <>
Subject Supported Toolchain JDK version in Surefire / was: surefire refactoring done
Date Wed, 06 May 2015 18:17:20 GMT
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.


2015-05-06 18:42 GMT+02:00 Tibor Digana <>:

> 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

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