Some Iterator- and Iterable-implementations (FilteredIterable, FilteredIterator) are adapted to null-filters/mappers/delete-hooks while others (CustomDeleteIterator, FilteredSpliterator) aren't. If they aren't adapted, they do not throw in the corresponding setters/constructors (CustomDeleteIterator, FilteredSpliterator) but crash later.
Algorithms::callIf and Algorithms::applyIf have different null-value tolerances although they belong to the same group
The API must be harmonised among the entire Project:
As Iterables and Algorithms extensively use and produce nulls. there should probably be factory methods that only create Decorators if given filters/hooks are not null. The mappers must always be not null, as there is no default way of converting an element T to R.
The constructors/setters in the Decorators themselves should throw upon null values.
Status Quo:
FilteredIterable,FilteredIterator) are adapted to null-filters/mappers/delete-hooks while others (CustomDeleteIterator,FilteredSpliterator) aren't. If they aren't adapted, they do not throw in the corresponding setters/constructors (CustomDeleteIterator,FilteredSpliterator) but crash later.Algorithms::callIfandAlgorithms::applyIfhave different null-value tolerances although they belong to the same groupThe API must be harmonised among the entire Project:
IterablesandAlgorithmsextensively use and produce nulls. there should probably be factory methods that only create Decorators if given filters/hooks are not null. The mappers must always be not null, as there is no default way of converting an element T to R.