Gradle support for raspberry pi?

So, I can get this far…

pi@raspberrypi ~ $ gradle-1.1/bin/gradle -version
19:53:07.341 [main] DEBUG o.g.l.i.TerminalDetectorFactory - Unable to initialise the native integration for current platform: Linux 3.1.9+ arm. Details: Could not locate JNA native library resource '/com/sun/jna/linux-arm/'.
Gradle 1.1
  Gradle build time: Tuesday, July 31, 2012 1:24:32 PM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.7.0_06 (Oracle Corporation 23.2-b09)
OS: Linux 3.1.9+ arm

Attempting to run any tasks such as “gradle tasks” or start the daemon “gradle --daemon” results in the following error:

FAILURE: Build aborted because of an internal error.
  * What went wrong:
Build aborted because of an unexpected internal error. Please file an issue at:
  * Try:
Run with --debug option to get additional debug info.
  * Exception is:
        at org.gradle.internal.nativeplatform.filesystem.FileSystems$DefaultFileSystem.<clinit>(
        at org.gradle.internal.nativeplatform.filesystem.FileSystems.getDefault(
        at org.gradle.initialization.DefaultCommandLineConverter.convert(
        at org.gradle.initialization.DefaultCommandLineConverter.convert(
        at org.gradle.launcher.cli.BuildActionsFactory.createAction(
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.createAction(
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(
        at org.gradle.launcher.Main.doAction(
        at org.gradle.launcher.Main.main(
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
        at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(
        at org.gradle.launcher.GradleMain.main(
Caused by: java.lang.ClassCastException: org.jruby.ext.posix.JavaPOSIX cannot be cast to org.jruby.ext.posix.BaseNativePOSIX
        at org.gradle.internal.nativeplatform.filesystem.FileSystemServices.addServices(
        at org.gradle.internal.nativeplatform.filesystem.FileSystemServices.<clinit>(
        ... 22 more

It’s the Raspian Wheezy distribution from 08-08-2012, which is a Debian variant. uname -a provides: Linux raspberrypi 3.1.9+ #272 PREEMPT Tue Aug 7 22:51:44 BST 2012 armv6l GNU/Linux

A simple check for the return type of the PosixUtil.current() call in the “linux/macosx” section would probably be sufficient. I’m guessing the Linux/Mac libC calls are better for chmod or stat than Java 7, since they are tested first? I may try hand-patching so that the Java 7 test runs first and see how things fare from there.


Hi Spencer, I opened GRADLE-2445 for this.

I think you meant issue GRADLE-2445, at

I actually searched the issue database, but couldn’t find it, because Raspberry is missing the “p” in the issue title. Had to look through the latest issues created instead.


Sorry about that. You’re correct.

This should be fixed. Can you try with a recent nightly build from

The filesystem access issue is resolved. Thanks.

There is still the TerminalDetectorFactory warning that I’ll want to get rid of.

As expected, it’s quite slow on such reduced hardware, and the daemon is essential to even make it run, but I was surprised that the daemon claimed 1353MB (yes, that’s ~1.2GB) of virtual memory. Resident memory is 46MB, which is quite a bit of the 256MB total RAM. I’m going to also try the embedded JVM version later and see if it shrinks that some.

Just for reference. With the daemon running it takes 13 seconds to invoke gradle tasks. All of that time is basically JVM start up for the client call.


The daemon currently uses a very generous default for heap size. You can configure the JVM arguments that the daemon uses:

Also, we do have a prototype native client for the daemon which addresses the client startup. It’s currently not ready for any practical use, but we do intend to release it at some point.

I’m wondering if it makes sense to in the future have the default daemon launch be computed against the actual RAM available on the system it is running on.

I assume the native client is written in C or C++, but I do not see anything like that in the codebase anywhere. Attempting to do anything productive on the Raspberry Pi really makes me want to have a native client, even if it is just a prototype ;-).

I’m also looking into the JNA issue, and part of it is clearly that an older version 3.2.7 is being used, but even with the newer version I’m not sure that ARM stuff is for the “correct” flavor of instruction sets. I see that a whole bunch of new classes got added in newer versions of JNA and the whole package is significantly larger, which is probably part of the reason for not upgrading yet.

I’ll have to see what jamming in version 3.4.1 does :slight_smile:


I’m wondering if it makes sense to in the future have the default daemon launch be computed against the actual RAM available on the system it is running on.


I assume the native client is written in C or C++, but I do not see anything like that in the codebase anywhere.

It’s in a branch:

We haven’t upgraded to a newer JNA due to some issues on OS X that we haven’t had time to hunt down yet.