In message <[EMAIL PROTECTED]>, Henr
i Yandell writes:
>6. Put ORO in Commons as Jakarta Regexp(?). End of life both Regexp and
> ORO. Enter the Commons community as a tight reusable module.
Yep, I've thought about that before. The only issue with it is the
impact of package renaming on users, but I don't think that's major.
>Though I'm unsure what ORO offers over JDK, and what your plans are
>regarding the JDK.
There are a couple of reasons why it's still has something to offer,
although it's inevitable we'll lose users since most people only need
convenient/simple regex access (and who can compete with the stuff built
right into String). In no particular order:
o Plenty of folks are still using J2SE 1.3, although eventually this
will change.
o ORO offers multiple regular expression syntaxes and a set of generic
interfaces. In the past, we've talked about merging in jakarta-regexp
as another syntax engine and altering it to comply with POSIX regexps
since people know those.
o javax.regex isn't available on J2ME. It's easy to modify ORO to compile
for J2ME (we just haven't settled on a conditional compilation mechanism
so that we can prepackage a J2ME version). Users have asked for J2ME
support in the past.
o On the performance front, we've had users doing heavy pattern matching
with multiple threads on multiprocessor machines say that javax.regex
doesn't cut it in that environment because of synchronization bottlenecks.
In the general performance area, there's a lot we can do to improve
performance if the motivation is there.
o Perl5 compliance. Even though the Perl 5 classes haven't kept up with
the latest Perl regular expression additions, the goal of our Perl 5
classes is strict compatibility with Perl, something javax.regex
doesn't provide. We also provide niceties like Perl5Util which allow
you to use straight up Perl like "s/foo/bar/g".
o ORO was intended as the basis for building more general text processing
tools. By implementing the proper factory class(es) for our regular
expression engines (we can also wrap javax.regex), we could focus more
on providing higher-level tools like tokenizers where you can choose
what the underlying regular expression engine will be. Still, a
decision has to be made if we want to restrict the project to low
level functions and move generic things that take pluggable engines
(like the filename filters) to a Commons project.
That's off the top of my head. My failure as a project member has been
that I don't have any itches to scratch, so I just engage in maintenance
and wait for others to jumpstart the initiatives we've discussed on oro-dev
(e.g., moving from Perl 5.003 to Perl 5.8 compatibility, writing a proper
user's guide, etc.).
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
