[
https://issues.apache.org/jira/browse/ACCUMULO-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942147#comment-13942147
]
Sean Busbey commented on ACCUMULO-2487:
---------------------------------------
A side effect of the preexisting implementation is that we allowed null for all
of the other constructor arguments, but only if readFields is called before any
of the accessors are used.
I'd like to tighten up things so that null args aren't allowed. It's unlikely
that existing users are implementing their use of readFields by using something
other than the no-arg constructor.
Any objections?
> Value implementation provides conflicting statements
> ----------------------------------------------------
>
> Key: ACCUMULO-2487
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2487
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Reporter: Mike Drob
> Assignee: Sean Busbey
> Priority: Critical
> Fix For: 1.6.0
>
>
> The javadoc for the no-arg constructor for {{Value}} states that it "Creates
> a zero-size sequence." However, the implementation of get will error in this
> case.
> {code}
> public byte[] get() {
> if (this.value == null) {
> throw new IllegalStateException("Uninitialized. Null constructor " +
> "called w/o accompanying readFields invocation");
> }
> {code}
> Either we need to change the javadoc to be more explicit or change the
> behaviour of various accessors in the class. I would consider both solutions
> to be breaking of the API contract since we are changing what clients can
> expect from us.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
