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.
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.
Regards, Michael