Table Of Contents
- 1. Introduction
- 2. New Features in Java language
- 3. New Features in Java compiler
- 4. New Features in Java libraries
- 5. New Java tools
- 6. New Features in Java runtime (JVM)
- 7. Conclusions
- 8. Resources
This site is about Latest NEWS, Articles, Videos, Books, Course, Presentations, Tips & Tricks related to I.T Pro's
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.
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.
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?
|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:
@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.
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.
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 :
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.