There is no good way to make a global cache at runtime other than a SUID binary, which is not happening. A per user cache is also not practical.
On Tue, 2005-03-29 at 12:45 +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. > > > 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 > > -- Jerry Haltom <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
