I'm thinking of programming a wrapper for an Enumeration or Iterator,
FilteredEnumeration or FilteredIterator respectively, which filters the
objects passing through it. Each would be a sub-class of the
corresponding API class. Each wrapper class would of course override
the two or three methods of the corresponding API class, simply calling
the API method repeatedly until the filter criterion is satisfied or
there's nothing next. These could be chained to filter on more than one
condition.

For example, you could filter according to membership in
some class per the following constructor:

 FilteredEnumeration(Enumeration en, Class cl, int inheritMode,
                     int filterMode)

cl can be a class or an interface

inheritMode = EXACT_MATCH | ANY_SUBCLASS
filterMode = ASSERT_MATCH | DISCARD_NON_MATCH | DISCARD_MATCH
(mode ASSERT_MATCH throws an exception if object doesn't match)

For another example, you could filter on an arbitrary predicate that
takes one parameter of type Object, the predicate of course being a
Method:

 FilteredEnumeration(Enumeration en, Method predicate)
 static boolean predicate(Object | someClass)

predicate can be any static method of signature  boolean <method>(Object)
If en is a FilteredEnumeration using ASSERT_MATCH or DISCARD_NON_MATCH
and with cl = someClass1, then predicate can be any method whose
signature is  static boolean <method>(someClass2)  where someClass2 is
the same class or any super-class of someClass1.

Does anybody know of such a filter already implmented and freely
available, or can I safely program it without having to worry I'm
re-inventing the wheel?

Also, I have a technical question. I'm thinking of compiling a library
of static methods which use (*) only well-known classes. If the source
code is available, then a whole bunch of such selected static methods
could be appended into one big java source file and compiled with no
problems to create a custom utility-library class suitable for small
machines where you can't afford to have the entire class that each
static method came from, or if each method costs money and you don't
need them all so don't want to pay for them all. But what if the source
isn't available? Is it possible to find a static method within a class
object, clone it, and put the clone into a custom-library class being
built, without any problems? I'm thinking that a static method is
basically unrelated to the class it's in, so it can be copied from
there and pasted anywhere else without problem, but did I overlook
something?

* (To "use" a class means to accept parameter which is instance of that
  class, or use local variable or temporary value which is instance of
  that class, or call static method of that class, or return object
  which is instance of that class.)

So I'm thinking of a net-accessible database which indexes zillions of
different static Java methods and allows people to download any
specific method they need for their particular application.

This contrasts with instance methods and constructors, where if you
want to make any use of objects which are instances of somebody's
custom class, you probably want to download the entire class as a unit
rather than try to break it apart. So for that usage the database would
list each complete class as a single unit rather than having separate
entries for each method. (Of course it would still *document* each
public method individually so you could see if the class had what you
wanted before downloading.)

Has anybody already set up a per-single-static-method library like
that, or can I safely go ahead and implement it without "re-inventing
the wheel"?

Back to my first idea above: I'm thinking that each constructor for
different kind of filtered enumeration/iterator is really constructing
a different kind of object, so each such constructor, and the two or
three corresponding methods (hasNext, next, delete), should be in a
separate class, all of which are sub-classes of the interface
FilteredEnumeration or FilteredIterator. But an interface can't be a
sub-class of a regular class, right? So maybe I have to turn this
around backwards and instead of using a constructor I need to have a
set of static methods which are factories for constructing objects
which really are each instances of sub-classes of Enumeration or
Iterator, but all the user needs know is that the source code can
declare the variable (holding the return value from the factory) to be
of type Enumeration or Iterator and inheritance works correctly to pick
the appropriate override of hasNext/next/delete in each case. The user
of my API never need know that the actual objects are of classes named
ClassFilteredEnumeration or PredicateFilteredEnumeration etc. So
anyway, these factories for making custom objects of sub-classes of
Enumeration or Iterator, would *not* satisfy the criterion for
membership in the per-method database, because their return value is
not of a well-known type, so the user would need to download the entire
class consisting of one factory and two or three methods to be used on
the return value of the factory. But at least by using static factory
methods instead of constructors, the names can all be the same even
though each is in a different class. (There really is a
differently-named constructor for each class, but those are private
constructors, so the users never need be aware they're included in the
downloads.)

Oh, one last: The factor would be called MakeFilteredEnumeration
or MakeFilteredIterator, of course.