+1 to rename crypto.utils it to .internal, and then we are somewhat free to shrink it in 1.1.
I see many things in there that could form a minimal Commons Native, e.g. to help with bundled native libraries and architecture detection. While perhaps less people deal with JNI now than 10 years ago, several Apache projects do this, e.g. Hadoop (?). (Indeed, having a tmpfs with noexec flag has broken "java" software for me, as then the extracted .so fails to load, but often without a helpful error message - so a Common code for this might help) What exists already in Java land for Native library handling? One could even expand to Android support, which does this a bit differently.. On 12 Jun 2016 12:41 p.m., "Benedikt Ritter" <brit...@apache.org> wrote: > Hi, > > looking through the code I wonder what to do with the utils package. It > looks like the typical "don't know where to put this peace of code"-dumping > ground. I think we should at least mark the whole package as internal. > Further more we should change class names: Utils, IOUtils and > ReflectionUtils just call for trouble in user code. The best would be if we > could get rid of the package completely. I'm currently trying to find out > if that's possible. > > Benedikt >
