commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: codec - thread safe
Date Sun, 07 Oct 2007 21:31:43 GMT
On 07/10/2007, Qingtian Wang <qingtian.wang@gmail.com> wrote:
> Ok, I got the point.
>
> So let's say I wanted to work on this. What's the most effective way to do it?

You could try running some of the code checking utilities on the library.

For example Findbugs and PMD.

I've done a quick check with FIndbugs, but that has not found any
synchronisation issues. This is because there are no synchronised
methods, so it cannot find any inconsistencies.

But it should be possible to configure PMD to find any instance or
static variables that are modified after construction.

Or indeed you could perhaps try making all such variables final, and
see whether it's possible to fix the compiler errors - but that might
be a lot of work.

> Search the entire code base line by line trying to ID all the thread
> unsafe points by myself? I guess that's very ineffective compared to
> have an issue open, and have the individual developers who write the
> code to address it - They know what needs to be tweaked without having
> to even spend any time since it's their own code. Or at least, the dev
> team as a whole can come up a list of points that need to be worked

Not necessarily - the code may have been developed over a long period,
and the original authors may not longer be around. Unless the code has
been worked on recently, it's possible that no-one has much detailed
knowledge of the code.

> on. I think that'd be much more effective. Any established channel
> where that can happen?

If you find some bugs, then report them via JIRA.
It helps if you can provide test cases; obviously patches as well is
even better.

> Thanks,
> -Q
>
>
>
> On 10/7/07, Torsten Curdt <tcurdt@apache.org> wrote:
> > >>> Can the dev team make that happen? - a humble request from a user.
> > >>
> > >> The think about open source is that there is no distinction between
> > >> developer and user.
> > >
> > > That's interesting. Why then almost all open source projects have
> > > "users doc vs. developer doc", "users mailing list vs. developers
> > > mailing list"....?
> >
> > Point taken. But this is more about the presentation of information.
> > Still the distinction is blurry as many developers and contributors
> > come initially from the user background. They felt the itch to
> > improve the code and ended up providing the fix/feature
> > themselves ...I guess we are trying to get you to do the same :) You
> > should see that more as an invitation to help.
> >
> > >> The developers develop because they want to use the
> > >> code. And when somebody wants to use a feature that doesn't exist,
> > >> then
> > >> they can develop it.
> > >>
> > >> In short, if you want this feature, you can do this yourself and
> > >> post a
> > >> patch to this list so it gets included in the next release. There
> > >> is no
> > >> paid "dev team" for any of the commons code.
> > >
> > > OK i see. My intention was just to bring up an issue/request. There is
> > > no saying the developers are obligated to work on it. And contributing
> > > code is certainly not the only way of involving with an open source
> > > project.
> >
> > That is of course true. But I guess what Simon was wanting to point
> > out is that "requesting a feature" rarely means it gets done unless a
> > developer needs that feature too. The personal TODO lists are usually
> > very long. So usually you are better of contributing a patch
> > yourself ...or pay someone to do it for you. That's how it works.
> >
> > > Nevertheless, if the dev team (unpaid as I understand it)
> > > wants the project to be more popular, it might help listening to what
> > > other users have to say other than themselves; otherwise just forget
> > > about it.
> >
> > Well, sure ...listening is great - but someone gotta do it.
> > There is no us vs you, no dev vs user ....there is just us.
> >
> > Does that make sense?
> >
> > cheers
> > --
> > Torsten
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

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


Mime
View raw message