The former just defers to the latter for now, since it provides
strictly weaker guarantees. Thus it's correct to use full
volatile-style barriers, though not as efficient as it could be on
some architectures.
Unsafe.compareAndSwapLong was moved from classpath-openjdk.cpp to
builtin.cpp, but the fieldForOffset helper function was not, which
only caused problems when I tried to build for ARM. This commit moves
said helper function, along with Unsafe.getVolatileLong, which also
uses it.
Most of these regressions were simply due to testing a lot more stuff,
esp. annotations and reflection, revealing holes in the Android
compatibility code. There are still some holes, but at least the
suite is passing (except for a fragile test in Serialize.java which I
will open an issue for).
Sorry this is such a big commit; there was more to address than I
initially expected.
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.
Method.invoke should initialize its class before invoking the method,
throwing an ExceptionInInitializerError if it fails, without wrapping
said error in an InvocationTargetException.
Also, we must initialize ExceptionInInitializerError.exception when
throwing instances from the VM, since OpenJDK's
ExceptionInInitializerError.getCause uses the exception field, not the
cause field.
Inner classes can have inner classes, but getDeclaredClasses() is
supposed to list *only* the immediate inner classes.
Example: if class Reflection contains a class Hello that contains
a class World, Reflection.class.getDeclaredClasses() must not
include World in its result.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We should pass the method of the original interface to the
InvocationHandler, not the method of the interface.
That way, proxy instances of annotations will have easy access to
the default values.
This happens to be compatible with the way Oracle Java does it, too.
To accomplish our goal, we keep a global map between proxy classes and
Method references and assign the appropriate list to a field of the
Proxy subclass. This means that we now have to call the super-class
constructor in the generated constructor (which is the correct thing to
do anyway... ;-)).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is only a cosmetic change, but we should not call getName()
over and over again ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Proxies implement interfaces whose methods *must* be public, as per the
specification of the Java language.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This developer did not read the specs closely enough and missed that
the length of the byte array needs to be written out first, so that
DataInputStream#readUTF has a chance of reading the string back.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the class whose field is to be inspected has no annotations at all,
at least my javac here (1.6.0_51 on MacOSX) does not produce any class
addendum.
Therefore, let's verify that the addendum is not null before proceeding.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is done by implementing the readObject()/writeObject() method
pair as demanded by the serialization specification. The specifics
were reverse-engineered from serializing trivial TreeMap instances
with OpenJDK.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This will be needed for Java-compatible serialization of tree maps.
Note that the field should be null when the TreeMap uses the default
comparator.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We punted previously on any serializable super class' descriptor and
simply expected the super class not to be serializable (and consequently,
we expected the respective descriptor to be null). However, for quite
common classes, e.g. OpenJDK's Double class, this is not true.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There are serialized objects out in the wild which make heavy use of
TC_REFERENCE: for example when an object has a reference to itself.
Therefore we need to support that, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We punted previously on any serializable super class' descriptor and
simply expected the super class not to be serializable (and consequently,
we expected the respective descriptor to be null).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The specification of the Java deserialization demands that a private
readObject(ObjectOutputStream) method is used -- if it exists. In
that case, ObjectInputStream must not initialize the contents of the
fields (called 'classdata[]' in the documentation) but offer that
functionality via the defaultReadObject() method.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The specification of the Java serialization demands that a private
writeObject(ObjectOutputStream) method is used -- if it exists. In that
case, ObjectOutputStream must not write the contents of the fields
(called 'classdata[]' in the documentation) but offer that via the
defaultWriteObject() method.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The serialization protocol specifies a quick method to serialize
a String (because that is so common an operation): TC_STRING +
(short)length + bytes. Let's use that, also to make it easier to test
the upcoming changes to TreeMap harmonizing that Avian's serialization
of said class with OpenJDK's.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is by no means a complete support for the deserialization compliant
to the Java Language Specification, but it is better to add the support
incrementally, for better readability of the commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Java Language Specification documents the serialization protocol
implemented by this change set:
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/protocol.html#10258
This change is intended to make it easier to use Avian VM as a drop-in
replacement for the Oracle JVM when serializing objects.
The previous serialization code is still available as
avian.LegacyObjectInputStream.
This commit only implements the non-object parts of the deserialization
specification.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Java Language Specification documents the serialization protocol
implemented by this change set:
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/protocol.html#10258
This change is intended to make it easier to use Avian VM as a drop-in
replacement for the Oracle JVM when serializing objects.
The previous serialization code is still available as
avian.LegacyObjectOutputStream.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... otherwise, logging would throw an exception when trying to
determine whether the current level allows the message to be logged.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The getResources method can be used to find all matches in the class
path for a given path, e.g. to seek out all the META-INF/MANIFEST.MF
files contained in all of the .jar files in the class path.
We just taught the findResources() method to return all matches (rather
than only the first), so let's use that method to get all the matches
from the current class loader's class path elements.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The findResources method is supposed to enumerate all the class path
elements' matching paths' URLs, but we used to stop at the first one.
While this is good enough when the system class path contains only a
single .jar file, since b88438d2(sketch of JAR support in Finder)
supports more than a single .jar file in the class path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This implementation is intentionally simple. If and when the need arises,
we can always implement a more performant version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This implementation is intentionally simple. If and when the need arises,
we can always implement a more performant version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If need be, this functionality can be sped up by implementing a
descending iterator on the tree without copying it into an ArrayList.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This change reuses the existing insertion sort (which was previously what
Arrays.sort() executed) in a full intro sort pipeline.
The implementation is based on the Musser paper on intro sort (Musser,
David R. "Introspective sorting and selection algorithms." Softw., Pract.
Exper. 27.8 (1997): 983-993.) and Wikipedia's current description of the
heap sort: http://en.wikipedia.org/wiki/Heapsort.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is a very dumb implementation that wastes space and time by
constructing a full-blown ArrayList as backend. However, it is
better to have a dumb implementation than none at all, and we can
always do something about the performance when, and if, that should
become necessary.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the previous commit, we did not support characters in regular
expressions specified via \0..., \x... or \u... yet. This is a bit more
involved, therefore support for them is added in its own commit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a regular expression contains escaped characters such as the
backslash, it is actually still a literal string. So let's support the
trivially-escaped characters, too, that are documented in
http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
