We Keep Coding

Getting "java.lang.NoClassDefFoundError: Could not initialize class" only in QA environment, not locally?

I have seen this:
java.lang.NoClassDefFoundError: Could not initialize class XXX
And this: Different methodologies for solving bugs that only occur in production
But my question is, given what the first answer says about this problem, how could it be that I could be getting that error on only one of the two places? isn't this a pretty serious error that should prevent the program from compiling in any location? (I properly import the class in the file this error occurs.)
What differences between the two environments should I be looking for?
Other questions about the error I'm getting in QA indicate it could be some nested problem with the class itself, but like I said if that was the case why would it only happen in the QA environment? I can run jmeter load/endurance tests against my program all day long locally and not see this error.
Note, I don't handle the deployments to QA, but is there something I should ask the guy who does? Would run config differences be a potential cause?
The logs in splunk aren't super helpful, here's part of the exception of one instance of the error:
[https-jsse-nio-11402-exec-9] 28 Jun 2021 13:29:45,415+0000 ERROR GenericThrowableMapper [{applicationSystemCode=[removed]-app, clientIP=[removed], clusterId=[removed], containerId=[removed], correlationId=[removed], domainName=[removed], hostName=[removed], messageId=[removed], userId=[removed], webAnalyticsCorrelationId=|}]: java.lang.NoClassDefFoundError: Could not initialize class [removed].CDDConfig
at [removed].execute([removed]AggregationResource.java:77)
at [removed]AggregationResource$$FastClassBySpringCGLIB$$7a8c5a8e.invoke(<generated>)
It then goes on into package classes and all that for a bunch of lines. I add this to ask - maybe there's something else I should try to have it log?

This isn't much more than a spontaneous guess, but judging from experience, I suspect a JDK / JRE version error.
Classic case I witnessed: you compile something on your dev machine with, say, OpenJDK version 8.x.x. You commit / push, the Jenkins CICD pipe starts running, but someone configured its JAVA_HOME to some 11.x version JDK.
-> ClassNotFoundError, NoClassDef, etc.
If you do not do the deployment to QA yourself, can you check what JDK the code has been compiled with? Or ask the guy doing it for that info.

ClassNotFoundException while replacing java 6 rmi w/ java 8 [duplicate]

The following method :
private void startServer() { // snippet that starts the server on the local machine
try {
RemoteMethodImpl impl = new RemoteMethodImpl();
Naming.rebind( "Illusive-Server" , impl );
}catch(Exception exc) {
JOptionPane.showMessageDialog(this, "Problem starting the server", "Error", JOptionPane.ERROR_MESSAGE);
System.out.println(exc);
}
}
throws this exception :java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: Interfaces.RemoteMethodIntf
When i start my project, i am greeted with the message in JOptionPane saying problem starting the server and then the above exception. What could be the reason for this ?
I don't understand why does the last statement of exception says class not found exc when i have imported the right packages

There are four cases of this exception.
When exporting: you didn't run 'rmic' and you didn't take the steps described in the preamble to the Javadoc for UnicastRemoteObject to make it unnecessary.
When binding: the Registry doesn't have the stub or the remote interface or something they depend on on its classpath.
when looking up: the client does't have these things on its classpath.
When calling a remote method: you either sent something to the server of a class not present on its CLASSPATH, or received something from the server (including an exception) of a class not on your CLASSPATH: in both cases possibly a derived class or interface implementation of a class or interface mentioned in the remote interface's method signature.
This is case 2. The Registry can't find the named class.
There are several solutions:
Start the Registry with a CLASSPATH that includes the relevant JARs or directories.
Start the Registry in your server JVM, via LocateRegistry.createRegistry().
Use dynamic stubs, as described in the preamble to the Javadoc of UnicastRemoteObject. However you may then still run into the same problem with the remote interface itself or a class that it depends on, in which case 1-3 above still apply to that class/those classes.
Ensure that case (4) above doesn't occur.
Use the codebase feature. This is really a deployment option and IMO something to be avoided at the initial development stage.

Remote Server Error:RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: mathInterface
The error very simple to solve to be perform following steps:
For example your java file consider D drive
Start rmiregistry D drive( example D:\start rmiregistry)then don't start rmiregistry on the other drives, it will yield the above error
(Wherever your file is, start rmiregistry)

