Robert, > all dynamic binders by their nature require tuning. > though your benchmarks are useful for generative binders, > they not all > that informative for the dynamic binders. all dynamic > binders are slow > (since they use reflection). what's crucial (for users) > is whether they > can be tuned. two sets of benchmarks (vanilla and tuned) > would be more > interesting and useful for the dynamic binders.
To see what exactly? That the default options of some dynamic binder are not good? Why are they default then? > > 2. If it takes a first-time user that looks at the > examples > > more than 4-5 hours to make the library even work, > chances > > are that this user will no longer be a user. > > i would expect most users either to follow the example as > documented or > know that private static inner classes are inaccessible. I understand the reflection limitations, but the marshaler goes half way (emits the attribute names, but not values, and doesn't provide errors at all), while the unmarshaller fails completely. It's either all go, or no go. > > i would also not expect most users to use > ByteArrayOutputStream unless > they knew enough about it to realise the need to flush > the stream. Thankfully, i realised that, having worked a lot with BAOS. However, if i need to close BeanWriter, it should be in the docs. > > 3. BeanReader is not reusable, producing empty results > > after the first unmarshaling. > > SAX is by it's nature single threaded. so there really > isn't too much to > gain by pooling readers. Is it mentioned anywhere in the docs? > > > 4. It says in the documentation that > XMLBeanInfoRegistry is > > the default choice, so how do i share them and why it's > not > > on the first page of the documentation? > > the slowest part of the process is introspection. though > bean readers > are no reusable, registries are reusable and can be > shared. Three replies later, and i still don't see an example of doing this. > > The team is (once again) more than welcome to see the > > source code and to send me the corrections, which will > be > > incorporated, assessed and published. > > does this include correcting the mistakes on the > ease-of-use page? Currently, the following entries are on the ease-of-use page. I don't see any mistakes there yet. # requires writing your own classes This can be viewed as either a negative or as a positive. You can say that i can take all my classes and just feed them to Betwixt with no changes. Obviously, this is not so - the conventions for get/set pairs (for both simple and list attributes) are pretty rigid. On the other hand, if i start working with external system that provides its interface description as schemas (which is a very standard way of doing this, and believe me when i say it, because this is where i work), i'd like to just generate those intermediate classes from a schema without the need to create hundreds of classes manually. # xml-commons jar files (resolver.jar and which.jar) have common names which can easily lead to jar name collision The jar naming *is* a big concern once you start to use open source libraries *and* your own. The names should be clear and unequivocal. # the marshaler needs to explicitly add xml header Call this petty, but why should i add this by myself? # the marshaler and the unmarshaler require specifying root xml tag name Once again, may sound petty, but why should i treat root as something different? If the an object of the same class appears elsewhere in the hierarchy, you are not requiring me to provide you the name, so what's different? # example docs use deprecated functions (setAttributesForPrimitives, setWriteIDs, setMatchIDs) The project examples should be *the first* to get rid of deprecated functions. If you don't do it, what it says about the status of deprecation? # can not correctly handle private static inner classes I understand the reflection limitations, but the marshaler goes half way (emits the attribute names, but not values, and doesn't provide errors at all), while the unmarshaller fails completely. It's either all go, or no go. # if ByteArrayOutputStream is used for marshaling, the BeanWriter must be close()'d to see the xml, unlike StringWriter The documentation in its current state says nothing about using BAOS and need to explicitly close BeanWriter. I had to figure out this one by myself. # default log level for BeanReader is INFO and it produces messages on the examples (and real code) which can be turned off only via configuration Now this *is* a major issue. I don't want a 3rd party to pollute my logs, especially since everything went smoothly. In addition, commons logging is *way* too complicated. You can say here that it figures out everything on its own, but there is simply no option to turn it off in every possible system configuration except creating your own logger and putting it on BeanReader). > not only is the betwixt entry inaccurate but i've noticed > mistakes in > several others as well. IMO it's sloppy methodology not > to post your > comments to the project in question first so that you > have a chance to > correct your mistakes before they are made public. by > labelling a > document as subjective does not excuse inaccuracies. Once again, i don't see mistakes. You can have your subjective opinion, but this doesn't mean that my subjective opinion is wrong. If you point out the inaccuracies and i agree, they will be corrected. > > The personal biases are outlined for all to see in the > > project FAQ, and everyone can draw his / her own > > conclusions on the weapon of choice. > > IMO your project would be far more effective if it didn't > suffer so much > from being obviously just one man's opinions. setting > yourself up as a > expert without taking great care to ensure that you > understand the > subject and that your criticisms are accurate is to > invite attacks on > your personal integrity. No comment really. > the project would also be more useful if you tried to > educate users > about how to choose the most suitable binder for their > problem. I think i provide enough information for the users to make their choice. > you show a consistent bias against start-from-java > binders in favour of > start-from-schema binders. for example, you consistently > list 'Requires > writing your own classes' as a negative point but this is > the whole > point of start-from-java binders! if you don't like > start-from-java > binders, it would be more honest to write this at the top > of the page. See the second last entry in FAQ on "What are the factors that you use for "ease-of-use" scoring?" question. As a provider of open-source *alternative* solution, you should strive to provide a library that doesn't lock me in and doesn't require tons of configuration files. > this bias extends to the benchmarks as well. i would be > interested to > see additional benchmarks organised to hit the > start-from-java hot spot > rather than the start-from-schema one. Sorry, lost me on this one. How is this biased, if the first two places are JiBX and Javolution which are not schema-based? Are you suggesting to manipulate results or input sets to move more start-from-java libraries to the top? > i also find your treatment of JAXB binders confusing. not > only do you > confuse the specification with the reference > implementation but > shouldn't all implementations be equally easy to use? There are only two implementations of JAXB (Sun's RI and JaxMe), and only one implementation of JAXB 2.0 (Sun's RI). No confusion here. All other schema-based libraries are most definitely not JAXB binders. The question is completely irrelevant. > your ratings of the generative binders also do not seem > to accord with > experience. JAXB is known to be a difficult specification > to work with. > i think that most people would be very surprise to see > the JAXB > implementations rated so highly in terms of ease of use. > i note that you > acknowledge this in the FAQ. That's what the word "subjective" means last time i checked it in the dictionary. The FAQ clearly states why JAXB 2.0 is rated 10 out of 10. My association with JAXB 2.0 is also clearly stated and shown to be irrelevant for the purpose of using the library. Kirill __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
