[
https://issues.apache.org/jira/browse/HTTPCORE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509114#comment-14509114
]
Volodymyr Kyrychenko edited comment on HTTPCORE-400 at 4/23/15 2:18 PM:
------------------------------------------------------------------------
rfc2045
The Content-Type header field specifies the nature of the data in the body of
an entity by giving media type and subtype identifiers, and by providing
auxiliary information that may be required for certain media types. After the
media type and subtype names, the remainder of the header field is simply a set
of parameters, specified in an attribute=value notation. The ordering of
parameters is ___not___ significant.
Current implementation is in violation of common java practice.
ContentType.parse("application/json").equals(
ContentType.parse("application/json")) == false
It cannot be used with collections relying on hashCode. It cannot be used in
reflection that is not aware of particular types. It cannot be used with
collections classes relying on equals. So in general it cannot be reliably used
with any of the JRE classes.
Current Implementation has Constants like ContentType.APPLICATION_JSON. They
make no sense since they could not be compared to anything that is parsed from
protocol.
ContentType.APPLICATION_JSON.equals(ContentType.create("application/json",
Consts.UTF_8)) == false; !!!
ContentType is defined as Serializeable but after serialization it becomes not
equal to itself.
Are you really saying that it is a good style and correct implementation?
Not regarding your disagreement about attribute order current implementation
violates whole rfc. It just compares references which has no useful meaning at
all.
was (Author: razer):
rfc2045
The Content-Type header field specifies the nature of the data in the body of
an entity by giving media type and subtype identifiers, and by providing
auxiliary information that may be required for certain media types. After the
media type and subtype names, the remainder of the header field is simply a set
of parameters, specified in an attribute=value notation. The ordering of
parameters is ___not___ significant.
Current implementation is in violation of common java practice.
ContentType.parse("application/json").equals(
ContentType.parse("application/json")) == false
It cannot be used with collections relying on hashCode. It cannot be used in
reflection that is not aware of particular types. It cannot be used with
collections classes relying on equals. So in general it cannot be reliably used
with any of the JRE classes.
Current Implementation has Constants like ContentType.APPLICATION_JSON. They
make no sense since they could not be compared to anything that is parsed from
protocol.
ContentType.APPLICATION_JSON.equals(ContentType.create("application/json",
Consts.UTF_8)) == false; !!!
Are you really saying that it is a good style and correct implementation?
Not regarding your disagreement about attribute order current implementation
violates whole rfc. It just compares references which has no useful meaning at
all.
> ContentType.equals & hashCode are not implemented
> -------------------------------------------------
>
> Key: HTTPCORE-400
> URL: https://issues.apache.org/jira/browse/HTTPCORE-400
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Reporter: Volodymyr Kyrychenko
>
> Since equals and hashCode are not implemented it's impossible to use them in
> handful of cases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
