I had forgotten this - I agree something like pint, pboolean etc is
cumbersome and counter-intuitive and would negate a significant reason for
my suggestion so prob not worth it.
-Original Message-
From: Brent Worden [mailto:[EMAIL PROTECTED]
Sent: 14 October 2003 00:55
To: Jakarta
As a user I would point out that a likely use case would involve one
primitive type but lots of different collections of that type.
Would packaging by type work?
I know it has negatives but if most of the code will be done via a template
and code generation that it wouldn't be too bad perhaps?
layout. I think a package that consists
of all Maps will be easier to manage than a package consisting of all
int collections, lists, maps, iterators, and sets.
Hope, Matthew wrote:
Is this really the case?
The problem of primitives is that inheritance becomes impossible for a
collection
Would suggest putting the resetting of the old logger in the tearDown()
method...
I have to do this a lot a the moment where all unit tests are run through
irrespective of the result of others and this means you don't run any risk
of losing the output.
Finally will do the same but Junit provides
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: 21 September 2003 19:10
To: Jakarta Commons Developers List
Subject: Re: [collections] CollectionUtils.index() behavior
OK, I will leave as is, but I personally see this as bad design -- maps
are not ordered
Not so -
perhaps less so from 1.5 onwards since for non critical performance the ease
of autoboxing is hard to beat but when you are using primitives not just
because of other interface concerns but for performance/space considerations
a pure primitive implementation should be considerably better for large
PROTECTED]
Sent: 02 September 2003 12:03
To: Jakarta Commons Developers List
Subject: Re: [primitives] Open for business
- Original Message -
From: Hope, Matthew [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List'
[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 10:26
Here's a rough idea:
class AsserterFactory
Asserter getAsserter(String name)
interface Asserter
void assertTrue(boolean condition, String message)
class Java14Asserter
void assertTrue(boolean condition, String message)
assert condition : message;
());
}
}
-Original Message-
From: Hope, Matthew
Sent: 20 August 2003 15:16
To: 'Jakarta Commons Developers List'
Subject: RE: [collections] Questions
I knocked this up - javadocs are crap but is this the sort of
thing you were
thinking of?
a mutable version is not too hard either
from:Hope, Matthew [EMAIL PROTECTED]
inlined as attachment was stripped...
import java.util.*;
/**
* Quick and simple implementation of a single element
collection. The
collection
* starts with one entry and always keeps it that way, therefore
modification
-Original Message-
From: Takuya Murata [mailto:[EMAIL PROTECTED]
Sent: 20 August 2003 04:29
To: Jakarta Commons Developers List
Subject: Re: [collections] Questions
Hi,
So the question is do we really need SingletonIterator and
such. If we
want to eliminate the
-Original Message-
From: Takuya Murata [mailto:[EMAIL PROTECTED]
Sent: 20 August 2003 11:55
To: Jakarta Commons Developers List
Subject: Re: [collections] Questions
A tricky situation is
class A {
public void method (Iterator i);
public void method (ListIterator
I knocked this up - javadocs are crap but is this the sort of thing you were
thinking of?
a mutable version is not too hard either.
Matt
-Original Message-
From: Hope, Matthew
Sent: 20 August 2003 13:18
To: 'Jakarta Commons Developers List'
Subject: RE: [collections] Questions
We could fix the US spelling ;¬)
seriously - is there a convention within apache / jakarta / commons to use
US or UK english spelling?
(or is it a case of consistency within sub project)
Matt
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: 13 August 2003 18:57
I believe you are in the wrong mailing list for this.
You have a classloader issue with your servlet container. this is nothing to
do with commons.
if you're using tomcat try the tomcat USER list however my best guess is
that you haven't put the jdbc driver jar in the
WEB-INF/lib/ directory...
There's at least one person in this discussion who needs to extend the
utils classes so it doesn't make sense to declare the classes
final. How
does it benefit anyone by declaring a reusable library
class/method final?
Preventing people who don't know what they are doing from making
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: 30 July 2003 18:39
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style
Preventing people who don't know what they are doing from making
mistakes.
In my experience this
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: 23 July 2003 12:52
To: Jakarta Commons Developers List
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
Logging is useless in this case,
Such a statement seems ludicrous The relative merits of
I did a lot of this kind of bugs myself too and it is very
trivial to fix.
1. Set maxConnections to 1 for testing
useful
2. Use lazy decorator for connection to throw exeption from close
???
3. Use find/replace to remove all }finally{ connection.close(); }
??!?!?!?!
4. Store decorator in
-
From: Hope, Matthew [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List'
[EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 2:34 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
I would disagree on one point. The idea of logging when a
connection is
closed due to garbage
I have only had a cursory read through this - using someone elses
(hopefully better tested both in unit and real world) implementation is
better than writing your own...
...however any system attempting to remove resource cleanup responsibilites
from the developer either has to place extremely
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: 23 July 2003 15:48
To: Jakarta Commons Developers List
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
--- Hope, Matthew [EMAIL PROTECTED] wrote:
-Original Message-
From: Glenn Nielsen [mailto
I would disagree on one point. The idea of logging when a connection is
closed due to garbage collection finalization strikes me as a good one
(assuming the pool used is using a weakly referenced mapping otherwise
garbage collection release of resources is going to be a real bummer).
this kind of
interesting problem...
empty string has a very clear meaning in java, it is a non null String
object of zero length.
Does the entrenched user base merit retaining a non standard naming
convention.
or is Empty sufficiently entrenched to also mean null? (I don't think it is)
I appreciate the
As a user I agree with the benefits of both proposals (can't decide which I
prefer yet). When I saw the initial proposal I wasn't happy either but could
not come up with a 'complete' solution either.
one point on the first though, I would find in my code that the vast
majority of my use cases
I see no reason for any of the methods we are talking about to distinguish
x from xyz so lets simplify the set:
I always use Empty to refer to never null - I am unaware of anyone doing
any different.
I normally use Whitespace to mean etc but NOT . I am aware some people
differ in this.
I am
A side question: even if Java permitted operator
overloading, I have read
comments to the effect that the technique is not to be
preferred. Never having
done much with it in a language that permits it, I don't have
the experience to
know why. As someone who thinks mathematically (at
You are aware that the following two methods could not coexist in the same
class?
/**
* A getter for a Map that maps the phoneType to the phoneNumber,
* here represented by a String
*/
Map getPhone();
/**
* A getter method for a Phone
28 matches
Mail list logo