[
https://issues.apache.org/jira/browse/CASSANDRA-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711223#comment-14711223
]
Benedict commented on CASSANDRA-9901:
-------------------------------------
I completely reject that. If you insist that I perform bytecode analysis to
demonstrate that this pollutes the instruction cache, than I can do so, but I
will not separate the decision from this patch.
As far as I am concerned, making rational decisions based on likelihood of
result when there are limited resources to expend chasing down every proof is
the only sane way to perform development. Furthermore, previously we only had
_one_ such call, since the compare method _did not_ perform
{{FastByteOperations.compareUnsigned}}
> Make AbstractType.isByteOrderComparable abstract
> ------------------------------------------------
>
> Key: CASSANDRA-9901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9901
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0 beta 2
>
>
> I can't recall _precisely_ what was agreed at the NGCC, but I'm reasonably
> sure we agreed to make this method abstract, put some javadoc explaining we
> may require fields to yield true in the near future, and potentially log a
> warning on startup if a user-defined type returns false.
> This should make it into 3.0, IMO, so that we can look into migrating to
> byte-order comparable types in the post-3.0 world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
