A "catch" with static method calls....

I am quite puzzled by the following.

There is class which which creates an instance of a class from a 3d party library, as follows:

import com.3dparty.enterprise.notify.MessageListenerService;

public class StaticMethodInvocationTest

{

private static final String SOME_STRING = "someString";

public StaticMethodInvocationTest()

throws Exception

{

//try

//{

MessageListenerService service = newMessageListenerService(40000);

//}

//catch (Exception e)

//{

//e.printStackTrace();

//}

}

static String getSomeString()

{

return SOME_STRING;

}

public static void main(String[] args)

{

System.out.println( StaticMethodInvocationTest.getSomeString());

}

}

Note the static method getSomeString(). All it does is return a constant. As one would expect, once the code is compiled, this method can be called with or without the presence of the 3d party library, because it does not make any references to the 3d-party classes. And in fact, it works without the 3d party jar just fine.

Now: note the try/catch block that's commented out. If I un-comment that block and compile the code, then it will still run fine when the library jar is in the classpath, but fail with a "ClassNotFoundException", if the library is removed from the classpath.

Why? The only thing that changed in this example is that now we have a "catch" for any exception that COULD be thrown from the "new", but when we call the static method, we do not create any instances...of anything!

I ran this example on Sun JDK 1.4 and JRockit 1.5_6 with same results.

Unfortunately, for me this is more than just a curiosity. Understanding what's going on here may help me avoid some very annoying problem, so I'd appreciate any insights. Thanks!

- Alex

Message was edited by:

alex_yershov

[1953 byte] By [alex_yershova] at [2007-11-26 19:29:13]
# 1

Use code tags when you post code.

The origins of the problem has to do with the fact that the library method is throwing a custom exception I would guess.

I am not really sure why that would cause the problem you are seeing though.

For a solution try catching Throwable rather than Exception and remove the throws clause to see if that changes the behavior.

jschella at 2007-7-9 21:57:27 > top of Java-index,Java Essentials,Java Programming...
# 2

Ok, here's one problem: The class loading process is not guaranteed by the java spec to always occur ONLY when you actually USE the class.

From the 12.2.1 of the jvm spec:

The loading process is implemented by the class ClassLoader and its subclasses. Different subclasses of ClassLoader may implement different loading policies. In particular, a class loader may cache binary representations of classes and interfaces, prefetch them based on expected usage, or load a group of related classes together.

So the behavior of your code is not defined. Furthermore, it is not guaranteed that you will always be able to perform static initialization of your class when you comment out the try/catch stuff.

I know that when you catch an exception, the compiler checks to see if that exception could have been thrown by the enclosing code (for java.lang.Exception, it always can, because java.lang.Exception is a superclass of java.lang.RuntimeException. However, this doesn't mean that it doesn't check what kind of exceptions can be thrown). It's possible that this is manifesting itself in the class file somewhere?

The best way to solve your problem is to compile the class both ways, run them both through javap, and look at the difference between the two compilations. Look for changes to exception tables, the constants table, and method signatures, as well as look for any synthetic members. All of those could potentially be the cause of early class loading. That should give you an idea of why it expects that class to exist.'

I would check that for you, but I don't have a copy of the library to compile with.

- Adam

guitar_man_Fa at 2007-7-9 21:57:27 > top of Java-index,Java Essentials,Java Programming...
# 3
Thank you all for your replies.
alex_yershova at 2007-7-9 21:57:27 > top of Java-index,Java Essentials,Java Programming...