This is the mail archive of the
mailing list for the Java project.
Re: why do we generate class$ for native code?
- From: Tom Tromey <tromey at redhat dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: java at gcc dot gnu dot org
- Date: 11 Mar 2004 11:05:11 -0700
- Subject: Re: why do we generate class$ for native code?
- References: <405015D7.firstname.lastname@example.org>
- Reply-to: tromey at redhat dot com
>>>>> "Per" == Per Bothner <email@example.com> writes:
Per> The function build_incomplete_class_ref in parse.y
Per> has this comment:
Per> /* Generate the synthetic static method `class$'. (Previously we
Per> deferred this, causing different method tables to be emitted
Per> for native code and bytecode.) */
Per> I'd like to understand why this is important.
I believe it was an old attempt to get serialization compatibility.
You could probably verify that by looking to see when the code was
written and by whom. If Alex wrote it a long time ago, or around when
other serialization work was done, then that's probably the case.
Since then we've come to realize that compatibility at this level
isn't possible. Instead we put serialVersionUID into code explicitly.
Sun recommends this for user code as well; I think they realized they
couldn't always retain compatibility with their own specification.