[fedora-java] Native code not loaded when it is in the db

[Andrew Overholt]

Hi Andrew,

I have natively-compiled all of Eclipse and created .db files and merged
them all into the system-wide .db.  I have verified that the .db file that
is being used by gij (this is a gcc that I have built from 4.0 branch head)
contains the .jar,.jar.so combinations that I want to use.  However, two of
the jars are being loaded as bytecode when I want them to be loaded from
their corresponding .so (as evidenced by the following).

eclipse -vmargs -verbose:

[...]
[Loaded (bytecode) org.eclipse.core.resources.ResourcesPlugin from (file:/home/andrew/work/eclipse/binary/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar <no certificates>)]
[...]

I wrote a little test app (attached) to generate the byte strings from a
jar just like they are presented by gcj-dbtool -l (*) so that I could
verify that the actual classes I'm interested in are in fact in the .db.
This is what I get:

java MD5Test /home/andrew/work/eclipse/binary/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar 
[...]
org/eclipse/core/resources/ResourcesPlugin.class -> 617779565aed3728932e63a591ad9d
[...]

and

gcj-dbtool -l `gcj-dbtool -p`
[...]
[21443] 617779565aed3728932e63a591ad9d -> /home/andrew/work/eclipse/native-3.1reallyclean/org.eclipse.core.resources_3.1.0.jar.so
[...]

(I have verified that my test program run on another jar that loads classes
that are BC-compiled has matching signatures to those in the .db)

Interestingly enough, when I try the same jar but with some modifications
(I edited some classes in Eclipse, re-generated the jar, and
natively-compiled it in the same way I did the above), its classes *are*
loaded from the .so.  This leads me to believe that something's either
wrong with this jar/.jar.so or with the part of gij that intercepts class
loading to feed stuff from .jar.sos in the .db.  Any ideas?  I guess
Eclipse could be loading these two jars in unique ways.  The second jar is
SWT which I know has JNI .sos ripped out the first time it is used so maybe
that is causing some weirdness there?

Thanks,

Andrew

* it would be nice if gcj-dbtool could have this functionality but I guess
  then it'll need to store the original classname ... perhaps I'll write a
  patch
-------------- next part --------------
import java.io.*;
import java.nio.channels.*;
import java.util.*;
import java.util.jar.*;
import java.security.MessageDigest;

public class MD5Test {

    public static void main(String[] args) {

	try {
	    MessageDigest md = MessageDigest.getInstance("MD5");

	    JarFile jar = new JarFile (args[0]);

	    int count = 0;
	    {
		Enumeration entries = jar.entries();
		while (entries.hasMoreElements())
		{
		    JarEntry classfile = (JarEntry)entries.nextElement();
		    if (classfile.getName().endsWith(".class"))
			count++;
		}
	    }

	    Enumeration entries = jar.entries();

	    while (entries.hasMoreElements())
	    {
		JarEntry classfile = (JarEntry)entries.nextElement();
		if (classfile.getName().endsWith(".class"))
		{
		    InputStream str = jar.getInputStream(classfile);
		    int length = (int) classfile.getSize();
		    if (length == -1)
			throw new EOFException();

		    byte[] data = new byte[length];
		    int pos = 0;
		    while (length - pos > 0)
		    {
			int len = str.read(data, pos, length - pos);
			if (len == -1)
			    throw new EOFException("Not enough data reading from: "
				    + classfile.getName());
			pos += len;
		    }
		    System.out.println(classfile.getName() + " -> " + bytesToString(md.digest(data)));
		}
	    }
	} catch (Exception e) {
	    e.printStackTrace();
	}
    }

    static String bytesToString(byte[] b)
    {
	StringBuffer hexBytes = new StringBuffer();
	int length = b.length;
	for (int i = 0; i < length; ++i)
	    hexBytes.append(Integer.toHexString(b[i] &
			0xff));
	return hexBytes.toString();
    }
}