Introducing Java::Bridge (really, this time)
So, a few days ago, I intended to post a paragraph of metablogging, and then get on with introducing a project. Then I was going to post a few paragraphs. Then I actually write it, decided it deserved it’s own entry, and posted it … and decided that I deserved a break. So here I am, a few days later…
Java::Bridge’s intent is to be a way to use and control any arbitrary Java API you want, from inside of Perl code, without requiring the author of Java::Bridge (IE me) to have considered your use case in advance, or having to have a Java compiler on the target system. (Or, for that matter, a C compiler. Preferably, at all.)
Why is this useful, you ask? Well, a month or two ago, my wonderful girlfriend got a wonderful shiny new Android tablet. Naturally, I want to hack on her new toy, like you do. She will, however, very explicitly not allow me to root it. And, despite Android being based on Linux, it’s APIs are not C, it’s APIs are Java. There is hope: there is a perl implementation available, and even an Android.pm, which uses the Android Scripting Environment to allow you to be able to call Android APIs from perl-space!
So what’s wrong? As I was reading the docs for the ASE, I realized that it only allows use of a very few APIs. It had a lot of functionality near what I wanted, but not the specific bits I wanted.
So, Java::Bridge was started. It’s not as complicated as it sounds. Perl, of course, has a rich history of metaprogramming. You can create an modify classes at runtime to your heart’s content, and in the last few years, things like mro, Moose, and Class::Meta have made it much easier to do it. Java, it turns out, also has a (somewhat less nice, but not horrible) system for metaprogramming, called reflection. It has some niggles — most annoyingly so far, the rules of getMethod do not match the rules of the Java language — but it’s not horrible, and since my focus is calling Java from Perl, the worst depredations of hackery happen on the Perl side.
So, it’s somewhat slow going, but http://github.com/theorbtwo/Java—Bridge/ has my code thus far. Please, have a poke, ask me questions.
Surprisingly, like I said, it’s slow going — but there are very few points at which I went “oh, bleep, I don’t think this is possible”, it’s been more of “right, done, now only 10,000,000-1 things to do”. This is much preferable.
The next big hurdle is going to be letting you subclass java classes from Perl code, then pass them about. I’m afraid that’s going to be necessary for some stuff — it turns out that Java has a hack for dynamically creating a new class that implements arbitrary interfaces, but not that descend from arbitrary classes… but parts of the android API go “create a new subclass of android.app.Activity and change these methods” and the like, which shall be … tricky.
Oh, and of course, it doesn’t actually run on Android yet.
My, it’s hard to get me going, but I do like to waffle once you do, eh?
So, to repeat: http://github.com/theorbtwo/Java—Bridge/ - play, extend, enjoy, tell me what I’ve got wrong, what you want to be able to do.
Adventures in eclectic geekery.
Not to say you shouldn’t continue your current line of work — but I’ve had some very good luck using Inline::Java when building bindings to the HtmlUnit library (see WWW::HtmlUnit). This includes subclassing and all that. Perhaps something to take a look at if you haven’t already.
Inline::Java seems like good stuff, but it’s not what I’m trying to write. I’d like to make it so that you don’t have to code any Java, and so that your system doesn’t need to have a javac at runtime. It’s possible that I could write my code so that I write Java that works with Inline::Java, compile it once at module install time, and then you use my module and forget that it’s written with Inline::Java — which would give me the benefits of JNI, but contrarywise, also the drawbacks of JNI.
Hi
I want to use android classes in perl. I tried with Inline::java but it’s not work for me.
Can u plz suggest?