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.
Related
In using TypedActor.get(system) intellij spell an error 'ambiguous method call', here system is of type ActorSystem. I found in the decompiled source code of the TypedActor class file there are two methods with the same signature:
To my knowledge it is impossible for two methods to have the same signature in Java, so what is wrong here? What is the proper way to call the TypedActor.get(ActorSystem system) method?
The version of AKKA I'm using is 2.5.11 and the jar file akka-actor_2.13.0-M3.
This was a bug caused by an issue in the Scala compiler (https://github.com/akka/akka/issues/25449) it has since been fixed so upgrading to a more recent Akka version should fix it.
EDIT: According to #johanandren below, this was a bug and it has now been fixed.
You can use
TypedActor$.MODULE$.get(system). This happens because of the way Scala objects get turned into singleton classes.
A Scala object TypedActor actually gets turned into the class TypedActor$ with a singleton instance called MODULE$. This is because JVM bytecode doesn't actually support Scala's singleton objects, so lots of Scala names are wrangled and are hard to access from Java.
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?
While im trying to run TexturePacker gui jar file from command line, its showing this error. Please see the image below. Thank you for your help in advance.
I don't think we can give you a specific solution, but the general diagnosis is that you have called a native method for which the the JVM hasn't been given an implementation. Possible causes are:
missing native libraries (DLLs, whatever)
the JVM can't find the native libraries
the application hasn't told the JVM to load the library (e.g. by calling System.loadLibrary(...)
the library doesn't define the required native method with specific method signature that you are looking for.
In the example you have shown us, the JVM is failing to find the native code implementation for a method with this signature:
void setWindowProc(java.lang.reflect.Method)
that is declared in the class org.lwjgl.opengl.WindowsDisplay. The problem could be a missing or incorrectly configured library, or it could be due to a version mismatch between the library's DLL and Java code.
Based on a 2 minute read of the "getting started" example for LWJGL, it doesn't look like there is an explicit initialization call that your application needs to make. (But I may have missed something, or you may be using a version of the library that doesn't match the "getting started" docs.)
I'm getting the following exception:
com.google.gwt.user.client.rpc.SerializationException: Type 'java.lang.Long' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized
using GWT 2.1 and the built in Jetty server. According to the docs, this type is definitely serializable... How can I include it in the SerializationPolicy?
Here's the link that should resolve problem:
http://developerlife.com/tutorials/?p=131
A user defined class is serializable if:
the class is assignable to IsSerializable or java.io.Serializable, either because it implements one of these interfaces, or because it is derived from a superclass that implements one of these interfaces.
all the class’s non-final, non-transient instance fields are serializable
the class has a public default (zero argument) constructor
Needed include a superfluous method in the RPC service that "whitelists" a number of objects. This arises because of the use of generics, GWT is unable to necessarily determine which object I may be serializing to include within some generic.
I included all of the types that may need to be (un)serialized as members of an object (SerializableWhitelist). I added a method to the RPC servlet object like:
public SerializableWhitelist junk(SerializableWhitelist l) { return null; }
It's worth noting that you need to include the whitelist datatypes as both an argument and as the return type, as GWT apparently maintains two separate serialization policies.
Try deleting the *.gwt.rpc files in your war/app directory, clean and rebuild.
One thing to note: you should avoid long or Long if possible because they are
emulated on GWT (because there is no native Javascript long) and very
slow. Use int instead where ever you can.
FYI I've raised this as a GWT bug: http://code.google.com/p/google-web-toolkit/issues/detail?id=5811
We'll see what they say.
FWIW, I was having this problem but my 'Object' type was hidden behind generified classes. The error message itself was wrong.
So if one of your rpc methods involves a class:
class Xxx<T> implements IsSerializable {...
It needs to change to:
class Xxx<T extends IsSerializable> implements IsSerializable {...
The problem can also be because the code on your local machine on which you are running hosted mode is not the same as the one on the external server you are connecting to via RPC. So in my case i was missing a git pull on my local machine to match what was deployed on the external server. The changes were minimal, just a new property in one of the classes that were included in the gwt.rpc, but this was already sufficient that the gwt.rpc md5 filenames were different and thus the above mentioned error occurred.
Inspired by http://groups.google.com/group/google-web-toolkit/browse_thread/thread/7dd5123d359ddfa8
Using eclipse and maven and gwt 2.1.1
Compile and deploy gwt war.
Try using OOPHM launched from Eclipse. This would fail for me.
This will generate in server logs:
ERROR: The serialization policy file 'blah.gwt.rpc' was not found; did you forget to include it in this deployment?
WARNING: Failed to get the SerializationPolicy '94DEC228B2828D3A5897FEE3D6845A40' for module 'http://blah:8080/BlahUI/BlahUI/'; a legacy, 1.3.3 compatible, serialization policy will be used. You may experience SerializationExceptions as a result.
And then
Exception while dispatching incoming RPC call
com.google.gwt.user.client.rpc.SerializationException: Type '[LpathToClass;' was not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.For security purposes, this type will not be serialized.: instance = [LpathToClass;#9d524af
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:614)
Now that extra gwt.rpc files have been generated (either by eclipse/maven plugin who knows?)
Recompile (even a clean compile will work because the gwt.rpc files are not in the target folder, my OOPHM gwt.rpc files are at same folder as entrypoint html) and redeploy. This new war file will contain the generated gwt.rpc files.
Relaunch OOPHM from Eclipse. Works for me.
Another FWIW: I believe I cleared up a similar problem in an enum class by changing
the access modifier of the single, one argument constructor from default (no modifier)
to 'private'. In any event, doing that didn't break it because it's working that way now.
I faced this error and got stuck for 1 day completely. Then I came to across following quick solution:
Make sure your DTOs or Entities classes following the serializable interface rules.
Its the the only thing you need to do because rest of the issues will be with your build creation.
So if you are using maven then make sure do clean build and clear all browser cache.
I resolved my issues with this. I hope it will help. Thanks!
Make sure that the class is in shared folder.
This is what I was Missing.
I'm quite restricted in the platform I'm currently working on (JDK 1.3, BD-J). One JAR file I would like to use attempts to perform a self-integrity check on load and if it fails it goes into an inoperable state. It's quite difficult to find out why this is happening but most sources point to that it cannot find/access it self through the BD-J structure, so it dies.
This rules out using it at load time and instead to load it in the application itself. This is quite a large library so I have to create quite an amount of interfaces so I can cast a loaded object to it and potentially use it. This is where my problem lies.
The interfaces are loaded on normal load time and the library is then loaded during run time and casted to the previously loaded interfaces, is this a problem? I'm receiving ClassCastException
I've based the interfaces off the libraries public methods as best I can, but when I attempt to cast to an interface I receive the ClassCastException. Note: It all loads fine, I can access constructors and read the method names. Just when casting it for it to be useable it fails.
The interface packages are different in my project to that of the toolkit, does this matter?
I'm running out of ideas, is there something I have overlooked?
Thanks.
I'm not sure I fully grok what your problem is - maybe some more details about what the class hierarchy looks like would help in figuring out the situation. From what you wrote I can guess two possible scenarios:
.1. The classes you want to use do not implement any interface.
In this case no matter what you name your interfaces, it will not work, since the classes you're loading do not implement them. You're stuck with using reflection if you can't load that jar as part of the boot classpath.
.2. The classes you want implement some interface that you're trying to replicate.
In this case you interface implementation must match the exact qualified name of the interface the classes are implementing. Normally, when loading the classes from the jar, the class loader will pick up the interfaces from the system class loader first, thus loading your interfaces, and everything should work.
If they use some crazy internal class loader, though, they might still try to load their own interfaces. You could try to figure out if that's the case by using "-XX:+TraceClassLoading", although I don't know if the 1.3 jre will understand that option.
Now if you're willing to experiment more, you could also try another approach. Write your own class loader that loads both the classes from that jar and the code you want to run. That way, your code would be able to directly refer to the classes in that jar, but to start your application the "main" method will have to be one that initializes this classloader, loads the "real" main class using reflection, and executes its main() method also via reflection.
Most probably the classes are loaded by different class loaders. http://mindprod.com/jgloss/classloader.html may give some idea.