This is the mail archive of the
mailing list for the Kawa project.
Re: Question, GSoC Idea `Easier Access to Native Libraries using JNA/JNR"
- From: Per Bothner <per at bothner dot com>
- To: Vasantha Ganesh <vasanthaganesh dot k at gmail dot com>, kawa at sourceware dot org
- Date: Sun, 2 Apr 2017 08:12:45 -0700
- Subject: Re: Question, GSoC Idea `Easier Access to Native Libraries using JNA/JNR"
- Authentication-results: sourceware.org; auth=none
- References: <CAL0TjKrATQ=DTwrJd2Xydca-dGZ6f-uTPg6ee_KaKELv2kQnag@mail.gmail.com>
On 04/02/2017 04:07 AM, Vasantha Ganesh wrote:
I have been trying to write a proposal for ``Easier Access to Native
Libraries using JNA/JNR" idea for my GSoC project.
The access to native libraries is available through popular libraries
such as JNA and JNR. Access to native libraries in Kawa is just like
any other Java library in a very consistent way (strengths of Kawa?).
I tried looking into the Ruby wrappers. JRuby is trying to make their
FFI API compliant with other implementations. So that Code on JRuby
can run in the same way as other Ruby implementations.
Common lisp is trying to do something similar with CFFI. Common lisp
implementations are trying to make their code that can run on other
implementations in the same way. This calls for a common API (CFFI).
Looks like you've done some good research.
But in scheme we are not trying to be compliant with any other Scheme
implementations. Take Guile and Kawa for example. Guile code does not
necessarily run on Kawa. Also, Guile has its own FFI.
These are just my views. I would like to know the motivation of this
project because I'm fuzzy about the usefulness of this project.
I'm afraid I haven't JNA or JNR myself, so I don't know firsthald how
useful they are, or how much a Kawa binding would help.
What was an open question was whether a Kawa wrapper (i.e. some
well-design Scheme procedures and/or macros) would make JNA or JNR
easier to use. You've suggested that it probably wouldn't. Or at
least we don't have enough experience with possible "pain points"
to identify areas where a Kawa wrapper would make using JNR
noticeable easier or more pleasant, partly because Kawa already makes
it very easy and pleasant to use the Java API as-is. Right?
It might be a little late to write proposal for other ideas.
Probably You could take a look at the "function types using MethodHandles"
idea that I mentioned in an email March 13, and detailed here:
This is definitely useful, and at least I myself understand both the problem
and a general direction for solving it. You could use the text from my link.
The problem is it requires a fair bit of understanding of Kawa. For a GSoC
proposal you should should that you understand the problem and have a general
plan for how to solve it. That may be difficult in less than 2 days.