I was trying to implement JNativeHook on jython, using JES.
I tried using JNativeHook on pure Java, and it does work as expected, yet, the same thing on jython throws an exception.
The exception NoClassDefFoundError occurs on GlobalScreen.registerNativeHook().
Why is that?
P.S. I checked the java.library.path of both Java and Jython, and they are the exact same.
Edit:
Tested some more and found out that the whole GlobalScreen class throws NoClassDefFoundError exceptions when using its methods.
Edit 2:
Doing dir(GlobalScreen) jython can actually see the methods of the class, yet exceptions get thrown on use.
Related
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 have the luck to migrate a large monolithic system from Java7 and Scala 2.10 to Java8 and Scala 2.11. So far so good. The application is using SpringSecurity.
After updating the spring libraries to the newest one we faced a null pointer exception thrown in Wss4jSecurityInterceptor in the validateMessage method here:
if (validationActionsVector.contains(WSConstants.NO_SECURITY)) {
return;
}
The exception occurs during running a test. However, before I post here tons of code (test/implementation..) probably somebody has an idea where to approach the problem - or which part should be investigated in more detail.
EDIT:
One interesting fact that by compiling with Java7 and Scala 2.10 (with the same library versions) the null pointer exception do not occur.
It's an open SWS bug
If you don't use the validation (no validationActions set), then do:
interceptor.setValidateResponse(false);
interceptor.setValidateRequest(false);
Edit:
As of 30.10.2017 the bug is closed. Should work fine with versions 2.4.1, 3.0.0.RELEASE and above.
the main reason is the inconsistency between the versions of ws and xmlsec.
if you are only client, then you can opt out the validation.
interceptor.setValidationActions("NoSecurity");
interceptor.setValidateResponse(false);
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.
I'm using the most up-to-date version of Eclipse (Helios) for Java development. I've written a lot of code for my project, and I'm also using some 3rd-party code in the project.
It's normal for the 3rd-party code to internally throw exceptions, even when nothing is deeply wrong. It will catch these itself. During a normal run, the 3rd-party code might throw a lot of these not-really-a-problem Exceptions.
I'd like to tell Eclipse that, during debugging, it should break when any of my code throws an Exception, but not when other code I'm linking to throws an Exception. Does anyone know if Eclipse supports this?
I know Eclipse lets you break only when Exceptions of certain types are thrown, but that doesn't help when 3rd party code and my own both throw standard Exceptions.
AFAIK no. But you can set a root Exception and make all your exceptions extends it. Then you can set up a Exception Breakpoint on you root exception.
In the breakpoint window you can do so, there is an icon.
I am having real trouble tracking down a bug and it would help be a lot to know which method called a certain method. Is there an easy way to get a call hierarchy from java? Java is a small part of the app so I cannot compile and run the whole app in eclipse/net beans so I don't have access to an IDE debugger's call hierarchy.
Thread.currentThread().getStackTrace();
or
Exception ex = new Exception();
ex.printStackTrace();
It's fairly slow, but fine for debugging purposes. API docs here.
Java is a small part of the app so I cannot compile and run the whole app in eclipse/net beans so I don't have access to an IDE debugger's call hierarchy.
You dont need to run the app at all. If you make a project in Eclipse, you can use its built-in Call Hierarchy tool to find all of the possible places that call a method.
There is a trade off: The Call Hierarchy tool will give you ALL of the places from where a method is called. This is a good if you want/need to know all the possibilities. Neslson's suggestion of Thread.currentThread().getStackTrace() will give you the places from where a method is invoked during the process of you program for this invocation. The nuance is that you might not run through every code path during this invocation. If you are seeing specific behavior and want to know how you got there, use the getStackTrace() option.
Have you tried using Java's remote debugging capability?
Google search to get you started if you haven't
The best thing to do is throw an exception, immediately catch it and analyze the stack trace.
I believe that is how Log4J is capable of logging the calling method.