[Mobile-sig] Experiments with Dalvik

[Gabriel Pettier]

One limitation we didn't work around yet with pyjnius, and that is quite 
painful on android, is that JNI doesn't provide a way to extend a class, 
and it's painful because a lot of the android API requires you to do 
precisely that, in such case the way to do it is to do a java class for 
the part that requires it, and then use this class from pyjnius, but 
it's not very nice to have to jump to java often if you use a lot of the 
android api that requires that. Another way I toyed with (quite some 
time ago) was to automatically generate utility classes, that allowed 
you to implement an interface instead of extending a class (the 
generated java class would call code from your implementation in its 
overriden methods), but failing to find a way to generate a whole set of 
the possible classes you'd need to generate the android api, i put that 
aside and never really came back to it. Another possible solution was 
suggested recently, which was using bytebuddy [1] to generate the 
classes you'd need, i didn't explore this track, since i'm not currently 
focused on android stuff, but that could be a nice way to work around 
the issue.

[1] http://bytebuddy.net/

@david: thanks for sharing, that does look nice, and as was said, even 
parts of it could maybe help us to do a better usage of android assets 
formats, so thanks again for sharing :)

On Tue, May 17, 2016 at 07:18:01PM +0200, Dima Tisnek wrote:
>How about python-java bridge, like Rubicon or pyjnius?
>
>You get best of both worlds -- a good language and a mature runtime.
>On 17 May 2016 18:05, "David Boddie" <david at boddie.org.uk> wrote:
>
>In a belated attempt to jump on the Android bandwagon I started to look
>into learning Java and the Android APIs. I realised very quickly that I
>couldn't face writing a lot of code in that language. Looking around for
>other languages running on the Dalvik VM, I found a few that might be nicer
>than Java, but I wasn't so sure that I wanted to write in any of those,
>either.
>
>In the end, I decided to try an experiment to see how much I could learn
>about Dalvik and Java by creating tools to handle some of the file formats
>used in Android packaging, and by trying to implement a compiler for a
>subset
>of Python.
>
>The result can be found in this repository:
>
>  https://bitbucket.org/dboddie/duck
>
>It should be noted that the source language isn't really Python. The parser
>from the standard library is used to parse it, but the semantics of the
>generated code are different to those of Python. That's why I gave the
>language a different name.
>
>How is this relevant to a mailing list about Python on mobile platforms?
>
>Firstly, the language may be close enough to Python for people to find it
>more familiar than Java, even if there are places where the differences may
>trip them up. Writing code to fit into a framework designed for a statically
>typed language requires a slightly different mindset to the one you might
>have when writing regular Python code, so it may not seem so strange to
>developers once they've accepted that.
>
>Secondly, it makes it possible to write a more faithful implementation of
>Python using code that looks a lot like Python, instead of Java. You could
>use it to write support code for a compiler, or perhaps write an interpreter
>in it.
>
>It's all very experimental at the moment. I've been uncomfortable about
>publishing it before now because I keep finding things I've overlooked,
>though it's been a good learning experience. Maybe there will be things in
>there that people find useful.
>
>David
>_______________________________________________
>Mobile-sig mailing list
>Mobile-sig at python.org
>https://mail.python.org/mailman/listinfo/mobile-sig

>_______________________________________________
>Mobile-sig mailing list
>Mobile-sig at python.org
>https://mail.python.org/mailman/listinfo/mobile-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mobile-sig/attachments/20160518/7e433cf6/attachment.sig>