On 10/8/07, sebb <[EMAIL PROTECTED]> wrote: > On 08/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote: > > On 10/7/07, sebb <[EMAIL PROTECTED]> wrote: > > > On 07/10/2007, Qingtian Wang <[EMAIL PROTECTED]> 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?
No, admitted I wouldn't. But I do believe, if I am still physically around, it's easier for me to get back the code I wrote, and ask myself "what the heck was I thinking?" than someone tries to do the same. > > This is not just a software problem. Any large or long-lived project > will have areas that are not immediately familiar to anyone. Agreed. But at the same time, trying to fully utilize the available knowledge base to start with might be beneficial. That's all I am trying to say. > > > 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. That's exactly what I was trying to figure out: Is thread-safe an intention in general for the code base? And after I found out that the answer is "No", and worse, it seems some methods are thread-safe and others are not, and nobody knows what's what. That's where I made an issue out of it: Since no body even knows for sure which is and which not, can we at least try to be able to say for sure on the existing code base in terms of thread-safety. And I'd say before we can be sure of that, tell the users up front: No thread-safety is considered. To me, that's much better than saying nothing. > > For example, Java's SimpleDateFormat is not thread-safe. > Can one predict exactly what happens in multi-threaded mode? > Probably not. That is actually a very good example: In the Javadoc of the that class, Sun says it loud and clear: "This not thread-safe." My wish is simply that codec is able to give those kind of statements, and then make the main business methods such as encode/decode thread safe, rather than saying nothing and leave it for the users to find out. > > > > 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. Well big or small is rather subjective: For a slow developer like myself in a rush to find a codec library for my work, it's big enough. :) > > > -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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
