Trying to solve the properties memory problem
Fixing property copying
Fixed memory leak (which triggered asserts in tests)
Replacing strcpy with memcpy - should be slightly faster because we're forced to know strlen, so no need in byte-by-byte copying
Merge pull request #224 from bigfatbrowncat/avian-pack

Properties don't work in some cases
fix incorrect EXPORT definition for Windows/x86_64 in boot-javahome.cpp

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.
only define soname-flag and version-script-flag for openjdk builds

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.
fix Android bootimage build

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.
add expect call to ensure tryAllocateExecutable actually succeeds

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.
fix broken Android build due to 617bd85

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.
Merge pull request #228 from dicej/expect-executable

add expect call to ensure tryAllocateExecutable actually succeeds
Merge pull request #225 from dicej/javahome

fix incorrect EXPORT definition for Windows/x86_64 in boot-javahome.cpp
Merge pull request #227 from dicej/flags

only define soname-flag and version-script-flag for openjdk builds
Merge pull request #229 from dicej/preBoot

fix broken Android build due to 617bd85
Fix tyop

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>
Merge pull request #230 from dscho/lastest-javadoc

Fix typo
Merge pull request #226 from dicej/android-bootimage

fix Android bootimage build
update "Quick Start" examples in README.md

It's safer to assume developers are using x86_64 rather than x86_32
these days, and JAVA_HOME should be defined as
$(/usr/libexec/java_home) on OS X.
Merge pull request #232 from dicej/readme

update "Quick Start" examples in README.md
Small change to make these two structures implement RandomAccess (as they should)