From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6393 invoked by alias); 11 Jul 2007 15:03:01 -0000 Received: (qmail 6380 invoked by uid 22791); 11 Jul 2007 15:03:01 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_20,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jul 2007 15:02:57 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6BF2sDX032402 for ; Wed, 11 Jul 2007 11:02:55 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6BF2smY001661 for ; Wed, 11 Jul 2007 11:02:54 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6BF2qfg022407 for ; Wed, 11 Jul 2007 11:02:52 -0400 Message-ID: <4694F12E.6080406@redhat.com> Date: Wed, 11 Jul 2007 15:03:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: frysk@sourceware.org Subject: cni vs jni Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00084.txt.bz2 [This was today's technical topic] What are the advantages vs disadvantages of CNI over JNI. Going forward, should Frysk stick with the GCJ specific CNI, or migrate to the more standard and accepted JNI. Discuss. - cagney noted that while CNI isn't going away, it certainly isn't being pushed [he keeps getting hints that frysk should break its dependency] - MJW noted that the JNI is far more cumbersome for accessing class data, complex data types, and callback methods. Reflection calls are needed to access those methods. On the other hand full access to reflection becomes possible. - MJW indicated that JNI works best when information is exchanged using simple types (e.g., ints) and simple interfaces. Consequently it is best to perform large chunks of work in JNI with few and thin calls to/from Java. - Tim noted [is this right] that CNI gives us a fast simple and efficient access to the Java interfaces from C++. A switch to JNI would loose that; and a loss of one of the advantages of being able to code most stuff in Java. - Swig was mentioned; Phil noted that he'd looked at that for the elfutils bindings but discarded it as it over exported the interfaces - for frysk only a focused subset of the interfaces need to be bound; Cagney also noted that Swig didn't understand the memory patterns and requirements of libraries such as elfutils. - Phil asked if it was possible to combine CNI and JNI code; cagney indicated that it was (well sort of) as it is clumsy. - cagney noted that pushing more functionality into the native layer could make it easier to add other, additional bindings (binding C++ is easier than back binding native java). Possible options - simplistically translate the bindings into JNI - push more core code into C++ and move the bindings to a higher layer - status quo Schedule?