We Keep Coding

Java API for Vowpal Wabbit?

I am trying to use Vowpal Wabbit through Java. I have downloaded and successfully compiled the code from GitHub. The command line tool works fine.
After having a quick look at the repository (especially here), I can only assume that using it through Java is supposed to be already possible, and I don't really want to reinvent the wheel.
A wrapper around Vowpal Wabbit that allows use through Java. This wrapper is designed to be self contained. Because
of the use of JNI, a number of platforms are supported in this JAR.
I have added the maven dependency (found here) to my project, but without any kind of document, I don't really know where to start.
I have seen in another question that it seems to be possible to use VW with Java, but the guy only uses Runtime.getRuntime.exec() to call his bash command, and I can't find any documentation about any other way of doing (and there are only 2 questions mixing VW and Java on SO, which doesn't help).
I am new to JNI, so most likely there is something easy that I don't see.
To be perfectly clear, my questions are :
Should I just make a valid vw command and use it through Runtime.getRuntime.exec()? This doesn't seem to be the spirit of JNI, for there is no need for any wrapper/library for this. Plus, this doesn't make it very portable.
Where (the hell) is the (Java API) documentation ?
Any kind of help or guidance would be welcome.

I was one of the two primary authors of the VW JNI wrapper. Since the posting of this question the interface has significantly changed. We now encourage users to compile the native side on their own and provide it on the java.library.path. We have updated the README significantly to show how to use the library from Java.
I totally agree with your criticism that we have not published the Java API. I will work on that the next time I modify this code. In the meantime please feel free to clone the library and run mvn install and you can generate the Java API docs yourself. They should be quite detailed as we spent a lot of effort writing detailed docs.

You may checkout vowpal wabbit JNI wrapper we've built in Indeed: https://github.com/indeedeng/vowpal-wabbit-java.
We wrote integration test that can work as usage examples and we wrote API documentation as well. Check "using the library" section of README.
Hope this will help.

I don't think this adds a lot, but none of the previous answers really provided a clear answer. Like #Macchiatow mentioned, to use the Java wrapper which comes with Vowpal Wabbit, you would:
(on the project root dir) make all java or make java
cd into java and verify the installation with mvn test
you'd then mvn install to have the Java API jarred up and placed in your local maven repository. Supposedly this builds the JNI parts on your machine, so as to fit the C/C++ libraries of your platform if you have the necessary native C/C++ libraries installed and available to the make command.
you'd supposedly be able to include the vowpal package/s from those jars in the build tool used in your own project (ant/maven/boot/leiningen/sbt/etc. as in here).
For more background maybe see the Vowpal Wabbit Java readme. I think what it tries to say there, is that if you want a ready made jar from maven central, you should make sure it's the same vowpal version you're using, but without knowing more I'd guess if you built it like above, you are by definition using the same version.
I've had the above process work off a fresh clone, with Ubuntu 16.04 and Java 8.

This link may be of some help with regards to setting up a JNI wrapper.

I wasn't able to find Java API documentation anywhere, but Java code seems well documented - did you maybe try generating Javadoc yourself from the code?

There is indeed Java JNI wrapper to have a basic access to VW. By basic I mean to teach your model and to predict probability later on. They also provide Python library that can do far more than wrapper for Java. Recently I was forced to expose few more VW methods to Java by extending code provided.
Back to the questions:
Rather use the vw-jni artifact available in central maven repo and clone their code and run make all java. I some cases compiling code yourself will be the only solution, as for example provided artifact won't run on OpenSuse (my case)
Code available pretty straight forward. VWLearners::create is a factory to get an instance of VW from Java.

Scala or Java based on IDE and Memory footprint

