Allowing Java-C++ interaction

[Tyler Mandry]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20111224/878c9e86/attachment.html>