On Tue, Mar 29, 2005 at 12:45:01PM +0200, [EMAIL PROTECTED] wrote: > Hi list. > > > >>When these .so files are present (in the correct location, > >>registered with the correct mechanism) gij will load them automatically > >>and use them in the place of the corresponding .jar file. > > Though I don't know too much about GCJ/GIJ, I've followed the discussion > about native java labraries > with interest. IMO, all of this sounds interesting, but it should be an > optional feature. The users > should be able to decide whether to use it or not. > > > Philipp Hug wrote: > >Why don't we optionally compile the jars when the package is installed on > >the users machine? > > Isn't that similar to the way Python files are now handled in Debian? There > it is source-files (*.py) > vs. byte-code-files (*.pyc), whereas for Java it is byte-code-files (*.jar) > vs. native-files (*.so). > But otherwise the problem seems analog. > > I don't know exactly, how those compiled Python libraries are handled in > Debian, but I've got the > impression that they are compiled, when the package is installed. Maybe > someone would mind to figure > out if that's correct? Then you could ask the python guys for implementation > details... > > > Though in Debian the Python byte-code-files seem to be compiled on > installation, the usual approach > of a python interpreter is to compile such files on demand. I think, such an > approach would be a good > idea for native java libraries. > > So here is my proposal: > Since the use of native java libraries is a feature of GCJ/GIJ only, the > handling of those libraries > should be left to those. GIJ should first check if there is native version of > a java library. If not, > it should compile one the first time it is needed, and persistently add it to > a cache of native > libraries (e.g. in somewhere in /var). This would mean a performance loss the > first time a library is > loaded, but might improve loading speed on future access. > > Such a feature could probably be implemented in some Debian-specific wrapper > scripts for GIJ. Or > someone could propose this feature to the upstream developers of GCJ/GIJ. > Also, this feature should > be optional, e.g. controlled by some configuration file or by an environment > variable. Additionally > some tools could be offered to monitor and manipulate the cache of native > libraries manually. > > I havn't thought to much about implementation details yet, since I don't have > enough knowledge > anyway. But I think my approach should be possible somehow. The big benefit > would be, that it does > not have any impact on the archive space or the on disk space of users who > can't benefit from it > anyway. On the other hand, it would still offer easy access to native java > libraries for all GIJ > users who want that feature.
Have you looked into GCJ upstream sources? It does already most of what you describe and Fedora uses it. BTW: The Fedora people decided after a long discussion to compile to native at build time of a package. > Please tell me, if any of the above sounds reasonable! In any case, I'd > advice to evaluate that > native java libraries stuff carefully, before letting it have too much impact > on *all* Java packages > in Debian. Well, it sounds reasonable but at as long as there are cases where GCJ-4.0 compiles over 30 minutes on a recent system with 512MB of RAM and then exits with an OutOfMemoryError this is more or less useless. As said and decided before we need a proof that we really gain something from compiling to native and not only get new problems. Michael -- Homepage: http://www.worldforge.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