We have huge stack of xml files (around 5000+ files) possibly about 80 MB when not compressed) all of them are device configurations used for read & write data & build user interfaces without any language dependencies. These XML files can be ported to any technologies like Android and Apple world. Not all the 5000+ are loaded at one shot to memory, we might load 200 files into memory based on 1 device connected. We have a .NET/WPF based application which is using those XML files to build the UI and access the device information through protocols like Modbus & Hart (Don't bother protocols now). Anywhere we need custom logic, we have written them in DLL's (in .NET) and we use the reflection & IoC to load those DLLs, create object and access them through interfaces at runtime to complete the XML configuration. On desktop, then we build UI and load configuration
Now We need to develop Android app which runs on Phone and tablet as well. I have 1 year experience working lightly in Java. We could write a core modules which can be used for both phone and tablet and UI layer which is just to render our XML as a UI elements. We know to use Java's Class Loader to create instance so that instead of DLL's we could build .jar file in Android world and load them (if possible?) and access via interfaces. When we load our XML, it will consume nearly 80 to 100 MB of RAM (in WPF & .NET).
When looking into Android world, I could not decide whether to go with Scala or Java. We do not have any Java expert to advise us. Having worked on Python, I feel like Scala is modern & good choice. Also I read that Android apps compiled using Scala is fat(big), take long time to boot up.
But coming from Visual Studio background, we are much sophisticated development team expect everything to run through IDE. Also team has to learn Java/Scala whatever our choice from start.
If we choose to work on Scala on Android, do we except the memory efficiency is near to Java? Also do we have sufficient IDE support (Eclipse or NetBeans or IdeaJ) for Scala?
I am specifically looking for Memory footprint (internals) and IDE support for building Android application. No discussion on performance or productivity..

My Scala IDE is Maven in one terminal window and Vim in another. The browser serves up help documentation. If you can base your build process on Maven, then any IDE should do fine. And since you are working a lot with XML files, I suggest that you do base your build process on Maven rather than SBT.
Of course, there is Eclipse support for Scala, Intellij supports it, there is a Netbeans plugin for Scala, even a Komodo language extension for Scala. Lots of IDE choices to try out. Only the developer knows what works for them.
Make half a dozen identical VMs. Install one IDE on each one of them. Get the developers (end users of the IDE) to test them and choose the one that they want. Do all of the build and continuous integration with SVN and Maven. Make that the boundary between the developers'personal toolset (the IDE or Emacs or Vim) and the supported development tools.

If you're coming from C#, I'd advice choosing Scala. That way you could actually preserve some of your business logic, because good C# code might probably look a bit like things are done in Scala, too. E. g. LINQ in C# and Scala's collection classes (v.s Java collections).
The syntax is a bit different compared to Java/C#, but syntax is hardly a real problem these days.
Java's IDE support is pretty good, but if you're coming from Visual Studio, Intellij (or Eclipse) + Scala plugin might be good enough for you.
If you program the same code in Java and Scala, memory consumption should be pretty the same.
You should keep in mind that you should use ProGuard to keep the size of the Android application manageable.

How to create a mobile oriented, multiplatform, shared library in Java?

I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?

This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.

These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.

Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.

The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.

it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch

Starting with Android: Java or Python (SL4A)

I just ordered an Android smartphone and want to start playing around with creating my own applications. Now the question is which language to use, the native Java or Python using SL4A (former ASE).
I tend to Python, as I know it much better than Java, but I'm wondering what I would be missing using a "second class" language on Android. On the SL4A website it is also stated to be alpha quality software, which is not exactly encouraging.
I'm also not quite sure what the limitations of the scripting environment are and if they would be problematic.

At the moment you cannot create a releasable program with Python (or any other scripting language) using SL4A. I have heard rumours that this is something Google is working on, but even if they do enable it Python apps are likely to be slow and power-hungry compared to Java. Also the scripting API only gives you access to a limited subset of the native Java API. I would not consider using SL4A for serious development work at the moment, only for one-off scripts and prototyping.
Take a look at Scala. It is a statically typed language on the JVM, but uses type inference to remove most of the noise that you get in Java. It also fully supports functional programming, and has a lot of pythonish features. Because it is statically typed it is as efficient as straight Java with none of the disadvantages. IMHO it is the language that Java should have been in the first place.
A lot of people are blogging about using Scala on Android, so Google around for more information.

More likely will depend what type of applications you will develop.
I would start with Java to become familiar with Android SDK. Anyway first you need to look into some examples, tutorials. Most of them are done in Java, and only a few, probably on the dev site of SL4A for that.
Also there is native development Android NDK, that can be programmed with C++.
But anyway Java rules for general applications.

Adding an update to Dave Kirby's answer:
Issue 55, Distribute scripts as APKs, in the issue tracker at SL4A deals specifically with that.
There is a solution being worked out (may be complete by now) described at SharingScripts. The only issue seems to be that you need to have a interpreter APK already installed.

you may want to check out Ruboto it is a framework for developing Android apps based on JRuby which means your JRuby code can call Android APIs and can also be called back from the Android Java side.
Here is an introduction article .

Consider ising Kivy, if you want to write Android apps with Python. The process of packing script to .apk file is described here.
The problem is, resulting .apk will be big (~7Mb for 300Kb data). It is obvious, because you need to pack there Python runtime and all libraries.
Another solution I have heard of, is Pygame for Android, but it works on lower lewel, so you need to draw graphics manually.
Unfortunately, I have not tried any of this ways yet, but it looks, that I'm going to start using kivy soon.

Suggestions for an embeddable scripting language for iPhone and Java app?

I'm developing an app for iPhone with a Java desktop companion that it synchs to over the network. I'd like to embed a scripting language into both apps so that end users can write scripts that add new behaviours and interact with the object model, and so that I can more rapidly develop some features.
Any suggestions for this, or anyone done this before and got experiences to share? I'm thinking of something like tcl which I've used in the past, but not tcl itself as I'm not a big fan of the language.
Main criteria are that it should be
lightweight as poss (memory usage)
easy to interface and extend with java and objective-c
(nice to have) readable/approachable for people with limited programming experience
My initial hunch is that I should be using one of python, ruby, or lua. My preference would be ruby, as I already have some experience with it and don't know much about the others. However my main unknown is which of these is easiest to get integrated with iPhone and Java.
edit 2: per Jason Coco in the comments, the SDK terms prohibit embedded scripting languages. Checking into this it does indeed seem to, but I read it to preclude dynamic installation and extension only. I would still be interested in answers here, as the agreement doesn't seem to preclude having prepackaged scripts inside the application bundle itself - Apple would still get to vet that code.
The agreement also seems to allow use of Apples "interpreters"...what are these? Javascript and what else? Any route to use those here?

JavaScript
As I understand the iPhone SDK Licence, there is nothing preventing you from using a scripting language in your app - just that you cannot intall any interpreters or runtimes of your own. You can only use those scripting languages for which Apple provides the interpreter in the SDK.
Given that you want to run the same scripts in your iPhone app and in a Java app, the obvious choice is JavaScript. You can use Apple's APIs in your iPhone app, and something like Rhino (http://www.mozilla.org/rhino/) in your Java App.
You have to be aware that there may be slight differences between the two interpreters in the more obscure regions of syntax or object model.
P.S. I assume that users are going to be writing their own scripts to run on their own device/desktop. These would be part of the application data, and should be fine under Apple's licence

The only thing I've seen that allows a non-objective-c/c/c++ application to run on the iPhone is Unity3d (http://unity3d.com/unity/features/iphone-publishing) - BUT, it uses C# via Mono and does a full static compilation (http://tirania.org/blog/archive/2008/Nov-05.html) down to native code in order to do it. So, by the time the app is on the phone, it's no longer C# so it's allowed by Apple (and several apps have already made it into the App Store - so this does seem to be acceptable).
I don't think you would be able to do the idea you're talking about even if you could do the equivalent for Java/Ruby/Lua/Python/other (so having your desktop app pre-compile and upload just the native code to the device). As far as I know, you can't execute code outside of your application bundle...and if you modify the application bundle, then you invalidate the codesigning Apple does which allows the app to run on your phone in the first place. So even if you could get executable code to the phone, I'm not sure that you would be able to run it if it didn't come along with the app in the first place.

I was researching this too, and it seems that it's possible to pre-compile a Lua script (by converting it to C using Lua and then compiling the C file). Because all of your code could then be part of the application bundle (including the embedded Lua interpreter), it should be acceptable as an iPhone app.
See here for a discussion and sample script:
http://lua-users.org/lists/lua-l/2008-11/msg00453.html
*Note that I haven't tried this (yet)