We Keep Coding

Why throwing an exception tries to loads the class which extends Exception (though it is not executed) but not a regular class

I have the below classes.
I have manually compiled the classes using javac and ran the Driver class.
Later removed the entity.class and MyCustomException.class and ran the app like below.
java Driver test
The below error is complained about MyCustomException is missing but not about the Entity class. So, not clear why JRE complaining about MyCustomException class but not the Entity class.
Indeed I have removed code throw new MyCustomException(); but I did not encounter error about Entity class.
Caused by: java.lang.NoClassDefFoundError: com/techdisqus/exception/MyCustomException
Please note that the IF condition will NOT be executed as I am passing command argument as test
Why is it throwing an exception is causing to load the MyCustomException which would be never executed but the JVM does not load any other regular class unless condition is satisfied, as here Entity class here. Please check Driver.java below.
MyCustomException.java
public class MyCustomException extends RuntimeException {
}
Entity.java
public class Entity {
}
Driver.java
public class Driver {
public static void main(String[] args) {
String s = args[0];
if("true".equals(s)){
Entity entity = new Entity(); // This is not loaded, unless s is true
throw new MyCustomException(); // this is loaded even s is NOT true.
}else{
System.out.println("success");
}
}
}
Thanks for help

(this is an educated guess; I'm by no means an expert on JVM internals)
I assume the error happens during verification, when the loaded class undergoes some sanity checks so the runtime can make some assumptions later.
One of the checks is a typecheck of bytecode instructions. Specifically athrow:
An athrow instruction is type safe iff the top of the operand stack matches Throwable.
So at this point, the classloader has to load MyCustomException to check whether it extends Throwable

What is the difference between java.lang.NoSuchMethodError main Exception in thread "main " and Error: Main method not found in class

I have this class
public class demo3 {
private static void sum()
{
}
}
when I tried to run this class, I expected the error to be java.lang.NoSuchMethodError main Exception in thread "main "
however, the output was a bit different and I got below message
Error: Main method not found in class demo3, please define the main method as:
public static void main(String[] args)
now this got my curiosity as to in which case I will get java.lang.NoSuchMethodError or in which case I will get the other error message.

You get the Main method not found message when public static void main(String[]) can't be found in the class that you've asked the JVM to start running. That is, the entry point of the overall program cannot be found.
You get the java.lang.NoSuchMethodError message if your (already running) code attempts to invoke a method on a class which was available at compile time, but not available in the version of the class you are using at runtime (for example, you compile against one version of the library, and then update the library jar without recompiling). This can occur at any point in the program.
There doesn't look to be anything in JLS which says that NoSuchMethodError can't be thrown, rather than the Main method not found; however, failing to write a main method (either entirely, or writing one with the wrong signature) is a far more common mistake than the "class changed after compilation" case, especially for beginners, for whom the NoSuchMethodError might be too cryptic. There is no harm in providing a more user-friendly message in this one case.

Unexpected behaviour in JVM class loading (ClassNotFoundException before the class is really needed)

I would need help trying to understand why this is happening to me:
Using Java 1.8.0_131, I have a class such as this:
public class DynamicClassLoadingAppKO {
/*
* THIS VERSION DOES NOT WORK, A ClassNotFoundException IS THROWN BEFORE EVEN EXECUTING main()
*/
// If this method received ChildClassFromLibTwo, everything would work OK!
private static void showMessage(final ParentClassFromLibOne obj) {
System.out.println(obj.message());
}
public static void main(final String[] args) throws Throwable {
try {
final ChildClassFromLibTwo obj = new ChildClassFromLibTwo();
showMessage(obj);
} catch (final Throwable ignored) {
// ignored, we just wanted to use it if it was present
}
System.out.println("This should be displayed, but no :(");
}
}
Two other classes are being used up there: ParentClassFromLibOne and ChildClassFromLibTwo. The latter extends from the former.
There are two external libraries involved:
One library is called libone and contains the ParentClassFromLibOne class. The application includes this library in the classpath both for compiling and executing.
A second library is called libtwo and contains the ChildClassFromLibTwo class. The application includes this library in the classpath for compiling, but not for executing.
As far as I understand, the Java runtime should try to load the ChildClassFromLibTwo (which is not in the classpath at runtime) at this line:
final ChildClassFromLibTwo obj = new ChildClassFromLibTwo();
Given this class is not in the classpath, a ClassNotFoundException should be thrown, and given this line is inside a try...catch (Throwable), the System.out.println line at the end should be executed anyway.
However, what I get is the ClassNotFoundException thrown when the DynamicClassLoadingAppKO itself is loaded, apparently before the main() method is executed at all, and therefore not caught by the try...catch.
What seems more strange to me is that this behaviour disappears and everything works as I would expect if I change the signature of the showMessage() method so that instead of receiving an argument of the parent class, it is directly of the child class:
/*
* THIS VERSION WORKS OK, BECAUSE showMessage RECEIVES THE CHILD CLASS AS A PARAMETER
*/
private static void showMessage(final ChildClassFromLibTwo obj) {
System.out.println(obj.message());
}
How is this possible? What am I missing in the way class loading works?
For testing convenience, I have created a GitHub repository replicating this behaviour [1].
[1] https://github.com/danielfernandez/test-dynamic-class-loading/tree/20170504

OK, the details of why this happens are explained in this Spring Boot ticket [1] which I've been very lucky to be promptly pointed to by Andy Wilkinson. That was definitely a difficult one IMO.
Apparently, what happens in this case is that when the calling class itself is loaded, the verifier kicks in and sees that the showMessage() method receives an argument of type ParentClassFromLibOne. So far so good, and this would not provoke a ClassNotFoundException at this phase even if ParentClassFromLibOne was not in the classpath at runtime.
BUT apparently the verifier also scans method code and notes that there is a call in main() to that showMessage() method. A call that does not pass as an argument a ParentClassFromLibOne, but instead an object of a different class: ChildClassFromLibTwo.
So it is in this case that the verifier does try to load ChildClassFromLibTwo in order to be able to check if it really extends from ParentClassFromLibOne.
Interestingly this wouldn't happen if ParentClassFromLibOne was an interface, because interfaces are treated as Object for assignment.
Also, this does not happen if showMessage(...) directly asks for a ChildClassFromLibTwo as an argument because in such case the verifier does not need to load the child class to check it is compatible... with itself.
Daniel, I'm voting up your answer but I will not mark it as accepted because I consider it fails at explaining the real reason why this is happening at verify time (it's not the class in the signature of the method that's causing the ClassNotFoundException).
[1] https://github.com/spring-projects/spring-boot/issues/8181

This is a bit more complicated than you think. When a class is loaded, all functions are verified. During the verify phase also all referenced classes are loaded, because they are needed to calculated the exact types that are on the stack at any given location in the bytecode.
If you want that lazy behaviour, you have to pass the -noverify option to Java, which will delay the loading of classes until the functions that reference them are executed the first time. But don't use -noverify for security reasons when you don't have full control over the classes that will be loaded into the JVM.

Subclass obtained from Serviceloader throws AbstractMethodError

I am trying to make a Java app that can load plugins implementing an abstract class and am having an AbstractMethodError with the instances generated from ServiceLoader. The code is a bit heavy so I've made a simplification below.
First, I have an abstract class:
package stuff.TheAbstractClass;
public abstract class TheAbstractClass implements ClassInterface{
//Stuff happens
}
Which implements the below interface:
package stuff.ClassInterface;
public interface ClassInterface {
public String getClassName();
}
I have a service provider NotAbstractClass which extends TheAbstractClass and states so in a meta-inf/services folder:
package anotherstuff.NotAbstractClass;
public final class NotAbstractClass extends TheAbstractClass implements ClassInterface{
private String name = "Silent Bob";
#Override
public String getClassName() { return name; }
}
Then on the main application (which is actually a plugin inside another application), I want to find all classes which extend TheAbstractClass:
package stuff.TheApp;
import java.util.ServiceLoader;
public class TheApp {
private String name;
public final static TheApp INSTANCE = new TheApp();
private TheApp() {
ServiceLoader<TheAbstractClass> serviceLoader =
ServiceLoader.load(TheAbstractClass.class);
for (TheAbstractClass class: serviceLoader) {
name = class.getClassName;
}
}
My application does find NotAbstractClass. I know this since, in the for loop, I can do class.getName() and it'll give me anotherstuff.NotAbstractClass) but gives the error:
java.lang.AbstractMethodError: stuff.TheAbstractClass.getClassName()Ljava/lang/String;
I'm stumped. Any suggestion? Thank you, Pedro

According to the API for AbstractMethodError you get this:
Thrown when an application tries to call an abstract method. Normally,
this error is caught by the compiler; this error can only occur at run
time if the definition of some class has incompatibly changed since
the currently executing method was last compiled.
Just by looking at your code and your comment I see that this could only have happened at runtime.
If that is the case then:
some class has incompatibly changed since the currently executing
method was last compiled
I've tested your logic after some adjustments in a Java compatible form and I had no problems. The only thing that seems to be happening is a change in any of the subclasses of TheAbstractClass.
Another thing I did was to declare the dependencies using the dependency files in: resources/META-INF/services:
file: <full-package>.TheAbstractClass
content: <full-package>.NotAbstractClass
After this I had no problems.

It seems the issue wasn't in the code, but in the IDE (IntelliJ). I deleted all previously packaged jars and made new jars without changing anything and it magically worked... So it's an IDE bug, and not a language issue!
Thanks to #Joao and #hotzst for taking time to read however.
Best, Pedro

how to add #Override annotation to a method while creating the .class file using javaassist?

How to add the #Override annotation to a method while creating the class using javaassist?
ClassPool pool = ClassPool.getDefault();
CtClass ctClasz = pool.makeClass("test.ExampleImpl");
ctClasz.addInterface(pool.get(MyInterface.class.getName()));
CtMethod method = CtNewMethod.make ("#Override public void print() { System.out.println(\"Hello! \"); }", ctClasz);
ctClasz.addMethod(method);
System.out.println("Implementd: Interfaces:" + ctClasz.getInterfaces());
System.out.println("Methods: " + ctClasz.getMethods());
ctClasz.writeFile("D:");
This code is throwing exception as follows:
Exception in thread "main" javassist.CannotCompileException: [source error] syntax error
near "#Override p"
at javassist.CtNewMethod.make(CtNewMethod.java:78)
at javassist.CtNewMethod.make(CtNewMethod.java:44)
at javaassist.Demo.main(Demo.java:17)
Caused by: compile error: syntax error near "#Override p"
at javassist.compiler.Parser.parseClassType(Parser.java:983)
at javassist.compiler.Parser.parseFormalType(Parser.java:191)
at javassist.compiler.Parser.parseMember1(Parser.java:51)
at javassist.compiler.Javac.compile(Javac.java:89)
at javassist.CtNewMethod.make(CtNewMethod.java:73)
... 2 more

#Override isn't a runtime annotation so even if you could add it, it wouldn't make any difference whatsoever.
For annotations that do have a runtime effect (RetentionPolicy.RUNTIME), you can take a look at this question.

Short Version
It isn't interesting to add the annotation. Because as this has #java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE), it will not make any difference. So, you don't need to care about this issue.
I would care with annotations that has #java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.RUNTIME) retention.
Long Version
This anntotation has #java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE) retention meaning it will not change anything even if you add it with JAVASSIST when you are generating some classes to use during runtime.
The annotation doesn't has any influence on the code. When Java generates the sources this is already stripped out. As JAVASSIST generates code it makes no sense add it.
According documentation, retention can be configured as:
CLASS Annotations are to be recorded in the class file by the compiler but need not be retained by the VM at run time.
RUNTIME Annotations are to be recorded in the class file by the compiler and retained by the VM at run time, so they may be read reflectively.
SOURCE Annotations are to be discarded by the compiler.
In JAVASSIST it would be interesting to add the RUNTIME or CLASS annotations (but for CLASS it would not be that interesting, see here).

#Override is only useful to the compiler.
It tells the compiler to ensure that the annotated method either:
a. Overrides a method on the superclass
b. Implements an interface method.
This becomes of particular importance when interfaces or superclasses change. Your class may otherwise compile, but the method you think is defining functionality on the interface or the superclass may no longer be doing that.
So the #Override annotation lets the compiler bark at you in that case.
Edit
Example:
public interface Foo {
void bar();
}
public class FooImpl {
public void bar() { ... }
}
public class MyFooExtension extends FooImpl {
public void bar() { .... }
}
Now, let's say Foo and FooImpl change:
public interface Foo {
void bar(String input);
}
public class FooImpl {
public void bar(String input) { ... }
}
You're MyFooExtension class would still compile, yet the "bar()" method in that class would never be called. Thus your method is useless. If you add the #Override annotation, you'd get a compile error telling you that no method "void bar()" is being overriden, and you would have to fix your class in order to get it to compile.