Since we can't predict what warnings future compilers will emit, and
most people just want to build Avian without some new warning tripping
it up, we now omit -Werror unless requested via the "use-werror=true"
option to make. Note that we pass "use-werror=true" in test/ci.sh to
ensure Travis alerts us to new warnings as they appear.
BTW, sorry about the unrelated whitespace changes in this patch; I've
got Emacs set up to fix whitespace "problems" on save, and those are
what it found.
This option specifies that the test classes should be AOT-compiled
along with the class library, which allows us to test that everything
works in AOT-compiled form as well as JIT-compiled form. This is
primarily motivated by the need to test d906db6 (support for
AOT-compilation of Java 8 lambda expressions).
Note that I had to tweak Misc because it tested something that
couldn't be done in an AOT build without a lot of extra work, and
SystemClassLoader.getPackage because it was returning null when the
requested package could not be populated with JAR manifest metadata.
Technically, we probably *should* return null for packages that don't
exist at all (in the sense that no classes have been loaded from such
a package), but tracking that kind of thing seems like more trouble
than it's worth unless someone complains about it.
Lots has changed since we forked Android's libcore, so merging the
latest upstream code has required extensive changes to the
Avian/Android port.
One big change is that we now use Avian's versions of
java.lang.Object, java.lang.Class, java.lang.ClassLoader, some
java.lang.reflect.* classes, etc. instead of the Android versions.
The main reason is that the Android versions have become very
Dex/Dalvik-specific, and since Avian is based on Java class files, not
dex archives, that code doesn't make sense here. This has the side
benefit that we can share more native code with classpath-avian.cpp
and reduce the amount of Java/C++ code duplication.
So there I was, planning to just fix one little bug: Thread.holdsLock
and Thread.yield were missing for the Android class library. Easy
enough, right? So, I added a test, got it passing, and figured I'd go
ahead and run ci.sh with all three class libraries. Big mistake.
Here's the stuff I found:
* minor inconsistency in README.md about OpenSSL version
* untested, broken Class.getEnclosingMethod (reported by Josh)
* JNI test failed for tails=true Android build
* Runtime.nativeExit missing for Android build
* obsolete assertion in CallEvent broke tails=true Android build
* obsolete superclass field offset padding broke bootimage=true Android build
* runtime annotation parsing broke bootimage=true Android build
(because we couldn't modify Addendum.annotationTable for classes in
the heap image)
* ci.sh tried building with both android=... and openjdk=..., which
the makefile rightfully balked at
Sorry this is all in a single commit; I didn't expect so many
unrelated issues, and I'm too lazy to break them apart.
There are two important things here:
* We only want to run "jdk-test" if we were running "test" for everything else.
This gets around a bug where jdk-test fails for cross-compile builds (where JNI is involved)
* We can specify a different test target by setting the "test" environment variable.
This is useful for cross-compiling the tests in a docker image
(setting the test_target to "build-test")
The intent of this target is to run our test suite against the installed jre.
This should help prevent our VM from diverging in implementation from the jdk.
The remainder of this commit fixes the problems that this exposes.
