<div class="gmail_quote">On 21 February 2012 22:01, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 21 February 2012 17:10, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
> On 21 February 2012 19:02, H. S. Teoh <<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>> wrote:<br>
>><br>
>> On Tue, Feb 21, 2012 at 01:03:09PM +0200, Manu wrote:<br>
>> > So I was thinking about this extern(language) thing, the obvious ones<br>
>> > are<br>
>> > supported, but it would be really nice to be able to implement custom<br>
>> > conventions for other languages/scripting languages.<br>
>> ><br>
>> > For instance, I'm thinking about Android, I have JNI binding code<br>
>> > everywhere, it's really ugly.<br>
>> > I'd love to be able to declare:<br>
>> >   extern(Java) int someJavaFunc(int x, float y)<br>
>><br>
>> I wonder if there's a way to "outsource" (har har) extern declarations<br>
>> somehow so that instead of requiring the compiler to implement<br>
>> everything, it can forward most of the stuff to a library, e.g.,<br>
>> something that interfaces with JNI. The compiler would provide hooks to<br>
>> such a library so that it doesn't have to know how JNI works, but just<br>
>> forward calls to someJavaFunc(x,y) to a wrapper in the external library<br>
>> that can then do type translation, JNI mapping, etc..<br>
><br>
><br>
> ... that's the essence of my whole proposal, except not quite like you<br>
> describe :)<br>
><br>
>> This way, we don't have to bottleneck at the compiler when we need to<br>
>> support a new language binding, and we don't have to bloat the compiler<br>
>> with C, C++, JNI, PerlAPI (buahaha), what-have-you. Somebody can just<br>
>> write a library with the necessary hooks, and you can compile away at<br>
>> your leisure.<br>
><br>
><br>
> C/C++ is important to be known internally within the language, because to<br>
> make good use of these super-common languages, you need to know about the<br>
> differences in structure layout, and the language needs to generate code<br>
> accordingly (where to find the vtable/etc).<br>
> With the (typically VM based) languages I was referring to, there's no<br>
> direct linkage, all communication must be via some API, so the intrinsic<br>
> knowledge of foreign structures is not necessary in that case. You would<br>
> always need to understand the layout or contents of foreign structures via<br>
> some sort of marshalling api/class, since the VM is free to do whatever it<br>
> likes internally.<br>
<br>
</div></div>You will need to know where things are with Java Classes, so I would<br>
have thought that would be a very problematical issue for you...<br>
Although D (gdc) follows a similiar but not identical ABI to Java<br>
(vtable should be located in the same area).<br></blockquote><div><br></div><div>Are you talking about hard-linking to statically compiled java code? Otherwise the internal layout doesn't really matter when you're interacting through the jni API...?</div>
<div>Or are you actually talking about hitting the jvm's data structures directly and subverting the jni API?</div></div>