Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for generation of java .class files from Ion Schema. #146

Open
abhijit10m opened this issue May 19, 2020 · 2 comments
Open

Add support for generation of java .class files from Ion Schema. #146

abhijit10m opened this issue May 19, 2020 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@abhijit10m
Copy link

abhijit10m commented May 19, 2020

  • We presently use ION schemas to validate incoming ion documents.
  • We have a data transform use case where we are extracting data from multiple sources (CSV, DynamoDB, wikis, etcs) and would like to convert all of that to ion documents. We would also like to keep the transformation logic across multiple tools updated for changes made to the ion schema. Presently, we need to ensure that the transformation logic is updated whenever the underlying schemas are updated.
  • With automated class definition generation in place, it would be possible for us to simplify the transformations. We would also be able to implement build verification tests that fail when there is incompatibility between the schema and the corresponding Java tools.
@abhijit10m abhijit10m changed the title Add support for generation of POJOs from Ion Schema. Add support for generation of java .class files from Ion Schema. May 19, 2020
@pbcornell
Copy link

Thank you, Abhijit--this certainly sounds useful, and is effectively the inverse of #89.

Capturing a few additional thoughts:

  • open content: care should be taken to avoid generating code that drops open content (e.g., copy known fields from an Ion struct to fields of a POJO, then discard the struct--open content is lost; one alternative is to preserve the original Ion struct and have the getters/setters operate on the struct)
  • annotations: similarly, annotations should somehow be preserved
  • POJO vs. POJI: we should consider tradeoffs between generating POJOs or POJIs (plain-old Java interfaces) with a generic java.lang.reflect.Proxy impl
  • would generated setters be expected to perform additional validation based on the schema's constraints for a field?
  • some valid ISL presents interesting questions, e.g.: if a struct field is constrained by not: string, what should be generated?
  • proper handling of imports and the type constraint should be considered
  • http://www.jsonschema2pojo.org/ may provide some helpful ideas for such a feature

@popematt
Copy link
Contributor

I had an offline conversation with an Ion user who wants to generate POJOs that have annotations for controlling how the POJO gets serialized/deserialized by Jackson.

We should consider providing an API in this tool that would allow users to inject their own framework-specific code into the POJO generation process to support this and other use cases that require specific annotations on POJOs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants