BibleGet I/O-2.8

This release of the plugin or extension for Open Office resynchronizes the plugin code with the 2.8 version of the plugin for LibreOffice. The preceding 2.6 release had been published for OpenOffice and then published as v2.7 for LibreOffice seeing that this last platform needed a few adaptations.

I had pushed the code for the extension to github when releasing the 2.6 version (year 2015) to keep it publicly accessible to the open source community. In the meantime, because of some technical difficulties with the computer I used for developing, I lost the local copy of the extension code. In order to proceed with this release, I retrieved the code from github (mainly the 2.7 release for LibreOffice). And I'm not entirely sure the code on github was actually 100% up to date with the actual 2.7 release because it seemed to have some bugs which didn't appear when testing for the 2.7 release; either the github code wasn't 100% up to date or there were some changes in some of the Java libraries used between releases which made for some bad bugs. In any case, these were all ironed out for the current 2.8 release.

After the recent BibleGet Project server updates which set HSTS headers enforcing the usage of the https protocol throughout the domain, including the query.bibleget.io service endpoint, it was necessary to use the https protocol in the extension web connections to the service endpoint. However the BibleGet.io domain uses Let's Encrypt certificates. Let's Encrypt certificates should be accepted in JRE 1.8 keystores which should trust the "DST Root CA X3" certificate used to sign Let's Encrypt certificates. However the keystore on my development machine didn't trust this certificate even though a Java 1.8 runtime was installed, and so the Let's Encrypt certificate was still causing an SSLHandShake exception to be thrown. In order to make sure untrusted certificates would not cause SSLHandShake exceptions which would have impeded the correct functioning of the extension, the DST Root CA X3 certificate was included in the extension resources and forcefully made to be trusted during plugin execution.

I'm guessing with there were some changes in updated Java libraries used for the extension, or perhaps in JRE itself, which changed the behaviour of javax.json . Not sure if this was because of code that was not pushed to github for the 2.7 release or because of updated libraries that acted differently since the 2.7 release, because the 2.7 release didn't have any problems with this as far as I can tell. In any case, the built json objects are now correctly passed into JsonObject variables which are then returned, instead of directly returning the JsonBuilder once it was built.

Another issue handled in the current release was that of UTF-8 encoded resource strings not being handled correctly, and the localized string translations were not being retrieved. I added a utf-8 control class to correctly read utf-8 encoded string resources.

Changelog

• use https protocol for web connections
• the root CA certificate included and forcefully added to the trusted certificates on runtime to make sure https connections don't throw SSLHandShake exceptions
• fixed bugs with options not being correctly loaded, this was depending on how JsonBuilders were behaving
• JsonValues which are string values are now explicitly cast to JsonStrings and the string value is obtained with JsonString.getString
• new utf-8 control class to handle retrieval of utf-8 encoded strings from resources
• use Java Runtime 1.8 (x86) to build the extension, along with the 32bit Open Office 4.1.6 SDK. This requires using a 32 bit JRE rather than 64 bit. In any case a minimum JRE of 1.8 is now required
• some resource strings were updated