On Mon, 2004-07-05 at 10:14, mr mike wrote: > Thomas, > > does this mean that when we start a java program it will be compiled to > native code and then run? > No. The java command will be a wrapper script that runs gij. When gij is invoked on a class name, it first searches in /usr/lib for a natively-compiled version of that class. For example: $ gij org.eclipse.jdt.internal.compiler.batch.Main will cause gij to look for libraries in this order: /usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-Main.so /usr/lib/lib-org-eclipse-jdt-internal-compiler-batch.so /usr/lib/lib-org-eclipse-jdt-internal-compiler.so ... until it finds a match for org.eclipse.jdt.internal.compiler.batch.Main. If it doesn't find a match, then it begins searching through its class path for a bytecode version of the class, just like a traditional JVM. The plan is to create separate RPMs that provide these natively-compiled libraries. If those RPMs are installed, then gij will transparently find and run the native libraries, rather than the (slower) bytecode provided by the corresponding noarch RPMs. Tom > mike > > On Sat, 2004-07-03 at 21:25, Thomas Fitzsimmons wrote: > > > To make use of GCJ's abilities, we're going to create an arch-specific > > add-on package for each jpackage that will contain DSOs created from the > > jpackage's jars. gij will automatically find and load these DSOs as > > part of its class lookup algorithm. This will give us the speed > > benefits of native compilation without requiring us to sacrifice > > compatibility with more traditional Java environments. > > > > Tom > > > > >
