[Bug libgcj/13708] [3.4/3.5 regression] static java program crashes at startup, UTF-8 environment

["tromey at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From tromey at gcc dot gnu dot org  2004-06-09 19:43 -------
Mark, I looked at this.

This is a longstanding gcj issue.  I hesitate to call it
a problem because, as I see it, static linking with gcj
can't really be made completely robust.  The user will always
need to know something about his application and will have
to explicitly link in classes that are only discovered via
reflection.  This is a general issue affecting not just libgcj
itself but any java library one might link against.

I looked at the patch in question.  It is reasonable enough,
though it still needs a tweak (there is no encoding named
"iconv", that handler is a special case).

I'd prefer not to check it in.  I think that, if it is fixed,
real programs will just run into further problems down the road.
For instance, a statically linked program won't have any
locales compiled in.  This means that java.text.* will work
mysteriously, or perhaps fail, depending on the circumstances.
Likewise for java.util.Calendar.

The fix we ordinarily recommend is to have your program directly
reference the encoders and locales it plans to use.  This is not
very satisfactory, I realize, but static linking isn't fully supported.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13708