[
https://issues.apache.org/jira/browse/JAXME-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523718
]
Robert Eric Reeves commented on JAXME-94:
-----------------------------------------
The following is an email from Jose that describes his approach to his patch:
I sent you an attachment with the patch that solves the problem of the huge
size in the classes that parse sequences (in addition, it solves an existing
problem with multiplicities other than 0..required for minOccurs and
1..unbounded for maxOccurs, some unit test created)
As I told you yesterday, the class to parse a sequence with 250 optional
elements was around 290.000 lines long before applying the optimization, and
now the class to parse the same sequence is around 4.000 lines.
I have elaborated a bit more the concept of a state machine that was underlying
in the existing code to validate the structure of elements in the sequence,
using regular expressions.
My first approach was moving all the logic that decides if the received element
is valid in the current state to a table of transitions. It worked but I still
didn't like the solution, because, while the code that takes the decision was
reduced dramatically, the code to initialize the table with all the states and
transitions became huge, and the class was still 40.000 lines long (better than
290.000 but still not good). Besides, the table of transitions was very memory
consumpting.
Then I remembered that a a deterministic finite state machine can always be
represented by a regular expression and then all the table stuff could be
substituted by generating an adequate RE. For example:
<xsd:sequence>
<xsd:element name="nolessthan3" minOccurs="3" maxOccurs= "unbounded"
type="xsd:string"/>
<xsd:element name="nomorethan3" minOccurs="0" maxOccurs= "3"
type="xsd:string"/> <xsd:element name="between3and5" minOccurs="3" maxOccurs=
"5" type="xsd:string"/> </xsd:sequence>
If we assign symbols to the elements ("nolessthan3" --> 0, "nomorethan3" -->
1, "between3and5" --> 2), then a XML that follows this XSD could be validated
using the regular expression 0{3,}1{0,3}2{3,5}
This works smoothly and all the tests that comes with JaxMe keep passing. I
have also tried the modification with the XSDs and XMLs of our project without
apparent problems. I could even have reduced more the code, but there is a lot
of information about the elements that is available only at "generating classes
time" but it is not at "parsing time" and changing it would be very difficult
only to save a few lines.
The patch is intended to be applied over a fresh 0.5.2 or 0.6-SNAPSHOT(trunk)
version (without my previous patch).
> startElement method larger than 64KB when using a large amount of
> complexType's
> -------------------------------------------------------------------------------
>
> Key: JAXME-94
> URL: https://issues.apache.org/jira/browse/JAXME-94
> Project: JaxMe
> Issue Type: Improvement
> Components: JaxMe Core
> Affects Versions: 0.5, 0.6
> Environment: All
> Reporter: Robert Eric Reeves
> Priority: Critical
> Fix For: 0.5, 0.6
>
> Attachments: test.xsd, veryLongSequences-patch-0.5.2.diff,
> veryLongSequences-patch-0.6-SNAPSHOT.diff
>
>
> Using an XSD that has a complexType with ~50 child complexTypes in a
> sequence, the generate Java code has a method startElement that is too large
> for javac.
> Jose Luis Huertas Fernández has created a patch to fix this error. I will be
> attaching it to this issue. There are two patches. One for 5.2 and the other
> for 6.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
