Difference between java 7 and java 8

Java 7

Java 8

Features Added: -Support for dynamically-typed languages (InvokeDynamic): Extensions to the JVM, the Java language, and the Java SE API to support the implementation of dynamically-typed languages at performance levels near to that of the Java language itself - Strict class-file checking: Class files of version 51 (SE 7) or later must be verified with the typechecking verifier; the VM must not fail over to the old inferencing verifier. - Small language enhancements (Project Coin): A set of small language changes intended to simplify common, day-to-day programming tasks: Strings in switch statements, try-with-resources statements, improved type inference for generic instance creation (\"diamond\"), simplified varargs method invocation, better integral literals, and improved exception handling (multi-catch) - Upgrade class-loader architecture: A method that frees the underlying resources, such as open files, held by a URLClassLoader - Concurrency and collections updates: A lightweight fork/join framework, flexible and reusable synchronization barriers, transfer queues, concurrent linked double-ended queues, and thread-local pseudo-random number generators. - Internationalization Upgrade: Upgrade on Unicode 6.0, Locale enhancement and Separate user locale and user-interface locale. - More new I/O APIs for the Java platform (NIO.2), NIO.2 filesystem provider for zip/jar archives, SCTP, SDP, TLS 1.2 support. - Security & Cryptography implemented Elliptic-curve cryptography (ECC). - Upgrade to JDBC 4.1 and Rowset 1.1. - XRender pipeline for Java 2D, Create new platform APIs for 6u10 graphics features, Nimbus look-and-feel for Swing, Swing JLayer component, Gervill sound synthesizer. - Upgrade the components of the XML stack to the most recent stable versions: JAXP 1.4, JAXB 2.2a, and JAX-WS 2.2. - Enhanced Managed Beans.

Code name is Spider. Features Added: - JSR 335, JEP 126: Language-level support for lambda expressions. - JSR 223, JEP 174: Project Nashorn, a JavaScript runtime which allows developers to embed JavaScript code within applications. - JSR 308, JEP 104: Annotation on Java Types. - Unsigned Integer Arithmetic. - JSR 337, JEP 120: Repeating annotations. - JSR 310, JEP 150: Date and Time API. - JEP 178: Statically-linked JNI libraries. - JEP 153: Launch JavaFX applications (direct launching of JavaFX application JARs). - JEP 122: Remove the permanent generation. - Java 8 is not supported on Windows XP. But as of JDK 8 update 5, it still can run under Windows XP after forced installation by directly unzipping from the installation executable.

Order of catching exceptions in Java

Order of Catching Exceptions:
1: Checked exception
2: Run time Exceptions:

when catching exceptions you want to always catch the most specific first and then the most generic (as RuntimeException or Exception).
For instance, imagine you would like to catch the StringIndexOutOfBoundsException thrown by the String.charAt(index) method but your code could also throw a NullPointerException, here's how you could go to catch the exceptions

For Example:

String s = null;
try {
  s.charAt(10);
} catch ( NullPointerExeption e ) {
  System.out.println("null");
  e.printStackTrace();
} catch ( StringIndexOutOfBoundsException e ) {
  System.out.println("String index error!");
  e.printStackTrace();
} catch ( RuntimeException e ) {
  System.out.println("runtime exception!");
  e.printStackTrace();
}

--------------------------------------------------------------
So, with this order, I am making sure the exceptions are caught correctly and they are not tripping over one another, if it's a NullPointerException it enters the first catch,
if a StringIndexOutOfBoundsException it enters the second and finally if it is something else that is a RuntimeException (or inherits from it, like a IllegalArgumentException) it enters the third catch.

Your case is correct as IOException inherits from Exception and RuntimeException also inherits from Exception, so they will not trip over one another.

It's also a compilation error to catch a generic exception first and then one of it's descendants later, as in:

try {
  // some code here
} catch ( Exception e) {
  e.printStackTrace();
} catch ( RuntimeException e ) { // this line will cause a compilation error because it would never be executed since the first catch would pick the exception
  e.printStackTrace();
}
So, you should have the children first and then the parent exceptions.