Allowing Java-C++ interaction

[BogDan]

Hi Tyler,

Please accept my apologize for slow reply.

I need a few days to understand what is wrong with current design and to check your patch, then I'll come back with feedback !

Thank you very much for your patience !

Cheers,
BogDan.




> 
>
>BogDan,
>
>
>Do you think this patch can be included in the next alpha? If not, what needs to be done?
>
>
>Thanks,
>Tyler
>
>
>
>On Thu, Dec 29, 2011 at 12:48 AM, Tyler Mandry <tmandry at gmail.com> wrote:
>
>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
>>
>
>
>
>-- 
>Tyler Mandry
>
>
>