Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <CAMBJEmXx+wjndrrCrzC9i6OpJpEzbRgz5bFLDVebV_Nuap4saQ@mail.gmail.com>
References: <CAB917R+RTT_Us9ko_qD72-H+Y-8-yzGYXKKVCu7V8zGmBr5sPg@mail.gmail.com>
 <CAMBJEmXx+wjndrrCrzC9i6OpJpEzbRgz5bFLDVebV_Nuap4saQ@mail.gmail.com>
From: sebb <sebbaz@gmail.com>
Date: Sun, 19 Jun 2016 02:16:28 +0100
Message-ID: <CAOGo0Vawhcnyx9W_53u2_UANZ62yrB8rfT6tkCrmHBCAQ_9TGQ@mail.gmail.com>
Subject: Re: [CRYPTO] Utils package
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Sun, 19 Jun 2016 01:16:34 -0000

On 19 June 2016 at 01:30, Stian Soiland-Reyes <stain@apache.org> wrote:
> +1 to rename crypto.utils it to .internal, and then we are somewhat free to
> shrink it in 1.1.

Also there are a couple of methods that are only called in one place
so should be moved to the calling class:

CRYPTO-83
CRYPTO-84

There may be others.

> 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" <britter@apache.org> wrote:

Please start a separate thread for native code discussions.

>> 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
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org