LCContextGet

Moderators: heatherlaine, Klaus, FourthWorld, kevinmiller, LCMark

Janschenkel
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 977
Joined: Sat Apr 08, 2006 7:47 am
Location: Aalst, Belgium
Contact:

Re: LCContextGet

Post by Janschenkel » Mon Jun 10, 2013 5:10 am

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
Quartam Reports & PDF Library for LiveCode
www.quartam.com

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCContextGet

Post by monte » Mon Jun 10, 2013 9:15 am

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
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...
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.
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: LCContextGet

Post by LCMark » Mon Jun 10, 2013 9:43 am

Well... 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...
Yeah - I realized that was probably the angle you were coming from after posting - and after reading Jan's thread :)
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.
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:

Code: Select all

void myTestFunction(String myString, int myInt)
This would have to be interpreted as being a function taking two arguments if you only have Java reflection to rely upon. However, it could be that the intention is that it be specified as:

Code: Select all

command myTestFunction(in myString as optional string, in myInt as optional int default 100)
The point here is that the 'native' signatures (whether that be Java, native code, or LiveCode) don't give quite enough information to be able to determine how the engine should call such a method.

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).

Janschenkel
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 977
Joined: Sat Apr 08, 2006 7:47 am
Location: Aalst, Belgium
Contact:

Re: LCContextGet

Post by Janschenkel » Mon Jun 10, 2013 10:14 am

@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.
Quartam Reports & PDF Library for LiveCode
www.quartam.com

Post Reply

Return to “Engine Contributors”