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