Most operating systems have Java as an afterthought, and native applications written in C (or some similar language) load a Java VM in their own process. Android was designed from the start around the concept of a VM for running applications, and when you open a LiveCode executable, it actually clones a Dalvik VM and loads the com.runrev.android.LiveCodeActivity class, which then taps into native code.
So if we want desktop Java external support, code will have to be added to the engine C layer to load a JavaVM. Not a lot of code, though
As for the differences between Android and Standard Java: a lot of libraries can be used just fine on both; but once you tap into Android-specific or AWT/Swing-specific user interface elements, it won't be portable. So there would be two types of Java externals: generic ones which can run on both Desktop and Android, and specific ones which run either on Desktop or on Android.
I don't mind the idea of specifying things in a .lcidl file but still don't see the necessity when it can all be determined at runtime - except for the open language syntax definitions, of course.
Jan Schenkel
LCContextGet
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: LCContextGet
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Re: LCContextGet
Right, that's what I was suggesting... and that loading could be done conditionally on if there is an external that needs it I think...So if we want desktop Java external support, code will have to be added to the engine C layer to load a JavaVM. Not a lot of code, though
I don't have a strong opinion either way... other than wondering if the lcidl method stub way allows us to reuse much of the parameter checking code...I don't mind the idea of specifying things in a .lcidl file but still don't see the necessity when it can all be determined at runtime - except for the open language syntax definitions, of course.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCContextGet
Yeah - I realized that was probably the angle you were coming from after posting - and after reading Jan's threadWell... there's heaps of Java stuff that could be used that has nothing to do with android... arguably it would be better to find a C library that does the same job and use that but for Java devs that's not going to help much...
Well sometimes uniformity is enough of a reason to necessitate something... The 'only' (albeit reasonably sized) thing you can get from Java at runtime is the methods and their signatures (and classes and fields). This isn't quite enough information to specify the methods from the point of LiveCode (even without Open Language). For example:I don't mind the idea of specifying things in a .lcidl file but still don't see the necessity when it can all be determined at runtime - except for the open language syntax definitions, of course.
Code: Select all
void myTestFunction(String myString, int myInt)
Code: Select all
command myTestFunction(in myString as optional string, in myInt as optional int default 100)
Anyway, there is more to say on this topic (we're moving into the realm of general language bindings - which is quite an exciting idea - why not let people extend LiveCode in any language that is suitably hostable?), but it might better be done in a new thread - besides, I need to explain what the plan is with regards the current way the engine binds to external methods and the existing external interface(s).
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: LCContextGet
@runrevmark: we can provide additional annotations on the parameters to allow specifying the default values.
As I noted before, I'm not opposed to .lcidl files to help the engine figure things out; but ideally an annotation processor would spit it out for the developer.
Jan Schenkel.
As I noted before, I'm not opposed to .lcidl files to help the engine figure things out; but ideally an annotation processor would spit it out for the developer.
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com