Based on the just-implemented PikeVM, let's test it with a specific
regular expression. At this point, no parsing is implemented but instead
an explicit program executing a(bb)?a is hardcoded.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
So far, these are humble beginnings indeed. Based on the descriptions of
http://swtch.com/%7Ersc/regexp/regexp2.html
I started implementing a Thompson NFA / Pike VM.
The idea being that eventually, regular expressions are to be compiled
into special-purpose bytecode for the Pike VM that executes a varying
number of threads in lock-step over each character of the text to match.
The thread count is bounded by the length of the program: two different
threads with identical instruction pointer at the same character-to-match
would yield exactly the same outcome (and therefore, we can execute just
one such thread instead of possibly many).
To allow for matching groups, each thread carries a state with it, saving
the group offsets acquired so far.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This makes both the Pattern and the Matcher class abstract so that more
specialized patterns than the trivial patterns we support so far can be
implemented as convenient subclasses of the respective abstract base
classes.
To ease development, we work on copies in test/regex/ in the 'regex'
package. That way, it can be developed in Eclipse (because it does not
interfere with Oracle JRE's java.util.regex.* classes).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For quick access, the sezpoz library stores lists in
META-INF/annotations/ of classes that have been annotated in a
special way.
To support the use case where the annotations actually changed since
sezpoz stored said lists, sezpoz then creates proxy instances for the
annotations to provide some backwards compatibility: as long as there
are default values for any newly-introduced annotation values,
everything is groovy.
Therefore, let's make sure that proxy instances inherit the
annotations' default values.
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>
Earlier, if the annotations were already up-to-date (but
Annotations.class not), the compilation would fail.
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>
... for proper statistics (I thought I was #5 contributor at the
time I started the mailmap, but I was only #6).
Unfortunately, I could not find the full name of Stan
<goo.in.my.shoes@gmail.com> for proper credit.
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>
