id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
44	bootstrapping smart handles	Bernhard Haumacher (haui at haumacher dot de)		"A smart handle class always must be compiled together with the corresponding smart stub class, because it accesses the method identifiers defined in the stub class. Because the handle class of the remote base class is not generated, the corresponding stub can not be generated just in time. Therefore a pre-generated stub class exists in the source directory that is gained from a bootstrapping process. This stub class is compiled together with the handle of the remote base class.
=== Problem ===
After compiling the classes the JavaParty compiler generates stubs and skeletons for all RMI server classes. During this process the stub class for the remote base class is regenerated. This may cause severe problems, if in this second pass other method identifiers are generated, because the handle class does already inline these method identifiers from the pre-generated stub class. Calling a method of RemoteObject will then fail in an unpredictable way.
=== Solution ===
The JavaParty compiler could suppress the stub generation process, if a matching stub is already found in the class path. This is not a really brilliant work around and may cause other strange effects. It is better to suppress the automatic stub generation exactly for the remote base class.
=== Problem ===
Even when compiling regular remote classes, the stubs must be generated at the same time the handle is generated, but the corresponding skeleton can not be generated immediately (see: ticket:48). Therefore a skeleton build pass is needed after the remote compilation, to build the matching skeletons for the already generated stubs. This process should not rebuild the stubs for the same reason.
=== Solution ===
The stub generator is enabled to only generate skeletons instead of stubs and skeletons at the same time. This option is used in the second pass after code generation for remote server classes (the fix for ticket:48 is sufficient for this issue, too)
=== See also ===
ticket:48

'''fixed''' since 1.03n.
"	defect	closed	normal	1.03n	jpc		normal	fixed