Re: gcj 2.96 and rh7 [I18N/getopt]

[Per Bothner <per at bothner dot com>]

David Brownell <david-b@pacbell.net> writes:

> 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.

My take on this problem: The default jdk model is that an application
is shipped as a jar file.  The corresponding (default) gcj model is
that an application is shipped as a shared library (.so or dll).  (I'm
ignoring embedded systems where you would want to use static linking.)
So if a jar file contains a data file, then the shared library
should contain the same data file.

Consider properties files, which at runtime becomes PropertyResourceBundle
instances.  What gcj needs is a tool that compiles a properties file to
static text.  For example (from the Java 2 API docs):

        s1=3        
        s2=MeinDisk
        s3=3 Mar 96

becomes the equivalent of:

const char const * MyResources[][2] =
{ {"s1", "3"}, {"s2", "MeinDisk"}, {s3", "s3=3 Mar 96"}, {NULL, NULL} };

(Or whatever magic is needed to ensure that the MyResources gets placed
in a shared non-relocatable segment of memory.  Some alternative
representation may be better suited to avoid pointers that might have
to be relocated by the linker.)

It also needs to do the equivalent of:

static { registerPropertyBundle("MyResources", MyResources); }

so ResourceBundle.getBundle can find the properties and create the
PropertyResourceBundle instance from it.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/