jna-inchi-ixa and jna-inchi-wasm

[BobHanson]

There are three separate check-ins here.

1. Addition of int getCodeObj(Object) to streamline the connecting of strings, enums, and Java enum values with InChI Code values. This is a generally useful friendly amendment.

2. Addition of a Maven module, jna-inchi-ixa. This adds two additional files, one in the jnainchi folder (InchiAPI.java) , and one in jnainchi/inchi (IXA.java). These two classes provide an alternative to JnaInchi and IxaFunctions that work in Java and in JavaScript. They are not perfect, as there are a few missing features relative to JnaInchi that the IXA interface cannot (yet) deliver, but the point is that this is an interface that does not require any encoding or decoding of C structures. All pointers are simply held until needed to pass back to the originating C functions. Dependency for this module is jna-inchi-api. This is generally useful module for Java, not just JavaScript. It focuses specifically on the IXA interface. The only two functions it calls that are not libinchi IXA_* functions are two simple C methods, int checkInchi(String) and int checkInchiKey(String). These two new classes are completely independent of JnaInchi and IxaFunctions. They are simply Java alternatives, and JavaScript necessities.

3. Addition of a Maven module, jna-inchi-wasm. This adds two resources, jnainchi.js and jnainchi.wasm, (created in the InChI-SwingJS project) that can be used for any JavaScript program that calls the InChI Extended Interface, whether it be node.js-based, SwingJS, or some combination of those (as demonsrated here. Dependency for this module is jna-inchi-ixa. Note that these two files must be in the jnainchi/inchi folder, as that is where the SwingJS adaptation of NativeLibrary expects them.

Note that there is no change to InchiLibrary.java itself (which works perfectly in JavaScript as is).

I hope that makes reasonable sense.

See README-IXA for a more thorough discussion.

I think I came close to getting this right in terms of the POM files, but that may not be in the exact format you need. I have never created a POM file before. If this is basically the idea, but I am missing something, just let me know or feel free to fix it.

In any case, except for future updates of these for key files, this is all I plan to push to JNA-InChI. Everything with these additions is working perfectly in JavaScript now, and there are absolutely no additional changes needed JNA-InChI for my overall project.

The first implementation of this has been for the CDK, enabling all of its InChI-related methods to be used in JavaScript as well as Java.

[BobHanson]

This PR now includes a follow up on the original. I figured out how JavaScript can use the same InchiLibrary autogenerated by JNA-InChI to access a WASM module created from inchi C. For that there is absolutely no changes needed for JNA-InChI that distinguish Java from JavaScript.

The new version simply offers a new option to replace calls to JnaInchi.java with calls to InChIAPI.java, and replaces IxaFunctions.java with IXA.java. These two versions are still completely compatible. It's just that now we have two Java options, one of which is fully JavaScript compatible as well.

The new InchiAPI class only makes calls to methods in libinchi/ixa. This removes any need to handle the complex issue of machine achitecture for reading and writing C structures between Java and C as well as JavaScript and C.

Although, as discussed in this InChI PR, I'd like to add just a bit more to JNA-InChI to fill out the InChI Extended API a bit, and there were a few changes I made to accommodate those.

This has been tested now in JavaScript and Java using an implementation of JNA-InChI in the CDK.

Also, I have field-tested it in Java and JavaScript for an array of InChI/mol conversions. In that 110-conversion test, I am happy to report that the InchiAPI runs reproducibly 10% faster than JnaInchi in Java. I think it is because there is a significant overhead in extracting Java classes from C structures. Just passing C pointers back and forth is more efficient.