10471944bd
Avoid the pattern where a Random object is allocated, used once or twice, and then left for GC. This pattern triggers warnings from some static analysis tools because this pattern leads to poor effective randomness. In a few cases we were legitimately suffering from this issue; in others a change is still good to reduce noise in analysis results. Use ThreadLocalRandom where there is no requirement to set the seed to gain good reuse. Where useful relax use of SecureRandom to simply Random or ThreadLocalRandom, which are unlikely to block if the system entropy pool is low, if we don't need crypographically strong randomness for the use case. The exception to this is normalization of use of Bytes#random to fill byte arrays with randomness. Because Bytes#random may be used to generate key material it must be backed by SecureRandom. Signed-off-by: Duo Zhang <zhangduo@apache.org> |
||
|---|---|---|
| .. | ||
| src | ||
| README.txt | ||
| pom.xml | ||
README.txt
ON PROTOBUFS
This maven module has core protobuf definition files ('.protos') used by hbase
REST that ship with hbase core including tests. The protobuf version
they use can be distinct from that used by HBase internally since HBase started
shading its protobuf references. REST Endpoints have no access to the shaded protobuf
hbase uses. They do have access to the content of hbase-protocol -- the
.protos found in here -- but avoid using as much of this as you can as it is
liable to change.
Generation of java files from protobuf .proto files included here is done as
part of the build.