I don't want to allege the bug is important moreover there is a simpliest workaround anyway: check an element type against NULL value and interpret this NULL value as anyType. Really, I've been realy confused when I got a NPE over a work with element types.
XMLSCHEMA-30 is more dangerous from my point of view. It's look like a mine ( :)) ) over using collections of some types and implementations (f.e. hash-based) for storing of XmlSchemaType objects. I've been "undermined" over using Guava immutable collection. Its implementation assumes that, if an equals method returns TRUE, then hash codes of compared objects are equal. And it's true assumption in accordance with oracle JavaDoc. 08.01.2014, 02:12, "Daniel Kulp" <[email protected]>: > On Jan 7, 2014, at 5:04 PM, Alexandr Klimov <[email protected]> wrote: > >> Hello all! >> >> Could anyone tell me who is a lead of XMLSCHEMA-CORE project now? >> >> I've created a pair of bugs: XMLSCHEMA-29 and XMLSCHEMA-30 but they haven't >> been estimated by anybody so far. >> >> Am I right about creation these bugs? >> If I'm right can I propose pull requests to a github mirror of this project >> for these bugs fix? > > Pull request (or patches attached to the JIRA) are certainly welcome. > > However, looking a -29, it’s probably a bit more involved than you think. > We’d likely also need a flag to determine if the user actually specified > “xsd:anyType” or not and have the serializer updated to take that into > account. This would also affect any other users of XmlSchema that use the > assumption that null is equivalent to anyType , but is not user specified. > Not sure if that matters anywhere, I’d have to run a few tests to check. > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] -- //Best regards //Alexandr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
