On Mon, Aug 5, 2013 at 22:25:53 -0700, Kevin Cernekee wrote: > This patch series adds native Java API wrappers for current > libopenconnect functions. The eventual goal is to be able to use > libopenconnect in an Android VpnService based client app, so it's > still a work in progress and there is much more left to be done. I'm > posting this now to gather feedback and to compare notes with anyone > else who has been working on similar projects. Had a moment to try this out briefly, works for me, mostly. Some minor feedback from just building and running your example follows. $ ./configure --with-jni checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes [...] checking for LIBSTOKEN... yes checking for LIBOATH... yes configure: error: '$JAVAC' undefined $ ./configure --with-jni JAVAC=javac # now it works With my packaging hat on, do you think it would it be reasonable to split out the JNI API into a separate library? Something like libopenconnectjava, libopenconnect_java, libjopenconnect? The library currently has a fairly stable API, this would introduce new symbols that may or may not be present in a given build. How would a user know whether libopenconnect has Java support built in or not? How would a program that depends on the Java binding know whether a given libopenconnect has it enabled? Are you expecting that this will be disabled on host builds / distributions? I assume so, since you're talking about Android and the default is disabled. However, keep in mind that once it's out there someone may come up with a use for this on a server or desktop and we may eventually want to enable this feature on distributions as well. Thanks, -- mike
