...

Currently users may customize their JCas cover classes.  PEAR classpath isolation allows the use case where different customizations are present in one pipeline.  The current implementation supports this, and switches the set of JCas cover classes as Pear boundaries are crossed.  The idea of a Feature Structure being an instance of its cover class breaks down when multiple definitions of this exist.  Some ideas for fixing this.

Support parallel execution of components (if they don't depend on each other)

This would require parallel implementations of many of the internal data structures (e.g., indexes), which come at a cost, so this should be configurable, or better yet, automatically managed. 

We could even consider implementing parallel capable versions of some internal UIMA Types (Lists, arrays, and Maps if we add that).

Consider ideas from other popular big-data frameworks: Hadoop, Spark

...

(Unlikely) Making the element of the "stream" be a new CAS - replacement for CAS Multipliers. Seems like the wrong granularity...  Maybe best to let Java evolve this for a few more releases. 

New packaging support using component boundaries

Some new capabilities may benefit from specifying boundary actions.  Some possible actions:

• If a component defined some customization of JCas for some types, and we implement this via hooks, the hooks could be inserted/withdrawn at the boundaries.  This is similar to switching JCas implementations at PEAR boundaries, but applies outside of PEARS and on finer grain size (e.g., just one component).

Additional capabilities

Integration with popular component reuse systems (e.g., Maven)

...