On Wed, 17 Jun 2015 22:09:09 +0200, "Markus KARG" <markus@headcrashing.eu>
wrote:
> Mark,
>
> the chapters you describe list explicitly the exceptions that can
happen,
> and the causes. None of them covers "a class is referenced that has a
> non-referenced method that has a non-existent class".
I think you fail to see the meaning of "resolution of symbolic references"
and the implications of JLS 12.3. A referenced class (be it in a method
signature or body) in the java code, has a symbolic reference (ie: a String
with type information, for simplicity: the fully qualified name) in the
bytecode. A JVM implementation can choose to resolve those to actual
classes at classloading time, or when it really needs it (eg if the method
is called). Depending on the specific JVM implementation, this means that a
class with a method that has a type in its signature that is not available
at runtime might either fail at classloading time or at runtime when - as
demonstrated by Vladimir - you enumerate the methods of the class using
reflection.
> Even with early resolution, the JLS does not cover the case we have,
which
> is containing non-existent classes in non-referenced methods of
referenced
> classes!
Yes it does.
> The devil's in the details, right? ;-)
>
> Hence we're still safe.
>
> If that won't work, nobody could write a Java EE program and compile and
> test it agains the official javaee.jar, as that one not even contains
ANY
> byte code but SOLELY declarations. And that one's an official JAR from
the
> makers of Java!
Sorry, but that doesn't make any sense at all. The "official" JavaEE jar
does contain bytecode: interfaces and some supporting classes like
exceptions.
Mark
