CGLIB 3 has been released in order to depend on ASM 4, which Spring now depends on internally (see previous commit). This commit eliminates spring-beans' optional dependency on cglib-nodep v2.2 and instead repackages net.sf.cglib => org.springframework.cglib much in the same way we have historically done with ASM. This change is beneficial to users in several ways: - Eliminates the need to manually add CGLIB to the application classpath; especially important for the growing number of @Configuration class users. Java-based configuration functionality, along with proxy-target-class and method injection features now work 'out of the box' in Spring 3.2. - Eliminates the possibility of conflicts with other libraries that may dependend on differing versions of CGLIB, e.g. Hibernate 3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a conflict if the application were depending on CGLIB 3 for Spring-related purposes. - Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is that much less likely to work well in a Java 7 environment due to ASM 4's support for transforming classes with invokedynamic bytecode instructions. On CGLIB and ASM: CGLIB's own dependency on ASM is also transformed along the way to depend on Spring's repackaged org.springframework.asm, primarily to eliminate unnecessary duplication of ASM classfiles in spring-core and in the process save around 100K in the final spring-core JAR file size. It is coincidental that spring-core and CGLIB currently depend on the exact same version of ASM (4.0), but it is also unlikely to change any time soon. If this change does occur and versions of ASM drift, then the size optimization mentioned above will have to be abandoned. This would have no compatibility impact, however, so this is a reasonable solution now and for the forseeable future. On a mysterious NoClassDefFoundError: During the upgrade to CGLIB 3.0, Spring test cases began failing due to NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter regarding its use of asm-util's TraceClassVisitor type. previous versions of cglib-nodep, particularly 2.2, did not cause this behavior, even though cglib-nodep has never actually repackaged and bundled asm-util classes. The reason for these NoClassDefFoundErrors occurring now is still not fully understood, but appears to be due to subtle JVM bytecode preverification rules. The hypothesis is that due to minor changes in DebuggingClassWriter such as additional casts, access to instance variables declared in the superclass, and indeed a change in the superclass hierarchy, preverification may be kicking in on the toByteArray method body, at which point the reference to the missing TraceClassVisitor type is noticed and the NCDFE is thrown. For this reason, a dummy implementation of TraceClassVisitor has been added to spring-core in the org.springframework.asm.util package. This class simply ensures that Spring's own tests never result in the NCDFE described above, and more importantly that Spring's users never encounter the same. Other changes include: - rename package-private Cglib2AopProxy => CglibAopProxy - eliminate all 'cglibAvailable' checks, warnings and errors - eliminate all 'CGLIB2' language in favor of 'CGLIB' - eliminate all mention in reference and java docs of needing to add cglib(-nodep) to one's application classpath Issue: SPR-9669
Spring Framework
The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. A key element of Spring is infrastructural support at the application level: Spring focuses on the "plumbing" of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.
The framework also serves as the foundation for Spring Integration, Spring Batch and the rest of the Spring family of projects. Browse the repositories under the SpringSource organization on GitHub for a full list.
.NET and Python variants are available as well.
Downloading artifacts
See downloading Spring artifacts for Maven repository information. Unable to use Maven or other transitive dependency management tools? See building a distribution with dependencies.
Documentation
See the current Javadoc and reference docs.
Getting support
Check out the Spring forums and the spring and spring-mvc tags on Stack Overflow. Commercial support is available too.
Issue Tracking
Report issues via the Spring Framework JIRA. Understand our issue management process by reading about the lifecycle of an issue. Think you've found a bug? Please consider submitting a reproduction project via the spring-framework-issues GitHub repository. The readme there provides simple step-by-step instructions.
Building from source
The Spring Framework uses a Gradle-based build system. In the instructions
below, ./gradlew is invoked from the root of the source tree and serves as
a cross-platform, self-contained bootstrap mechanism for the build. The only
prerequisites are Git and JDK 1.6+.
check out sources
git clone git://github.com/SpringSource/spring-framework.git
compile and test, build all jars, distribution zips and docs
./gradlew build
install all spring-* jars into your local Maven cache
./gradlew install
import sources into your IDE
Run ./import-into-eclipse.sh or read import-into-idea.md as appropriate.
... and discover more commands with ./gradlew tasks. See also the Gradle
build and release FAQ.
Contributing
Pull requests are welcome; see the contributor guidelines for details.
Staying in touch
Follow @springframework and its team members on Twitter. In-depth articles can be found at the SpringSource team blog, and releases are announced via our news feed.
License
The Spring Framework is released under version 2.0 of the Apache License.