Closed piovezan closed 3 years ago
Oh. A type erasure issue.
Not easy to retrieve the runtime type of T
. I guess this is why getPartType()
was needed in the first place.
Okay then, I think the issue can be closed. I'll try to deal with it some other way.
Not sure if this is a bug, a behavior that should be flexibilized, or one that should be enforced (or just kept that way).
TL;DR: Setting up a multipart POST request won't allow
field(String name, String value)
calls to receive anull
String value as it used to in older versions (I'm updating client code dependencies and don't want to break the existing server-side code).It throws
NullPointerException
instead since, although the BodyPart class constructor looks like it acceptsnull
values (nothis.value = Objects.requireNonNull(value);
is enforced, for example), it actually throws an exception when invokingthis.partType = value.getClass();
right below in the constructor.I'm no HTTP connoisseur but I don't think a non-
null
String
field value should be a requirement for multipart requests (or, in the case it is, it seems like it is being only incidentally enforced). In my opinion anull
String
value could simply be translated to an empty string when the actual request is made.It seems that it is only needed in order to return the
value
object'sClass<?>
instance ingetPartType()
, which in the case of anull
value in my opinion could be the actualT
class parameter fromBodyPart<T>
(I haven't thought out how that would translate to actual code, though). Also, I haven't cloned the repo to look for further consequences of implementing such flexibilization.To Reproduce
Resulting stack trace:
Expected behavior In my thinking, the request object should be constructed normally instead of throwing a
NullPointerException
.Environmental Data