Allowing Java-C++ interaction

[Tyler Mandry]

Here is the patch (against alpha4 head 2469081) to make everything work.
I've tested and it works. The basic approach is to compile
qtmain_android.cpp into its own .so during Qt compilation, and load it in
the application. It uses dynamic linker calls to find the main() function
at runtime. So there is no awkward back-and-forth library loading needed
after all.

Backward compatibility: I made sure my changes to the JAR allowed it to
still work with existing built applications as-is, and light testing
confirms that it is. This required a few extra lines that are marked as
such in case you want to remove them.

I didn't touch Ministro, however, and I suspect that my addition to
lib/rules.xml will cause new versions of Ministro to try to load
libqtmain.so, which won't exist in old/current applications. I'll leave
that issue for someone more familiar with Ministro to look at, if it's a
concern.

Finally, I mentioned creating a new category of user-defined bundled libs
in case the user wants to use JNI with those libs, but did not implement
that.

I hope you like it and that it can be included in the next alpha. Let me
know if you have any questions or comments :)
Tyler

On Sat, Dec 24, 2011 at 11:28 PM, Tyler Mandry <tmandry at gmail.com> wrote:

> BogDan,
>
> Merry Christmas again! When you have time:
>
> Separating out qtmain_android.cpp into its own shared lib allows us to
> build it during the Qt build rather than with the application projects. (We
> have to remove the --no-undefined linker option, but it works.) My question
> is, where should that library go in the Qt install? It isn't technically a
> Qt plugin, so I don't know about putting it with plugins, and lib/ is all
> official Qt libs. It fits in best with jar/, but then the directory name
> doesn't make sense :). We could also make another directory, though it
> seems unnecessary. I'll probably stick it in jar/ unless I hear from you.
>
> I've proved that this method works, and now I'm just working on
> integrating all the changes in code.
>
> Cheers,
> Tyler
>
>
> On Fri, Dec 23, 2011 at 2:14 AM, Tyler Mandry <tmandry at gmail.com> wrote:
>
>> One thing I've encountered: If I'm not mistaken, people can/will use
>> bundled libraries to bundle Qt libraries along with their application (to
>> bypass Ministro.) Others will use bundled libs of their own for other
>> purposes. We will want to load the Qt bundled libs inside the child class
>> loader, so our JAR can talk to them, and the other bundled libs inside the
>> main Java class loader, in case they want to interact with those native
>> bundled libs via JNI. This will require us to make a new distinction on the
>> type of bundled library.
>>
>> Other thoughts: I've been looking and it looks like this isn't a
>> difficult change to make. It's very minimal in the way it changes how
>> things are done right now. It does require a change to the JAR files to
>> accomodate for that back-and-forth lib loading that I described. Anyway, I
>> plan to implement all this tomorrow and see how it goes.
>>
>> On Thu, Dec 22, 2011 at 8:51 PM, Tyler Mandry <tmandry at gmail.com> wrote:
>>
>>> Hi all, and Merry Christmas.
>>>
>>> We were discussing the importance of allowing Java and C++ to interact
>>> for many people's apps in android-qt (thread: C++ and Java interaction in
>>> Alpha3.) With the new separation of the JAR files, and use of a different
>>> class loader for the app code, it has become very difficult to allow this.
>>> Traditional native interface classes can no longer see the native methods
>>> that are loaded by the separate class loader.
>>>
>>> I did some playing around, and I think I found a simple solution that
>>> works. If we separate out the code in qtmain_android.cpp into its own (very
>>> small!) shared library, and allow the user's application code to be in one
>>> library all by itself, we can load them in separate class loaders. While
>>> you can't do Java-Java or Java-native interaction easily across the class
>>> loader barrier, native-native interaction works fine since it's all the
>>> same process. Simply load the Qt library in the /child/ class loader,
>>> followed by the application code library in the /main/ class loader,
>>> followed by the qtmain_android code in the /child/ class loader. Then the
>>> user's Java code can see the user's C++ code and vice versa, because they
>>> are all loaded under the same class loader.
>>>
>>> I did a testcase of this (with libraries of my own, not Qt) and
>>> confirmed that it works in a simple case. If no one sees any problems with
>>> this let's implement it.
>>>
>>> --
>>> Tyler Mandry
>>>
>>
>>
>>
>> --
>> Tyler Mandry
>>
>
>


-- 
Tyler Mandry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20111229/824eca7b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: userJNI.tmandry.patch
Type: application/octet-stream
Size: 14168 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20111229/824eca7b/attachment-0001.obj>