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