This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binary metadata


>>>>> "Jakob" == Jakob Praher <jp@hapra.at> writes:

Jakob> I think I've heard that you are going to replace the generated
Jakob> class file (currently as a generated c++ class) by binary
Jakob> metadata placed into the object file. ( perhaps a .meta elf
Jakob> section ... )

Actually we already do this in a sense.  A Java class requires a fair
amount of associated metadata: string constants, method and field
tables, information about superclasses and superinterfaces, etc.  See
java/lang/Class.h for the (horrible) details.  The compiler currently
emits all this information, the recent discussions about this are
basically about changing the form in which the information is emitted.

Jakob> Do you have already plans/specifications for the meta data?

There aren't really specifications, it is just whatever we happen to
need and is ad hoc.  In fact it currently isn't even complete, there's
a PR on this.

Jakob> Will the meta data spec be tied to java type system or is it generic
Jakob> enough for any kind of meta data?

It is currently tied to libgcj.

Jakob> I am interested in that, since I am playing a little bit with a language
Jakob> called D too, where such a meta data spec could be handy. (they don't
Jakob> have a separation of header/implementation like c/c++ and thus it would
Jakob> be interesting to put the metadata into the object files, so that you
Jakob> can compile without the need of source/external type information)

Ah, for this we use standard Java .class files.  For gcjx I've
considered adding the ability to map in libgcj.so and use the compiled
classes directly.  Unfortunately this won't really work because there
is some metadata which is not carried through to the compiled
representation; at present this is just the @deprecated tag -- which
could be added easily enough, but eventually the 1.5 "SOURCE"
annotations will defeat this (unless we wanted to keep them around as
well, but that seems heavy for a compiler optimization).

For D, I think you could define the compiled metadata easily enough
and then modify the compiler to use it.  This sort of thing is easy,
easier than defining a class file format or something like that, since
you don't need readers -- just compiler code to write it out and plain
old data structures at runtime.  It is fragile though, if you change
formats.  But then presumably the runtime would be fragile in that way
as well.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]