Develop Reference

NoClassDefFoundError eventhough class in in same folder

I executed a main class and got the following error and trace.
This is the console command:
java -cp . net.sf.tinyPayroll.Main
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.hsqldb.Trace
at org.hsqldb.Database.reopen(Unknown Source)
at org.hsqldb.Database.open(Unknown Source)
at org.hsqldb.DatabaseManager.getDatabase(Unknown Source)
at org.hsqldb.DatabaseManager.newSession(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
at org.hsqldb.jdbcDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at net.sf.tinyPayroll.dao.DBConnector.connectDataFile(DBConnector.java:88)
at net.sf.tinyPayroll.dao.DBConnector.<init>(DBConnector.java:72)
at net.sf.tinyPayroll.dao.DBConnector.getInstance(DBConnector.java:106)
at net.sf.tinyPayroll.model.DataFile.<init>(DataFile.java:53)
at net.sf.tinyPayroll.Main.main(Main.java:42)
However, all the necessary classes are in the same folder.
Here is the file which is extracted and available in the same folder (the entire library is available in extracted form).
find . -name Trace*
./org/hsqldb/Trace.class
./org/hsqldb/util/Traceable.class

Your exception is:
NoClassDefFoundError: Could not initialize class org.hsqldb.Trace
Which doesn't mean that it cannot find the class org.hsqldb.Trace in your classpath, it means that the class could not be initialized for some reason.
It generally means that a RuntimeException was thrown while either trying to assign a value to a static field or while trying to execute some code in a static block.
For example we will get such issue in the next cases:
class Trace {
static MyClass foo = MyClass.newInstance(); // If it fails while calling newInstance
static {
SomeClass.init(); // If it fails while calling SomeClass.init()
}
...
}

As Nicolas has mentioned this doesn't mean that it cannot find the class org.hsqldb.Trace in your classpath, it means that the class could not be initialized for some reason.
I've checked the code (This might change based on version) http://grepcode.com/file/repo1.maven.org/maven2/hsqldb/hsqldb/1.8.0.1/org/hsqldb/Trace.java
In the class it has some static block which do some processing. Most probably some of the resources are missing in your class path

Groovy ConfigSlurper gives Class file too large RuntimeException

I am using the Groovy ConfigSlurper to load a large groovy file (741KB) from a Groovy script and consistently receive a RuntimeException when it tries to do the compilation.
Groovy 2.1.1, Java 1.6 (Apple/MacOSX)
I call it like so:
conf = new ConfigSlurper().parse(new File('conf.groovy').toURL())
And always get the exception below. Is there a known limitation to the size of a file ConfigSlurper can compile?
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: Class file too large!
java.lang.RuntimeException: Class file too large!
at org.objectweb.asm.ClassWriter.toByteArray(Unknown Source)
at org.codehaus.groovy.control.CompilationUnit$15.call(CompilationUnit.java:797)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1036)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:573)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:551)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:528)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:279)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:258)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:244)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:202)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:212)
at groovy.lang.GroovyClassLoader$parseClass.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at groovy.util.ConfigSlurper.parse(ConfigSlurper.groovy:146)
at groovy.util.ConfigSlurper$parse.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at write_users.run(write_users.groovy:19)
at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:257)
at groovy.lang.GroovyShell.run(GroovyShell.java:220)
at groovy.lang.GroovyShell.run(GroovyShell.java:150)
at groovy.ui.GroovyMain.processOnce(GroovyMain.java:588)
at groovy.ui.GroovyMain.run(GroovyMain.java:375)
at groovy.ui.GroovyMain.process(GroovyMain.java:361)
at groovy.ui.GroovyMain.processArgs(GroovyMain.java:120)
at groovy.ui.GroovyMain.main(GroovyMain.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
1 error

There is a known limitation but it is arguably not Groovy; it is the ASM library and ultimately Java.
As Stuart Halloway has mentioned in talks, it is often insightful to know what is happening one layer below your level of abstraction.
For example, this link shows that this code:
public byte[] toByteArray() {
if (index > Short.MAX_VALUE) {
throw new RuntimeException("Class file too large!");
}
... is likely the exception shown here:
java.lang.RuntimeException: Class file too large!
at org.objectweb.asm.ClassWriter.toByteArray(Unknown Source)
Why does the ASM method throw this exception? This post states:
It turns out that the magic number for the "code too large" error is
65535 bytes (compiled byte code, not source code).
It is probable that the file is too large for Groovy's internal implementation, which would result in a synthetic method that is too large for the JVM.

What causes an InternalError to be thrown by sun.awt.shell.Win32ShellFolder2.initSpecial()?

Some of our Windows users get this stack trace shortly after launching our app:
java.lang.InternalError: Could not bind shell folder to interface
at sun.awt.shell.Win32ShellFolder2.initSpecial(Native Method) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2.access$300(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2$1.call(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2$1.call(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.ShellFolder.invoke(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2.<init>(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolderManager2.getNetwork(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2.getFileSystemPath(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2.access$400(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2$10.call(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolder2$10.call(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:1.7.0_25]
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Unknown Source) ~[na:1.7.0_25]
at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_25]
Observations:
Every frame in the stack trace is something in the JDK, not in our code.
This happens only on Windows, but we've had reports of it on both Vista and Windows 7.
This happens with various versions of Java: 1.6.0_19, 1.6.0_21, 1.7.0_11, 1.7.0_25.
The problem happens to only a handful of our users, but is 100% repeatable for those users. Unfortunately, we haven't been able to see anything which those users' systems have in common other than exhibiting this issue, and none of our developers has ever experienced it themselves.
My search of Oracle's bug database turned up no bugs with the same or a similar stack trace.
There seem to be a lot of posts on the net about this particular issue without anyone having any idea what causes it.
I'm not holding out any hope of Oracle fixing whatever the problem is, if it is indeed a JDK bug---but if we knew what triggered the bug, we could at least help our users afflicted by it. Can anyone shed light on what causes this to happen?
Edit: The relevant native function is this one, from ShellFolder2.cpp:
JNIEXPORT void JNICALL Java_sun_awt_shell_Win32ShellFolder2_initSpecial
(JNIEnv* env, jobject folder, jlong desktopIShellFolder, jint folderType)
{
// Get desktop IShellFolder interface
IShellFolder* pDesktop = (IShellFolder*)desktopIShellFolder;
if (pDesktop == NULL) {
JNU_ThrowInternalError(env, "Desktop shell folder missing");
return;
}
// Get special folder relative PIDL
LPITEMIDLIST relPIDL;
HRESULT res = fn_SHGetSpecialFolderLocation(NULL, folderType,
&relPIDL);
if (res != S_OK) {
JNU_ThrowIOException(env, "Could not get shell folder ID list");
return;
}
// Set field ID for relative PIDL
env->CallVoidMethod(folder, MID_relativePIDL, (jlong)relPIDL);
// Get special folder IShellFolder interface
IShellFolder* pFolder;
res = pDesktop->BindToObject(relPIDL, NULL, IID_IShellFolder,
(void**)&pFolder);
if (res != S_OK) {
JNU_ThrowInternalError(env,
"Could not bind shell folder to interface");
return;
}
// Set field ID for pIShellFolder
env->CallVoidMethod(folder, MID_pIShellFolder, (jlong)pFolder);
}
In order to reach the "Could not bind" exception, it looks like pDesktop != NULL and relPIDL is retrieved successfully, but pDesktop->BindToObject() returns something other than S_OK. pDesktop is an IShellFolder*, which is apparently defined in Windows's <shellapi.h>. Aggravatingly, Java throws away the error code returned by IShellFolder::BindToObject.
So, I guess the question reduces to: What can cause IShellFolder::BindToObject to fail?
Edit 2: Since Win32ShellFolderManager2.getNetwork() is what's calling the Win32ShellFolder2 ctor at Win32ShellFolderManager2.java:181, we can see that the last argument to Win32ShellFolder2.initSpecial must be Win32ShellFolder2.NETWORK. So, is something is wrong with the user's Network Neighborhood folder, perhaps?

Well, there are several reports similar to yours (like this one from jEdit, this one from codenameone and this one - in german - which seems like a JFileChooser bug with a stack trace very close to yours in Windows 7 and Java 6). All seem related to JFileChooser and/or File Browsing in one way or another.
So I would approach this in one of two ways:
Either go for the time-consuming / non speculative road and take dumps of the affected installations with tools such as jstack, VisualVM or JConsole until you are able to isolate the root cause of the problem (which may or may not be the JFileChooser). If you choose that path, remember that either remote access to one of the affected installations or help from a technical savvy user is a must.
Or try to take a shortcut, assume that the problem is indeed the JFileChooser (as anecdotal evidence shows) and release a custom version replacing the JFileChooser by FileDialog. If it runs as expected on the affected machines case is closed; else give yourself a tap on the back for trying and take "The Long and Winding Road".

Had same problem and the answer was
java.awt.FileDialog
If you look up VbScript solutions for "Open File Dialog", it seems that there is no COM class doing the job for most of the windows platforms

readObject() is not working and breaks from method

I'd like to read different kinds of objects from file to an ArrayList, all of them are instances of class which extend the class Advertisement. I'm trying with this code:
ArrayList <Advertisement> ads = new ArrayList<Advertisement>();
ObjectInput input2 = new ObjectInputStream(
new BufferedInputStream(new FileInputStream("ads.ser")));
//break from this method at this point
ads = (ArrayList<Advertisement>) input2.readObject();
The problem is at the 3rd line/last line. It doesn't read the objects in variable ads of type ArrayList<Advertisement>, furthermore, it breaks from this method, without any messages.
Edit: Removed the try-catch block, I should have done it earlier, but I still don't know the solution. Stacktrace:
java.io.InvalidClassException: Kiado; local class incompatible: stream classdesc serialVersionUID = -1393576200767336208, local class serialVersionUID = -841663850423605586
at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.ArrayList.readObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at java.io.ObjectStreamClass.invokeReadObject(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at Main.beolvasas(Main.java:30)
at Main.startup(Main.java:57)
at Main.main(Main.java:633)

Now that you have a stack trace, the problem is clear: since the moment you serialized the objects to the file, you have made changes to the class Kiado. So the class you have now is not compatible anymore with the class as it was when serializing the objects to the file.
If you didn't change the number and the names of the fields of the class (and of all its superclasses), you can make it compatible again by just adding the following variable declaration in the class:
private static final long serialVersionUID = -1393576200767336208;
If you added, removed or renamed at least one (non-transient) field, then you might make the new class still compatible with the old one, but with more pain. And we would have to know the nature of the changes to help you.
I would personally avoid using native serialization for long-term storage because, as you just noticed, it's fragile and makes it hard to change the model. I would use a more easily readable and migratable file format: XML or JSON for example.

Do you have any code like:
catch(<WheteverException> e)
{
// nothing here
}
If so do the following:
change the // nothing here to e.printStackTrace();
remove the try/catch and only add it back if the compiler tells you to, and then only add back what exception that the compiler tells you to add (for instance don't do catch(Exception e).

Why is WSDL parser still importing external documents?

I tried to turn off importing documents in WSDL4J (1.6.2) in the way suggested
by the API documentation:
wsdlReader.setFeature("javax.wsdl.importDocuments", false);
In fact, it stops importing XML schema files declared with wsdl:import tag, but does stop importing files declared with xs:import tags.
The following code snippet [see at the end of the letter] for the example file
http://www.ibspan.waw.pl/~gawinec/example.wsdl
returns the following exception:
javax.wsdl.WSDLException: WSDLException (at /definitions/types/xs:schema):
faultCode=OTHER_ERROR: An error occurred trying to resolve schema referenced
at 'EchoExceptions.xsd', relative to
'http://www.ibspan.waw.pl/~gawinec/example.wsdl'.:
java.io.FileNotFoundException: This file was not found:
http://www.ibspan.waw.pl/~gawinec/EchoExceptions.xsd
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at IsolatedExample.main(IsolatedExample.java:15)
Caused by: java.io.FileNotFoundException: This file was not found:
http://www.ibspan.waw.pl/~gawinec/EchoExceptions.xsd
at com.ibm.wsdl.util.StringUtils.getContentAsInputStream(Unknown Source)
... 10 more
Can you suggest me any solution to this problem? I just don't want to import
external XML schemata.
Regards,
Maciej
import javax.wsdl.WSDLException;
import javax.wsdl.factory.WSDLFactory;
import javax.wsdl.xml.WSDLReader;
public class IsolatedExample {
public static void main(String[] args) {
WSDLFactory wsdlFactory;
try {
wsdlFactory = WSDLFactory.newInstance();
WSDLReader wsdlReader = wsdlFactory.newWSDLReader();
wsdlReader.setFeature("javax.wsdl.verbose", false);
wsdlReader.setFeature("javax.wsdl.importDocuments", false);
wsdlReader.readWSDL("http://www.ibspan.waw.pl/~gawinec/example.wsdl");
} catch (WSDLException e) {
e.printStackTrace();
}
}
}

A quick look at WSDL4J (it's been a while since I've worked directly with this project) suggests that there is no option specifically to prevent the reading of imported schemas. You may have stumbled upon on a bug in WSDL4J's mechanism of deserializing schemas. That said, if you're not interested in the contents of any schemas, including those inlined in the WSDL document, you can register your own extension registry (simply modify the PopulatedExtensionRegistry class to leave out the SchemaDeserializer).
Specifically, leave out the following lines:
mapExtensionTypes(Types.class, SchemaConstants.Q_ELEM_XSD_1999,
SchemaImpl.class);
registerDeserializer(Types.class, SchemaConstants.Q_ELEM_XSD_1999,
new SchemaDeserializer());
registerSerializer(Types.class, SchemaConstants.Q_ELEM_XSD_1999,
new SchemaSerializer());
mapExtensionTypes(Types.class, SchemaConstants.Q_ELEM_XSD_2000,
SchemaImpl.class);
registerDeserializer(Types.class, SchemaConstants.Q_ELEM_XSD_2000,
new SchemaDeserializer());
registerSerializer(Types.class, SchemaConstants.Q_ELEM_XSD_2000,
new SchemaSerializer());
mapExtensionTypes(Types.class, SchemaConstants.Q_ELEM_XSD_2001,
SchemaImpl.class);
registerDeserializer(Types.class, SchemaConstants.Q_ELEM_XSD_2001,
new SchemaDeserializer());
registerSerializer(Types.class, SchemaConstants.Q_ELEM_XSD_2001,
new SchemaSerializer());

I haven't used Java for webservices, but have you tried setting an absolute path to the schemas you import? Perhaps it's trying to load a local file.
You could also try sniffing the wire to see if you're making a request, perhaps it's malformed.
$0.02