I recently spoke with Gavin King (spec lead for JSR-299) about this JSR. In addition to getting his agreement on both Matthias and James to be on the EG, we talked a bit about their (Red Hat's) plans for the RI and TCK. Their thinking is that the RI and TCK would be developed by Red Hat themselves (since they are the company responsible for providing it) under some reasonable open source license ... but Gavin would actually like it if there was a second implementation being developed at the same time. That kind of thing goes a long way towards catching design limitations and/or ambiguities in the spec as it's being developed.
So, I've got a question for us ... would we be interested (now or later) in building *a* compatible implementation of this JSR, even though it wouldn't be *the* RI? Instead, it would be a feature of Shale in addition to all the other stuff we do. I'm pretty intrigued by this, and the ideas that JSR-299 wants to deal with fit pretty nicely with what we've already started. It would make sense for us to have this kind of functionality available inside Shale. If we go this way, this seems like a good candidate for the sandbox during development (since we wouldn't be able to ship a finished release of it until the spec goes final). What do you think? Are we interested in putting this on our roadmap? (And following up +1s with code? :-) Craig PS: Another JSR we should keep an eye on is 303 (common annotations for validation) that Jason recently submitted. If it gets accepted, we'll likely want to support the result in Shale as well.
