You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/08/13 22:27:24 UTC
[VOTE] XxxUtils constructors
A problem recently came up in the Commons Lang. An application which used
Velocity had been using StringUtils via its public constructor as an
instance. This is a feature of Velocity. StringUtils was changed to have a
private constructor, which means Velocity cannot use it. To this end I
feel that Commons as a whole needs to have a common solution here. There
have been 2 or 3 long threads on the argument, but without a stunning
resolution. I wanted to put this to a vote and get it at a top-level
Commons awareness so we can have a good resolution.
The options I am aware of are:
Do we do public() as it's easy for Velocity/other-tools, and we assume our
consumers can figure out that instantiating a class with only static
methods is a bit thick.
Do we do private() and tell Velocity to get its act together and stop
using a loophole. The fact that Collections/Array have private() makes
this a fine stance to take I'd have thought, unless Velocity only cares
about String-based utilities.
Do we do protected() and have some kind of back-door system in which
people who need to use a Utils as an instance can extend it and use it
that way [or do we provide an extended instance somehow?] and most
consumers never know that the extension is not possible.
( ) public
( ) private
( ) protected
( ) This is up to each individual project
( ) Just worry about classes that Velocity might use
I myself am +1 on public.
[Any other options, let me know and I'll re-publish the vote]
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:
> ( ) public
> ( ) private
> (X) protected
> ( ) This is up to each individual project
> ( ) Just worry about classes that Velocity might use
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] XxxUtils constructors
Posted by co...@covalent.net.
@deprecated public - if the class doesn't explicitely requires a singelton
pattern.
Costin
On Tue, 13 Aug 2002, Henri Yandell wrote:
>
> A problem recently came up in the Commons Lang. An application which used
> Velocity had been using StringUtils via its public constructor as an
> instance. This is a feature of Velocity. StringUtils was changed to have a
> private constructor, which means Velocity cannot use it. To this end I
> feel that Commons as a whole needs to have a common solution here. There
> have been 2 or 3 long threads on the argument, but without a stunning
> resolution. I wanted to put this to a vote and get it at a top-level
> Commons awareness so we can have a good resolution.
>
> The options I am aware of are:
>
> Do we do public() as it's easy for Velocity/other-tools, and we assume our
> consumers can figure out that instantiating a class with only static
> methods is a bit thick.
>
> Do we do private() and tell Velocity to get its act together and stop
> using a loophole. The fact that Collections/Array have private() makes
> this a fine stance to take I'd have thought, unless Velocity only cares
> about String-based utilities.
>
> Do we do protected() and have some kind of back-door system in which
> people who need to use a Utils as an instance can extend it and use it
> that way [or do we provide an extended instance somehow?] and most
> consumers never know that the extension is not possible.
>
> ( ) public
> ( ) private
> ( ) protected
> ( ) This is up to each individual project
> ( ) Just worry about classes that Velocity might use
>
> I myself am +1 on public.
>
> [Any other options, let me know and I'll re-publish the vote]
>
>
>
> Hen
>
>
> --
> 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] XxxUtils constructors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
( -1 ) public
( +1 ) private
( +0 ) protected WITH Exception
( -0 ) protected NO excpetion
( -1 ) This is up to each individual project
( -1 ) Just worry about classes that Velocity might use
( -0 ) @deprecated public
( -0 ) @deprecated protected
Hen,
Note that there should be two choices for protected: with and without an
exception.
I am now more hard line on this than at the start. Sun uses private for
java.util.Collections and others. So Velocity is excluding useful code as it
stands.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] XxxUtils constructors
Posted by Juozas Baliuka <ba...@centras.lt>.
(+1 ) @deprecated public
> ( ) @deprecated protected
>
>
> --
> 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] RESULT XxxUtils constructors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Michael A. Smith" <ma...@apache.org>
> On Thu, 15 Aug 2002, robert burrell donkin wrote:
> > there is no consensus.
>
> agreed.
The problem is that the Jakarta voting rules don't help us here. Given Henri
and Michael also gave the result as 'inconclusive' I withdraw my result
declaration (gosh, that sounds very official).
The only way to move forward would seem to be another vote, more tightly
driven. However, there's probably time for another round of discussion
first...
> > > (Although we could probably argue about it forever ;-)
> >
> > the problem is that pushing this forward against opposition bodes ill
for
> > a project that is attempting to encourage code reuse. the class was
> > developed in velocity but it can no longer be used. instead, the stated
> > position of the privateers is that velocity needs to be changed. other
> > projects and component beware.
>
> I don't think anyone said that velocity *needs* to change. As far as I
> can remember, the "privateers" asked why commons needs to make beans out
> of decidedly non-bean classes rather than velocity accepting non-bean
> classes. Just because velocity says "beans-only", doesn't mean that the
> Utils need to be made into beans when they are not.
>
> In other words, we have some component (e.g. Velocity) that only works
> on beans, and another component (e.g. StringUtils) that is not a bean,
> and we're trying to get them to work together. To begin with, it
> already seems like a bad mix. Neither side wants to change things (i.e.
> velocity doesn't want to accept non-bean classes to allow static method
> invocation on them, and us "privateers" don't want to make a non-bean
> class into a bean).
>
> However, that doesn't mean that things can't work without making one of
> the "sides" change to accomodate the other. Paul posted a perfectly
> reasonable bridge between the two, and I don't think anyone has posted a
> reason why it couldn't be used:
>
> public class Util {
> public StringUtils string() { return null; }
> public ObjectUtils object() { return null; }
> public CollectionUtils collection() { return null; }
> }
>
> $foo.string().method()
>
> And, although I'm not that familiar with velocity, I'm guessing you
> could get even do:
>
> public class Util {
> public StringUtils getString() { return null; }
> public ObjectUtils getObject() { return null; }
> public Collectionutils getCollection() { return null; }
> }
>
> then, you could use:
>
> $foo.string.method()
>
> (i.e. without the "()")
>
> Is there a reason velocity users can't use this? Doesn't this bridge
> the bean to non-bean gap?
>
> regards,
> michael
>
>
> --
> 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] RESULT XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> Thanks for the clarification. Now we know that XxxUtils in commons is
> incompatable with Velocity as it stands. Thus the options are
> - change Velocity
> - change commons
> - tough (fork code)
>
> I voted last time, at least in part, on the belief that Velocity could find
> a way around this. So, I would now reconsider my vote.
>
> Daniel - can you clarify why this change to Velocity is unacceptable?:
> context.putStatic(StringUtils.class)
> [note the 'static' to indicate to use static methods, not an instance]
IMO, that's pretty unacceptable (but I'm obviously not the only
committer ;). In Velocity, the right way to handle this sort of thing
is via a custom introspector which can be plugged into Velocity
through its configuration. This introspector would look for instances
of a wrapper class which is responsible for invoking methods of the
class represented by Class object (the wrapper class would actually be
unnecessary when coupled with the customer introspector, but better
for compatibility's sake). Here's some very vague pseudo-code:
class Invoker
Invoker(Class c):
...
class CustomIntrospector:
doIntrospectionStuff(Object obj, String methodName):
if (obj instanceof Invoker):
((Invoker) obj).invokeMethod(methodName)
else:
// Do standard Velocity invoker stuff
It's even remotely possible that Geir and the gang might consider
including a patch providing this sort of functionality in the core,
since it doesn't negatively effect backwards compat.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> Thanks for the clarification. Now we know that XxxUtils in commons is
> incompatable with Velocity as it stands. Thus the options are
> - change Velocity
> - change commons
> - tough (fork code)
>
> I voted last time, at least in part, on the belief that Velocity could find
> a way around this. So, I would now reconsider my vote.
>
> Daniel - can you clarify why this change to Velocity is unacceptable?:
> context.putStatic(StringUtils.class)
> [note the 'static' to indicate to use static methods, not an instance]
IMO, that's pretty unacceptable (but I'm obviously not the only
committer ;). In Velocity, the right way to handle this sort of thing
is via a custom introspector which can be plugged into Velocity
through its configuration. This introspector would look for instances
of a wrapper class which is responsible for invoking methods of the
class represented by Class object (the wrapper class would actually be
unnecessary when coupled with the customer introspector, but better
for compatibility's sake). Here's some very vague pseudo-code:
class Invoker
Invoker(Class c):
...
class CustomIntrospector:
doIntrospectionStuff(Object obj, String methodName):
if (obj instanceof Invoker):
((Invoker) obj).invokeMethod(methodName)
else:
// Do standard Velocity invoker stuff
It's even remotely possible that Geir and the gang might consider
including a patch providing this sort of functionality in the core,
since it doesn't negatively effect backwards compat.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> Daniel Rall <dl...@finemaltcoding.com> writes:
>
> > It works, but it's not backwards compatible, nor very fair to one of
> > the projects which (in part) orginated the code in question and that
> > the Commons documentation system is based on. *shrug*
> >
> > If a non-private ctor isn't going to fly, it's probably the best
> > option proposed so far.
>
> So I was totally wrong about this, since that API's implementation has
> methods which really return null. That won't work with Velocity (or
> much else, for that matter).
Thanks for the clarification. Now we know that XxxUtils in commons is
incompatable with Velocity as it stands. Thus the options are
- change Velocity
- change commons
- tough (fork code)
I voted last time, at least in part, on the belief that Velocity could find
a way around this. So, I would now reconsider my vote.
Daniel - can you clarify why this change to Velocity is unacceptable?:
context.putStatic(StringUtils.class)
[note the 'static' to indicate to use static methods, not an instance]
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> It works, but it's not backwards compatible, nor very fair to one of
> the projects which (in part) orginated the code in question and that
> the Commons documentation system is based on. *shrug*
>
> If a non-private ctor isn't going to fly, it's probably the best
> option proposed so far.
So I was totally wrong about this, since that API's implementation has
methods which really return null. That won't work with Velocity (or
much else, for that matter).
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Michael A. Smith" <ma...@apache.org> writes:
> public class Util {
> public StringUtils string() { return null; }
> public ObjectUtils object() { return null; }
> public CollectionUtils collection() { return null; }
> }
>
> $foo.string().method()
>
> And, although I'm not that familiar with velocity, I'm guessing you
> could get even do:
>
> public class Util {
> public StringUtils getString() { return null; }
> public ObjectUtils getObject() { return null; }
> public Collectionutils getCollection() { return null; }
> }
>
> then, you could use:
>
> $foo.string.method()
>
> (i.e. without the "()")
>
> Is there a reason velocity users can't use this? Doesn't this bridge
> the bean to non-bean gap?
It works, but it's not backwards compatible, nor very fair to one of
the projects which (in part) orginated the code in question and that
the Commons documentation system is based on. *shrug*
If a non-private ctor isn't going to fly, it's probably the best
option proposed so far.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Michael A. Smith" <ma...@apache.org>
> After thinking further it further, I can see that no matter what
> velocity's implementation is, there's probably at least a few
> implementations that aren't going to save that typing information. So,
> having a private constructor isn't going to fly. So, I'm changing to my
> second preference, @deprecated protected.
The problem with the deprecated part is that we had a second use case -
subclassing to add extra static methods. These subclasses would have a
deprecation warning from their constructor if the superclass's constructor
is deprecated.
Or is that what you want the deprecation to mean?
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Michael A. Smith" <ma...@apache.org> writes:
> On Thu, 15 Aug 2002, robert burrell donkin wrote:
> > i'm not a velocity expert (i know about StringUtils because ages ago i did
> > quite a bit of source generation with texen and contributed some patches
> > to that class) but i suspect that since the runtime type of the method
> > returns are null, it won't work.
>
> I suppose it depends on how velocity is implemented. If it saves the
> type information which it knows from the method call, than it should be
> able to determine the static methods and use "null" as the object ot
> execute the methods on (which is exactly how you use reflection to
> execute a static method iirc). If, however, velocity doesn't save the
> method return typing information (possibly by just passing around the
> results from "$foo.string" rather than keeping the call info from
> $foo.string along with the return), then Paul's method won't work.
Yes, sorry, all along I was just looking at the interface and
(apparently wrongly) assuming those methods would return actual
instances. Duh. It doesn't work if a null reference is returned.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 15 Aug 2002, robert burrell donkin wrote:
> i'm not a velocity expert (i know about StringUtils because ages ago i did
> quite a bit of source generation with texen and contributed some patches
> to that class) but i suspect that since the runtime type of the method
> returns are null, it won't work.
I suppose it depends on how velocity is implemented. If it saves the
type information which it knows from the method call, than it should be
able to determine the static methods and use "null" as the object ot
execute the methods on (which is exactly how you use reflection to
execute a static method iirc). If, however, velocity doesn't save the
method return typing information (possibly by just passing around the
results from "$foo.string" rather than keeping the call info from
$foo.string along with the return), then Paul's method won't work.
> there are ways round this kind of thing in velocity but daniel's an expert
> and if he says that a deprecated protected constructor is the best way to
> allow reuse by velocity, then i - for one - am willing to accept his
> judgement.
After thinking further it further, I can see that no matter what
velocity's implementation is, there's probably at least a few
implementations that aren't going to save that typing information. So,
having a private constructor isn't going to fly. So, I'm changing to my
second preference, @deprecated protected.
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, August 15, 2002, at 10:25 PM, Michael A. Smith wrote:
<snip>
> And, although I'm not that familiar with velocity, I'm guessing you
> could get even do:
>
> public class Util {
> public StringUtils getString() { return null; }
> public ObjectUtils getObject() { return null; }
> public Collectionutils getCollection() { return null; }
> }
>
> then, you could use:
>
> $foo.string.method()
>
> (i.e. without the "()")
>
> Is there a reason velocity users can't use this? Doesn't this bridge
> the bean to non-bean gap?
i'm not a velocity expert (i know about StringUtils because ages ago i did
quite a bit of source generation with texen and contributed some patches
to that class) but i suspect that since the runtime type of the method
returns are null, it won't work.
there are ways round this kind of thing in velocity but daniel's an expert
and if he says that a deprecated protected constructor is the best way to
allow reuse by velocity, then i - for one - am willing to accept his
judgement.
(i've tried to stay out of this particular war so hopefully you'll forgive
me if i bow out early.)
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 15 Aug 2002, robert burrell donkin wrote:
> there is no consensus.
agreed.
> > (Although we could probably argue about it forever ;-)
>
> the problem is that pushing this forward against opposition bodes ill for
> a project that is attempting to encourage code reuse. the class was
> developed in velocity but it can no longer be used. instead, the stated
> position of the privateers is that velocity needs to be changed. other
> projects and component beware.
I don't think anyone said that velocity *needs* to change. As far as I
can remember, the "privateers" asked why commons needs to make beans out
of decidedly non-bean classes rather than velocity accepting non-bean
classes. Just because velocity says "beans-only", doesn't mean that the
Utils need to be made into beans when they are not.
In other words, we have some component (e.g. Velocity) that only works
on beans, and another component (e.g. StringUtils) that is not a bean,
and we're trying to get them to work together. To begin with, it
already seems like a bad mix. Neither side wants to change things (i.e.
velocity doesn't want to accept non-bean classes to allow static method
invocation on them, and us "privateers" don't want to make a non-bean
class into a bean).
However, that doesn't mean that things can't work without making one of
the "sides" change to accomodate the other. Paul posted a perfectly
reasonable bridge between the two, and I don't think anyone has posted a
reason why it couldn't be used:
public class Util {
public StringUtils string() { return null; }
public ObjectUtils object() { return null; }
public CollectionUtils collection() { return null; }
}
$foo.string().method()
And, although I'm not that familiar with velocity, I'm guessing you
could get even do:
public class Util {
public StringUtils getString() { return null; }
public ObjectUtils getObject() { return null; }
public Collectionutils getCollection() { return null; }
}
then, you could use:
$foo.string.method()
(i.e. without the "()")
Is there a reason velocity users can't use this? Doesn't this bridge
the bean to non-bean gap?
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, August 15, 2002, at 08:18 PM, Stephen Colebourne wrote:
> Vote results:
> 1st preference
> 4 private
> 2 protected
> 2 deprecated public
> 1 public
>
> 2nd preference
> 2 protected
> 1 deprecated protected
> 1 deprecated public
>
>
> I make it that private wins by having more 1st prefs.
there is no consensus.
the votes for protected, deprecated public and public means that a
majority don't want to have a private constructor. the big question is
whether those in favour of the private solution could win a majority vote
for that solution (ie. a straight private or not private) now that people
have seen that it has the largest minority or whether the other opinions
could agree on a common position that has a majority.
> (Although we could probably argue about it forever ;-)
the problem is that pushing this forward against opposition bodes ill for
a project that is attempting to encourage code reuse. the class was
developed in velocity but it can no longer be used. instead, the stated
position of the privateers is that velocity needs to be changed. other
projects and component beware.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RESULT XxxUtils constructors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Vote results:
1st preference
4 private
2 protected
2 deprecated public
1 public
2nd preference
2 protected
1 deprecated protected
1 deprecated public
I make it that private wins by having more 1st prefs. (Although we could
probably argue about it forever ;-)
Stephen
----- Original Message -----
From: "Steven Caswell" <st...@caswell.name>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Wednesday, August 14, 2002 12:09 AM
Subject: RE: [VOTE] XxxUtils constructors
> >
> > (-1) public
> > (+1) private
> > (+0) protected
> > (-1) This is up to each individual project
> > (-1) Just worry about classes that Velocity might use
> > [added]
> > (-0) @deprecated public
> > (-0) @deprecated protected
> >
> >
> > --
>
> Steven Caswell
> steven@caswell.name
>
>
>
> --
> 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>
[VOTE] Current standing - XxxUtils constructors
Posted by Henri Yandell <ba...@generationjava.com>.
( ) public
(4) private
(2) protected
( ) This is up to each individual project
( ) Just worry about classes that Velocity might use
(3) @deprecated public
( ) @deprecated protected
Ignoring people's +0's, -0's and -1's.
A pretty hung decision so far.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] XxxUtils constructors
Posted by Steven Caswell <st...@caswell.name>.
>
> (-1) public
> (+1) private
> (+0) protected
> (-1) This is up to each individual project
> (-1) Just worry about classes that Velocity might use
> [added]
> (-0) @deprecated public
> (-0) @deprecated protected
>
>
> --
Steven Caswell
steven@caswell.name
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] XxxUtils constructors
Posted by Henri Yandell <ba...@generationjava.com>.
( ) public
( ) private
( ) protected
( ) This is up to each individual project
( ) Just worry about classes that Velocity might use
[added]
( ) @deprecated public
( ) @deprecated protected
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] XxxUtils constructors
Posted by "Michael A. Smith" <ma...@apache.org>.
On Tue, 13 Aug 2002, Henri Yandell wrote:
> [Any other options, let me know and I'll re-publish the vote]
You can add:
@depracated public
@deprecated protected
deprecation just explicitly informs the users that using the constructor
is not a recommended practice.
My vote/preference is for private, but I'm willing to go for @deprecated
protected.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>