Honnix
Honnix
So something like? ``` ... static RoomBuilder builder() { return new RoomBuilder().id("foo"); } ... ```
So if I understood correctly. ``` @AutoMatter public interface Room { String id(); // default method called if value not set @DefaultValueOf(property = "id") default String defaultId() { return "foo";...
That lib looks very capable! Yeah we don’t need a separated method. Having an annotation telling automatter that this is a property default method instead of any other user defined...
@yschimke Thanks for looking into this. Could you please help me understand how #7354 fixes this issue? As I understood #7354 creates a dependency from `okhttp` to `okhttp-jvm` so current...
OK I see https://square.github.io/okio/changelog/#version-320 (https://github.com/square/okio/pull/1125) has a similar change. So maybe you could release 4.10.1 to depend on `okio-3.2.0` instead of `okio-jvm-3.0.0`?
Thank you so much! Looking forwards to a new release. Also thanks for working on the workaround to help users migrate.
Just to confirm, this will end up with depending on `okio`, not `okio-jvm`, right?
> @yschimke any thoughts on forcing a non `-jvm` dependency for Maven users? I think it’s probably worth the trouble so Maven users get the right artifacts no matter what...
The idea I think is, as long as okhttp depends on okio (non -jvm one), no matter what okio version user explicitly depends on, it would still be the same...
@JanWielemaker Thanks and t's not urgent at all.