{"action":"created","issue":{"url":"https://api.github.com/repos/elastic/elasticsearch/issues/11895","labels_url":"https://api.github.com/repos/elastic/elasticsearch/issues/11895/labels{/name}","comments_url":"https://api.github.com/repos/elastic/elasticsearch/issues/11895/comments","events_url":"https://api.github.com/repos/elastic/elasticsearch/issues/11895/events","html_url":"https://github.com/elastic/elasticsearch/issues/11895","id":91325830,"number":11895,"title":"Use only Jackson in favor of XContent?","user":{"login":"mtraynham","id":5741321,"avatar_url":"https://avatars.githubusercontent.com/u/5741321?v=3","gravatar_id":"","url":"https://api.github.com/users/mtraynham","html_url":"https://github.com/mtraynham","followers_url":"https://api.github.com/users/mtraynham/followers","following_url":"https://api.github.com/users/mtraynham/following{/other_user}","gists_url":"https://api.github.com/users/mtraynham/gists{/gist_id}","starred_url":"https://api.github.com/users/mtraynham/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mtraynham/subscriptions","organizations_url":"https://api.github.com/users/mtraynham/orgs","repos_url":"https://api.github.com/users/mtraynham/repos","events_url":"https://api.github.com/users/mtraynham/events{/privacy}","received_events_url":"https://api.github.com/users/mtraynham/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/elastic/elasticsearch/labels/:Java%20API","name":":Java API","color":"009800"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-06-26T18:18:55Z","updated_at":"2015-07-10T11:00:31Z","closed_at":"2015-07-10T11:00:30Z","body":"I've been using the Java API recently to dynamically generate different types of index mappings for particular use cases and indices.  I found myself implementing POJO's that simulate what XContent parses and using Jackson to produce JSON for the ElasticSearchClient.\r\n\r\nI see that XContent uses parts of Jackson under the covers, but I'm a little lost on why most of the endpoints don't just parse POJO objects that may be shared with the Java API.  Not to mention, it seems like some of the other data formats that Jackson has would be useful, such as Avro.\r\n\r\n*Edited this after some more investigation.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/elastic/elasticsearch/issues/comments/120385415","html_url":"https://github.com/elastic/elasticsearch/issues/11895#issuecomment-120385415","issue_url":"https://api.github.com/repos/elastic/elasticsearch/issues/11895","id":120385415,"user":{"login":"spinscale","id":667544,"avatar_url":"https://avatars.githubusercontent.com/u/667544?v=3","gravatar_id":"","url":"https://api.github.com/users/spinscale","html_url":"https://github.com/spinscale","followers_url":"https://api.github.com/users/spinscale/followers","following_url":"https://api.github.com/users/spinscale/following{/other_user}","gists_url":"https://api.github.com/users/spinscale/gists{/gist_id}","starred_url":"https://api.github.com/users/spinscale/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/spinscale/subscriptions","organizations_url":"https://api.github.com/users/spinscale/orgs","repos_url":"https://api.github.com/users/spinscale/repos","events_url":"https://api.github.com/users/spinscale/events{/privacy}","received_events_url":"https://api.github.com/users/spinscale/received_events","type":"User","site_admin":false},"created_at":"2015-07-10T11:00:30Z","updated_at":"2015-07-10T11:00:30Z","body":"one of the reasons, that we do not use POJOs, is that this would require serialization/deserialization up front and possibly create big objects in memory. This would not be GC friendly.\r\n\r\nFor example, take an elasticsearch query. Instead of having to pass the pojo to the different query parser (one for a filtered query, one for a geo shape query, etc.. one for each type), we can just pass the xcontent parser and read through it step by step.\r\n\r\nAs you already mentioned, the `XContent` stuff is just a small layer on top of JSON to simplify the handling of streaming data. Due to this, it is not really easy to create POJOs out of this at this layer and you need to do that in your client code.\r\n\r\nAs you can see in our `pom.xml` dependencies, we already use the `jackson-dataformat-smile`, `jackson-dataformat-yaml` and `jackson-dataformat-cbor` libraries. Because of the `xContent` abstraction it is really easy for us to support different formats and also extract the format being used in the data sent to elasticsearch (one of the reasons why we can index data in YAML format as well as read JSON configuration files). You may be able to extend the xcontentparsers to also support avro without the need to bind to a POJO by using the `jackson-dataformat-avro` library...\r\n\r\nI will close this ticket though, as we will not change our approach here. Hope this helps."}}