I will try to explain it as better as possible what I did:
1st. I declared the classpath variable like follow:
set classpath=%classpath%
set classpath=C:\compiler
set classpath=C:\compiler\libro\cap07\rmi\hello\Hello.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Server.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Client.java
(All in one lineset:
set classpath=%classpath%;C:\compiler;C:\compiler\libro\cap07\rmi\hello\Hello.java;C:\compiler\libro\cap07\rmi\hello\Server.java;C:\compiler\libro\cap07\rmi\hello\Client.java)
(I'm not sure if the .java files were nesesary, but I also wrote them for doubts).
2nd. I compilered with the line javac -d C:\compiler Hello.java Server.java Client.java. Where C:\compiler is the root directory like src on Eclipse IDE.
3rd. I ran the start rmiregistry line. (and don´t matter where you run it, it's the same).
4th. I ran:
start java -classpath C:\compiler -Djava.rmi.server.codebase=file:C:\compiler/ libro.cap07.rmi.hello.Server
You already know C:\compiler, but you need define packages address on the last to that the command can find the .class files. Open any .java file and copy the package address without packages sentense. You will see when you open the src directory (in my case C:\compiler), you find all directory sequence created. When this command line is created correctly, no matter where you will run it, C:, D:, src, anywhere it wil run.
5th. And finally, I ran the Client class with:
java -classpath C:\compiler libro.cap07.rmi.hello.Client
In conclusion, if the classpath variable won't created or it's to created wrong or the sentence of 4th point is not addressed well the JVM throws the same or similar error. Search there!
(Sorry my english).

You can launch rmiregistry from anywhere but you have to make sure that the compiled classes are already in your classpath. For example:-
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>set classpath=%classpath%;E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes <ENTER>
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>c: <ENTER>
C:\>rmiregistry
And the above should work fine.
In general, if you launch rmiregistry from the root location of the compiled classes (above example it is E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes), that will work because . (dot - current directory) is already set in your classpath.
But as soon as you remove . (dot - current directory) from your classpath, the above working condition will also fail.
Hope I have explained in details.

I got this same issue, and a different solution worked for me. I was running two different IntelliJ projects, with a copy of the interface in each project. One of them was in a package, and the other one wasn't, and that was what was causing this error.
Solutions:
Make sure the interface copies aren't in a package.
Make sure the interface copies have the exact same package name.

NoClassDefFoundError "wrong name" for a class in the java.lang package

I'm running Cassandra 2.2.11 (and won't be upgrading) on a host. Periodically, in a cron job, I run nodetool commands for monitoring. nodetool is implemented as just another java process that uses JMX to talk to the Cassandra java process. I launch five or so commands every minute.
Once in a while (not in any recognizable pattern), the execution of nodetool will fail with a NoClassDefFoundError that refers to a class from java.lang. For example,
java.lang.NoClassDefFoundError: java/lang/Thread (wrong name: java/lang/Thread)
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredField(Class.java:2068)
at java.util.concurrent.FutureTask.<clinit>(FutureTask.java:476)
at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:590)
at sun.rmi.transport.tcp.TCPChannel.free(TCPChannel.java:347)
at sun.rmi.server.UnicastRef.free(UnicastRef.java:431)
at sun.rmi.server.UnicastRef.done(UnicastRef.java:448)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:183)
at org.apache.cassandra.tools.NodeProbe.<init>(NodeProbe.java:150)
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.connect(NodeTool.java:302)
at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:242)
at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:158)
In this stack trace, the error happens during class initialization for FutureTask. I've also seen
java.lang.NoClassDefFoundError: java/lang/Object (wrong name: java/lang/Object)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.getDeclaredMethod(Class.java:2128)
at java.lang.invoke.MethodHandleImpl$Lazy.<clinit>(MethodHandleImpl.java:614)
[...]
but also
java.lang.NoClassDefFoundError: java/lang/String (wrong name: java/lang/String)
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredField(Class.java:2068)
at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1703)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:72)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:484)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:472)
[...]
So it's not only happening during class initialization, but, in the few samples I've collected, something in the reflection implementation does seem to be the culprit.
Java is at version 8
java version "1.8.0_144"
The nodetool launcher always uses the same classpath. And there are no weird classes in there (or additional class loaders). The same installation is done across hundreds of identical nodes (on Linux).
My top search results for NoClassDefFoundError wrong name refer to executions where a simplified class name was used to launch java, rather than the fully qualified name. That's not the issue here. Also, the names in the error messages are identical.
So what can cause such "wrong name" NoClassDefFoundError errors for "bootstrap" classes?

i think it is the lack of resource that cause the problems like the connector timeout or something. Do you see the log from your example?;
nodeprobe is connecting through the jmx or trying to connect then the error occurs?
Those are very typical error that can also cause other intermiten error on the shit.(usually OS/netowrk OS shit) thus :
includes your string and even object based error ;in conclusion it make sense.
may be you should check your resource when the error happen.
i know this is kind of catch 22 that the resource monitor is causing the lack of resource instead; but it happen hehe

