Re: [Caml-list] OCaml on Android

[Alexandre Pilkiewicz <alexandre.pilkiewicz@polytechnique.org>]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

http://gallium.inria.fr/blog/ocaml-on-a-nexus-7/


On Thu, Sep 19, 2013 at 11:18 AM, Kristopher Micinski <
krismicinski@gmail.com> wrote:

>
>
>
> On Thu, Sep 19, 2013 at 2:19 AM, forum@x9c.fr <forum@x9c.fr> wrote:
>
>>
>> Le 19 sept. 2013 à 06:35, Kristopher Micinski a écrit :
>>
>> > With a little bit of hacking it'd probably work, but I'm not sure of
>> the status of ocaml-java and haven't looked into the implementation
>> details.  Since ocaml-java outputs class files (afaik) you'd have to sort
>> of hack the android build pipeline yourself, but that wouldn't be the hard
>> part: all the tools are there.  The harder part is that the Android SDK is
>> very Java oriented, and it just feels awkward as hell to use in OCaml even
>> if you were to write a thin wrapper around the SDK.
>>
>> In theory, you are right that it wouldn't be hard.
>> In practice, the problem is that OCaml-Java emits classes
>> for Java 1.7 while (to the best of my knowledge) Android
>> only accepts Java 1.6 classes. As far as I know, there is no
>> other pending problem.
>>
>> From this point, the question would be: is it better to wait
>> for Android to update to Java 1.7 (or even 1.8...), or to
>> modify OCaml-Java? Honestly, I would need quite a bit
>> of encouragement to modify OCaml-Java in this direction...
>>
>>
> Yes, that would be a deal breaker.  That fell under the technical points
> of ocaml-java with which I wasn't familiar.
>
> Regarding interaction with the classes of the Android SDK,
>> one may be interested in the typer extension allowing to
>> manipulate Java instances from pure OCaml code:
>>     http://ocamljava.x9c.fr/preview/javaext.html
>> The main potential problem with this approach is that the
>> extension currently allows only to implement interfaces, but
>> not to extend classes. It may be a problem if for example the
>> event system of Android is based on abstract classes.
>> Another problem may be the "linking", i. e. the way Android
>> expects to execute an application: is it a bare main method,
>> or is there a need to implement/extend a given interface/class?
>>
>
> Yes, it does rely on extending an abstract class.  This does, in fact,
> permeate the framework.
>
>  kris
>
>

[-- Attachment #2: Type: text/html, Size: 3347 bytes --]