This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Which library implementation to use/work on?
- From: Mike Hearn <mike at plan99 dot net>
- To: Bryce McKinlay <bmckinlay at gmail dot com>, GCC Java <java at gcc dot gnu dot org>
- Date: Wed, 30 May 2012 23:13:48 +0200
- Subject: Re: Which library implementation to use/work on?
- References: <CANEZrP2XyFGg2G-MbNQg5Jeh+Zr5U0BO0Qw9zsZYR3GB8mu3_Q@mail.gmail.com> <4396cf72-3914-4b1f-a00e-92c94512d2f8@zmail17.collab.prod.int.phx2.redhat.com> <CANEZrP0f7QZCbesnCsHoHW=W2sMzfSsMwZwdfNjao1Jyru_7Vw@mail.gmail.com> <CALUNu-rKCMdSpzNw2rbkB7vc8rgvMb9vp9-f_3AidMVTObfjwg@mail.gmail.com> <CANEZrP3BErQkT+TyJ3i4fNcaRz6tce5mGimAyK851qjC7NcHcA@mail.gmail.com> <CANEZrP0bY0FQOZVKEErxvwpuMAf3rxgjaWsWnAwn6mhGqJArOA@mail.gmail.com> <CANEZrP2ukT8zjNjma9yBREJ6wEuhdU6Qb=bPSOjemTYjzwrH5g@mail.gmail.com> <CANEZrP0QcpHjxKHWoi=A8+CcE2gPzm2_eO4_PG5=BmMHj-f_+Q@mail.gmail.com>
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.
>>
>>