Re: jakarta-oro dilemma

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