Re: deferred parsing fallback?

On Wednesday 16 April 2003 02:00, David Li wrote:
> > I guess I had assumed that deferred parsing was just an added
> > capability and that the standard XMLCStdFactory would still be able to
> > load the classes, albeit without deferred parsing.  This would make it
> > so you could compile with the possibility of deferred parsing, but
> > then when you didn't need deferred parsing turned on, the classes
> > would be loaded like normal which, I assume, is a bit less overhead.

One of the problems with the "standard" classes is that the generated classes 
are huge - as they have to be, because they have to include all the content 
as string constants. This can get you into big trouble under certain 
circumstances, because these huge classes take up an equally huge amount of 
space in the VM and - at least in all VMs of the 1.3 series on Solaris - are 
likely to trigger a nasty VM bug in the handling of the so called "permanent 
space" (that's the memory area where the VM stores classes and precompiled 
code). In fact, this very problem was what made me build the deferred parsing 
feature - the benefits regarding on-the-fly relaoding were just a byproduct 
:-)  

Merging the "standard" (I'd rather call it "standalone", because I'd like to 
make deferred parsing the standard anyway in future XMLC versions) and the 
deferred parsing code - by merging them, you'd get all the content included 
in the generated classes again, with all the problems outlined above.

On the other hand, what can be done is extend the factory for deferred parsing 
so that it can load standalone classes. I've hacked up a patch that should do 
the trick, but I've no time to really test it. Could you please check out 
from CVS and see if it really works?

Best regards, 

Richard

-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, kunze@xxxxxxxxx

pgpkf9ay8LXgB.pgp
Description: signature