+1 to leaving the constructor in with a comment.
-- Tom Jordahl Macromedia -----Original Message----- From: Russell Butek [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 8:38 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: xml-axis/java/test/wsdl/interop3/groupE/client InteropTestDocLitServiceTestCase.java InteropTestRpcEncServiceTestCase.java This issue only arises when you write code to a given binding, and then pass the WSDL for that binding AND YOUR CODE somewhere else. If that somewhere-else were going to write their own code based on their own bindings, there'd be no problem (I think). I suspect we see this problem when we cross JVM lines. Somewhere, the parameters are put into a Hashtable or HashMap or something of that nature. I wonder whether IBM's JVM and Sun's use different algorithms for their Hashtable implementations. Doing things in the same JVM always produces the same order, so the constructor is usable and useful if you stay in one JVM. I guess you're asking whether we should depend on that? OK, what do folks think? The constructor that takes all the elements is useful, but could go astray. Do we leave it there for its usefulness or do we remove it to avoid problems like Glyn's? My vote? +1 to leave the constructor as is. (I COULD add a warning comment to that constructor when the WSDL has an <all> collection.) Russell Butek [EMAIL PROTECTED] Glyn Normington/UK/IBM@IBMGB on 02/22/2002 07:06:43 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: cvs commit: xml-axis/java/test/wsdl/interop3/groupE/client InteropTestDocLitServiceTestCase.java InteropTestRpcEncServiceTestCase.java Russell, Thanks for fixing those tests. What's the use of WSDL2Java generating those constructors if their signatures can't be relied upon not to change? Glyn
