Which library implementation to use/work on?

Wed May 30 21:14:00 GMT 2012

Sorry Bryce, +mailing list ...
On Wed, May 30, 2012 at 11:13 PM, Mike Hearn <mike@plan99.net> wrote:
> Ugh, mailing lists that reject HTML ...
>> OK, looks like GMP does indeed implement "next probable prime". All
> that's required is plumbing it through.
>>> One step forward, one step back.
>>>> I recently upgraded to the latest Bouncy Castle. It now contains an
>> implementation of "NTRU", an obscure crypto system that is theoretically
>> resistant to quantum computer attacks.
>>>> Unfortunately the NTRU library uses BigInteger.nextProbablePrime(), which
>> is not implemented. I don't know if the GNU biginteger library makes it easy
>> to support this, so will take a quick look at how easy it is to expunge NTRU
>> from Bouncy Castle.
>>>> On Tue, Apr 10, 2012 at 5:53 PM, Mike Hearn <mike@plan99.net> wrote:
>>>>>> I finally got there, w00t! It turned out to be easier to switch to the
>>> "lite" versions of BouncyCastle and protobufs than to upgrade
>>> classpath, so that's what I did, and now I have a spiffy CNI exposed
>>> API that can be used from C++, which is what I was after. Thanks!
>>>>>> On Sun, Apr 8, 2012 at 3:18 PM, Mike Hearn <mike@plan99.net> wrote:
>>> > Thanks, I got it to work eventually. That switch disables building of
>>> > ecj so I had to first compile without it, then install, then adjust my
>>> > path, then reconfigure/make/make install - bit confusing.
>>> >
>>> > I then encountered a couple of other issues. Firstly it seems there's
>>> > something odd about the Google protocol buffers library that gcj does
>>> > not like:
>>> >
>>> > com/google/protobuf/SingleFieldBuilder.java: In method
>>> >
>>> > 'com.google.protobuf.SingleFieldBuilder.mergeFrom(com.google.protobuf.GeneratedMessage)':
>>> > com/google/protobuf/SingleFieldBuilder.java:192:0: error: class
>>> > 'com.google.protobuf.GeneratedMessage' has no method named
>>> > 'getDefaultInstanceForType' matching signature
>>> > '()Lcom/google/protobuf/Message;'
>>> >
>>> > The code is some morass of generics so it's hard for me to figure out
>>> > what the issue is here. The relevant code is:
>>> >
>>> > public class SingleFieldBuilder
>>> >    <MType extends GeneratedMessage,
>>> >     BType extends GeneratedMessage.Builder,
>>> >     IType extends MessageOrBuilder>
>>> >    implements GeneratedMessage.BuilderParent {
>>> >
>>> >  ....
>>> >  private MType message;
>>> >
>>> >  public SingleFieldBuilder<MType, BType, IType> mergeFrom(
>>> >      MType value) {
>>> >    if (builder == null && message ==
>>> > message.getDefaultInstanceForType()) {
>>> >      message = value;
>>> >    } else {
>>> >      getBuilder().mergeFrom(value);
>>> >    }
>>> >    onChanged();
>>> >    return this;
>>> >  }
>>> > }
>>> >
>>> > Sure enough the GeneratedMessage class doesn't have
>>> > getDefaultInstanceForType - it's implemented by subclasses.
>>> >
>>> > GeneratedMessage says this at the top:
>>> >
>>> >
>>> > /**
>>> >  * All generated protocol message classes extend this class.  This
>>> > class
>>> >  * implements most of the Message and Builder interfaces using Java
>>> > reflection.
>>> >  * Users can ignore this class and pretend that generated messages
>>> > implement
>>> >  * the Message interface directly.
>>> >  *
>>> >  * @author kenton@google.com Kenton Varda
>>> >  */
>>> >
>>> > I suspect the reference to "implementing most of the interfaces using
>>> > reflection" is key. I don't know what that means exactly, the class is
>>> > very large and complicated:
>>> >
>>> >
>>> > http://code.google.com/p/protobuf/source/browse/trunk/java/src/main/java/com/google/protobuf/GeneratedMessage.java
>>> >
>>> > I switched to the "lite" runtime which is simpler and the issue went
>>> > away.
>>> >
>>> > The next problem is more stubs in classpath: specifically the elliptic
>>> > curve related classes in java.security.spec. I'm already using
>>> > BouncyCastle to implement the EC crypto - these classes are literally
>>> > just data structures. They're probably quite trivial to do.
>>> >
>>> > I'll try copying the equivalent code from openjdk and see if that
>>> > works.
>>>>