Improving Java Bindings

[e1528532]

I intend to use the JNA java bindings to implement the apache commons configuration integration #1085 . There are several things we can improve with the bindings to make them easier to use

Running Lint on the code

I use http://www.sonarlint.org/ on all of my java projects. Its a nice tool which checks for java code conventions, possible problems and best practices. There are various issues in the code of the JNA bindings, like having no serial version UID for serializeable classes, variables and constructors being in the middle of a class which does not comply to the java code conventions (although its no problem), using synchronized string buffers when there is no need for synchronization and similar. I intend to solve these issues to make the code more clear and easier to read.

Creating a Maven project

In Enterprise Java Development, i think its more common to use a build system like Maven or Gradle to manage your dependencies. That way, you don't have to mess around with compiling the libelektra.jar and including it yourself. Its probably also possible to upload the elektra bindings to a maven repository then, so everyone can include the bindings very easy in their projects.

In addition to converting the bindings to a maven project (which can still be built manually if one wants to), i'd change the package structure to comply more with maven and java conventions by

• Changing the package to org.libelektra, as this is our domain
• Moving the source to src/main/java build folder, and the tests to the src/main/test build folder, as its usually done with maven projects

Document the Plugin package

To me its not really clear yet what the plugin package is intended for. Once i found out, i will add those information to the documentation

TL;DR and TODOs

• Fix the issues detected by sonarlint
• Convert to a maven project
• Upload to a maven repository?
• Document plugin part of the bindings

[markus2330]

http://www.sonarlint.org/ on all of my java projects. Its a nice tool which checks for java code conventions, possible problems and best practices.

Very good initiative, do you think we can integrate it on our build server?
http://build.libelektra.org:8080/

There are various issues in the code of the JNA bindings, like having no serial version UID for serializeable classes

Thank you, I am looking forward to the PR! About the version UID: I think we can make all classes non-serializable: KeySet exists for the purpose of being serialized via KDB, it would be strange to also serialize it via Java's serialization mechanism. (It would be a different topic however to look into how the serialization techniques can be combined, but I think apache commons configurations is more promising).

to upload the elektra bindings to a maven repository then

Is this possible if a .jar depends on native code? And does a jar really need to be build via maven to have it available in the maven repo?

so everyone can include the bindings very easy in their projects.

I welcome any improvements which make it easier to use Elektra (e.g. for Java People), but please also consider that package maintainer do not want several build systems to get Elektra compiled, so it should still be possible to get the "libelektra.jar" via cmake (without additional dependencies).

To me its not really clear yet what the plugin package is intended for.

It is code intended to be used via the jni plugin. It is somehow misplaced there but it was much easier to keep all java code together. You are welcome to split it to several jars.

[e1528532]

Integration in the build server is possible, however you would need an own server running sonar (java code quality tool) and i'm not sure if its worth the effort for now, as there is not much java-related developement going on at the moment.

Fixed all those java issues and converted everything to a maven project while still maintaining the possibility to build it manually in #1238 .

I'll look at uploading this to maven central as discussed in the last PR, but i think thats worth an own PR. And since we decided to let the jni stuff rest for now, i think the plugin documentation is also freezed for now.

[markus2330]

but i think thats worth an own PR.

Yes, definitely!

[markus2330]

We migrated to maven.