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.

Handling specific Java version for desktop application

What is the best way to handle situation, when a Java desktop application (executable JAR) requires specific (or newer) version/update of Java, to not get some NoClassDef exceptions?
Details: I have JavaFX 8 desktop application, build with Maven and com.zenjava.javafx-maven-plugin to executable JAR. I'm using new features of JDK 8u40. I would like to nicely handle situation, when someone is trying to run it with older Java version.
First, most low-end approach is to check
System.getProperty("java.version");
at the start of main function, parse it with a couple of "ifs" to extract is it major >= 8 and update >= 40, if not show some popup instead of app. But it seems to me like mediocre solution.
I wonder are there better ways? I'd love to know more about direct code solutions, external libs, additional jar launchers or Maven options for this purpose.
Edit: additional info - I would like to avoid platform-specific solutions

The solution which mostly works: just create a native bunde with included JRE. This is the default when calling mvn jfx:native, so you shouldn't worry about the class being there, because you bundled that specific version.
That is the main reason why some are using that option. Just imagine the situation you are require Java 8 but the user just uses Java 7 and so on, it makes the bundle bigger, indeed, but it preserves you from such problems.
Disclaimer: I'm the maintainer of the javafx-maven-plugin, there are example-projects ;) but no cookies yet.

How to install Robot Operating System ROSJava on Windows?

The documentation for ROS is terrible.
One great irony is that the Groovy and ROSJava versions of ROS was created to allow developers on platforms like Windows to utilize the great robotics SDK, while all the installation instructions are still geared toward linux/ubuntu users.
The ROSJava core documentation says:
TODO: write a guide for a strictly java installation.
I've tried to follow the instructions here on the Google Code project, but seeing as all the instructions assume I'm running Ubuntu, it is very difficult as a traditional Windows/Web developer to translate into windows instructions on my own.
The link is also broken to the GIT repo, it is moved to github: https://github.com/rosjava/rosjava_core.git
If you were looking for rosws documentation, its here. Another broken link: http://www.ros.org/doc/independent/api/rosinstall/html/
Now, wanting a versatile IDE for coding, I chose Eclipse because it can handle Python, Java and c++. Now I have no idea how to build this project with Gradle and Maven-- Heck, I'm not even sure I should be building it.
Is there a definitive installation/build tutorial for ROSJava on Windows? If not, I think it would greatly benefit the community if somebody could create a walk-through that can help developers make their first "Hello World" in robotics. I've done some processing and some light Java before, but nothing too serious. The manual should assume you are new to Java, ROS and all the dependencies/build helpers/compilers. I feel like all the instructions from Google Code and ROSWiki assume you're familiar with many tools and dependencies or are aware of the historical context of ROSJava versus Groovy versus Linux implementations. Many of the necessary tools are off the beaten path for a C#.NET, Objective C or Javascript/Web developer.
Also, a big detriment is that the pre-compiled version of the ROS SDK is outright missing from ROSWiki. "Page Does Not Exist" so, us newcomers have to also install 10-16 dependencies for compiling the core (not to mention figuring out how to configure and use them).
Additionally, build scripts named in the Wiki don't even exist yet.
Currently, I've not even gotten far enough to start encountering problems like this: Gradle Eclipse Plugin

While the ROS documentation has improved in general during the past years, the ROS Java documentation is even currently not as detailed.
Using ROS_JAVA is in fact as easy as using any other dependency if you do not use custom messages.
ROS_JAVA can be practically divided in two parts.
An API to create your own servers/clients and publishers/subscribers
A pure Java roscore
The API is perfect for accessing and consuming ROS based services/topics/actions written in any language.
The pure Java roscore can be used for testing, or installation in any system that runs Java, in cases where the C++ ROS is not supported. However it is not as complete as ROS C++.
If you do not use custom messages you can easily add the required dependencies.
The following configuration should work in gradle.
repositories {
repositories {
mavenCentral()
maven {
url "https://github.com/rosjava/rosjava_mvn_repo/raw/master"
}
}
}
dependencies {
implementation 'org.ros.rosjava_core:rosjava:[0.3,0.4)'
implementation 'org.ros.rosjava_bootstrap:message_generation:0.3.3'
implementation 'org.ros.rosjava_messages:std_msgs:0.5.11'
}
This is part of a simple "Hello World" pure Java project that I have published here.
For programming only in Java /ROS Java you do not need to install ROSjava in windows. (This is also an article I had written trying to provide some quick instructions on the issue.)
If you also need to compile messages without a ROS installation then you can also do this manually through java.
Finally it is worth noting that ROS Noetic can be installed in windows. While this is not a requirement for development using ROS java.

Java Applet allowed for Javac or other jar access?

I am involved in a project that will need to run via web and have access to java's compiler tools and/or javacc api. My team is thinking of using a java applet to make it web based. I'm wondering if there are certain limitations on what an applet can and cannot do in this case. I would assume that since access to the compiler would be done on the server, not the client's machine, that this wouldn't be a problem. Does an applet allow us to separate the two as described?

