Hi All, This might be OK for 1.0 (with no Windows support) but I want to make sure we are all on the same page because it seems incredibly complicated and perhaps too clever.
The delivered jar file contains a native .so file, and this .so file is _extracted_ and _installed_ on the user's machine at runtime? See NativeCodeLoader.extractLibraryFile(). Does this mean that the jar will contain all possible native formats (.so, .dll, what about 32 vs. 64 bit, or are we only dealing with 64 bit?) and extract the right one at runtime for the current platform? Seems wasteful in space but portable and clever. Or, will there be a jar built with an .so file in it and a different jar built with a .dll in it (and 32 vs. 64 bit)? Depending on the choice, we need different maven coordinates to accommodate all the jar-file-contains-a-single-native-file combinations. In Commons-Deamon we also deliver native files, not embedded in jar files, but on the side. Gary On Thu, Jul 7, 2016 at 10:51 PM, Sun, Dapeng <dapeng....@intel.com> wrote: > Hi all, > > Please let me know if there is any blocks need to be resolved before the > release. > > Regards > Dapeng > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Tuesday, June 28, 2016 6:48 PM > To: Commons Developers List > Subject: Re: [CRYPTO]1.0.0 Release Plan > > 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/%3C > >>> C > >>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.co > >>> m > >>> %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/%3C > >>> C > >>> 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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
