Update source and target compatibility from 1.5 to 1.6, meaning that
@Override is now allowed on implementations of interface methods within
main classes.
Issue: SPR-10130
* cleanup-3.2.x: (33 commits)
Update Apache license headers for affected sources
Ignore performance-sensitive tests by default
Introduce 'spring-build-junit' subproject
Replace EasyMock with Mockito in test sources
Add @Override annotations to test sources
Update test source and target JDK compatibility
Update -Xlint compiler warning output
Fix various compiler warnings in spring-context
Fix "unnecessary @SuppressWarnings" warnings
Fix [rawtypes] compiler warnings
Fix [dep-ann] warnings with @Deprecated
Fix [cast] compiler warnings
Fix [serial] compiler warnings
Fix [varargs] compiler warnings
Fix warnings due to unused import statements
Replace <code> with {@code} throughout Javadoc
Fix various Javadoc warnings
Replace space indentation with tabs
Remove trailing whitespace in source files
Various updates to support IDEA
...
Conflicts:
gradle.properties
* cleanup-3.2.x: (21 commits)
Update Apache license headers for affected sources
Ignore performance-sensitive tests by default
Introduce 'spring-build-junit' subproject
Replace EasyMock with Mockito in test sources
Add @Override annotations to test sources
Update test source and target JDK compatibility
Update -Xlint compiler warning output
Fix various compiler warnings in spring-context
Fix "unnecessary @SuppressWarnings" warnings
Fix [rawtypes] compiler warnings
Fix [dep-ann] warnings with @Deprecated
Fix [cast] compiler warnings
Fix [serial] compiler warnings
Fix [varargs] compiler warnings
Fix warnings due to unused import statements
Replace <code> with {@code} throughout Javadoc
Fix various Javadoc warnings
Replace space indentation with tabs
Remove trailing whitespace in source files
Various updates to support IDEA
...
Make use of the new JUnit functionality introduced in the previous
commit to 'Assume' that perfomance- and timing-sensitive tests should
run only when TestGroup.PERFORMANCE is selected, i.e. when
-PtestGroups="performance" has been provided at the Gradle command line.
The net effect is that these tests are now ignored by default, which
will result in far fewer false-negative CI build failures due to
resource contention and other external factors that cause slowdowns.
We will set up a dedicated performance CI build to run these tests on
an isolated machine, etc.
Issue: SPR-9984
Introduce new 'spring-build-junit' subproject containing shared
JUnit utilities and classes to be used by other test cases. This
project is for internal use within the framework, and therefore
creates no artifacts to be published to any repository.
The initial code includes support for JUnit Assumptions that can
be used to determine when a test should run. Tests can be skipped
based on the running JDK version, logging level or based on specific
'groups' that have activated via a Gradle property.
It is intended that sources within the spring-build-junit project be
folded into spring-core/src/test/java, pending some Gradle work that
will facilitate sharing test output across subprojects; therefore this
commit should be seen as a temporary solution.
Issue: SPR-9984
"test" source and target compatibility has been upgraded to 1.7 except
where noted, allowing us to use 1.7 language features such as
diamond-style (<>) generics declarations, automatic resource management
and multi-catch. More importantly, we will be able to upgrade to 1.8
once it is available in order to make use of lambda expressions, etc in
our test cases.
IDE configurations must be relaxed to allow 1.7 across the board, as
neither Eclipse nor IDEA are clever enough to allow for different
language levels across production and test resources. See [1] for a
feature request on that front.
spring-oxm is a special case here, and has been pinned at 1.6
compatibility even for its test sources in order to avoid a class
verification error that JibX throws when encountering 1.7-level
bytecode [2].
Likewise with spring-orm, toplink encounters a similar class
verification error, so has been pinned to 1.6 for the time being.
When we remove the (already deprecated since 3.2) Toplink support
we can restore compatibility to 1.7.
[1]: http://youtrack.jetbrains.com/issue/IDEA-97814
[2]: http://jira.codehaus.org/browse/JIBX-465
Issue: SPR-10129
Enable output for the compiler warnings that have been eliminated so
far. 'rawtypes', 'deprecation', and 'unchecked' remain suppressed until
these warnings can be fully eliminated as well.
- Suppress rawtypes warnings for src/main
- Enable rawtypes warnings for src/test
This commit attempts to to resolve all rawtypes problems across tests as
aggressively as possible, i.e. without regard for binary compatibility,
whereas main sources must be treated much more cautiously with an eye
toward compatibility.
Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.
In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.
Remove the 'final' modifier from SingletonBeanFactoryLocatorTests
to work around the "cannot extend final class" error issued when
running all tests. The error was due to confusion with IDEA between
the two variants of SingletonBeanFactoryLocatorTests across
spring-context and spring-beans.
Rename one of the GroovyMessenger classes to GroovyMessenger2.
Previously there were multiple Groovy classes named
'GroovyMessenger', causing a compilation error in certain IDE
arrangements.
Update import-into-idea.md documentation
Add various IDEA artifacts to .gitignore
- ignore derby.log wherever it is written
- ignore IDEA's test-output directory
- ignore IDEA's Atlassian connector config file
Previously the algorithm used by GenericConversionService to find
converters incorrectly searched for interfaces working up from the
base class. This caused particular problems with custom List
converters as as the Collection interface would be considered before
the List interface giving CollectionToObjectConverter precedence
over the custom converter.
The updated algorithm restores the class search order to behave in the
same way as Spring 3.1.
Issue: SPR-10116
Backport-Issue: SPR-10117
Backport-Commit: aa914497dc
Previously the algorithm used by GenericConversionService to find
converters incorrectly searched for interfaces working up from the
base class. This caused particular problems with custom List
converters as as the Collection interface would be considered before
the List interface giving CollectionToObjectConverter precedence
over the custom converter.
The updated algorithm restores the class search order to behave in the
same way as Spring 3.1.
Issue: SPR-10116
This change resolves a specific issue with processing
java.math.BigDecimal via ExtendedBeanInfo. BigDecimal has a particular
constellation of #setScale methods that, prior to this change, had the
potential to cause ExtendedBeanInfo to throw an IntrospectionException
depending on the order in which the methods were processed.
Because JDK 7 no longer returns deterministic results from
Class#getDeclaredMethods, it became a genuine possibility - indeed a
statistical certainty that the 'wrong' setScale method handling order
happens sooner or later. Typically one could observe this failure once
out of every four test runs.
This commit introduces deterministic method ordering of all discovered
non-void returning write methods in such a way that solves the problem
for BigDecimal as well as for any other class having a similar method
arrangement.
Also:
- Remove unnecessary cast
- Pass no method information to PropertyDescriptor superclasses when
invoking super(...). This ensures that any 'type mismatch'
IntrospectionExceptions are handled locally in ExtendedBeanInfo and
its Simple* PropertyDescriptor variants where we have full control.
Issue: SPR-10111, SPR-9702
