Hi,
I have been examining the beanutils Convertor/ConvertUtils classes with a
view to using them instead of the type convertor code I have written:
http://www.scolebourne.eurobell.co.uk/JodaTypeConvertor.zip
Currently I have found the following differences:
1) The Joda type convertor is called
I think it is possible to add more methods for ConvertUtils like
method
useful for DynamicProxy :
Does this mean you think ConvertUtils should be broken out from
beanutils
into its own commons area?
I am not sure it is good to have a lot of small packages.I have no ideas
abaut
Hi,
As part of the Joda project (www.joda.org) I have developed the following
collections that I would like to propose for inclusion in Apache commons
collection:
1) TreeNode, ArrayTreeNode and TreeIterator
http://www.scolebourne.eurobell.co.uk/JodaTreeProposal.zip
There are no curent unit tests
A rough sketch of the interface, which admittedly follows the architecture
of
my own implementation more than yours, would be like:
public interface Tree extends Collection {
/** Throws an exception if the parent isn't in the Tree already. */
boolean add(Object parent, Object child);
Thus my TreeNode class
corresponds most closely
to the TreeEntry class of yours, not Tree.
Which suggests the right approach to take is to leave TreeNode as it is,
and consider whether to make an implementation of Tree that uses TreeNode
for its guts.
This was kind of where I was
It looks like ArrayTreeNode expects users to access
and manipulate the children of a node by returning a
List from getChildren(), which users then use to add,
delete, and access the child nodes. I don't think this
follows best practices as seen in the java.util
collections and other commons
Related to this is the question of hashCode and equals methods. (The
other
type of collection is a Set, which needs a hashCode). So far, my view is
to
use the == check for equals and the identity hashCode (ie. don't
implement
either method).
These sounds better than the alternatives you
This is true, Joda also performs Java-XML mappings. And like Betwixt it is
not intended for use starting from just any old XML. (Java is king, XML is
just a data format).
Joda got written because I could find no alternative that met my
requirements. JAXB is XML focussed, I needed a Java focussed
I've just spent the evening trying to figure out the property descriptor
classes myself. For the joda project I wanted to return a BeanInfo
specifying a description of the bean. But it seems to be a bit tricky.
PropertyDescriptor is OK for my needs (just about)
IndexedPropertyDesciptor is not
of
the Bean spec (though I don't see mapped properties in the bean spec :),
and to carry it out seems that these collection type uses need to be
manually handled. Use PropertyUtils and you'll get at your Lists.
Arron.
Stephen Colebourne wrote:
I've just spent the evening trying to figure out
)
From: James Strachan [EMAIL PROTECTED]
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
This is what I was getting at. If DynaBeans were to become used as
the
main
interface (instead of PropertyUtils), then DynaBeans would need to
support
this notation
Hi,
After a quick check, I could find no implementation of a type checking list
in collections. As I needed it, I have created one. Here is the class
javadoc:
* TypedList is a list wrapper that supports type checking. Only elements
* of the specified type (or a subclass) can be added to the
From: Henri Yandell [EMAIL PROTECTED]
What is the point of the wrap method?
Can I do:
List list = TypedList(new LinkedList());
Yes, but the syntax is
List list = TypedList.wrap(new LinkedList());
However, as noted above, the iterator is based on AbstractList - not
Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 3:36 PM
To: Jakarta Commons Developers List
Subject: Re: [Collections][SUBMIT] TypedList
From: Henri
From: Henri Yandell [EMAIL PROTECTED]
To answer myself, very bad form. I imagine that we would have a
MapFilter/Predicate and a CollectionFilter/Predicate. Separate structures.
Maybe allowing an adaptor for Maps which could use Collections on keys or
values.
So we need something more than
From: Tim Moore [EMAIL PROTECTED]
Well if you think of this as a list proxy with no backing store of its
own, then IMO it makes sense to think of the parameter as the collection
to delegate to instead of to copy items out of. I feel like this is
still in keeping with the spirit of the
Hi all,
I've updated the classes to work around the existing Predicate class and the
code below, see attached files.
Stephen
From: Tim Moore [EMAIL PROTECTED]
Works for me! :-)
From: Jack, Paul [mailto:[EMAIL PROTECTED]]
I wouldn't even have a subclass for TypedList; I'd just put a
OK, this is a different design to one using Predicate, although obviously a
similar purpose. Before I can continue and finish the other collections, I
would like a decision on which way to go ;-)
This design gives much more power, but is therefore more complex (more
methods, more choice). Maybe
the ttgetTypeCheckedList/tt
* static factory method.
* p
* By default, this class will use an ArrayList behind the scenes.
* Alternatively, a List implementation, such as ttLinkedList/tt, may
* be wrapped by the constructor.
*
* @author Stephen Colebourne
*/
Feedback welcome. If this is agreed
From: Kief Morris [EMAIL PROTECTED]
Stephen Colebourne typed the following on 12:17 AM 4/7/2002 +0100
I have tweaked our two sets of interfaces tonight to produce a
combination
that starts to hang together. I don't think I lost any functionality, but
they are only the interfaces at the moment
From: Jack, Paul [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Although it really does feel like we could provide some sort of
Transformer-
based approach that would enable weak elements but also other
functionality...
Like...Before I mentioned a two-transformer
From: Jack, Paul [EMAIL PROTECTED]
I'm not sure a two transformer approach is all thats needed. Collections
have three basic types of method:
- input (add/set)
- query (indexOf, contains, equals, remove)
- output (get, toArray)
The Predicate/Transform proposal covers only the input
For what its worth, I'm not planning on using the ProxyMap, or any other
Proxy* classes. I reckon that they don't add a great deal.
Stephen
- Original Message -
From: Jeff Keyser [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Wednesday, May 01, 2002
] PredicateUtils [was TypedList]
Hi Stephen
I've given the code a quick once-over and it looks great. Nice and clean.
I've added into CVS - if anyone has any objections please speak up.
Some JUnit test cases would be nice for this stuff ;-)
James
- Original Message -
From: Stephen
From: Arron Bates [EMAIL PROTECTED]
The java supplied collections allow nulls. A null rejecting collection
would
be a special case. As such I would have no problems with the javadoc of
LazyList stating that nulls are used as placeholders.
Well, using the empty object rather than null
From: Jack, Paul [EMAIL PROTECTED]
Thus I propose splitting PredicateUtils in two:
PredicateCollections (#1 above)
PredicateUtils (#2 above)
Well, that still leaves us with the problem that PredicateUtils
doesn't contain all of the predicate utils. Other ideas:
1. Move
From: Arron Bates [EMAIL PROTECTED]
I thought I'd try an example:
List lazyList = LazyUtils.lazyList(new ArrayList());
// create entries 0 and 1 as 'empty', 2 as an object
Object obj = lazyList.get(2);
// set 1 and 2 to null, leave 0 as 'empty'
lazyList.set(1, null);
lazyList.set(2,
This link contains the code for the PredicateUtils and PredicateCollections
classes:
http://www.scolebourne.eurobell.co.uk/Predicates.zip
This change:
- separates the 8 wrapper collections from the standard Predicate
implementations.
- patches a bug in the original checkin where a class was
The following link contains a submission to collections of classes to cover
trees:
http://www.scolebourne.eurobell.co.uk/TreeNode.zip
This was discussed earlier in the year, but failed to come to a conclusion
due to other commitments of Kief Morris at that time. I have now implemented
an API for
The following link contains a submission to collections of classes to cover
trees:
http://www.scolebourne.eurobell.co.uk/TreeNode.zip
This was discussed earlier in the year, but failed to come to a conclusion
due to other commitments of Kief Morris at that time. I have now implemented
an API for
From: Jack, Paul [EMAIL PROTECTED]
Now includes a junit test, which revealed several bugs,
which are now fixed.
Just an ideais it possible to write ReferenceMap as a wrapper around
another Map? If so, then we could have ReferenceSortedMap, ReferenceList
etc. all within
From: bob mcwhirter [EMAIL PROTECTED]
3. What's the rationale for having equals and hashCode
be reference based?
The alternative is to compare both the value and children of that node.
But
in comparing the children, each child node will compare its value and
children and so on.
From: Kief Morris [EMAIL PROTECTED]
I would rather keep the iterator on TreeNode. If there are only two
standard
ways to iterate then two methods would seem appropriate. But are there
more
than two ways??
I favor a single iterator() method on the interface which returns the
nodes in an
of?
Stephen
-Paul
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 27, 2002 11:19 AM
To: Jakarta Commons Developers List
Subject: Re: [Collections][Submit] TreeNode and friends
From: Kief Morris [EMAIL PROTECTED]
I would rather keep
Hi all,
Resubmitted, as it got missed first time.
Now LazyCollections is on the CVS, this rename/split is required to keep the
CVS naming consistency.
Stephen
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent
* It uses two params and not a return value to make it usable with
* event based Objects (contenthandlers).
* Events in the Morpher are notified by registering a listener.
* [new] parameters are managed with beans get/set methods
**none* are mandatory
*/
public
I too like the ComparatorUtils concept outlined below. However, we might
want to consider whether the method names are nullFirst(Comparator) or
nullFirstComparator(Comparator) etc. I raise this because PredicateUtils
uses the latter at the moment, and it would be nice to be consistent (we
could
Hi,
I have split the current PredicateUtils class in two as follows:
PredicateUtils - the predicate implementations (more added)
PredicateCollections - the validating predicate based wrapper collections
Could a committer please advise on whether this split is acceptable? I'm
concerned to get
Hi,
I have completed the updates proposed in the last discussion on trees. The
tree node code now contains:
TreeNode - a simple list based tree node interface
ArrayTreeNode - an implementation based on ArrayList
TreeUtils - a group of useful utilities for managing trees
TestArrayTreeNode - a test
- Original message
From: Jack, Paul [EMAIL PROTECTED]
I too like the ComparatorUtils concept outlined below.
However, we might
want to consider whether the method names are nullFirst(Comparator) or
nullFirstComparator(Comparator) etc. I raise this because
From: Ola Berg [EMAIL PROTECTED]
I see that the Collections package has pretty much the same classes that I
had, and that you wanted more ideas. What does any of you committers say
about:
Filtering collections, that guarantees that only objects that matches an
ObjectFilter (sorry, I mean
To: Jakarta Commons Developers List; Stephen Colebourne
Subject: Re: [Collections] ComparableComparator - nulls
OK
Hello,
What do you think of
Set predicate(Set set, Predicate predicate)
? Is that too nondescript?
Actually, there is another factor involved
Dmitri,
I have had a simiilar idea of using a prefix such as xpath:. I need to add
functionality similar to this to the Joda project to access data (as with
BeanUtils), so I am interested in using this if the API is suitable ;-)
Stephen
- Original message
From: Dmitri
for the decorator class names.
But do you see what I'm getting at here?
-Paul
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 11, 2002 4:20 PM
To: Jakarta Commons Developers List
Subject: [Collections] Naming conventions
I thought part of the aim of the Utils was to avoid having top level
classes, even if they are package scoped.
The problem as I see it is that someone new to the package will come along
and see maybe 60+ classes in the collections package. However, over half
could be package scoped with no way
Just a thought...could the Comparator class be used to do the sorting? Why
write your own if one exists?
Stephen
- Original Message -
From: robert burrell donkin [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Saturday, June 15, 2002 11:40 AM
Subject: Re:
From: robert burrell donkin [EMAIL PROTECTED]
On Friday, June 14, 2002, at 05:08 AM, James Strachan wrote:
From: Stephen Colebourne [EMAIL PROTECTED]
2) ID's as Strings - Betwixt uses ints for it's ID/IDREF values (to
handle
recursion). I needed Strings, to allow for more complex
]
Sent: Saturday, June 15, 2002 5:15 PM
Subject: Re: [Collections] Naming conventions
On Sat, 15 Jun 2002, Stephen Colebourne wrote:
I thought part of the aim of the Utils was to avoid having top level
classes, even if they are package scoped.
yeah, in a way. They coule also be looked
From: Ola Berg [EMAIL PROTECTED]
This is one of the two reasons why I don\'t use jakartas framework (yet)
but stick to my own. The generic transforming method needs to be declared as
throwing exceptions.
My Transformation interface (a Transformation is the thing doing the
Transformation from
If you've checked the spec, then I withdraw the request ;-)
Stephen
- Original Message -
From: Martin van den Bemt [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Saturday, June 15, 2002 8:46 PM
Subject: Re: [Betwixt] Some ideas
Hi Stephen,
Agreed.
I know what you mean, but I'm not sure that commoncommons is the answer.
IMHO, code in the commons falls into three categories -
- Widely used, and often as a group (BeanUtils, Betwixt, Collections,
Digester, Logging)
- Individual stable, less interrelationships (CLI, Cactus, DBCP, HTTP
Client,
- Original Message -
From: Martin van den Bemt [EMAIL PROTECTED]
Hmm.. mindspin coming up.. Since you can currently set any character you
like, we could just allow valid characters, which doesn't choke
parsers..
I support that
Stephen
--
To unsubscribe, e-mail: mailto:[EMAIL
From: Arron Bates [EMAIL PROTECTED]
The Commons project itself is now housing separate sub projects which
have seemingly their own boundaries Every little part is acting like its
own jakarta project. Hell, the votes are even working that way... This
guy's been doing some great work with
Hi,
Currently, Betwixt and other users of BeanUtils rely on the java.beans class
Introspector to extract details from a class. Introspector is a very old and
limited class in todays terms:
- it doesn't support collections, just simple objects and arrays
- it doesn't support modern conventions
, who have a lot of introspection in
there code.. It works on all jdk versions afaik.
See o.a.tools.ant.Introspectionhelper.
+1 on the idea btw..
Mvgr,
Martin
On Sun, 2002-06-16 at 13:40, Stephen Colebourne wrote:
Hi,
Currently, Betwixt and other users of BeanUtils
From: Ola Berg [EMAIL PROTECTED]
In my reflect packet I have the classes Getters, Setters, Adders,
Putters and Constructors and Call and Methods. Setters.set( Object
bean, \property\, Object value) sets the value on a property etc.
There are also methods for retrieving the type (as a Class)
about introspection, org.apache.commons.introspection?
- Dmitri
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Sunday, June 16, 2002 1:36 PM
Subject: Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal
I've just added a couple of the small TODOs. Hopefully they should be
alright for the release:
ObjectUtils.identityToString
ObjectUtils.NULL
I haven't got anything pressing extra to fit into the release now.
Stephen
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
The builders look good. I was able to subclass ToStringStyle to get
customized formatting, which was my chief concern. I do think the
javadocs for the ToStringBuilder and associated classes should be
expanded to make it easier to implement custom formatting, without
someone needing to wade
As I'm on holiday Sun-Tue, don't expect my vote until Wed. But it should be
poitive ;-)
Stephen
PS. Can you provide a new maven link, so I can fix a few checkstyles?
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent:
There's quite a bit of code here that could be useful. I tried to have a
look at the [configuration] project in commons sandbox to compare, but
didn't have the time to do it properly. I suggest you might like to produce
a compare and constrast list for your version versus the current commons
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
Any reason why the Enum class doesn't overload its methods with versions
that don't take the Class object?
So getEnumList() in the Enum class would call getEnumMap(this.getClass())
Because its static. There is no thisClass
+1
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Monday, September 23, 2002 4:08 AM
Subject: [VOTE] Commons Lang release 1.0
I'm proposing a vote for a 1.0 release of Commons Lang to be made.
The difference
My view is that one of the main advantages of StringUtils is to avoid NPEs.
I actually thought that we'd been through all the methods and ensured that
none of them did throw a NPE.
As I sugested the method initially, I looked at what my own implementation
of this does and what my needs are.
In the same way as [logging], by not being a regexp package itself.
Of course it may just not be appropriate...
Stephen
- Original Message -
From: Berin Loritsch [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, September 26, 2002 4:40 PM
Subject:
From: Steve Downey [EMAIL PROTECTED]
On Thursday 26 September 2002 04:54 am, Stephen Colebourne wrote:
My view is that one of the main advantages of StringUtils is to avoid
NPEs.
I actually thought that we'd been through all the methods and ensured
that
none of them did throw a NPE.
I
I just want to point out that jakarta-oro is more than just a regular
expression package and already contains the generic interfaces to wrap
other
packages (as it is, oro already implements 3 different regular expression
grammars). It's a simple matter to add a factory to generate generic
Can you point me to the piece of functionality in Digester that relies on
it.
Stephen
BTW: I am currently looking after the reflection code in lang.
- Original Message -
From: Gregory M. Messner [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday,
.
Stephen
- Original Message -
From: robert burrell donkin [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Saturday, September 28, 2002 9:31 AM
Subject: Re: [beanutils] plan for 1.5 release
On Saturday, September 28, 2002, at 09:21 AM, Stephen Colebourne
Last five patches applied, thanks.
Stephen
- Original Message -
From: Steve Downey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, September 28, 2002 5:58 AM
Subject: [lang] RandomStringUtils javadoc patch
Does :
public static String random(int count, int start, int end,
Split the thread as this bit got lost...
There are definite similarities between this Delegate description and the
code that is currently located in [pattern]. [pattern] contains four simple
callback interfaces Predicate, Transformer, Command and Factory. It also has
methods that support calling
Thanks to Hen for organising the release ;-) and all for contributions.
We seem to have a bit of momentum at the moment for new features and ideas.
Lets hope we can keep that going, so maybe the 1.1 release will follow
fairly soon.
On that note, I have been looking at the reflection code again
The DynaBean abstraction (in BeanUtils today) lets you synthesize
beans
with a dynamic set of properties -- although only PropertyUtils knows
how
to do property get/set calls transparently for you. In Struts, for
example, we take an XML-ized version of a description like your Person
There seems to be some consensus that a new project is possible here. I have
already been working locally on classes in this area. Below is the
proposal.html file that I was using to control my scope:?
h3(0) Rationale/h3
p
The Java Reflection Framework provides a set of classes for accessing
and
AFAIK, collections was prepared fully for a release, but the release never
ocurred. There was a delay in the primitive subpackage, but I believe Rodney
Waldorf completed his work there. I don't know who the release manager was,
but they either need a little reminder, or a new one electing.
This
From: Berin Loritsch [EMAIL PROTECTED]
Not sure about the name, but I like the concept. Maybe we can call it
Klass
(sounds the same)?
Any particular reason for not liking clazz??. Its not that important, I
guess klass would be fine. ;-)
Stephen
--
To unsubscribe, e-mail: mailto:[EMAIL
I've been coding up the new reflection handling code (low level) for [lang].
And I've discovered that the Sun implementation (1.3.1) is screwed.
Consider:
Class A. Defines _public_ field named 'number' value 1
Class B. Subclass of A. Defines _private_ field named 'number' value 2
Interface I.
From: Henri Yandell [EMAIL PROTECTED]
1) Notifier class. I need a better name for this. Basically it's a helper
that uses reflection [used to use Notifiable interface, but I decided it
wasn't worth it, possibly wants to do both] to help a developer create an
event/listener list.
It handles
be called
isIgnoreScope().)
This adds even more complexity to the code. I know about the MethodUtils
from [beanutils], but has anyone else come up against these kinds of issues
with reflection.
Stephen
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta Commons
StringStack is now deprecated as you propose.
Stephen
- Original Message -
From: John McNally [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, October 10, 2002 10:19 PM
Subject: [collections][lang] deprecate StringStack
This class is badly named
Patch applied, thanks
Stephen
- Original Message -
From: Steve Downey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 06, 2002 6:43 PM
Subject: [collections][PATCH] CollectionUtils unused variable
In isSubCollection(), there is a List that's new'd but never used.
Patch applied, thanks
Stephen
- Original Message -
From: Steve Downey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 06, 2002 6:50 PM
Subject: [collections][PATCH]MultiHashMap unused variable
in the inner loop of values(), there's an assignment to a boolean that is
never
The checking that was in ArrayStack was insufficient anyway (you could get
around it). I've enabled nulls to be added to ArrayStack now.
Stephen
- Original Message -
From: Christopher Lenz [EMAIL PROTECTED]
why does ArrayStack refuse to push null elements on the stack (it throws
a
By my examination, UFI was added after release 2.0. Thus I have deleted it
from the main package, so the patches are unnecessary.
Personally, I don't like UFI at all, as I think its a special case of a
FilterIterator with a Predicate. But as PredicateUtils isn't in
[collections] I can't argue.
From: [EMAIL PROTECTED]
LowercaseComparator (which should be called IgnoreCaseComparator) allows
you
to compare two strings, say Eric and eric and get back that they are
the
same. This is useful when you are sorting strings that are in multiple
types of case, and you don't care about the
Patch applied, thanks
Stephen
- Original Message -
From: Steve Downey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 06, 2002 6:22 PM
Subject: [PATCH][collections]import clean up
A lot of the collections classes import elements that are not actually used,
or are used
[collections] needs a release. The code appears to be in a releasable state
(I've done some tidying tonight of odds and ends).
We are currently lacking a Release Manager however. Does anyone fancy the
job ???
Stephen
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
See http://jakarta.apache.org/site/source.html for submissions details.
toMap(Object[]) is used to initialise a Map, such as a HashMap with data.
asMap(Object[]) exposes an array as a Map, thus can't have its size changed
toMap(Object[])
is the same as
map.putAll(MapUtils.asMap(Object[]));
Life is never simpleI started applying the patch, but hit some problems
By comparison with the JDK, the method asList(Object[]) is on Arrays. Thus I
have applied the patch to ArrayUtils in [lang] instead of [collections].
toMap(Object[]) fitted fine.
When I looked at asMap(Object[]) I
I have taken a look at the patch. Unfortunately I can't use it at present
because it would involve changing the MultiMap interface. Once released, we
generally do not change interfaces.
Stephen
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October
: Stephen Colebourne, assisted by Henri Yandell
version number: 2.1
features:
Buffer interface and implementations
Primitive collections
Decorators for Predicated, Synchronized, Unmodifiable, FixedSize
collections
Much better testing
Bug fixes
Package restructuring
Better javadoc
to do
A debate has recently arrived at my doors privately from Bruce Eckel related
to the primitive collections:
Bruce has argued that the primitive method names should be the same as the
Object ones from List, and the primitive classes should thus not implement
List but a new interface
There is a good body of code here, but the GNU licence rules it out I
believe.
Stephen
- Original Message -
From: Janek Bogucki [EMAIL PROTECTED]
Here's an example of a primitive collections library which uses a separate
class heirarchy and the same method names
The exclusion plan seems to be OK.
For the primitive design, my first approach would be to start with
IntCollection and IntList interfaces and work out. I think that the
interfaces can be exactly the same as the Collection and List interfaces,
but returning/taking in ints instead of Objects.
Primitives now removed from release plan:
Please advise the list of any essential changes required by Wednesday
midnight UTC.
A vote for release should thus occur on Friday-Sunday.
Release would then follow imminently.
Stephen
release plan
release manager: Stephen Colebourne
Much of the code for getting all the superclasses and superinterfaces of a
class is coded in the upcoming [lang] reflection code. Maybe the next
collections release should depend on [lang]?
Stephen
- Original Message -
From: Michael A. Smith [EMAIL PROTECTED]
To: Jakarta Commons
+1 from me (I knew I forgot something...)
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, October 17, 2002 10:04 PM
Subject: [VOTE] Release 2.1 of commons collections
The release candidate of 2.1
[Jonathan, I have sent back to commons-dev mailing list which is the
appropriate place for design/code discussions.]
I took a quick look, and I believe that the code in the zip will work.
However, my main concern is why this would be needed. Is there a use case
for an iterator that never ends?
I
[Alex, I have replied to commons-dev mailing list as the most appropriate
place for the discussion]
Inline...
- Original Message -
From: Alex Blewitt [EMAIL PROTECTED]
I've just read the JavaDoc for EqualsBuilder V 1.0 on the Apahce
website, and have a few comments which I think you may
Are you talking about the maven checkstyle report? Or a specific projects?
Stephen
- Original Message -
From: John Keyes [EMAIL PROTECTED]
I would be interested to hear people's opinions on the resolution
of checkstyle's error reporting. There are two options, one is to
correct the
1 - 100 of 1816 matches
Mail list logo