According to the stacktraces, the exception id being thrown in a calls to getDeclaredFields0. However, this is not where the exception came from originally. According to the OpenJDK source code, there is nothing in the codebase that throws an exception with "wrong name" in the exception message. The message has come from somewhere else.
I strongly suspect that this is actually re-reporting a problem that happened the first time that some class was loaded or initialized. What happens is that the classloader finds the problem the first time, marks the offending internal class object as "bad" and then the throws the error. According to the javadoc, applications should not attempt to recover from this. But if one does, and then attempts to use the "bad" class in some way, the original problem will be reported again as a NoClassDefFoundError with the original reason.
So what does the reason mean?
It is hard to tell because we don't have the stacktrace for the original exception; i.e. then one where the classloading / initialization first failed. If you can find that stacktrace, we can track down the 3rd-party library that did it. It is almost certainly happening in a classloader.
The obvious meaning is that a class file has a classname in it that doesn't match the name in the classes bytecodes. However, we'd need to examine the classloader code to be sure.
So why is it happening intermittently?
Possibly because the application JVM has many classloaders and only a subset of them have "polluted" their class namespace with this bad class.
That could be bad news. It suggests there may be some kind of synchronization issue in the core of the application.
Anyhow, there is not enough evidence to draw sound conclusions.
Bottom line
Based on the evidence, I would guess that this is a result of some kind of "code weaving" or "byte code engineering" that has gone wrong. As a further guess, I would say that some child classloader is not delegating properly, and has mistakenly attempted to process a built-in class. (It could even be that the classloader in question knows that it should never process a "java.lang.*" class and it has a obscure way of saying this.)
Why? possibly because someone / something explicitly added the "rt.jar" to some classpath that it shouldn't be on.
For further diagnosis, the first thing we need is the original stacktrace that tells us which classloader did the initial damage.

As none of basic java library found,I think there is problem in your java installation or you have not set CLASSPATH and JAVA_HOME environment variables. Try to set CLASSPATH and JAVA_HOME environment variables.
export JAVA_HOME="/usr/lib/jvm/java-8-oracle/bin"
export CLASSPATH="/usr/lib/jvm/java-8-oracle/lib"
If not worked, try reinstall java and set environment variables.

Java: Use of bootclasspath preventing H2 driver from being found

