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 2004/11/03 00:40:29 UTC
Re: [lang] JodaTime - was Commons Lang DateRange/Duration classes
Looking back in history, there have been various occaisions when this should
have happened. The trouble is that now it is a recognised product other
factors come into play:
1) ASF policy on everything going via the Incubator - this stuffs me
basically. JodaTime is the work primarily of two people, Brian S ONeill and
I. To get into ASF we would have to pass lots of tests of community
viability, mentoring, documentation, license assignment, ...................
Frankly the beaurocracy of even considering it seems pointless. *
2) Existing users - I'm about to do a 1.0 of JodaTime in its current
package, because its way overdue
3) Package name change/Brand name change - actually I'm not too worried
about this
4) Commons-Time - Does a 450k jar file, time-'framework' belong in commons.
But its too small to be an ASF top level project.
5) Would any other ASF people contribute to it just because I brought it to
ASF? Would the code be better?
Stephen
* Note that this worries me about ASF in general, although I'm not convinced
everyone actually plays by the rules
----- Original Message -----
From: "Gary Gregory" <gg...@seagullsoftware.com>
> Would it be interesting to bring Joda-Time as commons-time?
Gary
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Tuesday, November 02, 2004 14:12
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Commons Lang DateRange/Duration classes
>
> See http://joda-time.sourceforge.net
>
> This project makes me biased as to whether a DateRange/Duration class
> should
> be in [lang]. So I'll wait for other views.
>
> Stephen
>
> ----- Original Message -----
> From: "Eric Crampton" <cc...@eonomine.com>
> > I've noticed on the Commons Lang task list that there is a need for
> > DateRange/Duration classes. I've written such a thing when needing
to
> > scratch an itch and, after some cleanup to better look like existing
> > Jakarta Commons code, would like to submit it.
> >
> > Before submitting, however, I'd like to make sure no one else has
> > tackled or is tackling this. Also, does anyone have any special
ideas
> > or requirements for such classes?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 4 Nov 2004 18:19:32 -0800 (PST), David Graham
<gr...@yahoo.com> wrote:
> The main reason not to use assertions is that they can be disabled at
> runtime, rendering them fairly useless IMO. Personally, I would remove
> the null parameter checking entirely and let the code throw a NPE. The
> caller will see their offending method in the stack trace.
Assertions are actually disabled by default, and need to be explicitly
enabled at JVM startup time. To make things worse, specifying a flag
to the JVM on startup can be complicated when an app server is
involved.
In my day job, we looked into using Java assertions when we could
finally depend on JDK 1.4 or later, and chose to eschew them in favour
of our own homegrown assertion class for the reasons above.
--
Martin Cooper
> David
>
>
>
> --- Chris Lambrou <ma...@chrislambrou.com> wrote:
>
> > Hi,
> >
> > Although I've marked the subject with [collections], I guess this is
> > targeted at anyone who has an interest in a Java 5.0 port of any jakarta
> >
> > project. I'm slowly chipping away at a Java 5.0 port of
> > commons-collections. As I've been generifying the original collections
> > classes, I've found apart from a little bit of tidying here and there,
> > I've mostly been leaving the argument checking code at the start of most
> >
> > constructors and/or factory methods alone. It's just occured to me that
> >
> > all of these checks are explicit checks that throw some subclass of
> > RuntimeException. For example:
> >
> > protected ClosureTransformer(Closure<? super E> closure)
> > {
> > if (closure == null) {
> > throw new IllegalArgumentException("Closure must not be
> > null");
> > }
> > this.closure = closure;
> > }
> >
> > Since JDK1.4, the assert keyword has been available to replace this type
> >
> > of error checking, but obviously it's not been used in collections in
> > order to maintain backwards compatibility with earlier versions of the
> > JDK. With the move to Java 5.0, backwards compatibility is no longer a
> > concern, and I'm considering replacing all such runtime argument checks
> > with assertions. For example:
> >
> > protected ClosureTransformer(Closure<? super E> closure)
> > {
> > assert closure != null : "Closure must not be null";
> > this.closure = closure;
> > }
> >
> > I've heard both sides of the explict-check-and-RuntimeException versus
> > Assertions argument before in what feels like the dim and distant past,
> > but the discussion has always included the backwards compatibility
> > slant. I was wondering if anyone has any thoughts on the matter in
> > light of Java 5.0
> >
> > Chris
> >
> >
> > P.S. If anyone's interested, the JDK 1.5 port of collections is
> > currently hosted on SourceForge at http://collections15.sourceforge.net
> > - I'd be interested in any feedback, particularly on the new generic
> > interfaces in the main package.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> __________________________________
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> I think that Sun have got this wrong. They should have mandated IAE, not
> NPE. In parctice, however, I don't think it makes much difference to
> client code, since both are unchecked. I intend to throw IAEs
> throughout collections15, except where the Java Collections interfaces
> mandate NPEs instead.
;-)
This is actually what [collections] does pretty much
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Java5.0 - Runtime exceptions or assertion errors.
What's your preference?
Posted by Chris Lambrou <ma...@chrislambrou.com>.
Hi,
As much as I'd like to replace all of the existing parameter checks with
assertions, I think that the current method of having explicit parameter
checking on all public methods will have to stand. Many thanks to you
all for your useful input. I thought that for the sake of completeness,
I'd tell you my own take on the issue. If you're interested, read on,
but otherwise you should stop reading here.
Chris
My preference would have been to use assertion checks in the code,
rather than the existing set of checks. I've rejected this for the
following reasons.
1. The standard Java collection interfaces mandate the throwing of NPEs.
Using assertions would violate this.
2. Whilst Sun claims that disabled assertions have a negligible affect
on runtime performance, I don't especially believe that null pointer
checks have a great impact on performance either. Furthermore, for the
kind of parameter checks that take place in collections, I'm not
convinced that the ability to disable assertions would yield a
noticeable increase in performance.
3. No matter how well the code is unit tested, there's no guarantee that
library won't be bug free. In keeping with the principle of trying to
detect errors as early as possible, it's best to keep the checks in at
all times, rather than allow them to be disabled (by default) during
normal use.
4. I like to use assertions to catch and eliminate problems during
development and testing, and disable them the code is used in a shipped
product. However, I can't force users of collections15 to follow the
same development practice. Since these checks are to detect errors in
the user's code, rather than in collections15 itself, it's best to keep
the checks in at all times, rather than to use assertions.
Frank W. Zammetti wrote:
It is an accepted usage pattern that assertions are not to be used to
validate method parameters if they are part of the public interface.
They are properly used to check parameters passed to private members
though, but nothing a calling client might send in.
I generally agree. This is the approach I've settled on.
David Graham wrote:
The main reason not to use assertions is that they can be disabled at
runtime, rendering them fairly useless IMO. Personally, I would remove
the null parameter checking entirely and let the code throw a NPE. The
caller will see their offending method in the stack trace.
Maybe they will, but only if the error shows up. Following the principle
of detecting errors as early as possible, I think it's much better to
have an explicit check on the parameters, so it's easier to pinpoint
when and where the error occurred. For example, if the error checking of
arguments is in the constructor of a class, then the error will show
itself when and where the constructor is invoked, rather than the first
time the instance is used in such a way as to cause it to fail.
Martin Cooper wrote:
Assertions are actually disabled by default, and need to be explicitly
enabled at JVM startup time. To make things worse, specifying a flag to
the JVM on startup can be complicated when an app server is involved.
Point taken. Another good reason for not using assertions for this
particular purpose.
In my day job, we looked into using Java assertions when we could
finally depend on JDK 1.4 or later, and chose to eschew them in favour
of our own homegrown assertion class for the reasons above.
Collections15 is too low level for it to warrant having such a
dependency on another library.
Matthew Hawthorne wrote:
I think this was a fundamental goal of assertions. I imagine that the
idea is to enable assertions during heavy development time, and disable
them once the code reaches a certain degree of stability.
This is precisely the reason I was considering the use of assertions.
The enable/disable concept is appealing to some for performance reasons.
I think Sun claims that an assertion will have no performance cost if
they are disabled. I'm not sure how much of a difference it would make.
Me neither. I just can't see simple null checks causing a noticeable
degradation in performance. Even if they did, I think the benefits of
their presence generally outweigh such a cost.
I share your philosophy on this. In my opinion, the redundant parameter
checking everywhere (especially for null) does more harm than good.
I have to disagree. The only harm I can see is a slight performance
decrease (which I suspect is negligible for simple null checks), and
class files which are a bit larger than they otherwise would be without
the checks. The additional validation helps to detect bugs earlier
rather than later, which I think is a benefit that far outweights the
cost. The thinking behind this is in line with my earlier response to
David Graham's comment.
I like assertions, except in cases of input checking for a client
external to the application (like a web service client, for example).
Me too. This is the approach I've settled on.
I don't see the enable/disable as much of an issue. The
RuntimeException cases are supposed to be caught during development anyway.
That's how I like to develop, but I can't force programmers that use
collections15 to follow the same principle.
Stephen Colebourne wrote:
Personally, I strive to avoid any NPE, preferring IAEs instead, but not
everyone in commons agrees with that philosophy. collections15 should
make one decision on that and stick by it.
I agree. To my mind, the very name IllegalArgumentException tells me
that this is the Exception type for a method to throw if it detects
incorrect input.
Bear in mind that the JDK interfaces mandate NPE for null inputs.
I think that Sun have got this wrong. They should have mandated IAE, not
NPE. In parctice, however, I don't think it makes much difference to
client code, since both are unchecked. I intend to throw IAEs
throughout collections15, except where the Java Collections interfaces
mandate NPEs instead.
Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
The collections15 CVS looks good so far from a relatively quick look. The
main thing is to avoid the deprecated code and oddities like Bag (which you
seem to have done).
I wouldn't use assertions here, as you are trying to trap user input. (I've
never used assertions yet ;-)
Personally, I strive to avoid any NPE, preferring IAEs instead, but not
everyone in commons agrees with that philosophy. collections15 should make
one decision on that and stick by it.
Bear in mind that the JDK interfaces mandate NPE for null inputs.
Stephen
----- Original Message -----
From: "matthew.hawthorne" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, November 05, 2004 3:54 AM
Subject: Re: [collections] Java5.0 - Runtime exceptions or assertion errors.
What's your preference?
> David Graham wrote:
> > The main reason not to use assertions is that they can be disabled at
> > runtime, rendering them fairly useless IMO.
>
> I think this was a fundamental goal of assertions. I imagine that the
> idea is to enable assertions during heavy development time, and disable
> them once the code reaches a certain degree of stability.
>
> The enable/disable concept is appealing to some for performance reasons.
> I think Sun claims that an assertion will have no performance cost if
> they are disabled. I'm not sure how much of a difference it would make.
>
>
> > Personally, I would remove the null parameter checking entirely and let
> > the code throw a NPE. The caller will see their offending method in
> the stack trace.
>
> I share your philosophy on this. In my opinion, the redundant parameter
> checking everywhere (especially for null) does more harm than good.
>
> I like assertions, except in cases of input checking for a client
> external to the application (like a web service client, for example).
>
> I don't see the enable/disable as much of an issue. The
> RuntimeException cases are supposed to be caught during development
anyway.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Java5.0 - Runtime exceptions or assertion errors.
What's your preference?
Posted by "matthew.hawthorne" <ma...@apache.org>.
David Graham wrote:
> The main reason not to use assertions is that they can be disabled at
> runtime, rendering them fairly useless IMO.
I think this was a fundamental goal of assertions. I imagine that the
idea is to enable assertions during heavy development time, and disable
them once the code reaches a certain degree of stability.
The enable/disable concept is appealing to some for performance reasons.
I think Sun claims that an assertion will have no performance cost if
they are disabled. I'm not sure how much of a difference it would make.
> Personally, I would remove the null parameter checking entirely and let
> the code throw a NPE. The caller will see their offending method in
the stack trace.
I share your philosophy on this. In my opinion, the redundant parameter
checking everywhere (especially for null) does more harm than good.
I like assertions, except in cases of input checking for a client
external to the application (like a web service client, for example).
I don't see the enable/disable as much of an issue. The
RuntimeException cases are supposed to be caught during development anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Java5.0 - Runtime exceptions or assertion errors.
What's your preference?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
It is an accepted usage pattern that assertions are not to be used to
validate method parameters if they are part of the public interface.
They are properly used to check parameters passed to private members
though, but nothing a calling client might send in (where a client isn't
another part of commons for example).
Hope that helps!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Chris Lambrou wrote:
> Hi,
>
> Although I've marked the subject with [collections], I guess this is
> targeted at anyone who has an interest in a Java 5.0 port of any jakarta
> project. I'm slowly chipping away at a Java 5.0 port of
> commons-collections. As I've been generifying the original collections
> classes, I've found apart from a little bit of tidying here and there,
> I've mostly been leaving the argument checking code at the start of most
> constructors and/or factory methods alone. It's just occured to me that
> all of these checks are explicit checks that throw some subclass of
> RuntimeException. For example:
>
> protected ClosureTransformer(Closure<? super E> closure)
> {
> if (closure == null) {
> throw new IllegalArgumentException("Closure must not be null");
> }
> this.closure = closure;
> }
>
> Since JDK1.4, the assert keyword has been available to replace this type
> of error checking, but obviously it's not been used in collections in
> order to maintain backwards compatibility with earlier versions of the
> JDK. With the move to Java 5.0, backwards compatibility is no longer a
> concern, and I'm considering replacing all such runtime argument checks
> with assertions. For example:
>
> protected ClosureTransformer(Closure<? super E> closure)
> {
> assert closure != null : "Closure must not be null";
> this.closure = closure;
> }
>
> I've heard both sides of the explict-check-and-RuntimeException versus
> Assertions argument before in what feels like the dim and distant past,
> but the discussion has always included the backwards compatibility
> slant. I was wondering if anyone has any thoughts on the matter in
> light of Java 5.0
>
> Chris
>
>
> P.S. If anyone's interested, the JDK 1.5 port of collections is
> currently hosted on SourceForge at http://collections15.sourceforge.net
> - I'd be interested in any feedback, particularly on the new generic
> interfaces in the main package.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
Posted by David Graham <gr...@yahoo.com>.
The main reason not to use assertions is that they can be disabled at
runtime, rendering them fairly useless IMO. Personally, I would remove
the null parameter checking entirely and let the code throw a NPE. The
caller will see their offending method in the stack trace.
David
--- Chris Lambrou <ma...@chrislambrou.com> wrote:
> Hi,
>
> Although I've marked the subject with [collections], I guess this is
> targeted at anyone who has an interest in a Java 5.0 port of any jakarta
>
> project. I'm slowly chipping away at a Java 5.0 port of
> commons-collections. As I've been generifying the original collections
> classes, I've found apart from a little bit of tidying here and there,
> I've mostly been leaving the argument checking code at the start of most
>
> constructors and/or factory methods alone. It's just occured to me that
>
> all of these checks are explicit checks that throw some subclass of
> RuntimeException. For example:
>
> protected ClosureTransformer(Closure<? super E> closure)
> {
> if (closure == null) {
> throw new IllegalArgumentException("Closure must not be
> null");
> }
> this.closure = closure;
> }
>
> Since JDK1.4, the assert keyword has been available to replace this type
>
> of error checking, but obviously it's not been used in collections in
> order to maintain backwards compatibility with earlier versions of the
> JDK. With the move to Java 5.0, backwards compatibility is no longer a
> concern, and I'm considering replacing all such runtime argument checks
> with assertions. For example:
>
> protected ClosureTransformer(Closure<? super E> closure)
> {
> assert closure != null : "Closure must not be null";
> this.closure = closure;
> }
>
> I've heard both sides of the explict-check-and-RuntimeException versus
> Assertions argument before in what feels like the dim and distant past,
> but the discussion has always included the backwards compatibility
> slant. I was wondering if anyone has any thoughts on the matter in
> light of Java 5.0
>
> Chris
>
>
> P.S. If anyone's interested, the JDK 1.5 port of collections is
> currently hosted on SourceForge at http://collections15.sourceforge.net
> - I'd be interested in any feedback, particularly on the new generic
> interfaces in the main package.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[collections] Java5.0 - Runtime exceptions or assertion errors. What's
your preference?
Posted by Chris Lambrou <ma...@chrislambrou.com>.
Hi,
Although I've marked the subject with [collections], I guess this is
targeted at anyone who has an interest in a Java 5.0 port of any jakarta
project. I'm slowly chipping away at a Java 5.0 port of
commons-collections. As I've been generifying the original collections
classes, I've found apart from a little bit of tidying here and there,
I've mostly been leaving the argument checking code at the start of most
constructors and/or factory methods alone. It's just occured to me that
all of these checks are explicit checks that throw some subclass of
RuntimeException. For example:
protected ClosureTransformer(Closure<? super E> closure)
{
if (closure == null) {
throw new IllegalArgumentException("Closure must not be null");
}
this.closure = closure;
}
Since JDK1.4, the assert keyword has been available to replace this type
of error checking, but obviously it's not been used in collections in
order to maintain backwards compatibility with earlier versions of the
JDK. With the move to Java 5.0, backwards compatibility is no longer a
concern, and I'm considering replacing all such runtime argument checks
with assertions. For example:
protected ClosureTransformer(Closure<? super E> closure)
{
assert closure != null : "Closure must not be null";
this.closure = closure;
}
I've heard both sides of the explict-check-and-RuntimeException versus
Assertions argument before in what feels like the dim and distant past,
but the discussion has always included the backwards compatibility
slant. I was wondering if anyone has any thoughts on the matter in
light of Java 5.0
Chris
P.S. If anyone's interested, the JDK 1.5 port of collections is
currently hosted on SourceForge at http://collections15.sourceforge.net
- I'd be interested in any feedback, particularly on the new generic
interfaces in the main package.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org