From: Gregg Reynolds [mailto:[email protected]] Sent: Wednesday, May 9, 2018 1:19 PM To: Nash, George <[email protected]> Cc: Mats Wichmann <[email protected]>; iotivity-dev <[email protected]> Subject: Re: [dev] [iotivity-1.3.0] Windows "Java" Build Fails
On Wed, May 9, 2018, 2:09 PM George Nash <[email protected]<mailto:[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?) [geo] I wish the original implementers of the Java APIs had done exactly what you suggested. The original code was only targeting OCF for Android not a generic Java binding. Many decisions were made that tied the code really closely to Android. Of course since we had Java for one platform people wanted it for other platforms. So a Jira ticket was filled to make it work for Linux. Another (Intel) developer started work on it and got it working but it took them months to get it working. The developer left Intel and I was the lucky individual that inherited their work. The changes to IoTivity in just the few months it took them to get it working were significant. It took me weeks to get it sunk with master and fix all the bugs. After weeks of waiting on reviewers to be merged into master it was finally merged. Yay. [geo] Getting the code working on Linux was kinda ugly but it works. I love that I can run it on Linux. Most fixes for Java can now be done on Linux then just tested on Android. Ahhh, much faster. [geo] I gave myself the task of getting it working on windows. This is when the decision to use C++ in the JNI vs. C became a major problem as Mats pointed out in his response. Windows does not automatically export symbols into DLL files for C++. It requires using __declspec which is Microsoft specific. For Windows if you want to link against C++ code you have two options pepper the code all over with the __declspec so you can link to the DLL library or link statically. I chose to link statically originally since I had no desire to pepper the code with the __declspec. It worked really well for simple server/client apps. The problem was when services were used on android. The JNI code for IoTivity core would statically pull its copy of the OC stack and then a second copy would be pulled in when creating the JNI for services. The double stack problem was not discovered, till weeks later then I had to back out the bulk of the change when it was discovered. [geo] I have actually looked a little at your OpenOCFJ and OpenOCFJava. If you have implemented them against IoTivity instead of OpenOCF. I would be tempted to recommend them as a replacement for our current Java implementation. 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? [geo] Yes this is just for the JNI 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. [geo] my thought exactly. 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. [geo] I have not had a chance to use Bazel yet but the simple fact that it handles Java and Android makes it tempting. There are a lot of little hacks in the SCons scripts to handle Java and Android. Java feels like it has not received a lot of love from the SCons developers. Android is basically not supported which is why we are using Gradle to build Android sample code instead of SCons. 2 cents Gregg
