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 Mon, 08 Oct 2007 11:29:42 GMT
On 08/10/2007, Qingtian Wang <qingtian.wang@gmail.com> wrote:
> On 10/7/07, sebb <sebbaz@gmail.com> wrote:
> > 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.
>
> Wow, if that is really the case with commons codec that no one has
> detailed knowledge of the code, it would suggest to me that no one
> should use it as a off the shell usable product since no one really
> knows what it would do.

I did not write specifically about Commons Codec - I was just pointing
out that any software that has been developed over a long period is
likely to have areas that are unfamiliar to some  or all. Indeed, even
if you wrote the software yourself, would you still be familiar with
it several years later? Or even several months?

This is not just a software problem. Any large or long-lived project
will have areas that are not immediately familiar to anyone.

> I mean, it's one thing to say "Here's what our intention what this
> product behaves. But use it at your own risk since there is no
> guarantee of any kind.", but it's entirely different thing to say
> "Here's a bunch of code, but we don't know how it behaves, you're
> welcome to find out for yourself and play around with it."

That's not the case here.
Does Commons Codec offer any thread-safe guarantees?
If not, then yes, one cannot say how it may behave in multi-threaded mode.
But that does not mean the behaviour is unpredictable in single-threaded usage.

For example, Java's SimpleDateFormat is not thread-safe.
Can one predict exactly what happens in multi-threaded mode?
Probably not.


> To me those two things put a product at two rather different level of
> maturity. If codec falls in the latter, a normal user that needs a
> codec library for their work might as well look some where else or
> roll their own stuff to hand their codec needs, since it'd take same
> or even more time to dig in commons-codec and try to find out what
> exactly it's trying to do.

Not so with Commons Codec, since it is quite a small library.

> -Q
>
>
>
>
> >
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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