[
https://issues.apache.org/jira/browse/ACCUMULO-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840413#comment-13840413
]
Bill Havanki commented on ACCUMULO-1958:
----------------------------------------
I'd be OK with leaving out the range check in 1.6.0 as long as the method is
deprecated, since that's a flag to users that it's dangerous, and users will
likely need to make code changes for 1.6.0 and can take the opportunity to move
away from it.
For 1.4.x and 1.5.x, though, I think we'd need to add the range check. Even if
we deprecate it there too, users won't be expected to rebuild moving from 1.x.y
to 1.x.(y+1), so they'll continue using the constructor. In that case, it's
tantamount to a bug fix.
I'm unsure, since I don't know fully the compatibility promises and standards
for Accumulo across versions.
> Range constructor lacks key checks, should be non-public
> --------------------------------------------------------
>
> Key: ACCUMULO-1958
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1958
> Project: Accumulo
> Issue Type: Bug
> Affects Versions: 1.4.0
> Reporter: Bill Havanki
> Fix For: 1.7.0
>
>
> This ticket pertains to the Range class constructor with the following
> signature:
> {noformat}
> public Range(Key, Key, boolean, boolean, boolean, boolean)
> {noformat}
> The constructor does not check that the start key is before the end key, like
> every other constructor in the class. Since the constructor is public, this
> makes it possible for a caller to create invalid ranges.
> The constructor is used by other constructors that take in existing range
> objects, where the key check has implicitly been done, and so it would make
> sense to skip the check in this one, but then the constructor visibility
> should be at least protected.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
