Add exporter data model impl for profiling signal type. #6498
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Second step towards supporting the new experimental signal type for profiling...
Following on from the interfaces in #6374 this adds the AutoValue generated implementation classes. Less to discuss here, it's much more straightforward than the interfaces!
Still no test coverage, since most of the code is auto generated anyhow. For other similar classes the test coverage is indirect via the Marshaler tests, which for these classes won't be along until the next PR. Meanwhile codecov will probably continue to sulk.
The ByteBuffer use in ProfileContainerData presents a challenge. For other similar cases, the mutable object could be wrapped during the static create(...) call with e.g. Collections.unmodifiableList, such that the auto-generated getter can simply return the immutable wrapper. That pattern doesn't work with .asReadOnlyBuffer() since the resulting wrapper object is not immutable, though the content is. For now I've gone with adding an extra getter, as AutoValue won't support overriding the default one. The usability of the resulting API isn't great, but perhaps adequate as the only real use case is the Marshalers and they use it correctly. The alternative design is to disable AutoValue for that class and hand-tool all the getters, but that increases maintenance and cognitive load.