Tag Archives: JSR

Java 8 Features Tutorial

via Java 8 Features Tutorial – The ULTIMATE Guide (PDF Download).

Table Of Contents

1. Introduction
2. New Features in Java language
2.1. Lambdas and Functional Interfaces
2.2. Interface Default and Static Methods
2.3. Method References
2.4. Repeating annotations
2.5. Better Type Inference
2.6. Extended Annotations Support
3. New Features in Java compiler
3.1. Parameter names
4. New Features in Java libraries
4.1. Optional
4.2. Streams
4.3. Date/Time API (JSR 310)
4.4. Nashorn JavaScript engine
4.5. Base64
4.6. Parallel Arrays
4.7. Concurrency
5. New Java tools
5.1. Nashorn engine: jjs
5.2. Class dependency analyzer: jdeps
6. New Features in Java runtime (JVM)
7. Conclusions
8. Resources

JDK 7 tutorial: How to use Java 1. 7 Multiple Catch Block with example

via How to use Java 1. 7 Multiple Catch Block with example – JDK 7 tutorial.

As release of JDK 7 approaching General Availability (GA) on 2011/07/28, I thought to have a look on language enhancement as part of project coin, also called as Small language enhancements or JSR 334. Though there is not any major changes like Enum or Generics of Java 1.5,  but they are still very useful, in terms of simplifying your day to day programming task. Some of the interesting changes are allowing String in Switch cases, inclusion of fork join framework in JDK itself , , type inference using diamond operator, automatic resource management using  try with resource feature, and ability to catch multiple Exception in single catch block . In this Java 7 tutorial, we will learn how multi catch block of JDK 1.7 makes Exception handling code simpler and elegant. Multiple catch block will allow you to catch multiple exceptions in one block but it’s only available in JDK7 and you need to compiler your code with source 1.7. This article also shows you how to use JDK 7 multiple catch block with example. I also recommend book Java 7 Recipes: A Problem-Solution Approach to learn more about all the changes made in JDK 1.7 and how to make effective use of them.

Using JCache with CDI

via Using JCache with CDI | Voxxed.

The JCache JSR (JSR-107), finalized in late 2014, provides a standard mechanism to cache values in a map-like structure using a key. There are a number of different JCache implementations to choose from, and swapping between them should be no more difficult than swapping out .jar files on the classpath. In these examples I will use Hazelcast – it provides a distributed cache, giving the benefit that all of the nodes in the cluster are using the same cache and working consistently.

Java EE Security API (JSR 375) Update

via Java EE Security API (JSR 375) Update (The Aquarium).

From the current set of Java EE 8 JSRs, ‘Java EE Security API’ (JSR 375) is the latest one as it was only approved in December last year. It was started later than the other JSRs. Nevertheless, the EG is now very active (+200 messages just for last month!).

Obviously, this effort need a strong focus as ‘Security’ can mean a lot of things. And depending on whom you ask, you will high likely have different views. So to EG is currently busy filtering and consolidating ideas. In addition, one thing that is clear is that having a common ground for discussions is really needed. So the EG is also working on defining a security API terminology; i.e. a common vocabulary to enable concise and accurate communication amongst the EG and the community (see here). This may sounds obvious but it’s not; e.g. what’s the difference between a user store and a user realm?

Video: Using JCache (JSR-107) with Oracle Coherence

JEP 213: Milling Project Coin

Issue 8042880
Depends 8062373: Project Coin: diamond and inner classes
Relates to 8061549: Complete the removal of underscore from the set of legal identifier names
7196163: Project Coin: Allow effectively final variables to be used as resources in try-with-resources
7196160: Project Coin: allow @SafeVarargs on private methods


The small language changes included in Project Coin / JSR 334 as part of JDK 7 / Java SE 7 have been easy to use and have worked well in practice. However, several amendments could address a few rough edges of those changes. In addition, using underscore ("_") as an identifier, which generates a warning as of Java SE 8, should be turned into an error in Java SE 9.


This JEP does not propose to run a “Coin 2.0” effort or to generally solicit new language proposals.


Four small amendments to the Java Programming Language are proposed:

  1. Allow @SafeVargs on private instance methods. The @SafeVarargsannotation can only be applied to methods which cannot be overridden, including static methods and final instance methods. Private instance methods are another use case that @SafeVargs could accommodate.
  2. Allow effectively-final variables to be used as resources in the try-with-resources statement. The final version of try-with-resources statement in Java SE 7 requires a fresh variable to be declared for each resource being managed by the statement. This was a change from earlier iterations of the feature. The public review draft of JSR 334 discusses the rationale for the change from the early draft review version of try-with-resource which allowed an expression managed by the statement. The JSR 334 expert group was in favor of an additional refinement of try-with-resources: if the resource is referenced by a final or effectively final variable, a try-with-resources statement can manage the resource without a new variable being declared. This restricted expression being managed by a try-with-resources statement avoids the semantic issues which motivated removing general expression support. At the time the expert group settled on this refinement, there was insufficient time in the release schedule to accommodate the change.
  3. Allow diamond with inner classes if the argument type of the inferred type is denotable. Because the inferred type using diamond with an inner class constructor could be outside of the set of types supported by the signature attribute, using diamond with inner classes was disallowed in Java SE 7. As noted in the JSR 334 proposed final draft, it would be possible to ease this restriction if the inferred type was denotable.
  4. Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.

In the space of Java language changes, these refinements are very small changes. The @SafeVarags change might only involve changing a sentence or two of the specification with a similarly sized change in javac. However, as with any Java language change, care must be taken to handle all the pieces of the platform that need updating.


The language changes would require the usual unit and regression tests for javac. The JCK compiler suite would need to be updated, both positive tests and negative tests.

Java EE 8 Overview

Java EE 8 Overview

In this JavaOne session, Linda DeMichiel (Java EE 8 Specification Lead) gives an overview of what is currently planned for Java EE 8.

Linda starts by explaining the results of Oracle’s Java EE community surveys and the general thought process behind requirements gathering for Java EE 8.  She then gives technical details around some of the planned enhancements :

  • Enhanced support for HTML5 applications and other web tier features such as server-sent events, the new JSON-B JSR for binding JSON payload to Java objects, support for HTTP 2.0, the new MVC framework, etc.
  • Ease of development including CDI alignment and ease of use with security interceptors, extended use of CDI scopes, the introduction of CDI based model to simplify Message Driven Beans, etc.
  • Continued support for portable cloud applications. The sessions goes over the planned Java EE Management API but also touches on the new upcoming Security JSR.

Finally, Linda concludes her session by explaining how you can contribute and help to shape the next version of Java EE, i.e. JSR 366.

Watching Linda’s session replay will give you a good idea on where the EG wants to go with Java EE 8.