commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [betwixt] Time and memory performance
Date Mon, 08 Aug 2005 22:39:49 GMT
On Mon, 2005-08-08 at 13:43 -0700, Kirill Grouchnikov wrote:
> Robert, 
> 
> > > #   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.
> > 
> > this is inaccurate: betwixt ships only one jar
> > commons-betwixt.
> 
> Take a look at
> http://jakarta.apache.org/commons/betwixt/dependencies and
> note the following line: " The following is a list of
> dependencies for this project. These dependencies are
> required to compile and run the application". It may be not
> your fault, but once i want to use betwixt, i'm stuck with
> all these jars.

you're missing my point: resolver.jar and which.jar are not on that
list. your summary is inaccurate. if you're going to take on the role of
critique then it is important for your credibility that you make
accurate comments in your summary.

if your basic complaint is that the size of the dependency tree is a
negative: great! just say that. 

you could make great improvement to the site by separating out the
advocacy and linking to it. you dislike the xml-commons stuff and think
stuff should be better named: fine. put it in a link and say some simple
and true like 'has a big dependency tree'.
 
> > > #   the marshaler and the unmarshaler require
> > specifying
> > > root xml tag name
> > 
> > this is inaccurate. betwixt does not require specific
> > root tags.
> 
> Taken from
> http://jakarta.apache.org/commons/betwixt/guide/examples.html
> :
> 
> // Write example bean as base element 'person'
> beanWriter.write("person", new PersonBean("John Smith",
> 21));
> 
> // Register beans so that betwixt knows what the xml is to
> be converted to
> // Since the element mapped to a PersonBean isn't called
> the same, 
> // need to register the path as well
> beanReader.registerBeanClass("person", PersonBean.class);

this describes how the example works. 

do you intend to replace your inaccurate line with something more
accurate like: poor example code (or something).

> > > 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?
> > 
> > it isn't different: dynamic binders make a guess and may
> > have to be
> > corrected through configuration
> > 
> > > #   can not correctly handle private static inner
> > classes
> > 
> > this is accurate but misleading. the java language
> > prevents
> > construction. don't you feel a little silly listing that
> > as a negative
> > point?

<snip>

> If you remove setAccessible, you get access exception, but
> with them (silly me), it works like magic.

thanks for the information. i did ask you previously on the list but
you've decided to play a little game, i see! how amusing :)

> > > 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 disagree (and i'm in good company). start-from-java
> > binders typically
> > adopt a do-what-you-can approach. this is why
> > start-from-java binders do
> > not guarantee to be able to round trip. 
> 
> Except that in this case you just could go all the way
> (silly me for noticing this).

no, silly me for thinking that you might actually be engaged in honest
intelligent evaluation rather than submarine advocacy.

> > IMO it would be much more illuminating if you listed the
> > natural
> > weaknesses of start-from-java binders (as you see them)
> > separately and
> > then just classify those which adopt this approach. 
> 
> How about a link from the main page at
> https://bindmark.dev.java.net/ (to Ronald Bourret site)?

your site does not try to apply any classify to them, though. Ronald
seems to take a little bit of an unusual way to do it but any
classification would be better than none.

> > > #   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.
> > 
> > inaccurate: *all* streams and readers should be closed.
> 
> Back to
> http://jakarta.apache.org/commons/betwixt/guide/examples.html
> and write example. Can you spot a close() for me?

thanks for the spot. i'll add one.
 
> > > #   default log level for BeanReader is INFO 
> > 
> > this is inaccurate. the default log level depends on your
> > environment.
> 
> And my environment is pretty standard (it has commons
> logging and JDK 5.0). 

then why not actually clarify the statement so it's true?
 
> > > 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).
> > 
> > it's clear from comments about other libraries that you
> > view the use of
> > JCL as a major negative point. fine. IMO it would be much
> > clearer just
> > to say 'uses commons-logging' as a negative for each that
> > does rather
> > than list some inaccurate specific.
> 
> JCK is not a major negative point as long as it *doesn't*
> produce results when everything is OK. If something's up -
> let me see it, if not - why should i care if some function
> had empty options popped from the stack? And that C24 use
> of commons logging caused OutOfMemoryError since the
> logging infrastructure never released the resources (after
> about 8000 marshalings).

that's my point: you don't like JCL so why not say that?

> > i'll be interested to see whether you decide to correct
> > the inaccuracies
> > in your summary listed above. 
> 
> Am i missing something to correct (silly me)?

yes (silly you)

the words you've chosen are inaccurate for two and could be better
chosen for a number of others. for someone who has a gift for picking
out the documentation nits from other projects, it's a shame you don't
apply the same talent to your own...

but silly me as well: i tool the hard option and wasted my time engaging
with your very stupid little games. 

- robert 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message