This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: binary metadata
- From: Tom Tromey <tromey at redhat dot com>
- To: Bryce McKinlay <mckinlay at redhat dot com>
- Cc: "java at gcc dot gnu dot org" <java at gcc dot gnu dot org>
- Date: 27 Sep 2004 13:09:21 -0600
- Subject: Re: binary metadata
- References: <1095349123.4660.24.camel@jaques2> <41586225.1090502@redhat.com>
- Reply-to: tromey at redhat dot com
Bryce> Having the compiler use it is an interesting idea, however -
Bryce> the metadata is complete enough, so really its just down to some
Bryce> design/technical challenges in having the compiler read from the
Bryce> object files.
The compiled code doesn't have the deprecated tag, and perhaps won't
have @Retention(CLASS) annotations either. (The new @Deprecated
annotation seems to have @Retention(RUNTIME), which looks weird, but
would let this work.) That's a barrier to directly using the .so in
the compiler.
FWIW, I looked into this a bit for gcjx. It looks easy in that
context, if the annotation problems are solved. We could of course
just declare that @Retention(CLASS) annotations are to be kept in the
.so, perhaps optionally so the space-challenged can avoid bloat.
It is tempting to think that we could avoid making .class files at
all, but I suspect we'd still want them around for things like
Eclipse.
Tom