Friday, July 18, 2014

Finding java version from .class file

Below are simple steps to find on what java version a .class file is compiled upon.

Every compiled class has major minor version put in by the compiler. The first 4 bytes of the class file is the magic number used to identify that it is class file format of java and magic number is 0xCAFEBABE.
The next 4 bytes of the file contains minor version followed by major version (each of 2 bytes).

The below are values used for identifying each version:

Java version
HEXA Decimal value
Decimal value
8
0x34
52
7
0x33
51
6
0x32
50
5
0x31
49
1.4
0x30
48
1.3
0x2F
47
1.2
0x2E
46
1.1
0x2D
45

 
JVM checks whether the class being executed is supported on the current version of JRE or not. If an error occurs about version mismatch it prints the value in DECIMAL and not in HEXADECIMAL .

For example:
If a java file compiled on JDK 5.0 is executed on a JRE of version lower than 5.0 then always the below error will occur (meaning the version number won’t change)
Unsupported major.minor version 49.0

Most simple of way checking the HEXA values of the magic and version numbers of the class file is to open in a text editor which supports HEXA mode and check for the major/minor version as show in the below screen shot.

From the above image it is clear that the Version of java on which the java file is compiled is JAVA 7 (0033 corresponds to Java 7 from the above table).

Refer JVM Specs in order to understand the JAVA class file format.

Tuesday, May 13, 2014

Optional Type in Java 8

There are many new features like lambdas introduced in Java 8, but I thought of going through smaller ones. The current topic is one of such smaller changes but on the contrary quite interesting J

We all know that code is never expected to fail with a NullPointerException and proper handling of it is required. Doing NULL check is a very basic thing and expected out of every programmer. 

A new type Optional was introduced to indicate that the return value may be NULL and sort of enforces programmers to do a NULL check. I won't be discussing this feature in every minute detail for the reason there are many pretty good sources out there explaining the same. Blog Tired of Null Pointer Exceptions explains this very well.

The point that I want to emphasize here is about the programs which return NULL. One of the primary reason for introduction of Optional is because most of the programmers forget to do a NULL check but at the same time the code which returns NULL is forgiven. In my view returning NULL value is a bigger crime than not doing a NULL check and the reason being NULL shouldn't be used as an alternative for expressing nothing. Use an empty value instead of NULL; for example return an empty list instead of NULL. 

Also if you carefully go through the JAVA documentation for Optional.get() it says 'If a value is present in this Optional, returns the value, otherwise throws NoSuchElementException.' What this means? Now there are very good chances that programmers start facing more NoSuchElementException instead of NullPointerException.

In order to express the seriousness of the mistake in which the code returns a NULL value is presented very well in the blog post Empty !!!..