0

I'm currently debugging some code that looks like this:

if (!clazz.isAssignableFrom(TypeName.class)){
    return
}

Using the standard Eclipse debugging tools, I can inspect both classes and see that their names are both

com.packagename.package1.TypeName

I'd like to step into the isAssignableFrom() method that is being used to fail this evaluation when it seems like it should be passing to narrow down what the issue is. I've followed the answers from this question however, when attempting to "Step Into" isAssignableFrom(), Eclipse skips the line and goes right to the return statement, providing me no information about why two of the exact same type somehow aren't assignable from or to one another.

How can I step into this method to see which comparison is failing in an effort to fix the obvious issue with my TypeName class?

Community
  • 1
  • 1
seanr8
  • 411
  • 1
  • 5
  • 15

2 Answers2

1

You cannot. It's a native method. There is no Java implementation to step into; it's baked into the JVM.

Louis Wasserman
  • 191,574
  • 25
  • 345
  • 413
  • Is there any way to get an idea of what might be causing an issue like this? I assume that the JVM isn't returning the incorrect result of the method and I definitely need to figure out what I did to make two seemingly identical types fail this test. – seanr8 Dec 21 '16 at 22:02
  • 1
    My first guess would be classloader shenanigans or some other logic issue in your code that you're just not seeing (always a possibility). – Louis Wasserman Dec 21 '16 at 22:34
0

Likely the classes are loaded from different classloaders.

You could check with cls.getClassLoader().hashCode()

k5_
  • 5,450
  • 2
  • 19
  • 27