+1, when I see tickets like https://java.net/jira/browse/JSON_PROCESSING_SPEC-72 it makes me crazy. Of course there are the LOC but the main point is enable vendors to do their job vs just doing one implementation in javax.* which kind of break the whole spec beauty and richness. Only tolerated code for the spec itself should be 1. the provider loading (we can't help it) 2. the delegation to the provider 3. (tolerated but shouldnt) helper method fully delegating to others like Json.createReader(r). Any other implementation, even trivial, locks the vendors.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-11-23 10:15 GMT+01:00 Mark Struberg <[email protected]>: > Hi Folks! > > I found quite a few bits in the JSON-P 1.1 spec which I think should get > discussed again. > Thus I will create tickets over there so we can better track what got > changed. > > Here are a few resources > > Official bug tracker: > https://java.net/jira/browse/JSON_PROCESSING_SPEC > > An inofficial source mirror (used by the EG): > https://github.com/json-processing-inofficial/jsonp > > Our own spec jar: > https://svn.apache.org/repos/asf/geronimo/specs/trunk/ > geronimo-json_1.1_spec > > The EG mail archives: > https://java.net/projects/json-processing-spec/lists > > > hope that helps. > > txs and LieGrue, > strub
