Good point. And I don't think classpath exception would apply here. I'd be interested to hear if someone has actually seen this source code "in the wild".
This is a common misconception. The Classpath exception only applies to the class library, not to Hotspot (the core of the JVM implementation). The class library is also more tightly integrated with Hotspot than it used to be.
No, the classpath lists folders of classes, or actual paths to jars. Not paths to folders of jars.
> then, as far as i can recall, each class file can define package namespace so looking at the class path I have no clue what is there or what isn't so classpath errors felt more daunting to me
Classes are resolved from the root of the jar. Just inspect the jar to see what's in it. It's not common for third-party libraries to have conflicting package names.
I don't know why you're talking about tree searches.
If you plan to check, I won't bother (I had also planned to investigate later). You should also check on MethodHandles, since (as of the commit I linked) their parser also threw exceptions when it came across them.
If these things don't work, I'm very disappointed in the Android team, as this would be totally fake v51 classfile support.
I don't know. I remember problems with different classloaders, old versions of classes being deserialized, different versions of classes being sent over RMI, etc. Some of these probably resulted in ClassCastException. Some had thrown more specific Exceptions, am I supposed to remember the exact Exception that was thrown in each case? I'll probably know if you show me stacktrace. But I only know because I've encountered such problems. People working on the other end of our system would recognize different set of problems that results in this Exception or similiar.
Nano questions are bad, because you are really asking if candidate has had the exact same experience that you had. Some did, some didn't, it doesn't matter. Anybody will solve the problem within minutes, most probably googling the most promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or grepping the source tree, whatever).
Even auto-importing packages in IDE can cause problems - sometimes it imports from the wrong package. Is it enough reason to ask questions about "which package contains Hibernate Session class?" or even "which package contains ArrayList class?". I don't think so. Being aware of the problems good abstractions can cause (there's always a few problems) is IMHO enough, no need to remember everything you can google in 5 seconds.
EDIT: or maybe you meant that you just check if people know casting can throw ClassCastException, with that I'm OK.
I mean, just yesterday while I was running the JetBrains Rider install workflow, I hit a NullReferenceException (or whatever it's called in Java). That is a type-system related bug which arises only because Java's type system trivially represents illegal state.
It's not a commons-collections bug. There is nothing wrong with the existence of the classes being used from the commons-collections on their own. In fact, I'm sure they serve a purpose.
But, in an application that deserializes objects from an untrusted source, the fact that they happen to be on the class path leads to them being available to use in an undesirable manner.
Normally didn't do much in the partial class other than reference it.
You could override what it was doing in the main class file though if needed pretty easy. Again if it did break it was just aode and threw a normal exception in the designer, usually revolved around something that didn't work right in DesignMode so you had to check for that explicitly.
reply