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);
method.invoke(foo, 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
is C++
There are several differences between HashMap
and 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 null
values.
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 Hashtable
.
Since synchronization is not an issue for you, I'd recommend HashMap
. If synchronization becomes an issue, you may also look at ConcurrentHashMap
.
Best Answer
What is a raw type?
The Java Language Specification defines a raw type as follows:
JLS 4.8 Raw Types
Here's an example to illustrate:
Here,
MyType<E>
is a parameterized type (JLS 4.5). It is common to colloquially refer to this type as simplyMyType
for short, but technically the name isMyType<E>
.mt
has a raw type (and generates a compilation warning) by the first bullet point in the above definition;inn
also has a raw type by the third bullet point.MyType.Nested
is not a parameterized type, even though it's a member type of a parameterized typeMyType<E>
, because it'sstatic
.mt1
, andmt2
are both declared with actual type parameters, so they're not raw types.What's so special about raw types?
Essentially, raw types behaves just like they were before generics were introduced. That is, the following is entirely legal at compile-time.
The above code runs just fine, but suppose you also have the following:
Now we run into trouble at run-time, because
names
contains something that isn't aninstanceof String
.Presumably, if you want
names
to contain onlyString
, you could perhaps still use a raw type and manually check everyadd
yourself, and then manually cast toString
every item fromnames
. Even better, though is NOT to use a raw type and let the compiler do all the work for you, harnessing the power of Java generics.Of course, if you DO want
names
to allow aBoolean
, then you can declare it asList<Object> names
, and the above code would compile.See also
How's a raw type different from using
<Object>
as type parameters?The following is a quote from Effective Java 2nd Edition, Item 23: Don't use raw types in new code:
To illustrate the point, consider the following method which takes a
List<Object>
and appends anew Object()
.Generics in Java are invariant. A
List<String>
is not aList<Object>
, so the following would generate a compiler warning:If you had declared
appendNewObject
to take a raw typeList
as parameter, then this would compile, and you'd therefore lose the type safety that you get from generics.See also
<E extends Number>
and<Number>
?How's a raw type different from using
<?>
as a type parameter?List<Object>
,List<String>
, etc are allList<?>
, so it may be tempting to just say that they're justList
instead. However, there is a major difference: since aList<E>
defines onlyadd(E)
, you can't add just any arbitrary object to aList<?>
. On the other hand, since the raw typeList
does not have type safety, you canadd
just about anything to aList
.Consider the following variation of the previous snippet:
The compiler did a wonderful job of protecting you from potentially violating the type invariance of the
List<?>
! If you had declared the parameter as the raw typeList list
, then the code would compile, and you'd violate the type invariant ofList<String> names
.A raw type is the erasure of that type
Back to JLS 4.8:
In simpler terms, when a raw type is used, the constructors, instance methods and non-
static
fields are also erased.Take the following example:
When we use the raw
MyType
,getNames
becomes erased as well, so that it returns a rawList
!JLS 4.6 continues to explain the following:
The following bug report contains some thoughts from Maurizio Cimadamore, a compiler dev, and Alex Buckley, one of the authors of the JLS, on why this sort of behavior ought to occur: https://bugs.openjdk.java.net/browse/JDK-6400189. (In short, it makes the specification simpler.)
If it's unsafe, why is it allowed to use a raw type?
Here's another quote from JLS 4.8:
Effective Java 2nd Edition also has this to add:
In summary, raw types should NEVER be used in new code. You should always use parameterized types.
Are there no exceptions?
Unfortunately, because Java generics are non-reified, there are two exceptions where raw types must be used in new code:
List.class
, notList<String>.class
instanceof
operand, e.g.o instanceof Set
, noto instanceof Set<String>
See also
Collection<String>.class
Illegal?