Thanks to all for your contribution. We have now a version that works and without further optimizations we can run jamvm with a local classpath of ~ 800ko and still be able to use all the classes in GNU Classpath by loading them from a remote http location. Indeed there were several problems having a seperate ClassLoader among them: - all classes from a same package must be loaded from the same classloader due to a security concern. Bypassing this security in jamvm occurs further problems. - classes loaded by bootstrap and classes loaded by system class loader or any other one are not loaded in the same place within jamvm. Loading the class bytes in java and then providing them to the bootstrap class loader won't work either: -When resolving symbolic links, the VM re-use the same class loader as the class that is loading and in this case it is "null" so the only place it will look for the further classes is glibj.zip So: - Since we didn't want to code an HTTP classloader in C, the easiest solution we found is calling static java code from C using JamVM functions: => have a static method that getBytesFromURL in class ClassLoader (could have been another class) => Call this static method from JamVM / Bootstrap ClassLoader just after it has search in the local zip file and if the class was still not found. It is short, simple, doesn't need any other modifications in class/methods/function signature. It works well, so again, thanks for your advice.
