The Misc test was failing when run as "make input=Misc run" since
test-flags did not include $(build)/extra-dir in the class library,
leading the ClassLoader.getResources test to fail.
Also, the UnknownHostException test was not reliable -- some ISPs
(mine included) return DNS matches for bogus hostnames, defaulting to
the IP address of a webserver intended to help users with name
resolution problems. That's dumb, I know, but I'm guessing I'm not
the only person with a dumb ISP, and it seems better to just remove
the test than make people think Avian is broken when it's really just
their DNS server that's broken.
Let's not say 'lastest'. That would only confuse non-native speakears
such as yours truly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
617bd85 broke the Android build by creating an unresolvable
order-of-operations bug in classpath-android.cpp's
MyClasspath::preBoot method.
The problem is that, while JNIEnv::FindClass is supposed to initialize
the class that it finds, this causes JniConstants::init to indirectly
invoke native methods which are not registered until JNI_OnLoad is
called (which happens after JniConstants::init is called). However,
if we call JNI_OnLoad first, that causes methods to be invoked which
rely on JniConstants::init having already been run.
I haven't checked to see how Dalvik handles this, but I don't see any
way around the problem besides disabling initialization by
JNIEnv::FindClass until the preBoot phase is complete. Moreover, it's
dangerous to allow Java code to be invoked so early anyway, since the
VM is not yet fully initialized.
For some reason, running Avian under the SVN version of Valgrind
caused mmap to fail, which caused tryAllocateExecutable to return a
null pointer, which led to a non-obvious crash later on. Adding an
expect to check the result immediately will at least make it obvious
what went wrong.
bb86500 was a step in the right direction, but there was a bug that
caused Type_pad fields to be inserted between every other field in for
a derived class when type-maps.cpp was generated, and this led to
miscompilation of e.g. Android's
java.lang.reflect.Constructor.getModifiers.
These flags are only needed to ensure that libjvm.so can be used as a
drop-in replacement for OpenJDK's VM, and that only makes sense for
openjdk builds (without the openjdk-src option). It didn't hurt
anything to define them unconditionally, but it was misleading.
We should define EXPORT to be __declspec(dllexport) on Windows
regardless of architecture, not just non-x86_64 arches. This fixes
errors to to embedded JAVA_HOME files not being found in openjdk-src
builds, e.g. lib/currency.data.
Although the JNI reference documentation does not mention it,
FindClass should initialize the class before it returns it. That's
what HotSpot does, and that's what we have to do too.
In particular, OpenJDK's
Java_java_net_Inet6AddressImpl_lookupAllHostAddr relies on
Inet6Address's static initializer being run when it is resolved using
FindClass, or else it will crash.
Previously if there was a problem communicating to GitHub or if there was an issue with the GH_TOKEN the token would be displayed and stored in Travis. This update hides the token but still indicates the result for Travis.
The -flto flag slows down linking dramatically without providing a
noticeable improvement in speed or size. Rather than take the
build-time hit every time we rebuild, let's only do it when it's
explicitly requested.
* Unsafe.arrayIndexScale was always returning the native word size,
due to a thinko on my part
* Unsafe.getLongVolatile and putLongVolatile did not work for array
elements on 32-bit systems
