Thoughts on Java files and forward compatibility?

[Lauri Laanmets]

Hi

That's what I also would like to sort out - for example I'm trying to 
figure out the cleanest way to implement Bluetooth support and was 
thinking of an idea to precompile the .java file to .class and put it in 
Qt source code as a byte array and use JNI DefineClass. Something like 
this (in expressional syntax):

jbyte java_class[] = { 0x01, 0xFF, ...}; // Precompiled and hard-coded 
Java class byte array
jclass DefineClass(JNIEnv *env, const char *name, jobject loader, const 
jbyte *java_class, jsize bufLen); // register in Env
|jobject NewObject(JNIEnv *env, jclass clazz, jmethodID methodID, ...);|

and so on....

Am I thinking the right way or do I miss something? Could I do this?

Regards
Lauri





On 26.06.2011 16:05, Espen Riskedal wrote:
> A small problem just bit me in the ass, but it does show some issues
> regarding being able to promise forward compatibility with never
> versions of Qt.
>
> With Qt Creator, at the moment, it will copy QtApplication.java etc.
> to your local project. I had already done this for some older
> projects, and when I was trying to run these projects with a newer
> version of Qt they failed because:
>
> E/AndroidRuntime(21608): FATAL EXCEPTION: Thread-10
> E/AndroidRuntime(21608): java.lang.NoClassDefFoundError:
> eu.licentia.necessitas.industrius.QtApplication$4
> E/AndroidRuntime(21608): 	at
> eu.licentia.necessitas.industrius.QtApplication.setFullScreen(QtApplication.java:375)
> E/AndroidRuntime(21608): 	at dalvik.system.NativeStart.run(Native Method)
> E/AndroidRuntime(21608): Caused by: java.lang.NoSuchMethodError: openURL
>
> Now, openURL was added in QtApplication.java after I generated the
> project files, so we could simply fix this by instead of copying the
> eu.licentia *.java files simply _refer_ to them to where they're
> actually located in your installed Qt version. This would solve my
> problem.
>
> But actually, it won't solve the real problem: Changes in
> QtApplication.java will/may (it seems?) be reflected in changes in Qt
> libraries or the Android QPA plugin, which means older applications
> that don't have updated QtApplication.java implementations will crash
> as Qt libraries or the QPA plugin may call these functions.
>
> I'd say:
> 1 - we should not copy the .java files into projects, but simply refer
> to the .java files as they are in the installed Qt you're using (or at
> least, overwrite if they're different)
> 2 - find a more robust way which enables changes to the .java wrapper
> functions regardless
>
> I know Robert and Christian has been working on this? What are your thoughts?
>
> espen
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/necessitas-devel/attachments/20110626/4f051af3/attachment.htm