Migrating Native libraries
The server makes use of a couple of system native libraries. These are:
- Charva – Which is a windowing toolkit for terminals. With charva we have a library which “copies” the java.awt and javax.swing into charva.awt and charvax.swing, so we can still develop in the mimic of awt and swing, but then for text terminals. Charva uses ncursesw to draw to the terminal to the screen.
- SQLite JDBC driver by xerial – Our driver used for talking to SQLite databases.
- RXTX – The communication driver for USB attached devices as wel as the GPIO RX-TX pins.
- WiringPi through Pi4J – Used for accessing the I²C pins and future other pins.
I already got the projects working on the Soft Float version of raspbian. So now it was time to recompile for the Hard Float raspbian distribution. This is where the fun begins.
I took the sd card which had the soft float wheezy installment, and formatted it. Here comes the oops. The modifications I made to the above libraries where on this SD card. So had to start from scratch again. The upside of this is I can tell you the changes I made to get the libraries working.
First, the only builds I had to make are in Charva and the SQLite JDBC driver. The RXTX and WiringPi/Pi4J are premade and both working out of the box (well, quite).
Charva is nice, but I think not heavily maintained anymore. Because I was starting building and stumbled upon a little bug. The interface for terminal has the old norton commander color scheme, and popup borders where not getting the correct border color. So I made some tiny small modifications (just added 2 lines), created a bug report, which as of this day is still open.
So I have again changed the file in question, and changed other files so the new native library is usable on the rasp. I just followed the instructions and created a makefile for the raspberry pi. Because of charva is using ncursesw I installed ncursesw-lib, and started building. The result is available for download at the pidome server download site. It includes a readme file, the complete source code and the modified files so charva can be build on the pi.
P.S. It is using apache ant.
The SQLite JDBC is a different story. This library is designed for JDK 1.5 and not for JDK 1.7. As it extends java interfaces which has been modified over the last couple of years, features are missing. So the classes which extends these interfaces are missing required functions. Currently these functions are not used by the server, so i could add them with unsupported operation exception thrown if i wanted to use them, and met the requirements for building this library with JDK 1.7.
To create the raspberry pi native library I just did a quick and dirty hack in the makefile and modified some java files. I went to SQLite JDBC bitbucket site. I got the clone command, and cloned the project in netbeans with having jdk 1.7 installed (by accident a windows xp machine, but that should not matter). I’ve changed a couple of java files because this project was build for jre 5/jdk 1.5. So netbeans logical complains of missing function in classes extending default jdk classes. Just by letting netbeans add the missing functions (opening the java file, right mouse button add the error, and add the missing functions) the project will be jdk 1.7 “compatible”. After i was done i just copied the complete sqlite-jdbc directory to the pi. Next you can make the same changes as I did to build for the raspberry pi: Open Makefile.common and add the next lines around line 112:
Linux-arm_CC := gcc Linux-arm_STRIP := strip Linux-arm_CFLAGS := -I$(JAVA_HOME)/include -Ilib/inc_linux -O2 -mfloat-abi=hard -mfpu=vfp -fPIC Linux-arm_LINKFLAGS := -shared -static-libgcc Linux-arm_LIBNAME := libsqlitejdbc.so Linux-arm_SQLITE_FLAGS :=
The diry hack was adding a hardcoded assignment at around line number 50, just below the check for the os and arch:
target := Linux-arm
To make sure building it goes successful and have not done already, do the next:
pi@pidome-server ~/pidome-server/libraries/sqlite-jdbc $ export JAVA_HOME=/usr/lib/jvm/jdk-7-oracle-armhf/ pi@pidome-server ~/pidome-server/libraries/sqlite-jdbc $ chmod 755 ./amalgamation_version.sh
This makes sure the build process does not complain about the JAVA_HOME environment setting, and the amalgamation file can be executed.
Started make and got the jar file. I do not have a download nor a fork of the code. With the above it should be possible for you to build for the raspberry pi. This project is quite active, and together with developing the pidome server and client, it would be too much to maintain.
P.S. This is absolutely a quick hack and this project requires maven to build.
RXTX is quite a scattered project, some love it, some hate it, i use it. I did not build this project on the pi, not on the soft float nor on the hard float distributions. The version i’m using at this moment is found at https://blogs.oracle.com/jtc/entry/serial_port_communication_for_java. This causes a version change, because the soft float I used was another version with windows support. This new version does not have a compatible version in the server yet. This will be added later, but because of the focus on the pi, i can not tell when. The reason I used an other version is because that was the most elegant way to do cross platform support for the RXTX jar library, which of now is out of sync.
I love this package. No changes needed what so ever. No need for rebuilds or recompiles. Gordon from WiringPi and the guys who are developing the Pi4J package are doing a wonderfull job.
With the above new builds, I got the pidome server running on the hard float ABI of the raspberry pi. And I must say, There absolutely is a performance improvement. The soft float raspberry pi was clocked to 800 mHz, the hard float is default at 700 mHz. Initial start up of the VM and the application is almost the same despite the pi speed difference, it’s faster. Starting the server without debug logging and without any graphical interface went from 11 to 7 seconds. The web interface almost loads twice as fast, and so is data handling. Also running device commands from macro’s is faster.
So after rebuilding the libraries and moving to the Hard Float distribution, the server is, faster, as expected. I’m quite pleased with the results. Maybe I have to do some rebuilds with some optimizations. This move also means, despite mentioned earlier, The server does not support the soft float version anymore.
See you at a next post,