When I launch an SWT application (via an Eclipse launch profile), I receive the following stack trace:
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/jface/resource/FontRegistry
at org.eclipse.jface.resource.JFaceResources.getFontRegistry(JFaceResources.java:338)
at org.eclipse.jface.window.Window.close(Window.java:313)
at org.eclipse.jface.dialogs.Dialog.close(Dialog.java:971)
at org.eclipse.jface.dialogs.ProgressMonitorDialog.close(ProgressMonitorDialog.java:348)
at org.eclipse.jface.dialogs.ProgressMonitorDialog.finishedRun(ProgressMonitorDialog.java:582)
at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:498)
at com.blah.si.workflow.SWTApplication.main(SWTApplication.java:135)
Now, the things that make this odd:
When I change the project build path and replace jface.jar with the source project (same version - 3.3.1), the error goes away.
Other applications I have that use the same jar, and a copy of the same launch profile and project, all works fine.
This is NOT a ClassNotFoundException. The class is on the classpath. If I attach source to the jar, I can debug into the getFontRegistry method. The method will execute successfully several times before eventually throwing a NoClassDefFoundError on line 338. Line 337 is a "if variable == null" statement checking to see if a static variable has been initialized. Line 338 is initializing it if it is not already initialized. The first time through, the null check fails, and the initialization is performed. On subsequent passes through the method, the null check passes, and thus the already-initialized static value is returned. On the final pass (the one that fails,) the null check fails again (even though the static variable has already been initialized) and when it tries to re-initialize the static variable, the NoClassDefFoundError is thrown. Here is the relevant source (starting with line 336, note that fontRegistry is a private static variable that is set in no other place):
.
public static FontRegistry getFontRegistry() {
if (fontRegistry == null) {
fontRegistry = new FontRegistry(
"org.eclipse.jface.resource.jfacefonts");
}
return fontRegistry;
}
.
I have already gotten a fresh copy of the jar (to ensure it isn't corrupted,) deleted my .classpath and .project files and started a fresh project, and recreated the launch profile. No change.
Because of the peculiarities in #3 above, I'm suspecting some kind of wierd classloader behavior - it seems as if that final pass through the method is in another classloader?
Ideas?
Update: The answer provided by Pourquoi Litytestdata prompted me to pay attention to what happens in the try block just above line 458 of ProgressMonitorDialog. Indeed, that code was throwing an exception, which was being gobbled by the finally block. The root cause was ANOTHER missing class (the missing class was not JFontRegistry or any of its directly related classes, but another that was spider-web dependencied in an edge case.) I'm upvoting all answers pointing me to pay attention to the classpath, and accepting Pourquoi's, because it was the breakthrough. Thanks to all.
It sounds like you are missing a JAR file that holds a dependency, as mentioned in this blog entry from July 2006, written by Sanjiv JIVAN:
Difference between ClassNotFoundException and NoClassDefFoundError
A ClassNotFoundException is thrown when the reported class is not found by the ClassLoader.
This typically means that the class is missing from the CLASSPATH.
It could also mean that the class in question is trying to be loaded from another class which was loaded in a parent ClassLoader and hence the class from the child ClassLoader is not visible.
This is sometimes the case when working in more complex environments like an App Server (WebSphere is infamous for such ClassLoader issues).
People often tend to confuse java.lang.NoClassDefFoundError with java.lang.ClassNotFoundException. However there's an important distinction.
For example an exception (an error really since java.lang.NoClassDefFoundError is a subclass of java.lang.Error) like
java.lang.NoClassDefFoundError:
org/apache/activemq/ActiveMQConnectionFactory
does not mean that the ActiveMQConnectionFactory class is not in the CLASSPATH.
In fact, its quite the opposite.
It means that the class ActiveMQConnectionFactory was found by the ClassLoader however when trying to load the class, it ran into an error reading the class definition.
This typically happens when the class in question has static blocks or members which use a Class that's not found by the ClassLoader.
So to find the culprit, view the source of the class in question (ActiveMQConnectionFactory in this case) and look for code using static blocks or static members.
If you don't have access the the source, then simply decompile it using JAD.
On examining the code, say you find a line of code like below, make sure that the class SomeClass in in your CLASSPATH.
private static SomeClass foo = new SomeClass();
Tip : To find out which jar a class belongs to, you can use the web site jarFinder. This allows you to specify a class name using wildcards and it searches for the class in its database of jars.
jarhoo allows you to do the same thing but its no longer free to use.
If you would like to locate the which jar a class belongs to in a local path, you can use a utility like jarscan. You just specify the class you'd like to locate and the root directory path where you'd like it to start searching for the class in jars and zip files.
I think the stacktrace presented above is concealing the real problem here. Below is the code in the method run within
org.eclipse.jface.dialogs.ProgressMonitorDialog (with a comment added by me):
public void run(boolean fork, boolean cancelable,
IRunnableWithProgress runnable) throws InvocationTargetException,
InterruptedException {
setCancelable(cancelable);
try {
aboutToRun();
// Let the progress monitor know if they need to update in UI Thread
progressMonitor.forked = fork;
ModalContext.run(runnable, fork, getProgressMonitor(), getShell()
.getDisplay());
} finally {
finishedRun(); // this is line 498
}
}
The second-from-bottom line in Jared's stacktrace is line 498 of this class, which is the call to finishedRun() within the finally block. I suspect that the real cause is an exception being thrown in the try block. Since the code in the finally block also throws an exception, the original exception is lost.
To get a better handle on if it is a class loader issue go through the code where it works and add:
try
{
final Class clazz;
final ClassLoader loader;
clazz = Class.forName("org/eclipse/jface/resource/FontRegistry");
loader = clazz.getClassLoader();
System.out.println("The classloader at step 1 is: " + loader);
}
catch(final Throwable ex)
{
ex.printStackTrace();
}
And then do the same thing where you are getting the NoClassDefFoundError and see if the class loaders are different.
Then you will be able to ensure that it is the ClassLoader that is different. Can you report back with what happens with this? Depending on what the result is I might have more ideas.
To add to the excellent TofuBeer's answer, since NoClassDefFoundError indicates that:
class org.eclipse.jface.resource.FontRegistry was found by the ClassLoader,
but can not been loaded without triggering an error, like having static blocks or members which use a Class that's not found by the ClassLoader.
Let's look at org.eclipse.jface.resource.FontRegistry source code:
It does not have any static variable initialization (nor does its superclasses).
Let's look at org.eclipse.jface.resource.JFaceResources source code
The getFontRegistry() function in which the Error is triggered is using the static variable fontRegistry:
/**
* The JFace font registry; <code>null</code> until lazily initialized or
* explicitly set.
*/
private static FontRegistry fontRegistry = null;
Thus, it begs raises the question: why a static initialized variable would suddenly be considered null again ?
Because somehow FontRegistry or JFaceResources get unloaded by the gc ?!
If a field is declared static, there exists exactly one incarnation of the field, no matter how many instances (possibly zero) of the class may eventually be created. A static field, sometimes called a class variable, is incarnated when the class is initialized (§12.4).
So it doesn't matter whether instances of the class exist at any time, the field will exist as long as the Class itself has been loaded.
If this were a eclipse Plugin, this could have been related to this FAQ entry
Here is a typical scenario for a new user:
You are writing a plug-in that extends plug-in XYZ.
To get it to compile, you add a reference to the JAR file for plug-in XYZ to your project’s build path either from the Java Build Path property page or by editing the .classpath file.
When you launch a runtime workbench, the following surprising error is reported: java.lang.NoClassDefFoundError: XYZ.SomeClass.
Do not start looking in the Plug-ins and Fragments tab in the launch configuration for the runtime workbench.
That tab influences only which plug-ins are used for your runtime workbench and whether they are loaded from the workspace or from the Eclipse install directory.
Instead, start looking in the plug-in manifest.
Edit the plugin.xml file and ensure that XYZ is mentioned as a required plug-in.
Then, save the plugin.xml file.
This will update the project’s build path automatically.
Never manually edit the .classpath file when you are writing a plug-in.
The plug-in Manifest Editor simply overwrites any changes you make to it. Not very civilized, but that is the way it works.
If you try to load the class FontRegistry on your own (like TofoBeer described), you will find out that classes of the following JAR are dependent classes if using FontRegistry.
org.eclipse.core.commands_xxxxx.jar
You must add this JAR to your build path.
Related
Learning Java. I have two files, each containing one java class. When I run the file with the main method, I get the following error:
Exception in thread "main" java.lang.IllegalAccessError: failed to access class TapeDeck from class TapeDeckTestDrive (TapeDeck is in unnamed module of loader 'app'; TapeDeckTestDrive is in unnamed module of loader com.sun.tools.javac.launcher.Main$MemoryClassLoader #18bf3d14)
at TapeDeckTestDrive.main(TapeDeckTestDrive.java:3)
class TapeDeckTestDrive{
public static void main(String[] args){
TapeDeck t = new TapeDeck();
t.canRecord = true;
t.playTape();
if (t.canRecord == true) {
t.recordTape();
}
}
}
class TapeDeck {
boolean canRecord = false;
void playTape(){
System.out.println("tape playing");
}
void recordTape(){
System.out.println("tape recording");
}
}
Any help please?
Actual Issue
I got this exact same error* doing something very silly:
I tried to run the file as java {main-class}.java. That simple!
Instead, be sure to run it simply as java {main-class}.
*Specifically, the error format I had, like yours:
Exception in thread "main" java.lang.IllegalAccessError: failed to access class {pack.other-class} from class {pack.main-class} ({pack.other-class} is in unnamed module of loader 'app'; {pack.main-class} is in unnamed module of loader com.sun.tools.javac.launcher.Main$MemoryClassLoader #29f69090)
at {pack.main-class}.{who-cares-where}
at {pack.main-class}.{who-cares-why}
. . .
Extra Advice
You can get a similarly annoying error on the same issue, namely inability to access packages in the same directory, if you only compile your {main-class}.
So instead of javac {directory}/{main-class}.java
Be sure to compile all of them at the same time, so there's no issue in cross-referencing: javac {directory}/*.java
OP Specific
This would just be a silly command-line mistake. If it's occurring in IntelliJ as well, as you say, this isn't your issue. However, I hope it's at least helpful to the others who come across your question with this error!
Make sure each class is in the same folder, since the error is saying TapeDeckTestDrive can not find TapeDeck. I would recommend starting out with an IDE like Eclipse since it will help you focus more on coding and less with folder problems.
I know your code is all good (in java 8 at least) since when I copied it in eclipse it works no problem, meaning it has to be a folder problem, a problem with the installed version of java, or the way you are running the code is not working for some reason. If both files are in the exact same folder then I would make sure your java version says 1.8 something in the system files (Program Files(x86) most likely in windows), if it does not say that version then it could be another problem with the code and syntax for that version.
Another thing that might help is to put public behind the "class" on the first line of each class and make the Boolean public. This might be a syntax requirement on other versions of java or something that is needed when running off command prompt.
Quick possible fix, try making the classes and methods "Public".
Under normal circumstances this shouldn't be necessary but you may be hitting a specific case where it might be (It's an edge case so I don't know if it's a problem or not off the top of my head):
Java is really uncomfortable with stuff being in the "Default" package--code from other packages can't access objects in the default package (Meaning no package statement). Although this shouldn't cause problems in your case, maybe your "package" level security settings are also not working in the default package.
If this is actually the problem, the two fixes would be to make the packages and methods public (as I said above) or move both classes into a package.
What worked for me was to add the key word 'public' in both methods (playTape and recordPlay) and variables (canRecord).
I am dynamically compiling Java sources using the Java compiler API. My generated source files inherit from com.example.BaseClass, which is just a normal class, not dynamically generated. The generated Java sources look like this:
public class Foo implements com.example.BaseClass
{
#Override
public Integer getAnswer(com.example.Context context) throws Exception
{
return ...;
}
}
All works fine when running in IDE, but after packaging into a Springboot jar, my com.example.BaseClass is moved to BOOT-INF/classes/com.example.BaseClass. When dynamically compiling I now get:
/Foo.java:1: error: package com.example does not exist
public class Foo implements com.example.BaseClass
^
I try to change the classloader of the compiler so that the compiler will search in BOOT-INF/classes.
ClassLoader before = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(new CustomClassloader(before));
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
Thread.currentThread().setContextClassLoader(before);
However, debugging shows that my CustomClassloader.loadClass(String name) method is never called. More debugging showed that compiler.getClass().getClassloader() returns
java.net.FactoryURLClassLoader#39a5ae48
So, the CustomClassloader is not used by the Compiler instance. How can I get the Compiler to use my CustomClassloader? Better solutions for solving the compiling issue are also welcome ofcourse :-).
There are some oddities about how the java standard compiler does lookups and it doesn't always resolve out of the running class path correctly. Anyway, it does that resolution using the JavaFileManager.list call.
It will call it at least 4 times in the process of trying to look up your base class. Override a ForwardingJavaFileManager and pass that into getTask and have it lookup the resource and return it.
Alternately, you could use the Janino in-momeory compiler library which sets up a fake in memory file system ( no compiling to disk ) and still uses the plaform compiler and sorts out all this classpath nonsense for you.
I have this code:
GoogleApiAvailability googleAPI = GoogleApiAvailability.getInstance();
String msg = getString(R.string.common_google_play_services_update_text);
Log.e(TAG, msg);
Dialog errDlg = googleAPI.getErrorDialog(MyActivity.this, result, 1111, listener);
When this runs, the String common_google_play_services_update_text is correctly written to LogCat, but getErrorDialog() throws this Exception:
java.lang.NoSuchFieldError: No static field
common_google_play_services_update_text of type I in class
Lcom/google/android/gms/R$string; or its superclasses (declaration of
'com.google.android.gms.R$string' appears in
/data/app/com.mygame-1/base.apk)
How can I fix this?
The error NoSuchFieldError means that the class doesn't have a field of a specified name. It is thrown if an application tries to access or modify a specified field of an object, and that object no longer has that field. Normally, this error is caught by the compiler and can only occur at run time if the definition of a class has incompatibly changed.
Also, maybe you've got old code that is referencing a field that no longer exists in the recompiled class files. You may check it here.
The solution is to clean out all the class files and compile everything from fresh.
Update: If you still get the same error after recompiling everything, then you're probably compiling against one version of an external library and using another at runtime.
What you need to do now is first identify the class that is causing the problem (it looks like you have done this already) and then run your application with the -verbose:class command line option. It will dump a lot of class loading information on your standard out and you'll be able to find out where the problematic class is exactly loaded from.
Hope this helps!
I have a web service we'll call service.war. It implements an interface we'll call ServicePluginInterface. During the startup of service.war, it reads in environment variables and uses them to search for a jar (MyPlugin.jar). When it finds that jar, it then uses a second environment variable to load the plugin within the jar. The class that it loads looks like this:
public class MyPlugin implements ServicePluginInterface {...}
The servlet attempts to load the plugin using code like:
try {
if (pluginClass == null) {
plugin = null;
}
else {
ZipClassLoader zipLoader = new ZipClassLoader(Main.class.getClassLoader(), pluginJar);
plugin = (ServicePluginInterface)zipLoader.loadClass(pluginClass).newInstance();
plugin.getAccount(null,null);
}
} catch (Exception e) {
...
}
The trick is that I don't have source or a jar for ServicePluginInterface. Not wanting to give up so easily, I pulled the class files out of the service.war files. By using those class files as dependencies, I was able to build, without compiler warnings, MyPlugin. However, when actually executed by Tomcat, the section of code above generates a runtime exception:
java.lang.ClassCastException: com.whatever.MyPlugin cannot be cast to com.whomever.ServicePluginInterface
As a second point of reference, I am also able to construct a synthetic class loader (separate java executable that uses the same class loading mechanism. Again, since I do not have the original source to ServicePluginInterface, I used the class files from the WAR. This second, synthetic loader, or faux-servlet if you will, CAN load MyPlugin just fine. So I would postulate that the Tomcat JVM seems to be detecting some sort of difference between the classes found inside the WAR, and extracted class files. However, since all I did to extract the class files was to open the WAR as a zip and copy them out, it is hard to imagine what that might be.
Javier made a helpful suggestion about removing the definition of ServicePluginInterface, the problem with that solution was that the ZipClassLoader that the servlet uses to load the plugin out of the jar overrides the ClassLoader findClass function to pull the class out of the JAR like so:
protected Class<?> findClass(String name) throws ClassNotFoundException
{
ZipEntry entry = this.myFile.getEntry(name.replace('.', '/') + ".class");
if (entry == null) {
throw new ClassNotFoundException(name);
}
...
}
The class ZipClassLoader then recursively loads all parent objects and interfaces from the jar. This means that if the plugin jar does not contain the definition for ServicePluginInterface, it will fail.
Classes defined by different class loaders are different:
At run time, several reference types with the same binary name may be
loaded simultaneously by different class loaders. These types may or
may not represent the same type declaration. Even if two such types do
represent the same type declaration, they are considered distinct. JLS
In that case zipLoader returns an instance of MyPlugin that implements the other ServicePluginInterface (is it loaded from the zip too?):
(ServicePluginInterface)zipLoader.loadClass(pluginClass).newInstance();
It seems that the application server already has a definition of ServicePluginInterface, then you don't need to redeploy it. It should be enough to add the required files (ServicePluginInterface, etc.) as non-deployed dependecies of your project.
Another approach goes by living with the fact, and accessing methods in ServicePluginInterface via reflection (use the Class object returned by zipLoader, instead of ServicePluginInterface.class).
I'm trying to use the org.apache.ddlutils package for reading database metadata.
I've written the following method:
public static void readMetaData(DataSource dataSource) throws DdlUtilsException{
final Platform platform = PlatformFactory.createNewPlatformInstance(dataSource);
}
But the statement throws DdlUtilsException gives the following error:
No exception of type DdlUtilsException can be thrown; an exception type must be a subclass of Throwable
I simply do not understand the reason behind this error because the API at http://db.apache.org/ddlutils/api/org/apache/ddlutils/DdlUtilsException.html clearly states the following:
java.lang.Object
extended by java.lang.Throwable
extended by java.lang.Exception
extended by java.lang.RuntimeException
extended by org.apache.commons.lang.exception.NestableRuntimeException
extended by org.apache.ddlutils.DdlUtilsException
Please advice.
My guess is that you've got another class called DdlUtilsException somewhere - possibly in the top-level package, given that the compiler isn't mentioning a full package name. If you're using Eclipse or something similar, try to navigate to the class declaration.
EDIT: Okay, judging by your comment, you aren't including the various dependencies. Make sure you've downloaded DdlUtils-1.0-bin.zip, and the dependencies are all in the lib directory. It's not immediately clear to me whether you need all of them, but you might as well use them all to start with, and then remove what you don't need.
It looks like that other class 'org.apache.commons.lang.exception.NestableRuntimeException' is located in commons-lang. Download and add that jar and it should work. Check the docs for DDL Utils and see what else it depends on.