This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dynamic loading - solutions and more problems

Bryce McKinlay <> writes:

> That would be way cool (at least in theory), because I don't like the idea (both
> from a file-size and complexity pov) of having to distribute complete .class
> files along with every precompiled .so library.

Well, I think it is a good idea to distribute complete .jar files
along with every precompiled .so library.  If a client application
wants to be compiled against your library you need to include .class
files, or a .zip or .jar file - or the .java source files.  I think
distributing .jar files makes most sense.  Think of .jar files as
"precompiled include files" needed to use a library (beyond just
linking against it).

> I don't think there is any
> fundamental reason why it couldnt be done, assuming everything you need to
> compile is available via reflection data, but I would imaging it will be a lot of
> work to change the compiler to do this.

Yes, in theory you don't need the .jar files if you have the .so
files.  However, it looks it be quite painful, especially if you're
cross-compiling.  For just native code, in theory your compiler could
just load the .so file.

> However, my gut feeling is that creating hundreds of .so files (one for every
> class or so) and loading each one dynamically is a bad idea.

I agree.  I think the paradign is that there should be one .so file
for every .jar file.  I.e. where Sun or anyone not using gcj
would ship N .jar files + M .so files (for jni libraries), we would
ship N .jar files + (M+N) .so files.  If the application uses cni
but does not support jni, we can ship just N .jar files + N .so files,
since for gcj the cni native methods would get linked into the same
.so file as the non-native methods.

> I'm guessing [-fno-assume-compiled] has suffered bit-rot
> because nobody uses it.

I suspect so too.

> It isn't even clear to me (exactly) what it is supposed to do.

Well, Anthony did add the generalization in November, so presumably
he (or a client) saw a need for it.
	--Per Bothner

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]