On Wed, May 9, 2018, 2:09 PM George Nash <[email protected]> wrote:
> Unfortunately the Windows build for Java is broken. > > At one point in time it was working but to get it working I had to change > the build to statically link to most of the libraries. Dynamically linking > to C++ libraries is currently not possible on windows. Unfortunately > statically linking to the libraries caused multiple copies of the stack to > be instantiated when using services. I had to change the linking options > back to dynamically linking see https://jira.iotivity.org/browse/IOT-2678 > > Basically the decision was that Android is the primary target for Java > language bindings Nuttin personal, George, I know you have to work within constraints. But the mind boggles. You cannot target Android until you have a Java API. The former uses the latter. I have the following build targets: OpenOCFJ - plain old Java jni wrapper around the c lib, no Android stuff, but also no config/startup stuff for pojo apps. OpenOCFJava - depends on OpenOCFJ, adds the stuff a Java app needs OpenOCFJAndroid - depends on OpenOCFJ, adds stuff you need for Android. No "primary target". You gets whats you wants. (And what about Android Things?) so I could not break Java on Android even if it worked in Window. To get > Java working in windows again someone needs to go through all of the code > and add __declspec( dllexport) (using a MACRO that is only used on windows > since this is VisualStudio specific) to all of the functions and classes > that are needed for Java in windows. Is this just for the JNI c/c++ code? I started to do this but was asked if there was any demand for Java on > windows. I could not find any demand for Java on windows at the time Chicken, meet egg. I hate to be churlish, but I'm gonna make another plug for Bazel. After many many hours of trial and error I think I have it figured out. I have a build system that does minimal recompiles all through the stack, targeting either plain Java or android (all target ABIs, in both cases). Including the javah stuff, and is smart enough to do the right thing for pojo v. Android. You build your sample app, and any deps that have changed get recompiled. Including the iotivity c engine, the JNI c stuff, and the JNI Java stuff. If you change the JNI Java stuff, javah gets run, so your JNI c headers are up to date. Cross-Compilation is a simple matter of parameters. Note: there are 3 distinct projects involved, the c lib, the JNI layer, and the test app. Bazel makes it (relatively) easy to integrate them. I confess I have not tested it on windows (lately, that is) but I do not expect that would be a hyuuuge problem. 2 cents Gregg
