From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27586 invoked by alias); 10 Apr 2012 15:53:41 -0000 Received: (qmail 27572 invoked by uid 22791); 10 Apr 2012 15:53:39 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_GC X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 15:53:25 +0000 Received: by wera1 with SMTP id a1so3767516wer.20 for ; Tue, 10 Apr 2012 08:53:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.81.135 with SMTP id a7mr8242529wiy.16.1334073203977; Tue, 10 Apr 2012 08:53:23 -0700 (PDT) Received: by 10.216.230.218 with HTTP; Tue, 10 Apr 2012 08:53:23 -0700 (PDT) In-Reply-To: References: <4396cf72-3914-4b1f-a00e-92c94512d2f8@zmail17.collab.prod.int.phx2.redhat.com> Date: Tue, 10 Apr 2012 15:53:00 -0000 Message-ID: Subject: Re: Which library implementation to use/work on? From: Mike Hearn To: Bryce McKinlay Cc: GCC Java Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00007.txt.bz2 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 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.Gen= eratedMessage)': > 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 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 BType extends GeneratedMessage.Builder, > =C2=A0 =C2=A0 IType extends MessageOrBuilder> > =C2=A0 =C2=A0implements GeneratedMessage.BuilderParent { > > =C2=A0.... > =C2=A0private MType message; > > =C2=A0public SingleFieldBuilder mergeFrom( > =C2=A0 =C2=A0 =C2=A0MType value) { > =C2=A0 =C2=A0if (builder =3D=3D null && message =3D=3D message.getDefault= InstanceForType()) { > =C2=A0 =C2=A0 =C2=A0message =3D value; > =C2=A0 =C2=A0} else { > =C2=A0 =C2=A0 =C2=A0getBuilder().mergeFrom(value); > =C2=A0 =C2=A0} > =C2=A0 =C2=A0onChanged(); > =C2=A0 =C2=A0return this; > =C2=A0} > } > > Sure enough the GeneratedMessage class doesn't have > getDefaultInstanceForType - it's implemented by subclasses. > > GeneratedMessage says this at the top: > > > /** > =C2=A0* All generated protocol message classes extend this class. =C2=A0T= his class > =C2=A0* implements most of the Message and Builder interfaces using Java = reflection. > =C2=A0* Users can ignore this class and pretend that generated messages i= mplement > =C2=A0* the Message interface directly. > =C2=A0* > =C2=A0* @author kenton@google.com Kenton Varda > =C2=A0*/ > > 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.