This is the mail archive of the java@gcc.gnu.org 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] |
| Other format: | [Raw text] | |
You make it look as if Steve is speaking Klingon! ;-)
Doesn't what he says make sense? AFAICT, libgcj.so is not present even on most Linux users' system unless they are running a newish distro, so either the developer has to tell them to get this or bundle it with his application. (Even if it were, unless the API is sort of frozen, the issue will continue to persist.)
Both the scenarios are awkward, if not ugly, from a usability POV.
What is the difference between: (1) installation script installs a statically linked application; vs (2) installation script installs a dynamically linked application plus a shared library in an application-specific directory.
I have a hard time seeing the usability difference.
Download size for one - a statically linked in executable is unlikely to be as big as the whole libgcj.so, especially as more and more APIs keep getting implemented in libgcj. (On the other hand, the interdependencies in the core Java classes almost ensure that quite a bit gets linked in for even the most trivial applications!)
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |