We Keep Coding

Finding out the type of a set [duplicate]

This question already has answers here:
Java generics type erasure: when and what happens?
(7 answers)
Closed 7 months ago.
Given a Set<X>, I want to write a method that acts differently depending on the class X is. In actuality, I'd have 2 cases: A or B.
The method looks like:
public<X> boolean myMethod(Set<X> mySet)
{
// if X is actually the class A
...
// if X is B
...
}
I am not sure how to check this. I tried X::getClass, but it wouldn't let me use equals method.

In a general sense, this is not possible
Due to type erasure, a Java Set does not have a generic type at runtime. Generics act as compile-time checks on the objects passed into methods, but consequently the specific values are not available at runtime. A Set<String> is the same class as a Set<Map<Integer, Thread>> and the same class as a bare Set.
Potential workaround with class parameter
If you really need to know this, you could change the signature of your method to be:
public <X> boolean myMethod(Set<X> mySet, Class<X> clazz)
Now you have a Class instance available at runtime, which is guaranteed to be compatible with X. This you can introspect (e.g. String.class.isAssignableFrom(clazz)).
There are two drawbacks to this approach: firstly, you'll have to explicitly pass in the extra parameter each time the method is called. Secondly, if A and B can be subclasses of one another, this is not going to work; you could pass in e.g. B.class even when the generic parameter was A.
However, this feels like a code smell
You shouldn't be trying to do fundamentally different things based on a generic parameter. Instead of switching behaviour in your method here, do something different within the classes A and B:
public<X> boolean myMethod(Set<X> mySet)
{
boolean result = false;
for (X x : mySet) {
result &= x.doSomething();
}
return result;
}
class A implements MyDoSomethingInterface {
public boolean doSomething() {
// Here you put the logic for "if X is A"
}
}
class B implements MyDoSomethingInterface {
public boolean doSomething() {
// Here you put the logic for "if X is B"
}
}
And if your reaction is that this won't work because A and B are built-in classes, you'll need to wrap them in your own domain objects (which is the correct approach anyway because you want to associate this extra behaviour with them).

I suggest you take one object from set and check class of single object
like below, please check
public<X> boolean myMethod(Set<X> mySet)
{
Object tmpObj = null;
for(Object obj : set){
tmpObj = obj;
break;
}
if(tmpObj instanceof A){
// if X is actually the class A
}else if(tmpObj instanceof B){
// // if X is B
}
}

ClassCastException vs instanceOf in Generic Collections

I have a class that implements Collection<E>.
When I check if my collection contains an item the interface's method give a parameter of object, when it's have to be an <E>
Do you think it's "normal" to write this code:
#Override
public boolean contains(Object o)
{
E item;
try
{
item=(E) o;
}
catch (ClassCastException e)
{
return false;
}
//check if contains "item"
}
I know that normally it's a terrible idea to check the type of an object with try,catch, but in a generic collection I can't check with instanceOf and I don't find a better solution.

From the javadoc it says:
Throws: ClassCastException - if the type of the specified element is incompatible with this collection (optional)
So it is perfectly acceptable to code it like this:
#Override
public boolean contains(Object o) {
T item = (T) o;
// ...
}
and if the cast fails a ClassCastException is thrown.
You certainly should not hide that exception and quietly return false - that could leave many potential bugs in the user's code.

If your collection class has E as a generic type parameter with no bounds, your check is useless -- the cast can't possibly fail, because the cast is completely unchecked. E, if it is unbounded, is erased to Object, and your cast will be item=(Object) o;, which cannot fail. It could lead to other failures in other places down the line, but it can't fail here, and if it fails in other places later your try-catch doesn't catch it.
The fact you can't use instanceof should have told you something -- the reason instanceof cannot be used is because it is a runtime check, which needs the class at runtime to check, and you don't have the class at runtime. Trying to have a cast fail is also a runtime check, so it does not improve your situation at all. Relying on a cast to fail only works in the same situations that instanceof works, so it NEVER makes sense to "use a cast because instanceof doesn't work".
When you write generic code, it is important to consider what the code looks like after type erasure. When you erase generic code into non-generic code (by adding casts in appropriate places), the code should work the same. If it is not possible to write the code as non-generic, then it cannot be written as generic either.
#Override
public boolean contains(Object o)
{
Object item;
try
{
item= o;
}
catch (ClassCastException e) // does this make sense?
{
return false;
}
//check if contains "item"
}

