Re: native java libraries
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, spam2005@meeque.de 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 <wasabi@larvalstage.net>
Reply to: