ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

"Official" Java Client Library

We are planning to use some Java nodes in a ROS2 project. When we searched for Java and ROS2 we encountered several repositories that allow to start ROS2 nodes in Java (e.g. and

Is ROS2-Java the “official” (or preferred) Java client library for ROS2?


I’ve been working on The dashing branch should be compatible with ROS 2 Dashing and Eloquent. I wouldn’t say the branch is stable yet as we don’t have a release, but I’m working on it, along with items listed here (contributions welcome!)

I wasn’t aware of At a glance it sounds like it requires you to use this specific communication layer, and so probably not as general as It might make sense to try and consolidate efforts between the two projects, I’m not sure.


Hi Jacob,

I am trying to create an example project for ros2-java. I followed the steps in the git README, but the step ament build --symlink-install --isolated keeps failing.

I tried to run it with a fresh installation of ROS2 Dashing on Ubuntu 18.04. A copy of my console output can be found here: What version of ROS2 do you need to set ros2-java up? Can you provide me information on how to get it working?

I see that dashing is not yet supported (
What version of ros do you suggest?

Update 2
I found the ros2-java-branch for ros2 dashing here. The building goes fine, until it starts building rcljava_examples. I get the following error:
> Task :compileJava FAILED /home/niels/opentcs/integration/ros2-java/ros2_java_ws/build_isolated/rcljava_examples/src/main/java/org/ros2/rcljava/examples/service/ error: package example_interfaces.srv does not exist final example_interfaces.srv.AddTwoInts_Request request
See full log here.

It looks like there are files (example_interfaces) missing. Due to this error, it’s also not possible to run the examples. Can you provide me instructions on how to fix this problem?

@jacob I asked your remark “It might make sense to try and consolidate efforts between the two projects, I’m not sure.” in the ihcm-java-ros2-communication repo and their response is that the goals of the projects are different. Could you have a look at their points and share your vision there?

Reading the comments by Jesper it seems that his ideal:

a pure Java implementation of ROS2 below a pure Java implementation of the communication, avoiding any native code

is something which in ROS 1 led to almost all client libraries except the two main ones to never reach any form of feature parity or consistency in behaviour. They typically only implemented the bare minimum to be able to communicate with other ROS nodes, lacking many of the convenience features.

Even now there are things which are different between roscpp and rospy (although the situation has improved over the years), and those have the largest possible community around them.

The idea behind making all client libraries wrappers around rclc is exactly to avoid this.

I’m not sure this is being achieved right now, but feature parity and behavioural consistency between libraries would then depend on the wrappers getting updated to support new functionality in rclc, instead of maintainers having to implement new infrastructure completely from scratch. It’s probably too early to tell whether this is a lower-cost task, but that’s at least the idea.

Related page: About ROS 2 client libraries: Common functionality: the RCL.

1 Like

Let’s continue the discussion here.

While my ideal would be a pure native implementation, this is a lot of work. I agree that wrapper rclc would be the neatest solution from our side.

However, ideally that means we can compile rclc as a stand-alone library that we can statically link and include in our project. I think messages should still be compiled to native java code and a day-to-day developer should not have to re-compile the messages for all platforms the code runs on to distribute.

We actually started on using RTPS before ROS2 came out and all the IHMC ROS2 packages do is provide a small wrapper around the RTPS libraries that set the correct topic names and data types as well as provide the ability to compile .msg to .idl (which can then be easily converted to .msg). When I worked on this there was little to no documentation on the new ROS2 libraries, so my assumptions might be a little outdated.

I’m a maintainer of IHMC Robotics’ ROS 2 support and just wanted to add a few things.

Our biggest requirement is allocation free communication in order for our realtime robot controller to accept commands and publish configuration status. We run a normal JDK on top of a patched Linux kernel allowing us to create realtime threads in Java. If our Java software allocates memory over time, it will trigger a garbage collect, causing missed realtime deadlines.

Our approach to supporting ROS 2 was as a bonus feature. We are basically using SWIG on FastRTPS with some modifications to ensure zero Java allocations. We periodically upgrade FastRTPS to a version matching a ROS 2 release, but it has been rarely necessary. The only incompatibility between releases so far has been between Ardent and Bouncy when they changed how the topics were partitioned. That change didn’t even require upgrading FastRTPS. I’m only saying this as an argument that it might not require that much maintenance for any custom solution.

Also, we aren’t using very many ROS 2 features. We hardly even use any of the standard messages, but we would like to change that. We are using basic publish and subscribe with some FastRTPS performance settings. Our intraprocess mode is currently 100% Java. We don’t support ROS services or parameters, for example.

Our message type support is currently a forked and modified version of the official python msg -> IDL generator (.em template), which we then convert to a Java type using ANTLR. We add several convenience features to the Java types like deep copy, Javadoc sourced from the .msg file, and some others. This is actually the nicest part of our library. We do lack .msg dependency management because we aren’t in a ROS 2 workspace, so we have a hacked together system for that.

I am still somewhat unfamiliar with how ros2-java works. If someone could explain the ideas and tech behind it, that would be enormously helpful.

Java is a very difficult step for ROS to support because its build system is completely different. We have a similar setup to a ROS workspace for Java achieved with a complicated Gradle plugin. We too have the ability to clone several repositories to a folder which automatically get assembled into a single build. When dependencies aren’t present via source code, they are resolved via Maven.

I am a big fan of ROS in general. They have solved a lot of the same problems as us. I would be extremely excited to see the integration of these two projects.