The name reflection is used to describe code which is able to inspect other code in the same system (or itself).
For example, say you have an object of an unknown type in Java, and you would like to call a 'doSomething' method on it if one exists. Java's static typing system isn't really designed to support this unless the object conforms to a known interface, but using reflection, your code can look at the object and find out if it has a method called 'doSomething' and then call it if you want to.
So, to give you a code example of this in Java (imagine the object in question is foo) :
Method method = foo.getClass().getMethod("doSomething", null);
One very common use case in Java is the usage with annotations. JUnit 4, for example, will use reflection to look through your classes for methods tagged with the @Test annotation, and will then call them when running the unit test.
There are some good reflection examples to get you started at http://docs.oracle.com/javase/tutorial/reflect/index.html
And finally, yes, the concepts are pretty much similar in other statically typed languages which support reflection (like C#). In dynamically typed languages, the use case described above is less necessary (since the compiler will allow any method to be called on any object, failing at runtime if it does not exist), but the second case of looking for methods which are marked or work in a certain way is still common.
Update from a comment:
The ability to inspect the code in the system and see object types is
not reflection, but rather Type Introspection. Reflection is then the
ability to make modifications at runtime by making use of
introspection. The distinction is necessary here as some languages
support introspection, but do not support reflection. One such example
There are several differences between
Hashtable in Java:
Hashtable is synchronized, whereas
HashMap is not. This makes
HashMap better for non-threaded applications, as unsynchronized Objects typically perform better than synchronized ones.
Hashtable does not allow
null keys or values.
HashMap allows one
null key and any number of
One of HashMap's subclasses is
LinkedHashMap, so in the event that you'd want predictable iteration order (which is insertion order by default), you could easily swap out the
HashMap for a
LinkedHashMap. This wouldn't be as easy if you were using
Since synchronization is not an issue for you, I'd recommend
HashMap. If synchronization becomes an issue, you may also look at
When you declare a reference variable (i.e., an object), you are really creating a pointer to an object. Consider the following code where you declare a variable of primitive type
In this example, the variable
intand Java will initialize it to
0for you. When you assign the value of
10on the second line, your value of
10is written into the memory location referred to by
But, when you try to declare a reference type, something different happens. Take the following code:
The first line declares a variable named
num, but it does not actually contain a primitive value yet. Instead, it contains a pointer (because the type is
Integerwhich is a reference type). Since you have not yet said what to point to, Java sets it to
null, which means "I am pointing to nothing".
In the second line, the
newkeyword is used to instantiate (or create) an object of type
Integer, and the pointer variable
numis assigned to that
NullPointerException(NPE) occurs when you declare a variable but did not create an object and assign it to the variable before trying to use the contents of the variable (called dereferencing). So you are pointing to something that does not actually exist.
Dereferencing usually happens when using
.to access a method or field, or using
[to index an array.
If you attempt to dereference
numbefore creating the object you get a
NullPointerException. In the most trivial cases, the compiler will catch the problem and let you know that "
num may not have been initialized," but sometimes you may write code that does not directly create the object.
For instance, you may have a method as follows:
In which case, you are not creating the object
obj, but rather assuming that it was created before the
doSomething()method was called. Note, it is possible to call the method like this:
In which case,
null, and the statement
obj.myMethod()will throw a
If the method is intended to do something to the passed-in object as the above method does, it is appropriate to throw the
NullPointerExceptionbecause it's a programmer error and the programmer will need that information for debugging purposes.
In addition to
NullPointerExceptions thrown as a result of the method's logic, you can also check the method arguments for
nullvalues and throw NPEs explicitly by adding something like the following near the beginning of a method:
Note that it's helpful to say in your error message clearly which object cannot be
null. The advantage of validating this is that 1) you can return your own clearer error messages and 2) for the rest of the method you know that unless
objis reassigned, it is not null and can be dereferenced safely.
Alternatively, there may be cases where the purpose of the method is not solely to operate on the passed in object, and therefore a null parameter may be acceptable. In this case, you would need to check for a null parameter and behave differently. You should also explain this in the documentation. For example,
doSomething()could be written as:
Finally, How to pinpoint the exception & cause using Stack Trace
Sonar with find bugs can detect NPE. Can sonar catch null pointer exceptions caused by JVM Dynamically
Now Java 14 has added a new language feature to show the root cause of NullPointerException. This language feature has been part of SAP commercial JVM since 2006.
In Java 14, the following is a sample NullPointerException Exception message: