On 28 June 2016 at 07:03, Sun, Dapeng <dapeng....@intel.com> wrote: > Thank Sebb for your great work! > > About the Properties instance, I have some personal opinions. > > I think properties provide a flexible configuration mechanism. Config values > could be added and read/written without too much limitation, we also provides > default values for each properties, user don't need set value for every > properties. They could also give null, if they want to use the default > settings.
Agreed they are flexible. >>> also the way that classes are instantiated is very awkward, as properties >>> are not as easy to use as plain variables - String/boolean etc and >>> properties don't offer any type validation. > > Properties don't offer any type validation, but we can validate the type and > value before we using them. For example, stream buffer size, when > CryptoStream is creating, it will read the value and convert it to int. > >>> Since properties are used in the constructors, it's not enough for 3rd >>> parties to just implement the CryptoRandom interface - they also have to >>> provide a constructor which takes a Properties instance. > > For 3rd parties implementations, they may need to read some configuration > when initializing, properties will provide this ability at this time. > Otherwise, they need to handle the work such as reading config file, read > config value ant etc. For the 3rd parties implementations which don't need > the properties, they can leave it null or ignore. > > If you have a better configuration mechanism, could you tell me more detail? On further reflection, I think it's not going to make the API any easier for the general case where implementation-specific values are needed. However, we could perhaps add a convenience method for the case where only the classname(s) are needed. e.g. add new methods as below: CryptoRandom getCryptoRandom(String classids) and CryptoCipher getInstance(String transformation, String classids) These would each create a Property instance and call the existing getInstance method This would not save a lot of code, but it would be simpler for the OpenSSL implementations at least. > Regards > Dapeng > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Sunday, June 26, 2016 7:53 AM > To: Commons Developers List > Subject: Re: [CRYPTO]1.0.0 Release Plan > > On 24 June 2016 at 11:17, sebb <seb...@gmail.com> wrote: >> On 24 June 2016 at 10:08, Sun, Dapeng <dapeng....@intel.com> wrote: >>> Hi all, >>> >>> Thank all for helping review CRYPTO from different angles. >>> >>> According the number of jira remaining issues, I prefer to start the thread >>> for rolling a RC at June 29th(Next Wednesday). Please feel free to let me >>> know if you have any concern about it. >> >> Yes, I do have some concerns. >> >> I think the public API needs to be better documented. >> There are still a lot of public classes that AFAICT don't really >> belong in the API. >> For example >> JceCipher >> OpensslCipher >> JavaCryptoRandom >> OpensslCryptoRandom >> OsCryptoRandom >> These need to be made private/package protected or moved into an >> internal package, or at the very least clearly documented as internal. > > I have made them package private. > >> Also the way that classes are instantiated is very awkward, as >> properties are not as easy to use as plain variables - String/boolean >> etc - and properties don't offer any type validation. >> Since properties are used in the constructors, it's not enough for 3rd >> parties to just implement the CryptoRandom interface - they also have >> to provide a constructor which takes a Properties instance. > > This is still an issue. > >> Indeed I wonder why there is a CryptoRandom interface - would it not >> be better for JavaCryptoRandom to extend java.util.Random? The other >> implementations of CryptoRandom do. >> Or maybe none of them should extend j.u.Random? > > Likewise, this ought to be resolved. > >>> Regards >>> Dapeng >>> >>> -----Original Message----- >>> From: Sun, Dapeng [mailto:dapeng....@intel.com] >>> Sent: Monday, June 06, 2016 5:14 PM >>> To: Commons Developers List >>> Subject: [CRYPTO]1.0.0 Release Plan >>> >>> Hello, >>> >>> Apache Commons CRYPTO was established at May 9, 2016[1], There are >>> presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also >>> fixed the legal issue[3]. >>> >>> With the first release, we can begin to promote CRYPTO to other Apache >>> components, like Apache Hadoop, Apache Spark, so that they can benefit the >>> higher performance improvement from Apache Commons Crypto. >>> >>> We plan the following three opening features to next release(I think it >>> should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark >>> tool[6]. Please let me know if there is anything need to be done before the >>> release. >>> >>> >>> Regards >>> Dapeng >>> >>> >>> [1] >>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CC >>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com >>> %3E [2] >>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&p >>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6 >>> [3] >>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CC >>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.c >>> om%3E [4] https://github.com/apache/commons-crypto/pull/44 >>> [5] https://github.com/apache/commons-crypto/pull/47 >>> [6] https://github.com/apache/commons-crypto/pull/1 >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
