Fastest way to compile small Java files

I'm looking to programmatically compile (not through IDE) a few small classes such as:

public class Sum {
  public int sum(int[] nums) {
    int total = 0;
    for (int i = 0; i < nums.length; i++) {
      total += nums[i];
    }
    return total;
  }
}

Running javac Sum.java takes 429ms on macOS (2.3 GHz Intel Core i5) but in a Kubernetes container (t3.xlarge) with 3VCPU, and 6G of RAM, it takes 640ms. What causes this difference?

I tried different java versions and tried using javax.tools.JavaCompiler but with few files, it takes up to 2 seconds to compile 3 small files like these.

What's the best configuration of hardware/software to make a compilation of these small files fastest?

The number I just got empirically is 5ms/file...

If you have a lot of Java files to compile, then maybe you care about this. But if that's the case, then the timing numbers you're talking about are not realistic. I wrote this program to compile your test program 1000 times (I created 1000 java files defining classes Sum0 through Sum999.

import javax.tools.JavaCompiler;
import javax.tools.ToolProvider;

public class T {
    public static void main(String[] args) {
        JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
        int N = 1000;
        String[] files = new String[N];
        for (int i = 0 ; i < N ; i++) {
            files[i] = String.format("stage/Sum%d.java", i);
        }
        int result = compiler.run(null, null, null, files);
        System.out.println("Compile result code = " + result);
    }
}

I ran it, and here are the timing figures for that run:

> ls stage/*.class | wc -l
ls: stage/*.class: No such file or directory
       0

> time java T
Compile result code = 0

real	0m2.511s
user	0m4.737s
sys	0m0.549s

> ls stage/*.class | wc -l
    1000

So the total runtime was 4.737 seconds / 1000 = .005 seconds = 5 ms /file. All I can think of is that you're compiling files one at a time, in which case all the time is some kind of startup/teardown cost, and who cares about that.

The bottom line is that you can probably compile however many Java files you want in just a few seconds, so stop worrying about this.

This was run on a couple of generations back MacBook Pro.

Wahaaaaaay back in the distant, distant past, we had 'incremental compilers'. These would run continuously. You start them up once at the start of the day or whatnot and then just leave em running forever. They would then either wait for any keyboard input (an enter press), or set up some file watches (hooks that trigger when any file is modified in a given directory) and recompile every time that was needed. This saves VM warmup and VM boot loading.

I think they mostly died out as the build tools (particularly maven and gradle) became popular. The model doesn't mesh well with build systems; the build system itself should be the incremental unit (should run once and stay loaded), and must therefore also internalize the compiler in order to avoid having to init and warmup a VM every time it needs to compile.

Given that you want to compile one simple single small file, the VM init and compiler warmup is most likely 99% of that 640ms. An incremental compiler would be precisely what you need.

Incremental compilers still exist, but the only modern one I know of, is eclipse: If you save a file in eclipse, eclipse will almost instantaneously compile it using its own built in compiler. That's.. clearly not what you're looking for.

You can search the web if something incremental still exists and is decently maintained. You should also be able to handroll this, perhaps: Have a java app that will do something like: Listen for any full lines on system input (e.g. with Scanner and .useDelimiter("\r?\n"); .next(), treats those lines as files or dirs, will scan those for any new or changed files, invoke javax.tools.JavaCompiler on all changed things, and then update a hashmap mapping files to timestamps, and then go back to sleep waiting for more System.in traffic, using that map to decide on caches. Or forget the map and go old style: Find the class file, compare its timestamp to the source file's timestamp, and if the class file's stamp is newer, there is no need to recompile it. This doesn't quite map perfectly onto how java works (1 source file can produce multiple class files and it is not possible to determine from a class file name which source file produced it, though you probably can if you add enough debug info and open it up, but class files are quite a complex format so doing that is non-trivial) - so I'd do the hashmap, even if the compilers of yore went with the 'compare class file last-modified with source file' option.

Alternatively it could open up a TCP/IP port.

Note that eclipse also comes in 'language server' form which is exactly how VSCode works: When you edit java code in VSCode, VS starts a headless eclipse and uses it to do, well, everything 'intelligent' about java: Refactor scripts, live compilation, errors, warnings and general linting services, nav services (such as 'open type', 'find callers'), the debugger, and more. Compiling is part of the bevy of services that eclipse-as-a-language-server offers, and ecj is 4 to 10 times faster than javac to boot (speed of actual compilation after VM init and warmup is probably a fraction of a percent of that 640ms, so therefore not relevant, but I don't know exactly how fast you need this to be).