hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Volodymyr Kyrychenko (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HTTPCORE-400) ContentType.equals & hashCode are not implemented
Date Thu, 23 Apr 2015 14:19:38 GMT

    [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message