Spring was able to stay on schedule, seven months after they publicized their plan, Spring Framework 4.1 General Availability (GA) has been released and is now accessible. The GA announcement has been made by Juergen Hoeller, co-founder of Spring Framework, in Spring’s blog site last September 4.
Spring Framework 4.1, started its development in January 2014 and had its first release candidate in July followed up by a second release candidate last August 15 which includes fixes and improvements. According to Hoeller, the following are the new features being offered in 4.1:
- Upgraded/complete support for: JCache (107) annotations, JMS 2.0, Web MVC support for Groovy markup templates
- Use of simple annotation to create a JMS message listener
- Flexible resolution and transformation of static web resources
- MVC views: declarative resolution, Jackson’s JsonView
- WebSocket STOMP Messaging refinements: WebSocket Scope, SockJS (Java) client support, WebSocket stats
- Performance enhancements: Spring Expression Languange (SpEL) compiler mode, concurrency fine-tuning across the container
He also mentioned a bunch of other improvements made for this release such as:
- Direct field binding support with auto-growing for nested fields
- Java 8’s Optional for injection points and MVC handler parameters
- Support for the standard @Priority annotation for dependency ordering and selection
- Annotated @Lookup methods with support for provided constructor arguments
- Declarative SQL scripts and programmatic transactions in the TestContext framework
- Enhanced Hibernate JPA setup: isolation levels, discovery of managed packages
Additional information on the new features and enhancements can be found here.
Other features that weren’t able to make on this GA release will be included in the 4.2 line which is scheduled on the second quarter of 2015.
Minimum requirements for 4.1 didn’t change, you still need JDK 6+, Servlet 2.5+ and JPA 2.0+ same with Spring Framework 4.0. The 4.1.x line is now the “primary maintenance branch”, therefore, early upgrade to 4.1 is recommended. Since 4.1 line supersedes 4.0.x line, the 4.0.7 has been released together with 4.1’s GA to assist everyone in upgrading.
Modular Source Code also known as JEP 201, authored by Mark Reinhold and owned by Alan Bateman was created on July 22, 2014. JEP 201, second among the JEPs lined up for JDK 9, will “restructure the JDK’s source code from a scheme used since 1997 into modules, improve the build system to compile modules, and implement module boundaries at build time”. However, JRE and JDK binary images will stay as they are and no module system will be introduced.
JEP 201 is described as a part of the first phase of JDK 9’s main feature – Project Jigsaw. One main goal of the Project Jigsaw is to “make implementations of the Java SE Platform easily scalable down to small devices”. In connection with Project Jigsaw’s development, it was mentioned by Reinhold in one of his previous blog posts that merging is advisable to be performed before Jigsaw nears its completion.
In a short message posted by Reinhold last August 18, 2014, entitled “JDK 9’s source code is now modular”, he announced that JEP 201 changesets have been merged into the JDK. The changes are now included in the latest Early Access Release for JDK 9 – 9 Build b29 which is now available for download.
Restructuring the source code at an early stage is driven by the following factors:
- JDK developers will have a chance to familiarize themselves with the “modular structure of the system”;
- Implementation of “module boundaries in the build” to maintain that structure moving forward;
- “Shuffling” of non-modular source code to modular will be prevented during the improvements on Project Jigsaw.
Sample codes and details of the proposed new scheme versus the current scheme have been presented at the JEP 201 site. Below is an excerpt from the site that shows an illustration and explanation of the new scheme they wanted to implement “in every repository in the JDK forest except for hotspot”.
In abbreviated form:
$MODULE is a module name (e.g., java.base);
The share directory contains shared, cross-platform code, as before;
The $OS directory contains operating-system-specific code, as before, where $OS is one of unix, windows, etc.;
The classes directory contains Java source files and resource files organized into a directory tree reflecting their API $PACKAGE hierarchy, as before;
The native directory contains C or C++ source files, as before but organized differently:
- The includedirectory contains C or C++ header files intended to be exported for external use (e.g., jni.h);
- C or C++ source files are placed in a $LIBRARY directory, whose name is that of the shared library or DLL into which the compiled code will be linked (e.g., libjava or libawt); and, finally,
The conf directory contains configuration files meant to be edited by end users (e.g., net.properties).
Last week, Oracle announced on their blog site the official launching of the newest version of Java Platform, Enterprise Edition – Java EE 8. The Java EE 8 also known as JSR 366 was started through the Java Community Process (JCP). The primary focus of improvements for the Java EE platform are enumerated below, details are posted on JCP website:
- Ease of development – using CDI to improve managed bean model
- Cloud Support – enhancement of Java EE 7’s cloud support infrastructure
- Java SE 8 – use of Java SE 8 to build Java EE 8 and benefit from its features such as “repeating annotations, lambda expressions, the Date/Time API, type annotations, Completable Futures, etc.”
The following JSRs are proposed initial contents for the Java EE 8 Platform:
- Java API for JSON Binding (JSR-367) – defined as “standard binding layer (metadata & runtime) for converting Java objects to/from JSON messages”.Schedule of Final Release: Third Quarter of 2016.
- JCache (JSR-107) – “standardize in process caching of Java objects”. Final release date: March 18, 2014.
- Model View Controller (MVC)(JSR-371) – described as”a model-view controller specification for Java EE”. Schedule of Final Release: Third Quarter of 2016.
A number of additional APIs were also submitted for possible inclusion in the Java EE 8:
- CDI 2 (JSR 365) – an enhanced version of CDI 1.1 (JSR 346), targets “modularity and Java SE support”. Schedule of Final Release: First Quarter of 2016.
- JMS 2.1 (JSR 368) – newest version of Java Message Service API, used by Java programs in accessing enterprise messaging systems. Schedule of Final Release: Third Quarter of 2016.
- Servlet 4 (JSR 369) – will help users of Java EE cope up with the latest updates in HTTP such as HTTP/2. Schedule of Final Release: Third Quarter of 2016.
- JAX-RS 2.1 (JSR 370) – newest version of Java API for RESTful Web Services, wherein “asynchronous processing” will be introduced. Schedule of Final Release: Third Quarter of 2016.
- JSF 2.3 (JSR 372)– newest version of Java Server Faces with enhancement on specification’s clarity and addition of new features. Schedule of Final Release: Third Quarter of 2016.
Meanwhile, there is also a probability that all or some of Java EE platform’s existing technologies such as Java API for WebSocket, Expression Language (EL), Interceptors, Concurrency Utilities for Java EE, Batch Applications for the Java Platform, Contexts and Dependency Injection for Java EE (CDI), Bean Validation, Common Annotations, Java Connector Architecture, Java Transaction API (JTA), Java Persistence API (JPA), Enterprise JavaBeans (EJB), and JavaServer Pages (JSP) will be updated for Java EE 8’s release.
The Expert Group for Java EE 8 is scheduled to be determined this quarter and the final release is expected on the third quarter of 2016. Oracle encourage feedbacks on this new JSR and will keep everyone posted for updates.