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