Red Hat Bugzilla – Bug 225504
Flaw in computation of interfaceHash by GCJ's RMIC implementation
Last modified: 2007-11-30 17:11:54 EST
Description of problem:
When rmic from gcj is used to compile a stub/skel, it sets the "interfaceHash"
field of the generated skel/stub to a pointer location. This means that each
time that a stub/skel is compiled, the interfaceHash value changes. However,
this behaviour has unexpected consequences.
The interfaceHash value is used in the generated skeleton's dispatch() method to
ensure that it matches the value provided by the stub. This is a problem because
if the stub was re-compiled (for whatever reason), the interfaceHash value will
not match even though there has been no code change. The proper way to compute
interfaceHash is to rely on the file url and the contents of the file, so that
they are unique for a given url/code combination, but same for all copilations.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile a set of stub/skel with rmic and check the value of interfaceHash
(either by keeping generated source, or by using jcf-dump on the class)
2. Repeat step 1
3. Compare value of interfaceHashes from 1 and 2
The values are different
The values should be the same
To fix this, Mark Wielaard suggested the use of
ObjectStreamClass.lookup(clazz).getSerialVersionUID() to compute the
interfaceHash instead of using RMIHashes.getInterfaceHash() as is currently the
I'm not an RMI whiz ... is there a simple test case for this?
Does it still happen with the rewritten rmic?
Deepak, what package were you building when you hit this problem?
It was lucene. The interfaceHash values for Stubs/Skels in BUILD/... varied with
This is fixed.