Trying to understand "resource" files in GCJ

Thu Nov 28 16:08:00 GMT 2002

>>>>> "Ranjit" == Ranjit Mathew <rmathew@hotmail.com> writes:

Ranjit> gcj -c --resource foo.bar -o fooBar.o foo/bar.properties
Ranjit> 1. What *exactly* is the significance of the name passed
Ranjit> to the --resource flag? Is it the same string that you
Ranjit> give in code like "this.getClass( ).getResource( "foo.bar")"?
Yes, that's right.
Ranjit> That is, does it build up some kind of a registry for
Ranjit> the implicit ClassLoader so that it knows what to
Ranjit> retrieve for a given identifier?
Yeah. What happens is that there is a special `core:' URL handler.
`core:/' is implicitly added to the class path. A compiled resource
like this is found at `core:/foo.bar' -- where `foo.bar' is the
argument you passed to `--resource' when compiling.
Perhaps this should somehow be integrated with the CodeSource for a
shared library, the idea being that a shared library's CodeSource
would point to `core:/some-local-name', thus picking resources
compiled into the shared library by default. This is just off the
cuff, more thought would need to be put into it.
Ranjit> 2. If this object file (fooBar.o) becomes part of a static
Ranjit> library, why would the linker pull it in to construct
Ranjit> the final executable?
Offhand I'm not sure. It looks like perhaps these are implemented via
static constructors (see java/class.c:compile_resource_file) for
starters. Can a static constructor be left out of a static link? I
don't know.
Ranjit> Is there some "design notes" or some such thing about
Ranjit> this that I can read? For that matter, a lot of things
Ranjit> in GCJ/libgcj are quite interesting - apart from the
Ranjit> mailing list archives, is there any place one can find
Ranjit> "design notes" about them rather than wasting everyone
Ranjit> else's time by asking such questions?
There are some papers, mostly in SGML, on the web page. As I recall
(since as a rule I don't look at them), these are generally early
design papers written by Per. Many things after that are perhaps
undocumented.
Asking here is no problem. I don't consider it a waste of time. I do
agree that internals documentation would be useful though. The
problem is finding time and motivation to write it. Any suggestions
for how to make it easier?
Tom