You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by bu...@apache.org on 2003/01/10 11:25:18 UTC
DO NOT REPLY [Bug 14984] -
XSLTC compiltation error : Branch target offset too large for short
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14984>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14984
XSLTC compiltation error : Branch target offset too large for short
------- Additional Comments From jtl@schlund.de 2003-01-10 10:25 -------
I have the same problem as the reporter, and in our case it is very easy
identified as having one big, "/"-matching template that is way too big for XSLTC.
Unfortunately I have no possibility to split the templates, as these stylesheets
are the result of (possibly very) many transformations, so starting with the
source xml and stylesheets there is no way I could have any influence on where,
in the final, generated stylesheet I could split in two or more templates.
Most comments regarding this bug of XSLTC (or rather the bytecode generating
subsystem as far as I know) refuse to see this as a blocker. I just want to
point out that there a legitimate use cases where you can't split templates at all.
Wouldn't it be possible for the bytecode generating stuff to check if methods
are bigger than the allowed limit and artificially spread templates over more
then one method?