This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: gcj 2.96 and rh7 [I18N/getopt]
- To: java-discuss at sourceware dot cygnus dot com
- Subject: Re: gcj 2.96 and rh7 [I18N/getopt]
- From: David Brownell <david-b at pacbell dot net>
- Date: Tue, 28 Nov 2000 11:28:35 -0800
- References: <3A23EFEC.901B4866@pacbell.net>
One more problem I forgot to mention -- I'd be very interested to
know how other folk are dealing with this one.
I used the "gnu.getopt" package, a version I found somewhere that
seemed to be as current as it gets. But it didn't work with GCJ,
because of ResourceBundle problems related to the I18N that had
been done using text files. It couldn't load the default (which
I recall as English) properties file, and the exception couldn't
be recovered from.
That was easy enough to kluge around in source code (implement an
English resource bundle as a class etc), but I didn't have time
to start a "good" fix. The classfile based solution includes the
properties fils in the "jphoto.jar"; no problems.
So how do people solve resource bundle problems with GCJ? Is there
some version of "gnu.getopt" that works better with GCJ? I don't
really want to be installing /usr/*/lib/* textfiles along with every
simple command line tool built with Java.
This might be poking at a sensitive spot. After all, there's
a POSIX/C way to do locales, and there's a Sun/Java way, but
it's not clear to me when a GCJ-based program should try to
use the POSIX/C solution (using what API?) versus the Sun/Java
solution (which I kluged around).
Comments? Maybe "libgcj" should add some Java "getopt" API so that
nobody else has this particular problem ... :-)
- Dave