Re: Trying to understand "resource" files in GCJ

[Tom Tromey <tromey at redhat dot com>]

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