NoClassDefFoundError extends LinkageError which in turns extends Error.
Javadoc for Error class states:
An Error is a subclass of Throwable
that indicates serious problems that a reasonable application
should not try to catch.
Class loading methods like Class.forName() only declares ClassNotFoundException in throws clause. Which, in addition to above description of Error means that we should not be usually catching the NoClassDefFoundError when loading classes with Class.forName() etc.
My question is what are the conditions in which NoClassDefFoundError is thrown instead of ClassNotFoundException?
ClassNotFoundException is more likely to be thrown (to your code) in situations where you're manually loading classes - precisely for things like Class.forName(). These names may come from user input, for example.
NoClassDefFoundError will occur when a class file itself refers to a class that then can't be found. The class was present at some time, but now isn't - this isn't just a bug in the code that's trying to do reflection, it's a deployment mistake of not making all the required classes available. As far as I can tell a NoClassDefFoundError will usually or possibly always wrap a ClassNotFoundException - but the point is that this isn't something your code is meant to guard against, as it indicates an environment which is probably too broken to recover from.
At least, that's my understanding :)
NoClassDefFoundError occures at runtime because compiler not able to find .class file.
Related
https://stackoverflow.com/a/5948326/9454856
Exception in thread "main" java.lang.AbstractMethodError: org.apache.xerces.dom.CoreDOMImplementationImpl.createLSSerializer()Lorg/w3c/dom/ls/LSSerializer;
Why am I getting this error?
The definition of AbstractMethodError says:
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.
So you've got some kind of configuration or version control problem in your code, probably you're picking up a different version of Apache Xerces at run time from the version used at compile time; though it also suggests you might be straying outside the stable API into calling methods that weren't really intended for public use.
As I can't see your code, there's a lot of guesswork here. The next stage in debugging would be to look at a stack trace.
I have a native application that launches a JVM and interacts with it through the JNI API.
The native application constructs a (complex) JVM object and passes it as parameter in a method call.
The problem is that in some cases, on determinate inputs, the JVM crashes during the execution of the method with:
Exception in thread "Thread-1" java.lang.IncompatibleClassChangeError
I learned that this exception is thrown by the JVM when some incompatible binary changes has been made to a class used by a client that is not aware of the changes. However, I don't see how this could happen: in my case the JVM has only one fat jar in the classpath. I can't find duplicate classes in it, and the client code is always compiled to produce the fat jar.
On "What causes java.lang.IncompatibleClassChangeError?" I found that there is another potential reason: a method called via JNI with objects of the wrong type, e.g. in the wrong order. So, I added dynamic checks with IsInstanceOf to check the type of any object passed to the JVM. Unfortunately, all the checks succeed.
How can I debug this? The exception has no message (e.g. no message like "Expected non-static field ChildClass.message"). This may hint that it's a problem caused by the JNI, and not by the "more common" case of an incompatible binary change in a library.
I tried -verbose:class but I don't see anything strange in the log. The last loaded class seems a common Scala lambda function, nothing strange:
[Loaded a.b.c.FastPrettyPrinter$$$Lambda$457/868352876 from a.b.c.FastPrettyPrinter$]
Is there an exhaustive list, or explanation, of what might cause an IncompatibleClassChangeError when calling JVM methods via the JNI?
Why some exceptions are located in their respective packages (like IOException, located in java.io) but others are in java.lang (like ArrayIndexOutOfBounds in java.lang). Is this because one is checked and other is Unchecked Exception?
I really don't think that base on checked and unchecked conditions java exceptions are located in respective packages.If we consider about java.io package and java.lang packages,
java.io package contains classes for system input and output through data streams, serialization and the file system.And also handling files also done by Java I/O API.
java.lan package contains all the classes that are using to the design of the Java programming language such as String, Math. And provide basic runtime support for threads and processes.
Java IOException is thrown whenever an input or output stream is interrupted.So this regarding System input and output.So this IOException class must come under java.io package.
Java RuntimeExceptions such as ArrayIndexOutOfBoundEceptions are checked at the runtime.java.lan package support to handle runtime threads.It's include classes that support runtime for threads and process.
So IOException,ArrayIndexOutOfBound are classes with relevant function.So those classes must be categorized under relevant packages.
First: ArrayIndexOutOfBoundsException is not inside java.lang.Throwable. It is inside the package java.lang. It is a subclass of java.lang.Throwable, but so are all exceptions (including IOException).
ArrayIndexOutOfBoundsException is inside java.lang because all the "basic stuff related to the core language" is in java.lang, and ArrayIndexOutOfBoundsException is "basic stuff related to the core language".
IOException is inside java.io because all the stuff related to I/O is in java.io, and IOException is "stuff related to I/O".
There is no deep or interesting technical reason.
As a general rule, it is a good idea to place checked exceptions near the code which is throwing those types of exceptions. This explains your first observation. On the other hand, the exception ArrayIndexOutOfBounds is an unchecked runtime exception. It is associated with a type of runtime error from which the program is generally not expected to recover. As such, it placed in java.lang.throwable with other similar runtime exceptions. So as a general rule, if you define custom exceptions for your program, you should therefore probably put them in the packages, or near the code, which uses them.
We are using Sonarqube 6.2 across two projects and several branches per project. It has been working fine until today.
I have started seeing the following sorts of problems that I never saw before:
1.) Rule complaining about our Exception classes complaining that the class name should not end in Exception because they are not exceptions. However, these classes are exceptions and they do extend Exception--they just do so through another common Exception class.
2.) I am starting to see false positives recommending that I delete an unused private method even though the method is being used!
3.) I am starting to get issues with messages that contain '!unknownSymbol!' in them. For example:
Remove the redundant '!unknownSymbol!' thrown exception declaration(s).
It is flagging an Exception class that is not redundant and definitely is thrown from within the method.
I am using the Sonar Maven Plugin 3.2 to run the scans and push to the server. Any clues as to why this is happening?
A quick question regarding the java.lang.VerifyError exception. Suppose I get an error that looks like this:
Java call terminated by uncaught Java exception: java.lang.VerifyError:(class: com/.../MyClassName, method: <init> signature: (Ljava/io/Reader;)V) Incompatible argument to function
Could you help me with understanding what the "init" and what the "(Ljava/io/Reader;)V)" parts pertain to? They don't look like method names or signatures to me, but I'm not too familiar with java. Thanks!
This error means that somewhere in your code, you tried to call a constructor (the <init> method) passing in the wrong set of arguments. The expected argument was a Reader object.
This probably meant that you previously compiled a class file, then changed the class definition in some way without recompiling the class file. Consequently, your code tries to call a function that no longer exists. Try recompiling the code and see if that fixes it.
Hope this helps!
If you are running your application on an application server, it could be a class loading problem.
You compiled your code against a library and when you try to run your code it is running against a different (older?) version of the library.
The older library probably doesn't have that method or constructor.
Just to leave track of a different cause.
Always on an application server (in my case WildFly 10), you might be loading the same library on a modules and on the EAR lib. If this library contains an interface that needs to be implemented by the module, this might cause a conflict since the same class / interface loaded by two different class loaders are considered to be two different types.