Thanks for the solution. For us less than highly techie, could you provide more detailed steps:
how to update/rebuild with jna 4.1
which files (and where are they installed) to modify these lines of code
How do we get these changes into the pipeline so they become part of the source code of the system?
thank you for digging for a solution.
i’d be interested in a detailed (for dummies) how-to for your solution too. 
thx,
stefan
Thanks Alejandro - will try this in the upcoming xmas break!
any news on this? Will this be fixed in OH 1.8.0 or do we have to use the fix mentioned above?
I’ve experienced the same problem as described here. I can report that the solution by AlejandroGuirao works for me. Thx Alejandro! I’m not running openhab as root I just added openhab to the gpio group.
For those that find it a little difficult to compile a binding on their own I uploaded the jar file I’m now using to: https://www.dropbox.com/sh/uwoa2pv3o25rcig/AABRvk1wZamI62h2l_ClAJmla?dl=0
Just add this file ot your /usr/share/openhab/addons folder and remove the existing gpio binding.
Please also note that I’m using: JAVA_ARGS=-Djna.boot.library.path=/usr/lib/arm-linux-gnueabihf/jni in /etc/default/openhab
SOLVED
It is indeed an incompatibility between OpenHAB (built with libjna 3.2.7) and Raspbian (comes with libjna 4.1.0).
After trying to convince OpenHAB not to use the system jna-lib (-Djna.nosys=true) - which did not work (no idea, why not), I removed libjna-java and libjna-jri.
Installing libjna-java_3.2.7-4_armhf.deb (from http://ftp.debian.org/debian/pool/main/libj/libjna-java/) and restarting the GPIO input was initialised properly and changes are reported to OpenHAB.
I am running OpenHAB 1.7.1.
I did try OpenHAB 1.8.0 (#1113) with the above solution (replacing …io.gpio…) but that did not work. There was no error, but the GPIOs were never initialised.
I haven’t tried, but this should work with the OpenHAB version 1.7.1 from the repository as well.
Steamrunners solution didn’t work for me either, i guess the JAVA_ARGS-thing is the problem?
how do i remove libjna-java and libjna-jri and how to install the linjna-java_3.2.7-4?
i mean what would be the commands i would have to execute in the commandline?
thx,
stefan
thx for uploading the jar file. i replaced my old gpio binding with yours but it didn’t work.
i don’t really understand the last sentence in your post (JAVA-ARGS), so i guess the problem could lie there?
cheers,
stefan
To remove the installed version:
sudo apt-get autoremove libjna-java
If it wasn’t installed, then ignore the error.
To download and install the (old) version:
wget http://ftp.debian.org/debian/pool/main/libj/libjna-java/libjna-java_3.2.7-4_armhf.deb
sudo dpkg -i libjna-java_3.2.7-4_armhf.deb
That should work.
@poertner
I did try setting the jna.boot.library.path. But didn’t work either. No error, but no initialisation of GPIO ports. I assume the loop is waiting indefinitely for the ports to become available - but that’s just an assumption. I don’t really know java - well I had to learn it a bit and learned to hate it a lot 
Not sure if it’s clear from my initial post but you need to replace the org.openhab.io.gpio…jar and keep the existing org.openhab.binding.gpio…jar
Depending on how you installed openhab the documentation tells you to add -Djna.boot.library.path=/usr/lib/jni to either /etc/default/openhab or /opt/openhab/start.sh. I use /usr/lib/arm-linux-gnueabihf/jni in stead of /usr/lib/jni. Not entirely sure if that is needed though. (See here: https://github.com/openhab/openhab/wiki/GPIO-Binding#installation)
Please also note that there are a few other things to know about the gpio binding. (These are not raspbian jessie specific and are discussed elsewhere.)
That’s exactly what I tried. Didn’t seem to work. Didn’t look into it any further.
libjna-java-3.2.7 works with both openhab 1.7.1 and 1.8.0, running as user openhab. Unexporting of gpio is done is the start script for me (echo > /sys/class/gpio/unexport).
Using 1k resistors in the wired sensor/switch paths.
BTW:
The current 1.8 builds still come with JNA 3.2.7, which is rather outdated. Will the final (and ultimate) build be with 4.1 or will OpenHAB1 stick to the old JNA?
Quite a few people seem to use it on Raspbian, which shows the problem (as any new debian would - but there aren’t that many Debian-PCs with GPIOs out there).
it works now!
at first i tried the method @TSchenkel suggested, but something went wrong.
when i did the uninstall (sudo apt-get autoremove libjna-java), the gpio bindings are removed too, automatically.
so i installed libjna-java_3.2.7-4 and then again the binding via apt-get.
after a reboot i couldn’t access the webUI, a quick look into syslog revealed that some java errors caused OH to shut down…
then i started all over again, fresh JESSIE install with openhab via apt-get, install gpio binding via apt-get and just replaced the org.openhab.io.gpio…jar as @Steamrunner suggested --> that works now!
i hope in 1.8 the newer JNA is used!!
thx @ both of you for working on a solution!!
After a bit of experimenting with version 1.8 I downgraded again to 1.7.1. Didn’t manage to get it to work with the jar I compiled earlier. Didn’t try to recompile yet.
what can we do now, where to start really fixing this? 
i mean, GPIO not working on raspian JESSIE even with the latest OH 1.8.0 is really frustrating…
it’s basically useless.
who wrote that binding?
thx,
stefan
This binding is really a bit troublesome 
Apart from the problem I described in my previous posting (race condition) there is a problem with the jna libraries. The original binding comes with jna-3.2.7 which is really outdated (as also noted by TSchenkel). The actual version is 4.2.1 (see https://github.com/java-native-access/jna#download). Important for jna is also a library named libjnidispatch.so. When the installed library (for example with apt-get install libjna-java) does not correlate with the used jar the whole thing does not work.
I have substituted the jna-3.2.7.jar in the binding package with the actual jna-4.2.1.jar which also comes with the libjnidispatch.so for lots of different platforms (although for gpio we only need arm).
I have also included my previous fix to prevent the race condition with udev scripts. I changed it so it is no longer an infinite loop. No it has a timeout and throws an exception when the files in /sys/class/gpio are still not writable. The corresponding reserve method is as follows:
/**
* Exports the pin to user space, creates and initializes the
* backend object representing the pin. Updates the registry for
* initialized pins.
*/
public GPIOPin reservePin(Integer pinNumber) throws IOException {
final String SYSFS_CLASS_GPIO = sysFS + "/class/gpio/";
GPIOPinLinux pin = null;
/* Variable 'sysFS' may be null if mandatory pseudo file system 'sysfs' isn't mounted or mount point can't be determined. */
if (sysFS == null) {
throw new IOException("Mount point for '" + SYSFS_VFSTYPE + "' isn't configured and can't be determined");
}
/* Sanity check, negative pin number is illegal. */
if (pinNumber < 0) {
throw new IllegalArgumentException("Unsupported argument for 'pinNumber' parameter (" + pinNumber + ")");
}
/* Acquiring write lock guarantees atomic check/set operation */
try {
if (gpioLock.writeLock().tryLock(GPIOLOCK_TIMEOUT, GPIOLOCK_TIMEOUT_UNITS)) {
try {
if (gpioRegistry.containsValue(pinNumber)) {
throw new IllegalArgumentException("The pin with number '" + pinNumber + "' is already registered");
}
/* Exports the pin to user space. */
Files.write(Paths.get(SYSFS_CLASS_GPIO + "export"), pinNumber.toString().getBytes());
/* Create backend object */
pin = new GPIOPinLinux(pinNumber, SYSFS_CLASS_GPIO + "gpio" + pinNumber, defaultDebounceInterval);
/* wait until udev scripts gives write access to current user */
try {
Thread.sleep(udevWait);
} catch(InterruptedException ex) {}
if(!pin.isWritable()) {
throw new IOException("Pin with number '" + pinNumber + "' is not writable.");
} else {
logger.info("registering pin with number '" + pinNumber + "'");
}
/* Register the pin */
gpioRegistry.put(pin, pinNumber);
} finally {
gpioLock.writeLock().unlock();
}
} else {
/* Something wrong happened, throw an exception and move on or we are risking to block the whole system */
throw new IOException("Write GPIO lock can't be aquired for " + GPIOLOCK_TIMEOUT + " " + GPIOLOCK_TIMEOUT_UNITS.toString());
}
} catch (InterruptedException e) {
throw new IOException("The thread was interrupted while waiting for write GPIO lock");
}
return pin;
}
There is now an extra option in openhab.cfg: gpio:wait wich gives the time to wait for udev scripts in milliseconds. If not specified the default wait time is 50ms.
Now there is no necessity to install jna on linux and no parameters have to be given in /etc/defaults/openahb. This solution worked out of the box on various of my raspberries with different systems. I hope it works for you too and we can close this thread 
Here you can find a compiled and packaged binding: https://www.dropbox.com/s/zn3nroyks9odizz/org.openhab.io.gpio_1.7.0.jar?dl=0
good luck
I haven’t tested it but i don’t see why it shouldn’t work.