Re: [Jython-dev] Natively compiled jython, take II.

[Alexandre Petit-B. <apb...@cy...>]

Finn Bock writes:

> In addition to loading of java packages from .jar files, jython also
> accept directories in the filesystem found on the CLASSPATH as java
> packages. This is why your symlink helps.

And this is where setting CLASSPATH to point to our runtime jar and
jython's jar helps. Now I can run jython from anywhere.

> I'm not at all sure how this scanning of .jar files can/should be
> done in the gcj environment. Does the rt.jar (or classes.zip) file
> still exists as a file?

Yeah, it's a file called libgcj.jar.

> The AnonInner.java source in Lib\test\javatests must be compiled
> manually. The output .class files should just be placed the same
> directory.

Noted.

> How exactly would that work? Would a foo$py.class file be dynamicly
> compiled into a foo$py.so library and loaded by the gij VM?

Well, jython's executable would use class loading features of our VM
(that most importantly for us deals with loading things in and out,
without necessarily executing bytecode.) So basically, yes. The
mechanism is exposed here:

  http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/libjava/java/lang/natClassLoader.cc?rev=1.38&content-type=text/plain

(search for quux.) Note that this is a C++ file, as we seamlessly mix
native Java and C++ code -- that's how we write the native parts of
our runtime, but we support JNI if necessary. CNI is pretty cool, you
can read more about it here: http://gcc.gnu.org/java/papers/cni/t1.html

So you can write the following:

  Foo.java:
  class Foo {}

  jld.java:
  class jld {
    public static void main (String[] arg)
    {
        Class x;
        try {x = Class.forName ("Foo");} catch (Exception _) {return;}
        java.lang.reflect.Method m[] = x.getMethods();
        for (int i = 0; i < m.length; i++)
  	  System.out.println (m[i].toString());
    }
  }

Using gcj, you create an executable from jld.java:

 $ gcj jld.java --main=jld -o jld

If you execute it now, it will do nothing.

Compile Foo.java to a class file and you'll be able to extract
informations about the class Foo:
  
  $ gcj -C Foo.java
  $ ./jld
  public final void java.lang.Object.wait(long) throws ...
  public final void java.lang.Object.wait() throws ...

Now remove the classfile and generate the matching shared object:

  $ rm Foo.class
  $ gcj -fPIC -shared Foo.java  -o lib-Foo.so

(Or we could also do gcj -fPIC -shared Foo.class -o lib-Foo.so, which
 is what I hope to hook to jython and jythonc.)

Now re-run jld, it gives the same result because it's loading the
shared object in place of the class file. You can also compile
jld.java to a class file and let our interpreter do the work by
interpreting bytecodes (but still getting info about Foo loading a
shared object:)

  $ gcj -C jld.java
  $ gij jld
  ...

Note that libgcj's interpreter (gij) naturally naturally trades
bytecodes for shared object and applies it everywhere it can, as you
could make a shared library out of jld.java and let gij load it and
execute it natively instead of interpreting the bytecode:

  $ rm jld.class
  $ gcj -fPIC -shared jld.java -o lib-jld.so
  $ gij jld
  ...

Which still is not quite like having a jld stand alone executable, but
everything is still compiled natively.

> Do you have some web links that would allow us to read about the
> enviroment that gij is running with?

You can read the documentation section of our website:

  http://gcc.gnu.org/java/docs.html

We are fairly compliant with a mixture of 1.1, 1.2 and even 1.3. It's
a clean-room implementation of the Java runtime, we're working with the
classpath project. It's known to work on {x86,ia64,ppc,alpha}/linux,
*BSD is being re-fixed one more time, Solaris should work (it used to
be our primary platform but I'm not sure the interpreter works well
anymore.) Some people have been working on a Darwin port, and there
are also numerous lesser known CPU ports being hacked on.

./A