You are allowed to throw ClassCastException in this method, so You must not check type. Read javadoc of Collection interface.

Imho you should use equals / hashCode methods of parameter object to check if its present in your collection. Casting or instanceof is not required at all.

Type checking with generics

Here's an illustrational class:
class TypeChecker<T> {
boolean isGood(Object something) {
// won't compile
return (something instanceof T);
// maybe works, but oh so ugly!
try {
#SuppressWarnings("unchecked")
T tmp = ((T) something);
}catch(ClassCastException e) {
return false;
}
return true;
}
}
Is there any nice way to do this?
The particular purpose is a bit different than in the example, but the idea is the same - to check if a variable of type T (parameter) can hold certain object.

Use Class#isInstance.
class TypeChecker<T> {
private Class<T> ofType;
TypeChecker(Class<T> ofType) {
this.ofType = ofType;
}
boolean isGood(Object obj) {
return ofType.isInstance(obj);
}
}
Or just use the Class instead of making a wrapper object around it if all you need is the isInstance check.
There is not another way to perform run-time type checking dynamically. You must use a Class.
isInstance has the same semantics as instanceof (except that the left and right hand sides are flipped) so
"hello world" instanceof String
String.class.isInstance("hello world")
both are true.
Also, your 'maybe works' snippet, no that does not work. Generics are erased so unchecked casts do not happen at run-time. That is why they are unchecked. The ClassCastException will never throw. Using exceptions to determine logical flow is not good to begin with.

Check if an object belongs to a class in Java [duplicate]

This question already has answers here:
How to determine an object's class?
(13 answers)
Closed 9 years ago.
Is there an easy way to verify that an object belongs to a given class? For example, I could do
if(a.getClass() = (new MyClass()).getClass())
{
//do something
}
but this requires instantiating a new object on the fly each time, only to discard it. Is there a better way to check that "a" belongs to the class "MyClass"?

The instanceof keyword, as described by the other answers, is usually what you would want.
Keep in mind that instanceof will return true for superclasses as well.
If you want to see if an object is a direct instance of a class, you could compare the class. You can get the class object of an instance via getClass(). And you can statically access a specific class via ClassName.class.
So for example:
if (a.getClass() == X.class) {
// do something
}
In the above example, the condition is true if a is an instance of X, but not if a is an instance of a subclass of X.
In comparison:
if (a instanceof X) {
// do something
}
In the instanceof example, the condition is true if a is an instance of X, or if a is an instance of a subclass of X.
Most of the time, instanceof is right.

If you ever need to do this dynamically, you can use the following:
boolean isInstance(Object object, Class<?> type) {
return type.isInstance(object);
}
You can get an instance of java.lang.Class by calling the instance method Object::getClass on any object (returns the Class which that object is an instance of), or you can use class literals (for example, String.class, List.class, int[].class). There are other ways as well, through the reflection API (which Class itself is the entry point for).

Use the instanceof operator:
if(a instanceof MyClass)
{
//do something
}

I agree with the use of instanceof already mentioned.
An additional benefit of using instanceof is that when used with a null reference instanceof of will return false, while a.getClass() would throw a NullPointerException.

Try operator instanceof.

