You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/08/22 01:03:54 UTC
[VOTE] (3) XxxUtilsConstructors last chance
This discussion has gone on for days. This is my last attempt at a decision.
As such I am placing what is in _my_ judgement the only option likely to be
compromised on.
No compromise = no change = private
"Static utility classes should have public final constructors"
[ ] +1 I agree
[ ] +0 I can accept this
[ ] -0 I don't like it, but won't block it
[ ] -1 I disagree
If the vote passes, [collections], [lang], [io] and [pattern] are affected.
However it is up to the projects as to their approach to implementation.
This is a vote in principle.
Background (if you got bored by the threads)
- A static utility class has only static methods and fields
- Certain tools need instances of static utility classes
- These classes are not intended to be used as beans, hence private
constructors
- The compromise gives public constructors to satisfy the bean based tools
and final to keep the utilities from being abused by subclassing
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3) XxxUtilsConstructors last chance
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> "Static utility classes should have public final constructors"
> [XX] +1 I agree
> [ ] +0 I can accept this
> [ ] -0 I don't like it, but won't block it
> [ ] -1 I disagree
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3) XxxUtilsConstructors last chance
Posted by "Michael A. Smith" <ma...@apache.org>.
Stephen Colebourne wrote:
> "Static utility classes should have public final constructors"
"Static utility classes should be final and have a public constructor"
> [ ] +1 I agree
> [ ] +0 I can accept this
> [XX] -0 I don't like it, but won't block it
> [ ] -1 I disagree
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3) XxxUtilsConstructors last chance
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> This discussion has gone on for days. This is my last attempt at a decision.
> As such I am placing what is in _my_ judgement the only option likely to be
> compromised on.
>
> No compromise = no change = private
>
> "Static utility classes should have public final constructors"
> [ ] +1 I agree
> [ ] +0 I can accept this
> [ ] -0 I don't like it, but won't block it
> [ ] -1 I disagree
>
> If the vote passes, [collections], [lang], [io] and [pattern] are affected.
> However it is up to the projects as to their approach to implementation.
> This is a vote in principle.
>
>
> Background (if you got bored by the threads)
> - A static utility class has only static methods and fields
> - Certain tools need instances of static utility classes
> - These classes are not intended to be used as beans, hence private
> constructors
> - The compromise gives public constructors to satisfy the bean based tools
> and final to keep the utilities from being abused by subclassing
Now you want to change the JLS, Stephen? Constructors cannot be
final.
dlr@despot:dlr$ javac test.java
test.java:8: modifier final not allowed here
public final test() {}
^
1 error
dlr@despot:dlr$ jikes test.java
Found 1 semantic error compiling "test.java":
8. public final test() {}
<--->
*** Error: "final" is not a valid constructor modifier.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> > "Static utility classes should have public constructors with the class
> declared final"
> > [ ] +1 I agree
> > [ ] +0 I can accept this
> > [ ] -0 I don't like it, but won't block it
> > [XX] -1 I disagree
There is absolutely no reason for utility classes to be final. This
prevents inovation and blocks unpredicted use cases. Go search the
WebMacro mailing list archives if you'd like to see a first-hand
demonstration of the pain classes which are final because "the author
thought it was a good idea" can cause.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Juozas Baliuka" <ba...@centras.lt> writes:
> > "Juozas Baliuka" <ba...@centras.lt> writes:
> >
> > > constructor.setAccessible(true);
> >
> > Hack.
> It was not the best idea.
I appreciate you showing all the options anyhow, thanks Juozas.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Juozas Baliuka <ba...@centras.lt>.
> "Juozas Baliuka" <ba...@centras.lt> writes:
>
> > constructor.setAccessible(true);
>
> Hack.
It was not the best idea.
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Juozas Baliuka" <ba...@centras.lt> writes:
> constructor.setAccessible(true);
Hack.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Juozas Baliuka <ba...@centras.lt>.
<snip>
> protected StringUtils loadStringUtility(String className) throws
> Exception
> {
> // Get the Class object for the fully qualified class name.
> Class c = Class.forName(className);
> // Now get an instance of that class using its public no args ctor.
> return (StringUtils) c.newInstance();
> }
>
> The className parameter might come from a configuration file, or user
> specified option. The StringUtils instance returned by this example
> method might be used only via introspection, meaning that access to
> any methods defined by a sub-class would be allowed without casting.
You do not need "public exdendable" in this case :
protected Object loadAnyUtility(String className) throws
Exception /*, SecurityException */
{
// Get the Class object for the fully qualified class name.
Class c = Class.forName(className);
// Now get an instance of that class using its any no args ctor.
Constructor constructor =c.getDeclaredConstructor( new Class[]{});
constructor.setAccessible(true);
// do not need to cast for introspection
return constructor.newInstance( new Object[]{} );
}
>
> Making the class final or removing the no arguments constructor
> effectively removes the ability to use the class in this fashion. So
> far, the majority of arguments for taking this path revolve around "a
> book told me to" or "it breaks my idea of how static classes are
> used", while arguments against this path point out real world use
> cases (like this one) that, while not necessarily common, are
> completely valid.
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Steven Caswell" <st...@caswell.name> writes:
> I confess I'm a novice in the area of class loading. Can you elaborate a
> little more? What do you mean by "utility class extensions"?
By "utility class extensions", I'm talking about literally extending,
say, StringUtils, for instance. I might have code like this:
protected StringUtils loadStringUtility(String className) throws
Exception
{
// Get the Class object for the fully qualified class name.
Class c = Class.forName(className);
// Now get an instance of that class using its public no args ctor.
return (StringUtils) c.newInstance();
}
The className parameter might come from a configuration file, or user
specified option. The StringUtils instance returned by this example
method might be used only via introspection, meaning that access to
any methods defined by a sub-class would be allowed without casting.
Making the class final or removing the no arguments constructor
effectively removes the ability to use the class in this fashion. So
far, the majority of arguments for taking this path revolve around "a
book told me to" or "it breaks my idea of how static classes are
used", while arguments against this path point out real world use
cases (like this one) that, while not necessarily common, are
completely valid.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Steven Caswell <st...@caswell.name>.
I confess I'm a novice in the area of class loading. Can you elaborate a
little more? What do you mean by "utility class extensions"?
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> Sent: Wednesday, August 21, 2002 7:11 PM
> To: Jakarta Commons Developers List
> Cc: steven@caswell.name
> Subject: Re: [VOTE] (3b) XxxUtilsConstructors last chance
>
>
> "Steven Caswell" <st...@caswell.name> writes:
>
> > My vote is -0 instead of +0 because I haven't heard anyone
> present a
> > serious reason as to why a utility class, a non-bean, should be
> > subject to subclassing. I can somewhat see the need for
> construction
> > for tools that require a bean (which a utility class really isn't),
> > but I think other compromises, such as a wrapper class,
> would also be
> > reasonable. But again, no serious discussion on this topic was
> > engaged.
>
> Class loading is a very useful feature. Preventing
> sub-classing would effectively block the possibility of class
> loading of utility class extensions.
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Steven Caswell" <st...@caswell.name> writes:
> My vote is -0 instead of +0 because I haven't heard anyone present a
> serious reason as to why a utility class, a non-bean, should be subject
> to subclassing. I can somewhat see the need for construction for tools
> that require a bean (which a utility class really isn't), but I think
> other compromises, such as a wrapper class, would also be reasonable.
> But again, no serious discussion on this topic was engaged.
Class loading is a very useful feature. Preventing sub-classing would
effectively block the possibility of class loading of utility class
extensions.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 22 Aug 2002, Geir Magnusson Jr. wrote:
> On 8/21/02 7:38 PM, "Steven Caswell" <st...@caswell.name> wrote:
>
> > I can somewhat see the need for construction for tools
> > that require a bean (which a utility class really isn't), but I think
> > other compromises, such as a wrapper class, would also be reasonable.
>
> Do you want to maintain that wrapper class?
This is the main reason why the wrapper class it not possible. Each
Commons project with a Utils class would need to commit to maintaining
wrappers for bean-using projects.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Steve Downey <st...@netfolio.com>.
I think the inner class solution is better than the wrapper. Zero
maintenance. Although I think having an inner class that exists solely to
provide a public constructor that the outer doesn't provide is silly.
The inner class and wrapper have all of the disadvantages marshaled against
having a public constructor in StringUtils. Why not just have the public
constructor, rather than a work around that provides almost the same thing?
Deprecating the public constructor, with a note explaining that you probably
don't need to use it, is, I think, a good solution. Deprecating it will warn
naive users, while still allowing those who actually need it to use it. But
it isn't deprecated because it's planned to be removed, or because those who
need it should move to a different API. It's deprecated because it should
only be used in very particular, somewhat unusual, circumstances.
This would be analogous to Thread.stop(). It's not safe, for a whole lot of
reasons. Nonetheless, it can't be removed. Not because of backwards
compatibility, but because there sometimes isn't any other way of doing the
job. Sometimes you need to kill an unresponsive thread. It's better to use
thread.interrupt(), and let the task clean itself up gracefully, but what do
you do when the task ignores the request, shut down the whole VM?
> -----Original Message-----
> From: Steven Caswell [mailto:steven@caswell.name]
> Sent: Friday, August 23, 2002 9:19 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [VOTE] (3b) XxxUtilsConstructors last chance
>
>
> Sorry this response is late, but I have trouble sending e-mail at work.
> Yes, in a previous posting I said I would have no problem maintaining
> the wrapper.
>
>
> Steven Caswell
> steven@caswell.name
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."
>
>
> > -----Original Message-----
> > From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> > Sent: Thursday, August 22, 2002 8:02 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [VOTE] (3b) XxxUtilsConstructors last chance
> >
> >
> > On 8/21/02 7:38 PM, "Steven Caswell" <st...@caswell.name> wrote:
> >
> > > My vote is -0 instead of +0 because I haven't heard anyone
> > present a
> > > serious reason as to why a utility class, a non-bean, should be
> > > subject to subclassing.
> >
> > I can only assume you're joking. Maybe someone wants to
> > change the behavior?
> >
> >
> > > I can somewhat see the need for construction for tools
> > > that require a bean (which a utility class really isn't),
> > but I think
> > > other compromises, such as a wrapper class, would also be
> > reasonable.
> >
> > Do you want to maintain that wrapper class?
> >
> >
> > --
> > Geir Magnusson Jr.
> > Research & Development, Adeptra Inc.
> > geirm@adeptra.com
> > +1-203-247-1713
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Steven Caswell <st...@caswell.name>.
Sorry this response is late, but I have trouble sending e-mail at work.
Yes, in a previous posting I said I would have no problem maintaining
the wrapper.
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> Sent: Thursday, August 22, 2002 8:02 AM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] (3b) XxxUtilsConstructors last chance
>
>
> On 8/21/02 7:38 PM, "Steven Caswell" <st...@caswell.name> wrote:
>
> > My vote is -0 instead of +0 because I haven't heard anyone
> present a
> > serious reason as to why a utility class, a non-bean, should be
> > subject to subclassing.
>
> I can only assume you're joking. Maybe someone wants to
> change the behavior?
>
>
> > I can somewhat see the need for construction for tools
> > that require a bean (which a utility class really isn't),
> but I think
> > other compromises, such as a wrapper class, would also be
> reasonable.
>
> Do you want to maintain that wrapper class?
>
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/21/02 7:38 PM, "Steven Caswell" <st...@caswell.name> wrote:
> My vote is -0 instead of +0 because I haven't heard anyone present a
> serious reason as to why a utility class, a non-bean, should be subject
> to subclassing.
I can only assume you're joking. Maybe someone wants to change the
behavior?
> I can somewhat see the need for construction for tools
> that require a bean (which a utility class really isn't), but I think
> other compromises, such as a wrapper class, would also be reasonable.
Do you want to maintain that wrapper class?
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Steven Caswell <st...@caswell.name>.
My vote is -0 instead of +0 because I haven't heard anyone present a
serious reason as to why a utility class, a non-bean, should be subject
to subclassing. I can somewhat see the need for construction for tools
that require a bean (which a utility class really isn't), but I think
other compromises, such as a wrapper class, would also be reasonable.
But again, no serious discussion on this topic was engaged.
> Amended as requested by Daniel.
> > This discussion has gone on for days. This is my last attempt at a
> decision.
> > As such I am placing what is in _my_ judgement the only
> option likely
> > to
> be
> > compromised on.
> >
> > No compromise = no change = private
> >
> > "Static utility classes should have public constructors
> with the class
> declared final"
> > [ ] +1 I agree
> > [ ] +0 I can accept this
> > [XX] -0 I don't like it, but won't block it
> > [ ] -1 I disagree
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 22 Aug 2002, Geir Magnusson Jr. wrote:
> On 8/22/02 9:19 AM, "Henri Yandell" <ba...@generationjava.com> wrote:
>
> >
> >
> >If you focus on the single class in question
> > then you're missing the point. Currently Collections has Utils with a
> > private constructor, this means that the Collections project is off-limits
> > to instance-using projects. If this is such a big issue that many Jakarta
> > projects need instance Utils, then it's big enough that Commons needs to
> > have a common view on it.
>
> I don't think we need a common view...
If that's true, then the only issue at hand is how much control a project
that submits code has over its submissal, whether it matters if that code
was an original submission or a later one [StringUtils is a merger of at
least 3, more likely 4 or 5 versions], whether Jakarta projects
automatically supercede others, whether the Jakarta project existed
before the creation of the Commons project to get superceding, ie) all
Commons-wide issues which I'll leave for wiser heads to worry over.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/22/02 9:19 AM, "Henri Yandell" <ba...@generationjava.com> wrote:
>
>
>>>>
> On Thu, 22 Aug 2002, Geir Magnusson Jr. wrote:
>
>> On 8/21/02 7:30 PM, "Stephen Colebourne" <sc...@btopenworld.com>
>> wrote:
>>
>>>> Background (if you got bored by the threads)
>>>> - A static utility class has only static methods and fields
>>>> - Certain tools need instances of static utility classes
>>>> - These classes are not intended to be used as beans, hence private
>>>> constructors
>>
>> These classes were *ORIGINALLY* used as beans, hence public contructors.
>
> 'class', not 'classes' afaik.
Yes, you are correct. Sorry. (However, in my defense, this proposal was
mentioned as applying, in principle, to commons utils classes.... )
>If you focus on the single class in question
> then you're missing the point. Currently Collections has Utils with a
> private constructor, this means that the Collections project is off-limits
> to instance-using projects. If this is such a big issue that many Jakarta
> projects need instance Utils, then it's big enough that Commons needs to
> have a common view on it.
I don't think we need a common view...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Henri Yandell <ba...@generationjava.com>.
> >>
On Thu, 22 Aug 2002, Geir Magnusson Jr. wrote:
> On 8/21/02 7:30 PM, "Stephen Colebourne" <sc...@btopenworld.com>
> wrote:
>
> >> Background (if you got bored by the threads)
> >> - A static utility class has only static methods and fields
> >> - Certain tools need instances of static utility classes
> >> - These classes are not intended to be used as beans, hence private
> >> constructors
>
> These classes were *ORIGINALLY* used as beans, hence public contructors.
'class', not 'classes' afaik. If you focus on the single class in question
then you're missing the point. Currently Collections has Utils with a
private constructor, this means that the Collections project is off-limits
to instance-using projects. If this is such a big issue that many Jakarta
projects need instance Utils, then it's big enough that Commons needs to
have a common view on it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/21/02 7:30 PM, "Stephen Colebourne" <sc...@btopenworld.com>
wrote:
> Amended as requested by Daniel.
>> This discussion has gone on for days. This is my last attempt at a
> decision.
>> As such I am placing what is in _my_ judgement the only option likely to
> be
>> compromised on.
>>
>> No compromise = no change = private
>>
>> "Static utility classes should have public constructors with the class
> declared final"
>> [ ] +1 I agree
>> [ ] +0 I can accept this
>> [ ] -0 I don't like it, but won't block it
>> [XXXX] -1 I disagree
What possible good would that do you?
>>
>> Background (if you got bored by the threads)
>> - A static utility class has only static methods and fields
>> - Certain tools need instances of static utility classes
>> - These classes are not intended to be used as beans, hence private
>> constructors
These classes were *ORIGINALLY* used as beans, hence public contructors.
>> - The compromise gives public constructors to satisfy the bean based tools
>> and final to keep the utilities from being abused by subclassing
What kind of abuse are you imagining here? I'm behind in my reading, but if
you are going to offer summaries like the above (thanks, by the way) the
details would help...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3b) XxxUtilsConstructors last chance
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Amended as requested by Daniel.
> This discussion has gone on for days. This is my last attempt at a
decision.
> As such I am placing what is in _my_ judgement the only option likely to
be
> compromised on.
>
> No compromise = no change = private
>
> "Static utility classes should have public constructors with the class
declared final"
> [ ] +1 I agree
> [ ] +0 I can accept this
> [ ] -0 I don't like it, but won't block it
> [ ] -1 I disagree
>
> If the vote passes, [collections], [lang], [io] and [pattern] are
affected.
> However it is up to the projects as to their approach to implementation.
> This is a vote in principle.
>
>
> Background (if you got bored by the threads)
> - A static utility class has only static methods and fields
> - Certain tools need instances of static utility classes
> - These classes are not intended to be used as beans, hence private
> constructors
> - The compromise gives public constructors to satisfy the bean based tools
> and final to keep the utilities from being abused by subclassing
>
> Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3) XxxUtilsConstructors last chance
Posted by "Michael A. Smith" <ma...@apache.org>.
Stephen Colebourne wrote:
> I am not aware of any -1 to the CVS commit. There have been -1's to votes,
> but not IIRC to the commit.
>
> A lot of the discussion has come because Velocity used a sandbox component
> and expected it to be stable.
>
> For the StringUtils case, it seems to be proven that it was used in
> production. As such I feel that I have no choice but to support a public
> constructor (for backward compatability reasons).
The way I look at things, any product using an unreleased sandbox
component has bound themselves to dealing with potential instability in
some form. That is not to say that unreleased components do not need
to keep backwards compatibility in mind, but
My recommendation (with regards to the constructor issue) is to:
1. Put the public constructor back on StringUtils.
2. Add a bean wrapper, and deprecate the public constructor stating that
the constructor will be removed for the 1.0 release of StringUtils.
3. Cut a Beta-2 or Beta-3 (or whatever it should be) of the Lang
component.
4. Remove the public constructor.
5. Release 1.0 Lang
Those that depend on the public constructor can migrate away from the
beta-1 or beta1.1 release to the 1.0 release at their leasure through
the use of the Beta-2.
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3) XxxUtilsConstructors last chance
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I am not aware of any -1 to the CVS commit. There have been -1's to votes,
but not IIRC to the commit.
A lot of the discussion has come because Velocity used a sandbox component
and expected it to be stable.
For the StringUtils case, it seems to be proven that it was used in
production. As such I feel that I have no choice but to support a public
constructor (for backward compatability reasons).
Stephen
----- Original Message -----
From: "Steve Downey" <st...@netfolio.com>
> > From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> > Sent: Thursday, August 22, 2002 9:11 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [VOTE] (3) XxxUtilsConstructors last chance
> >
> >
> <SNIP/>
> >
> >
> > And I don't think that you should change from public to private CTOR,
then
> > ask for a vote on something as strange as making shared Jakarta
> > Commons code
> > final, with the claim that if the vote doesn't pass, the original
> > undiscussed change to private CTOR stands...
> >
>
> Hmm. I'd forgotten that this was a change.
>
> from http://jakarta.apache.org/site/decisions.html
> <blockquote>
> An action requiring consensus approval must receive at least 3 binding +1
> votes and no binding vetos.
>
> <...>
>
> Product Changes
> Changes to the products of the Project, including code and documentation,
> will appear as action items in the status file. All product changes to the
> currently active repository are subject to lazy consensus.
> </blockquote>
>
>
> I believe there may have been a -1 from a commons committer on making the
> constructor private. By apache rules, that means the change must be
> reverted.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (3) XxxUtilsConstructors last chance
Posted by Steve Downey <st...@netfolio.com>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> Sent: Thursday, August 22, 2002 9:11 AM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] (3) XxxUtilsConstructors last chance
>
>
<SNIP/>
>
>
> And I don't think that you should change from public to private CTOR, then
> ask for a vote on something as strange as making shared Jakarta
> Commons code
> final, with the claim that if the vote doesn't pass, the original
> undiscussed change to private CTOR stands...
>
Hmm. I'd forgotten that this was a change.
from http://jakarta.apache.org/site/decisions.html
<blockquote>
An action requiring consensus approval must receive at least 3 binding +1
votes and no binding vetos.
<...>
Product Changes
Changes to the products of the Project, including code and documentation,
will appear as action items in the status file. All product changes to the
currently active repository are subject to lazy consensus.
</blockquote>
I believe there may have been a -1 from a commons committer on making the
constructor private. By apache rules, that means the change must be
reverted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (3) XxxUtilsConstructors last chance
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/21/02 7:03 PM, "Stephen Colebourne" <sc...@btopenworld.com>
wrote:
> This discussion has gone on for days. This is my last attempt at a decision.
> As such I am placing what is in _my_ judgement the only option likely to be
> compromised on.
>
> No compromise = no change = private
>
> "Static utility classes should have public final constructors"
> [ ] +1 I agree
> [ ] +0 I can accept this
> [ ] -0 I don't like it, but won't block it
> [ ] -1 I disagree
This is my second vote - the other might be confusing as there are so many
>>> it looks like I'm responding to someone elses vote :
[xxx] -1 I disagree
And I don't think that you should change from public to private CTOR, then
ask for a vote on something as strange as making shared Jakarta Commons code
final, with the claim that if the vote doesn't pass, the original
undiscussed change to private CTOR stands...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>