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

feat: $V for inlined values in generated code #999

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Christopher-Chianelli
Copy link

If you have an instance you want to put inside
the generated code, and you trust it, you can
use the new "$V" argument spec to tell JavaPoet
to generate a Supplier lambda to construct the
object and immediately call it.

Design questions:

  • Is $V an appropriate name for the argument spec?
  • Currently, users need to explicitly register types as trusted, since serialization/deserialization of arbitrary objects is generally unsafe (although the code only calls getters/setters, it still counts). However, this might be too paranoid.
  • There is support for inlining records; Records are accessed exclusively using reflection, and Record.class is never loaded (check is done using Class.getName. However, since this project uses Java 8, it is hard to add a test for it. This can be removed; a user could add their own Record inliner if needed using addTypeInliner.
  • A helpful error message is thrown if generating code fails for any reason (untrusted type, missing public no-args constructor, or missing public setters for non-public instance fields ).

Closes #968

If you have an instance you want to put inside
the generated code, and you trust it, you can
use the new "$V" argument spec to tell JavaPoet
to generate a Supplier lambda to construct the
object and immediately call it.
Previously, if multiple threads were inlining using the same
ObjectInliner, the internal state of the inliner would be corrupted.
This is fixed by creating a new ObjectEmitter whenever a value is
being inlined; the ObjectEmitters created from an ObjectInliner
are completely independent and thus cannot be corrupted by
multithreaded use. Also undos the unneccessary NameAllocator
change, update the API for TypeInliner, and adds more tests
for custom inlining.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Construct transparent objects
1 participant