Add a Jackson 3 converter#4552
Conversation
6d5395d to
e7dffaf
Compare
|
Thanks! This mostly looks good from a quick check. I want to familiarize myself with this major release, but otherwise I hope to get this merged this month and released by EOY. |
e7dffaf to
4d79dea
Compare
|
I ran |
|
Mind approving the workflow once more to verify that tests now pass, @JakeWharton? |
4d79dea to
9f78f8c
Compare
I've rebased this to catch-up with the new required |
Is there still a chance to get this merged before the end of the year? |
Happy new year ping 😉 |
|
I have quit this company a few months ago so any work I do here is entirely volunteer work. I appreciate the contribution, but it'll still probably be a few weeks until I look at this project again. |
|
Hi! I'm also quite interested in this PR being merged. Is @JakeWharton the only maintainer of this project? |
|
The design of Retrofit is such that you do not need this to be merged to be unblocked. You can have your own Jackson 3 converter living in your codebase for the time being. And yes, it's basically just me. |
9f78f8c to
f6b073d
Compare
5f64562 to
64d8c19
Compare
be1740e to
8b481ce
Compare
danrebati-fujitsu
left a comment
There was a problem hiding this comment.
Looks good to me, though I am not a maintainer of this project. I'm just a passer-by 🙂
Thanks anyway for the review, you had some good findings there! |
|
when is this planned to get merged and released? |
8b481ce to
615e877
Compare
This was implicitly available as a transitive dependency, but that should not be relied on. It is required for `JsonAutoDetect.Visibility.ANY`. Note that `jackson-annotations` is versioned independently of the rest of Jackson and does not use a path-level version suffix.
This mostly copies the existing Jackson (2) converter and does the necessary migration [1]. Note that Jackson 3 requires Java 17. [1]: https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md
615e877 to
d0459e6
Compare
|
Any update on this? |
|
sorry to bother you @JakeWharton it seems (but i can be wrong) it only miss your approval to continue |
Maybe this will move forward in the context of https://jakewharton.com/the-lysine-contingency/ 🙏🏻 |
| } | ||
|
|
||
| try { | ||
| byte[] bytes = adapter.writeValueAsBytes(value); |
There was a problem hiding this comment.
In my opinion we can use a Buffer here?
There was a problem hiding this comment.
You mean like
ByteBuffer bytes = ByteBuffer.wrap(adapter.writeValueAsBytes(value));
return RequestBody.create(bytes.array(), mediaType);Why, what's the advantage?
There was a problem hiding this comment.
I mean okio.Buffer which reuses internal byte[]
There was a problem hiding this comment.
Well, I could do
ByteString bytes = ByteString.of(adapter.writeValueAsBytes(value));
return RequestBody.create(bytes, mediaType);but I still don't see the benefit, esp. as I believe ByteString.of() copies the data underneath.
If you have a different proposal, please share the exact code.
There was a problem hiding this comment.
I don't have a dev env of this repo so I can only provide following pseudo code.
var buffer = new okio.Buffer();
adapter.writeValue(buffer.outputStream(), value);
return RequestBody.create....But don't call readByteString at the end of it.
Use this (copied from my code):
private fun Buffer.asRequestBody(mediaType: MediaType) = object : RequestBody() {
override fun contentType() = mediaType
override fun contentLength(): Long = size
override fun writeTo(sink: BufferedSink) {
sink.writeAll(this@asRequestBody.copy()) // <- This is a shallow copy
}
}Well, if you want it to be simple you can ignore my comment.
|
No features will be merged until the repo is moved. Yes it's taking forever to move. |
|
Hi @JakeWharton, any timelines about this? |
|
No |
CHANGELOG.md's "Unreleased" section has been updated, if applicable.