I realise that solving the same problems over and over again can be counter productive and can sometimes even lead to bugs being introduced, but I think there is good value in it from a personal development and learning perspective. Bugs can be fixed and even frameworks have bugs that need fixing. More importantly though, it highlights the need to have specific low level solutions like these integrated into the core language API. That way we wouldn’t have to recode them or look for them in other frameworks.

By trying to solve problems using the core API first, we can better identify key missing features and propose to have them added to the language instead of just implementing them in frameworks. That would create a win-win situation for all programmers. Frameworks could then focus on solving the more higher level problems.

I have since corrected the problems identified in the above comments.

Do you know how many people code and recode the same algorithms over and over?

Do you know that they are wasting precious time and at the same time introducing subtle bugs that will take months if not years to detect?

I know this post will not change things, people will code and recode things that are already written in libraries just for the sake of it, because it is so much fun to code, but it is a shame on the profession.

Do you imagine you ask someone to build your house and instead of them buying standard bricks, try to invent how to create bricks, then how to create hammers, … If you saw that you would be very upset, but in the software development world this attitude is considered correct.

I do not mean we should build prototypes, and if you want to create your own database engine, be my guest, but please first read about the subject and do it own your time. When the thing works, come to show to it to me and make sure I’m saving a lot of time because of your invention!!! ;-D

A couple of questions:

1) I would have expected that the yield(..) method in IteratorAdapter would be abstract – any reason not to do this?

2) It appears that if a collection is passed to the constructor, then the remove() method will not behave as expected – ie the object will not be removed from the original collection.

WarpedJavaGuy – 12 August, 2007

Stephen,

1) The yield method is not abstract because I wanted the adapter to yield all items by default if no methods are overridden.

2) Oops, the constructor that accepted a collection did have that problem. I have removed that constructor. It would be nice to be able to support any type of collection, but it is not very viable with a list based solution like this one.

(PR.. PR…)

For example if the first element in your collection should not be returned (means should be filtered) but you do not call hasNext() it will be returned by next().

WarpedJavaGuy – August 12, 2007

I have never used iterators in that way, but you are right in that the standard Java iterators do allow it.

I have updated the code to support it.

The ability to yield is just one example of a simple yet powerful mechanism that would be useful to have in Java.

I’m sure there are many other similar abstractions that others have discovered and used in their projects and programs.
I’d like to know how they are being reused.