axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: request feedback on bug fix plan
Date Thu, 23 Oct 2003 22:37:06 GMT
More bad news: there's just not a lot that can be done to this code to make
it smaller (i.e. small enough to compile).  I'm now thinking about having
JavaStubWriter emit the binding information in a file that gets loaded as a
resource.  That will at least preserve the interface for the generated code
(i.e. not require the use of WSDD), but it does introduce some packaging


-----Original Message-----
From: Friedman, Eric D. 
Sent: Thursday, October 23, 2003 3:04 PM
To: ''
Subject: RE: request feedback on bug fix plan


Sure, each type produces two constant strings, at least one of which must be
unique.  I agree that this is much more remote than the method/class size
problem, however.


Unfortunately my attempt at generating static inner classes did not work:
the compiler's stack still blows up (javac) and jikes reports that the 64k
limit has been exceeded.  


On the assumption that the problem is the generated code itself, I will see
if I can re-roll the loop of binding data and supply an array of values to
feed the loop.  The unrolled version is clearly the source of the first
bottleneck and this may address that problem.


If anyone has another idea I'd be glad to hear it.




-----Original Message-----
From: Tom Jordahl [] 
Sent: Thursday, October 23, 2003 2:50 PM
To: ''
Subject: RE: request feedback on bug fix plan



I guess I would prefer the private method approach.  Do we really hit the
string constant limit in large cases?


Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: []

Sent: Thursday, October 23, 2003 4:21 PM
Subject: request feedback on bug fix plan


I'm looking into fixes for
<>  and would
appreciate some feedback on my proposed fix.


The issue is that WSDL2Java's stubs can exceed the limits of the JLS such
that a JVM will throw an Error when the class is loaded.  Briefly, there are
a number of limits that can come up:  64k limit on method size; 64k limit on
constant string pool size per class, etc.


The stubs are a problem for large WSDL/schema sets because all of the
binding metadata for a PortType is emitted in a single method.


The ideal solution would be to not write binding data in the stubs at all:
the data can be read from WSDD without limits other than available heap.
But, that would entail major changes and so I'm ruling it out.


The next thing I thought of is to chunk up the binding metadata so that it
stays within the JLS limits.  Two possibilities:


Generate private methods, each of which has a subset of the binding data;


Generate static inner classes, each of which has a subset of the binding


The latter approach will go further since the former approach solves the 64k
limit on method sizes but not the limit on constant string pool size.  I'm
therefore inclined to patch the stub writer to write out static inner
classes for every, say, 100 types for which binding metadata is needed.


This is sufficiently grotesque that I thought I'd better see if anyone had
strenuous objections up front.





View raw message