You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Christopher Tubbs (Jira)" <ji...@apache.org> on 2021/06/09 20:27:00 UTC

[jira] [Resolved] (ACCUMULO-2300) Leaking internal state in core/client code

     [ https://issues.apache.org/jira/browse/ACCUMULO-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Tubbs resolved ACCUMULO-2300.
-----------------------------------------
    Resolution: Not A Problem

This issue is quite old and probably OBE. We now regularly run spotbugs in our builds, and have also added javadocs to many APIs to improve the situation. Some of these issues are intentional for performance. If there is something more to be done for this, please open a new issue or PR at https://github.com/apache/accumulo

> Leaking internal state in core/client code
> ------------------------------------------
>
>                 Key: ACCUMULO-2300
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2300
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.5.0
>            Reporter: Josh Elser
>            Priority: Minor
>              Labels: findbugs
>
> In perusing over the findbugs reports, I noticed that there was a fair amount of classes in the core module that were subject to leaking internal state (most commonly, returning the actual array it holds internally instead of a copy or a wrapper).
> ArrayByteSequence, Column, ColumnUpdate, ComparableBytes, KeyValue, Mutation, Value, ColumnVisibility are the classes that caught my eye.
> I would imagine that this is something we ultimately want to fix, but I'm not sure of what the timeline should be. A decent short-term would be to just return copies of those {{byte[]}} instead of the internal member. A longer-term solution might be to rework some of those classes to use an object instead (e.g. ByteBuffer) that might have constructs to provide r/o views instead of having to make a defensive copy.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)