commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [VOTE] (re-vote) XxxUtils constructors
Date Thu, 22 Aug 2002 14:46:00 GMT

Henri Yandell wrote:
> On Thu, 22 Aug 2002, Nicola Ken Barozzi wrote:
>>Henri Yandell wrote:
>>>It's an issue whenever you submit code to anywhere. The maintainers of the
>>>code once submitted do not have solely your interests at heart and are not
>>>able to predict exactly where you want to take the code in the future.
>>" do not have solely your interests at heart "
>>Sometimes it seems like "do not have your interests at all".
> Sure. Within the context of a disagreement it will seem that way.
>>>On the other side, the submitter is no longer having to maintain the code.
>>But has to fight battles to even small changes to the code that the
>>submitter needs.
> They're welcome to join up.
>>These are utility classes, not core stuff, the hell with perfection and
> Can I quote this? I want to put this in javadoc at the top of each
> class :)

Sure ;-)

>>>If projects that submit code, Jakarta or not, were using bad concepts in a
>>>piece of code that is submitted, then improvement by Commons would be a
>>>*big* success and not a big failure. The only issue here is that there is
>>>debate over whether it is an improvement.
>>Commons should never deal with "bad concepts", only "unfunctional code".
>>If it works, good, if it doesn't, no good.
>>Leave "politics" to real projects.
> I'll put this down to being pissed off. Not allowing Commons projects to
> attempt to create commonality between the components that are submitted
> is a mistake.

Commonality, I never said I'm against this.

">>If it works, good, if it doesn't, no good."


"If it works *for all*, good, if it doesn't, no good."

>>>Can you point everyone to the threads on this subject on the submitting
>>>projects in which they discussed not having a private constructor on those
>>>classes, or was it just so obvious that no one ever questioned it?
>>If I submit code that I use, I want to be able to switch to the new
>>common version.
>>But if it becomes something that I cannot use anymore, my donation was
> Useless to the submitter yes. I don't think anyone is looking for a system
> in which you cannot use the submitted code anymore. So far you've listened
> to a lot of people who believe fervently in a private() trying to figure
> out a solution that encompasses their belief in a thinner API for
> stability [my interpretation] and the need for instance manipulation.
>>It's about deafness over feature requests from the projects that
>>submitted the code.
>>Commons must listen to the users, not dictate behaviour.
> Listen to users +1. Is this whole thread not an exercise in listening to
> the user?

No, it's an exercise in showing the user that their project does bad 
things, and that it must change tactics if it wants to use the code it 

I would call this "respect".

> Not dictate behaviour. -1. The only way I can see this happening is
> by:
> a) Having a package per user's submission.
> b) Never adding anything new.
> c) Allowing only the user who submitted to edit the code.

It's about not making the code unusable from a project that uses it 
without having to change itself.

Dictating is about having other projects do what Commons says instead of 
the opposite *even* when there is no need for it, and this need comes 
from different projects having clashing needs.

IE: If I have two projects that have a "Utility" class with many common 
things and a methid with different return types, *that* is a problem 
that Commons can help resolve.

>>Have a nice day, you all.
>>I hope the Velocity guys stop discussing this and get their forked
>>version working.
>>Maybe one day they will still be able o switch to the commons version.
> I thought the Commons guys were discussing this. We should move the
> conversation over to Commons-User then. *relatively intended tongue in
> cheek*

You are defending a position as a mediator, not a strenuous "public" 
My remarks are always about the bad attitude to compromise that many 
Commons devs have, which I haven't yet found in you; we are going on 
well with the Avalon stuff :-)

>>In the meantime, I better start thinking of a commons/private2public
>>project that changes automatically private constructors to public when
>>loading classes if I want to be free with my code...
> Cool. Could you use it on java.lang.Math, java.util.Collections,
> java.util.Arrays, java.x.x.x. I'd like to use them from Velocity.
> The alternative would be that some project of reusable objects for
> java.lang and java.collections could create bean wrappers to solve this
> problem, if it were deemed necessary.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message