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: why do we generate class$ for native code?


>>>>> "Per" == Per Bothner <per@bothner.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.

Tom


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