In JAVA-3879, we implemented aggregation expressions using the chaining pattern. This pattern differs from the implementation of the the existing aggregation stages, which do not use a chaining approach.

Creating chained implementations of the aggregation stages would a) make the API as a whole more consistent, b) remove the need for "glue" like `current()`, and c) would allow users to take advantage of the "debug" API for development. The negative effect is that this would introduce a second API, which we would need to commit to.

An example of the API:

List<Diagram> results = diagramsCollectionObject
        .debug()
        .addField("area", d -> d.shapes
                .map(shape -> shape.w.multiply(shape.h))
                .sum(v -> v))
        .filter(d -> d.area.gt(of(10)))
        .stage(Aggregates.count())
        .toList(); 

This performs an aggregation on a collection of diagrams, with shapes. It adds a field to the diagram, filters on that field, and then counts the results.

I used a "toList" method in the POC for convenience. The "debug" method enables stage-level debugging, via $documents, of the aggregation chain. The "stage" method accepts the existing BSON stages. For example, "addField" is implemented as:

return stage(Aggregates.addFields(new Field<>(fieldName, in.apply(getCurrent())))); 

This removes the need for "current()", since in the example, current is "d", just as each shape item under "map" is represented as "shape". The above example also uses schema classes (JAVA-5081) to save on "getField" calls.