If I build my own, tinkered version of rt.jar (called my-rt.jar) from the Oracle JDK 7 sources and hook it in with the bootclasspath mechanism, like this,
$ java -Xbootclasspath/p:/path/to/my-rt.jar -cp /path/to/h2-1.3.174.jar main
then, I can't even load the H2 driver at the beginning of my application:
// Application's main.java
public class main {
public static void main(String[] args) {
// ...
Class.forName("org.h2.Driver"); // Line 145
}
}
The above results in the following exception:
Exception in thread "main" java.lang.ClassNotFoundException: org/h2/Driver
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at main.main(main.java:415)
However, if I remove the -Xbootclasspath/p switch and with everything else the same as before, I can load the driver fine, and the rest of application too works fine too.
So, is there anything peculiar going on inside the initialization of a JDBC driver (such as H2's) that's preventing me from using the bootclasspath mechanism? Or, is there anything peculiar about the bootclasspath mechanism that it won't allow the loading of a JDBC driver like H2?
I'm out of things to try. For example,
I've even re-built the H2 driver from its sources and made sure that both my application and the driver are using the identical version of javac.
I've tried the above both from Eclipse and from command-line.
I've tried it on 2 different machines.
All yield the same exception.
Btw, my tinkered my-rt.jar has a very simple edit to it: It simply adds a public static int counter to java.lang.Object. Before the Class.forName(...) line above, I'm able to verify that I can indeed print the value of counter when the bootclasspath switch is enabled.
The strange thing is, even if I comment out this counter field in java.lang.Object but continue prepending my-rt.jar (that is as good as the original rt.jar, only recompiled andn prepended), even then I cannot get the H2 driver to be found/loaded!
(I've posted this on the H2 google group too but getting no response there. Maybe, those folks don't think this is an H2 problem, so I'm asking here.)

I've nailed it. Here's what I did.
I first prepended the original rt.jar to the original rt.jar, like so:
$ java -Xbootclasspath/p:/path/to/orig/rt.jar -cp /path/to/h2-1.3.174.jar main
And the exception disappeared! This clearly told me that the bootclasspath/p mechanism was no way interfering with the loading of the H2 driver.
So, I then unjarred the original rt.jar and diff'ed it with the unjarred contents of my-rt.jar, I found around a whopping 8000 files missing from my-rt.jar:
$ wc -l *.list
11285 my-rt.jar.list
19059 rt.jar.list
30344 total
So, obviously, my-rt.jar that I built from the official src.zip had tons of stuff missing from it. No wonder, H2 driver was having loading troubles.
To further confirm, this time I copied over only my tinkered java/lang/Object.class to the unjarred contents of the original rt.jar, and lo and behold, the H2 driver continued to load just fine.
Thus, the name src.zip is a terrible misnomer. Because it does not have everything needed to build rt.jar, it should be called partial-src.zip (or, something like that) instead.

Java RMI Remote Interface Tutorial - error: unmarshalling arguments [duplicate]

The following method :
private void startServer() { // snippet that starts the server on the local machine
try {
RemoteMethodImpl impl = new RemoteMethodImpl();
Naming.rebind( "Illusive-Server" , impl );
}catch(Exception exc) {
JOptionPane.showMessageDialog(this, "Problem starting the server", "Error", JOptionPane.ERROR_MESSAGE);
System.out.println(exc);
}
}
throws this exception :java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: Interfaces.RemoteMethodIntf
When i start my project, i am greeted with the message in JOptionPane saying problem starting the server and then the above exception. What could be the reason for this ?
I don't understand why does the last statement of exception says class not found exc when i have imported the right packages

There are four cases of this exception.
When exporting: you didn't run 'rmic' and you didn't take the steps described in the preamble to the Javadoc for UnicastRemoteObject to make it unnecessary.
When binding: the Registry doesn't have the stub or the remote interface or something they depend on on its classpath.
when looking up: the client does't have these things on its classpath.
When calling a remote method: you either sent something to the server of a class not present on its CLASSPATH, or received something from the server (including an exception) of a class not on your CLASSPATH: in both cases possibly a derived class or interface implementation of a class or interface mentioned in the remote interface's method signature.
This is case 2. The Registry can't find the named class.
There are several solutions:
Start the Registry with a CLASSPATH that includes the relevant JARs or directories.
Start the Registry in your server JVM, via LocateRegistry.createRegistry().
Use dynamic stubs, as described in the preamble to the Javadoc of UnicastRemoteObject. However you may then still run into the same problem with the remote interface itself or a class that it depends on, in which case 1-3 above still apply to that class/those classes.
Ensure that case (4) above doesn't occur.
Use the codebase feature. This is really a deployment option and IMO something to be avoided at the initial development stage.

Remote Server Error:RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: mathInterface
The error very simple to solve to be perform following steps:
For example your java file consider D drive
Start rmiregistry D drive( example D:\start rmiregistry)then don't start rmiregistry on the other drives, it will yield the above error
(Wherever your file is, start rmiregistry)

I will try to explain it as better as possible what I did:
1st. I declared the classpath variable like follow:
set classpath=%classpath%
set classpath=C:\compiler
set classpath=C:\compiler\libro\cap07\rmi\hello\Hello.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Server.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Client.java
(All in one lineset:
set classpath=%classpath%;C:\compiler;C:\compiler\libro\cap07\rmi\hello\Hello.java;C:\compiler\libro\cap07\rmi\hello\Server.java;C:\compiler\libro\cap07\rmi\hello\Client.java)
(I'm not sure if the .java files were nesesary, but I also wrote them for doubts).
2nd. I compilered with the line javac -d C:\compiler Hello.java Server.java Client.java. Where C:\compiler is the root directory like src on Eclipse IDE.
3rd. I ran the start rmiregistry line. (and don´t matter where you run it, it's the same).
4th. I ran:
start java -classpath C:\compiler -Djava.rmi.server.codebase=file:C:\compiler/ libro.cap07.rmi.hello.Server
You already know C:\compiler, but you need define packages address on the last to that the command can find the .class files. Open any .java file and copy the package address without packages sentense. You will see when you open the src directory (in my case C:\compiler), you find all directory sequence created. When this command line is created correctly, no matter where you will run it, C:, D:, src, anywhere it wil run.
5th. And finally, I ran the Client class with:
java -classpath C:\compiler libro.cap07.rmi.hello.Client
In conclusion, if the classpath variable won't created or it's to created wrong or the sentence of 4th point is not addressed well the JVM throws the same or similar error. Search there!
(Sorry my english).

You can launch rmiregistry from anywhere but you have to make sure that the compiled classes are already in your classpath. For example:-
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>set classpath=%classpath%;E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes <ENTER>
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>c: <ENTER>
C:\>rmiregistry
And the above should work fine.
In general, if you launch rmiregistry from the root location of the compiled classes (above example it is E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes), that will work because . (dot - current directory) is already set in your classpath.
But as soon as you remove . (dot - current directory) from your classpath, the above working condition will also fail.
Hope I have explained in details.

I got this same issue, and a different solution worked for me. I was running two different IntelliJ projects, with a copy of the interface in each project. One of them was in a package, and the other one wasn't, and that was what was causing this error.
Solutions:
Make sure the interface copies aren't in a package.
Make sure the interface copies have the exact same package name.