An applet (and even a JavaFX applet) can work in this situation if the applet is signed. There are numerous subtle pitfalls with applets, so I would advise prototyping before committing to that technology. Follow the JavaFX deployment guide to see how to deploy a JavaFX based applet.
I had thought that to compile Java, you needed to have the full Java Development Kit installed (which would be tricky to ensure in an applet deployment situation). But it seems that the compile API is included in the javax.tools API included with the standard Java Runtime Environment. So this likely means that you could develop your solution, including client based deployment and compilation of Java code, without requiring the user install the full Java Development Kit.
You may alternately wish to consider a client/server solution where the compilation can be performed on the server. An example of such an approach (with a Java WebStart based solution) is the TopCoder Algorithm Competition Application. Here is a jnlp file (http://apps.topcoder.com/wiki/display/tc/The+Algorithm+Competition+Arena) to run this application. I suggest you register an ID at TopCoder using the application and try out writing and compiling some code using it. The TopCoder implementation uses plain Swing as it was written before JavaFX existed, but you could equally use JavaFX for your implementation if you preferred.
If you additionally need an editor (with syntax aware text styling) for the code you will be compiling, you could use something like this CodeMirror based editor embedded in JavaFX. The CodeMirror based solution wraps the editor in html based WebView control. For JavaFX 8 you will probably be able to make use of the new TextFlow control for a syntax highlighting text editor, but that API is not part of a supported public release yet.
Update
I got this work using the strategy outlined in this answer.
The image is an html page allowing access as an applet or a webstart application to the client code editor. The top area of the image is the code editing area which is based on a WebEngine with an embedded syntax highlighting CodeMirror JavaScript editor that supports Java editing. The bottom area of the image is the output of compiling the code in the editor locally on the client machine and subsequently running it. The output constists of any compilation errors, any program output to sysout, as well as any runtime exceptions printed to syserr. The tricky parts of the solution were:
Working out how to capture sysout and syserr and redirect them to a JavaFX control.
Finding the Java compiler.
The default Oracle Java Runtime Environment Provider merely provides a generic interface to a Java Compiler implementation, but it provides no java compiler implementation itself - that implementation is only included in the tools.jar included with the jdk. So when I packaged my applet, I included the tools.jar in the packaging for the applet. I had some difficulty getting the service provider interface to get me an instance of the javac compiler, so in the end, I just instantiated it using the following line:
JavaCompiler compiler = new com.sun.tools.javac.api.JavacTool();
The above is somewhat brittle as sun may change their private com.sun classes at any time - but at least it worked in this instance.
Another thing to be aware of is that if you ship a tools.jar with a javac compiler which is earlier than the runtime environment that you have available for your system, then you might get some warnings such as below:
warning: C:\Program Files\Java\jre8\lib\rt.jar(java/lang/Object.class): major version 52 is newer than 51, the highest major version supported by this compiler.
It is recommended that the compiler be upgraded.
The above warning occurred because I shipped the applet with a java 7 tools.jar and ran the applet with a java 8 runtime (note that the applet worked fine regardless of those warnings).
Update
I put the code for this solution in a github repository (project name conception). The updated solution uses the Eclipse Compiler for Java rather than the Oracle Java Compiler. Mostly because, for the Eclipse Compiler, it is a separate jar (only 1.8meg rather than the 14meg tool jar of the oracle distribution) and the licensing is a bit clearer. Because the Java compiler interface is pluggable, the Oracle compiler can still be used if tools.jar is placed on the classpath.

Yeah applets can access them and can be a good choice. But it has very limited/ dull look and feell. Go for JavaFx in this you can define your own StyleSheet so it will give you a very good look and feel and yeah definitely it will separate the two layers too.
JavaFx Oracle Documentation

Open Office Spellchecker / Java API

Is it possible to make use of the Open Office spell-checker outside of Open Office for other Java programs?
Walter

We have done exactly that - used the hunspell engine from java. There is a JNA bridge that can be used to invoke hunspell from java. Very nice to use - takes care of loading the appropriate native library from the jar.
The only problem is that the bridge is not updated with the latest hunspell engine - it is at version 1.1.12, and at the time I looked (last year), hunspell was at 1.2.18, which contained fixes we needed. It's not a big deal to build the hunspell libraries and rebuild the JNA wrapper with the latest hunspell engines, although it does involve cross-platform compilation. IIRC we used a windows box and a linux box to rebuild both those platforms (cygwin on windows didn't cut it) and we didn't need the version for OS X. I can let you have what we built if that's useful.
See
Java API for Hunspell
jna.dev.java.net

OpenOffice simply uses hunspell for the spell checking - you should investigate it instead. Its home page mentions the existence of two java interfaces/ports.