Java 8, Java 9 Features Preview

Java 7 brought lots of new features after going through a number of delays.

Oracle is more prepared and excited about Java 8. They call it a Revolution and not an evolution.

Major improvements in Java 8 will be:

• JVM convergence i.e. hybrid of JRocket and Java Hotspot VM.
• Better support for Multicore hardware and applications.
• Addition of type annotations,
• a Date/Time API (JSR310) and support for sensors to widen the deployment options for the code.

It can be broken down to two major projects:

1. Project Lambda
2. Project Jigsaw

1. Project Lambda will enable Java to work much more effectively with multicore processing systems – the most likely hardware used by Java going forward.

“Some would say adding Lambda expressions is just to keep up with the cool kids, and there’s some truth in that,” Reinhold said. “But the real reason is multicore processors; the best way to handle them is with Lambda.”

Fundamentally, Project Lambda would allow programming patterns that require modeling code as data to be convenient and idiomatic in Java. The principal new language features include:

• Lambda expressions (informally, “closures” or “anonymous methods”)
• Expanded target typing
• Method and constructor references
• Default methods

The goal of OpenJDK Project Lambda is to host a prototype implementation of JSR 335 suitable for inclusion in JDK 8, the Reference Implementation of Java SE 8.The prototype compiler is being implemented in OpenJDK.

• Source code is available at http://hg.openjdk.java.net/lambda/lambda.
• Binaries at http://jdk8.java.net/lambda.

Full details about Lamda can be accessed here.

2. Project Jigsaw:

The original goal of this Project was to design and implement a module system focused narrowly upon the goal of modularizing the JDK, and to apply that system to the JDK itself. We expected the resulting module system to be useful to developers for their own code, and it would have been fully supported for that purpose, but it was not at the outset intended to be an official part of the Java SE Platform Specification.

Project Jigsaw Fundamentals: (from official page)

• Module dependences — The module system must replace the class path and its explicit enumeration of JAR files with a less error-prone system of named, versioned modules and explicit dependences between them. Where possible this approach should borrow from UNIX shared-library concepts. Most developers and deployers are quite comfortable with this model since it is used not only by shared libraries but also Maven, .NET, and most UNIX/Linux packaging systems.
• Resolution in all phases — Build-time, install-time, and run-time module resolution and linking must all be supported. UNIX has all three models and they are all still in use 40 years later.
• Fidelity across all phases — The set of modules seen by a library or application must be computed by the same algorithm at build time, install time, and run time.
• Encapsulation — If a module contains a type, whether defined therein or imported from some other module, then it must be possible to declare that it makes that type available for use by modules depending upon it, or that it does not do so.
• Versioning — The module system must support common version-string schemes such as those defined by OSGi and Maven and also those found in both proprietary and open-source software products. Version strings must be totally ordered but otherwise the module system must not impose any particular structure or semantics upon them. It must be possible to specify a range of allowable versions when declaring a module dependence.
• Optional modules — It must be possible to declare that a module depends optionally upon some other module. If that second module is available then it is resolved and linked normally. If it is not available, however, then no exception is thrown and no error is reported by the module system. A simple API must be provided so that a running program can test whether a particular optional module has been resolved and linked.
• Refactoring — It must be possible to refactor a module into a set of smaller modules, without breaking existing modules or applications that depend upon the original module (splitting). Likewise, it must be possible to refactor a set of modules so that they appear to be a single module, without breaking existing modules or applications that depend upon the original modules (aggregation).
• Substitution — It must be possible to declare that one module can substitute for another. This supports refactoring via aggregation and also allows a module to resolve against any one of a set of equivalent implementation modules. JREs from different vendors, e.g., can all declare that they are substitutes for the “java” module. An application module that requires only standard Java SE APIs can declare that it requires the “java” module rather than some specific JRE module, and that dependence will be satisfied by any one of those JREs.
• Module constraints on targets — In a module declaration it must be possible to declare that the module can only be used on target platforms with specific properties, e.g., particular operating systems, processor architectures, or display geometries. The resolution algorithm must ignore any module whose platform constraints are not satisfied by the target platform.
• Target constraints on modules — On a particular target platform it must be possible to declare that only modules with specific properties can be installed, e.g., particular authors, publishers, or licenses. The resolution algorithm must ignore any module that does not satisfy the target platform’s module constraints.
• Native code — The module system must provide a way to package both Java class files and native libraries in a single artifact and control linking in a similar way for both. The existing System.loadLibrary method and related methods must be enhanced to be module-aware. It must be possible for a native library in a Java module to have a native dependence upon another native library that is either in the same Java module, in some other Java module, or elsewhere in the target platform.
• Services — It must be possible to package service providers into modules so that they can be discovered via an enhanced version of the existing java.util.ServiceLoader API.
• Resources — It must be possible to package localization data into modules so that it can be discovered via an enhanced version of the existing java.util.ResourceBundle API.
• Read-only operation — The module system must be able to function at run time when running from a read-only volume. This is a security requirement in some scenarios and may also be required for some compliance regimes.
• Platform modularization — The module system must support a medium-grained modularization of the Java SE API whose minimal configuration defines an API roughly the size of the current Java ME CDC platform. It must provide a safety valve to prevent the JDK from continuing to grow without bound (e.g., a hypothetical java.3d API shouldn’t need to go into the base platform). It must be possible to provide subsets of the platform such as “headless” (no 2d/awt/swing/audio/sound) and “client” (no RMI, CORBA, etc.) commonly requested by developers of embedded SE and EE solutions. Finally, it must be possible to release and update logically-separate portions of the Java API separately.
• Package subsets — In support of platform modularization, it must be possible for the types defined in a Java package to be provided by more than one module yet still be loaded by the same class loader at run time. This is required so that CDC-sized subsets of large legacy packages such as java.util can be defined.
• Shared class loaders — In support of platform modularization, it must be possible to declare that the types defined in a specific set of modules must be loaded by the same class loader.

Further details about Jigsaw are available here.

Looking ahead to Java 9 areas of development would be:

• A self-tuning JVM,
• Massive Multicore scalability
• Hypervisor integration
• Improved native integration,
• Metaobject protocol
• big-data support,
• Reification,
• Adding tail calls and continuations,
• A new meta-object protocol to improve cross language support,
• multi-tenancy,
• RAS
• Resource management for cloud applications, and
• Heterogeneous compute models.

That’s all we know of Java 9 as of now, more, when we hear next.

We write latest and greatest in Tech Guides, Apple, iPhone, Tablets, Android,  Open Source, Latest in Tech, subscribe to us@geeknizeron Twitter OR on Facebook Fanpage, Google+: