Issue 1591:  Default Constructor for Stubs                                                                                                                                                                          (java2idl-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of 
 concern to the IDL-to-Java RTF because it affects the IDL-to-Java
 mapping.
 
 When adding support for idlToJava generated Stubs to 
 "InputStream.read_Object(java.lang.Class clz)" we ran into a small 
 problem while writing the code.  Initially we used "clz.newInstance()"
 to create an instance of the Stub object.  The problem here is the 
 Stub does not have a default constructor, so newInstance throws an
 exception.  We added a default constructor to the stub and everything
 worked fine.  The question is: should we add a default constructor to
 the stubs generated by idlToJava or should we use reflection(cost??) to
 invoke the one constructor that is already a member of the stub class?
 
 I propose that we state in the spec that a default constructor is
 required on all generated Stubs.
 
 

Resolution: 
Revised Text: 
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <nash@sp3at21.hursley.ibm.com>
Date: Mon, 29 Jun 1998 14:33:58 +0100
From: Simon Nash <nash@hursley.ibm.com>
Reply-To: nash@hursley.ibm.com
Organization: IBM
To: java2idl-rtf@omg.org
Cc: java-rtf@omg.org, issues@omg.org
Subject: Default Constructor for Stubs

This item arises from the Java-to-IDL Mapping RFP, but is also of 
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.

When adding support for idlToJava generated Stubs to 
"InputStream.read_Object(java.lang.Class clz)" we ran into a small 
problem while writing the code.  Initially we used "clz.newInstance()"
to create an instance of the Stub object.  The problem here is the 
Stub does not have a default constructor, so newInstance throws an
exception.  We added a default constructor to the stub and everything
worked fine.  The question is: should we add a default constructor to
the stubs generated by idlToJava or should we use reflection(cost??)
to
invoke the one constructor that is already a member of the stub class?

I propose that we state in the spec that a default constructor is
required on all generated Stubs.

   Simon	
-- 
Simon C Nash, IBM Java Technology Centre, Hursley, UK
MailPoint 146, x245156  Tel. 01962 815156 or +44-1962-815156
Internet: nash@hursley.ibm.com  Notes mail: Simon Nash@ibmgb