[INACTIVE] Avian is a lightweight virtual machine and class library designed to provide a useful subset of Java's features, suitable for building self-contained applications.
Prior to this commit, we had a little bit of "cleverness" wherein we
recursively invoked make to determine which of the .class files in the
class library were out of date with respect to their .java files. We
did this to avoid asking javac to recompile everything every time.
The problem with that is when building against an alternative class
library (e.g. OpenJDK or Android), we use a combination of classes
from the alternative library and some of the built-in Avian classes
(e.g. java/lang/invoke/MethodHandle, which is very closely tied to the
VM). This confuses the build process, since some of the classes were
taken from an external jar, and some of them were built from source.
The tricky bit is that, depending on the relative timestamps of the
extracted .class files and the .java source files, you might never see
the problem. That's why I couldn't reproduce this when it was first
reported a few months ago: my source files were newer than the .class
files from the OpenJDK jars I was using, so the Avian versions were
built and used as intended. It was only later when I used a newer
OpenJDK that I hit the problem.
Anyway, I've removed the cleverness. If this causes an unreasonable
regression in (re)build times, we can try to reintroduce it in a way
that avoids the above problem, but for now simpler is better.
Prior to this commit, we had a little bit of "cleverness" wherein we recursively invoked make to determine which of the .class files in the class library were out of date with respect to their .java files. We did this to avoid asking javac to recompile everything every time.
The problem with that is when building against an alternative class library (e.g. OpenJDK or Android), we use a combination of classes from the alternative library and some of the built-in Avian classes (e.g. java/lang/invoke/MethodHandle, which is very closely tied to the VM). This confuses the build process, since some of the classes were taken from an external jar, and some of them were built from source.
The tricky bit is that, depending on the relative timestamps of the extracted .class files and the .java source files, you might never see the problem. That's why I couldn't reproduce this when it was first reported a few months ago: my source files were newer than the .class files from the OpenJDK jars I was using, so the Avian versions were built and used as intended. It was only later when I used a newer OpenJDK that I hit the problem.
Anyway, I've removed the cleverness. If this causes an unreasonable regression in (re)build times, we can try to reintroduce it in a way that avoids the above problem, but for now simpler is better.
Fixes #479