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>
Previously, we initialized it to the boot class loader, but that is
inconsistent with Java; if compiling against OpenJDK's class library,
the context class loader is therefore initialized to the app class
loader, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This adds an extra class path element to the VM running the unit tests,
writes files with identical file names into both directories and then
verifies that SystemClassLoader#getResources can find them.
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>
When the system class path contains more than one .jar, it is quite
concievable that, say, 'META-INF/MANIFEST.MF' can be found in multiple
class path elements.
This commit teaches the working horse of class path inspection, the
Finder class, how to continue the search at a given state.
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>
When creating an object array with more than two dimensions, the
component type was erroneously set to the base type, not the array
type of one less dimension.
This prevented Collection<Class[]>#toArray(Class[][]) from working
properly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We do not really support regular expressions yet, but we do support
trivial patterns including ones with escaped characters. Let's make sure
that that works as advertised.
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>
