Formal proposal for features changes

[Joseph Ottinger]

In light of thinking about jsr107 earlier... I would like to offer that we retract JSR107 compliance as a requirement.

This affects a number of the proposed features. To wit:

1. Alternatives to JSR 107 Cache - proposed returning Future<V> instead of V. This allows us to focus more on our own APIs without the constraints of JSR107; analogs would still be acceptable, of course, and I have no objection to the concept as it stands. But JSR107 compliance and inspiration is not relevant; I would suggest that compliance with Java SE's streaming features would be far more important and serve as a better starting point.

2.1 Infinispan is a fine API, but again, I think we would enable leverage far better by using the Streaming API. (This is in accordance with 2.2.)

4. This section asserts that JSR107 asserts CDI-compliant behavior; good on 'em, but we need the feature apart from JSR107.

5. There are a lot of JSR107-leaning features here, which I don't think are entirely relevant and will, instead, serve as a bit of an albatross, especially in light of 2.2.

5.3, in particular, requires drop-in replacement for JSR107 cache, which would be entirely irrelevant.

Section 7 would be affected drastically (and positively) by the SE8 lambda and streaming APIs.

--
Joseph B. Ottinger
http://enigmastation.com

Memento mori.