The usual way would be:
if (a instanceof A)
However, there are cases when you can't do this, such as when A in a generic argument.
Due to Java's type erasure, the following won't compile:
<A> boolean someMethod(Object a) {
if (a instanceof A)
...
}
and the following won't work (and will produce an unchecked cast warning):
<A> void someMethod(Object a) {
try {
A casted = (A)a;
} catch (ClassCastException e) {
...
}
}
You can't cast to A at runtime, because at runtime, A is essentially Object.
The solutions to such cases is to use a Class instead of the generic argument:
void someMethod(Object a, Class<A> aClass) {
if (aClass.isInstance(a)) {
A casted = aClass.cast(a);
...
}
}
You can then call the method as:
someMethod(myInstance, MyClass.class);
someMethod(myInstance, OtherClass.class);

Java Generics: Generic type defined as return type only

I'm looking at some GXT code for GWT and I ran across this use of Generics that I can't find another example of in the Java tutorials. The class name is com.extjs.gxt.ui.client.data.BaseModelData if you want to look at all of the code. Here are the important parts:
private RpcMap map;
public <X> X get(String property) {
if (allowNestedValues && NestedModelUtil.isNestedProperty(property)) {
return (X)NestedModelUtil.getNestedValue(this, property);
}
return map == null ? null : (X) map.get(property);
}
X is defined nowhere else in the class or anywhere in the hierarchy, and when I hit "go to declaration" in eclipse it just goes to the <X> in the public method signature.
I've tried to call this method with the following two examples to see what happens:
public Date getExpiredate() {
return get("expiredate");
}
public String getSubject() {
return get("subject");
}
They compile and show no errors or warnings. I would think at the very least I would have to do a cast to get this to work.
Does this mean that Generics allow a magic return value that can be anything and will just blow up at runtime? This seems counter to what generics are supposed to do. Can anyone explain this to me and possibly give me a link to some documentation that explains this a little better? I've went through Sun's 23 page pdf on generics and every example of a return value is defined either at the class level or is in one of the parameters passed in.

The method returns a type of whatever you expect it to be (<X> is defined in the method and is absolutely unbounded).
This is very, very dangerous as no provision is made that the return type actually matches the returned value.
The only advantage this has is that you don't have to cast the return value of such generic lookup methods that can return any type.
I'd say: use such constructs with care, because you lose pretty much all type-safety and gain only that you don't have to write an explicit cast at each call to get().
And yes: this pretty much is black magic that blows up at runtime and breaks the entire idea of what generics should achieve.

The type is declared on the method. That's that "<X>" means. The type is scoped then to just the method and is relevant to a particular call. The reason your test code compiles is that the compiler tries to determine the type and will complain only if it can't. There are cases where you have to be explicit.
For example, the declaration for Collections.emptySet() is
public static final <T> Set<T> emptySet()
In this case, the compiler can guess:
Set<String> s = Collections.emptySet();
But if it can't, you must type:
Collections.<String>emptySet();

I was just trying to figure out the same thing with a GXT class. Specifically I was trying to call a method with the signature of:
class Model {
public <X> X get(String property) { ... }
}
To call the above method from your code and have it cast X to a String I do the following:
public String myMethod(Data data) {
Model model = new Model(data);
return model.<String>get("status");
}
The above code will call the get method and tell it that the type being returned by X should be returned as a String.
In the case where the method is in the same class as you, I've found that I have to call it with a "this.". For example:
this.<String>get("status");
As others have said, this is rather sloppy and dangerous by the GXT team.

BaseModelData raises unchecked warnings when compiled, because it is unsafe. Used like this, your code will throw a ClassCastException at runtime, even though it doesn't have any warnings itself.
public String getExpireDate() {
return get("expiredate");
}

Interesting note, from RpcMap (GXT API 1.2)
get's header:
public java.lang.Object get(java.lang.Object key)
Having a generic parameter of <X> in there that's uninstantiated has the same effect, except you don't have to say "Object" all over the place. I agree with the other poster, this is sloppy and a bit dangerous.

Yes, this is dangerous. Normally, you'd protect this code like so:
<X> getProperty(String name, Class<X> clazz) {
X foo = (X) whatever(name);
assert clazz.isAssignableFrom(foo);
return foo;
}
String getString(String name) {
return getProperty(name, String.class);
}
int getInt(String name) {
return getProperty(name, Integer.class);
}