axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Nagy <>
Subject Re: [Axis2] Issues with the current code base
Date Thu, 01 Feb 2007 17:57:32 GMT
Hi Sanjiva,

On Thu, 2007-02-01 at 21:33 +0530, Sanjiva Weerawarana wrote:
> On Thu, 2007-02-01 at 06:10 -0800, Bill Nagy wrote:
> > Hi Rajith,
> > 
> > Usage of the serialization is/will be configurable through Sandesha --
> > Matt said that he would be adding code to do that (if it isn't there
> > already.)  If the serialization doesn't get invoked, then all that will
> > occur will be a few no-op method invocations.
> > 
> > I don't agree with point 5 being a "definite no no."  I believe that it
> > is a matter of personal preference and if the author of the code
> > believes that it makes it easier to read and doesn't create issues then
> > so be it.  Any reasonable editor today will have no difficulty locating
> > the definition if you need to look at it.
> I disagree- as an open source effort we should write in ways that
> everyone can easily read and understand. These conventions are not
> tailorable for personal preference!
> It seems to me that most people declare variables at the top and methods
> below. Is that such a hard convention to accept?

I don't honestly think that anyone who we want to be writing code for
the project would have trouble understanding code simply because braces
weren't on the lines where they typically put them or that methods
aren't named in the same way that they usually name them.  With respect
to this particular issue, I don't think that the vast majority of people
go look for declarations by scrolling to the top of the file -- IDEs
have made that unnecessary.  I think that we simply disagree on where to
draw the line for "reasonable" deviations from the "rules."

> > As I said, I certainly welcome any concerned party to show me (in
> > hard/accurate numbers) where the code does not perform and it will be
> > addressed.
> IMO its everyone's responsibility to make sure Axis2 performs well.
> Telling someone else to run perf tests, do profiling and then point out
> the place to fix is silly .. that person might as well fix it. Can't Ann
> write some tests and check the perf and confirm all is koshure??

I completely agree.  The issues that have been raised so far, however,
have all been of the form "The code gets invoked on every invocation --
I don't like that."  I was addressing those issues.  I committed the
code, therefore I am ultimately responsible for it.  Before I did so, I
read through it and did my best to make sure that it was not adversely
effecting performance, and those are the points that I keep raising.  Is
this a lot of code that was changed/added?  Certainly.  Do I believe
that it is isolated when not in use?  Yes.  I don't have to run
performance tests simply because somebody says so when I'm comfortable
with the logic of a particular change.  Likewise, I don't believe that
anybody runs performance tests for the vast majority of the changes that
they make to the code, and they probably have thought about isolation a
lot less than was done so for this particular change.

Now if you want to raise the issue of performance when this particular
branch of code is in use, that's a fair thing to look at.  Right from
the start, however, I will tell you that what existed before and what
exists in the new code are not functionally equivalent.  I'm not saying
that the new code is slower or that if it is that it shouldn't be made
to be faster -- I'm simply saying that it won't be comparing apples to

> I'd prefer to be having this conversation with Ann .. not that I don't
> like to chat with you Bill ;-)).

That's fine; she's free to speak up (as she did.)  I was just aware that
she was busy, and since I'm aware of the details I wanted to address
your concerns as quickly as possible.  Also, as I stated, I committed
the code into the tree, and so am ultimately responsible for that


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message