LiveCode Forums.

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

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

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

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