RE: Jakarta RegEx vs Java Regex

2003-12-08 Thread Dubois, Jeff
   Thanks for your response Rod!

   Can someone list for me exactly what the advantages of the jakarta
package are?

   It appears from the Java API documentation that the Java regex does not
contain:

1. The conditional constructs (?{X}) and (?(condition)X|Y).
2. The embedded code constructs (?{code}) and (??{code}).
3. The embedded comment syntax (?#comment).
4. The preprocessing operations \l \u, \L, and \U. 

   However, it appears to me that Items 2-4 are not really part of a regular
expressions/pattern matching, but are nice features.  That is, there are
easy workarounds for embedding comments in Patterns, and the preprocessing
operations are easily handled by the various String methods:
String.toLowerCase() / String.toUpperCase() methods.  

I am not sure about the embedded code or the conditional constructs,
however, since I have never used them.  

If the embedded code construct simply calls a method passing in the text
of a particular matched group, then this would be easily accomplished via
Java's regex as well.

Also, can the functionality of conditional constructs be duplicated by
either 1) a more complex regular expression that contains additional or-s
|, or the use of an if-then-else statement and multiple patterns?  How are
conditional constructs used?

It appears to me, that the Jakarta package may offer some nice syntactic
features for conditional constructs and embedded code/comments, and it's
syntax is similar to Perl's.  Would that summarize the Jakarta advantage?

Also, what is the relationship between Jakarta ORO and regex?

Comment - are there any plans in the works to add named match groups to
Jakarta's regex offering?

Thanks!
   - Jeff


   
Hi Rod,
  Thanks

-Original Message-
From: Rod Macpherson [mailto:[EMAIL PROTECTED]
Sent: Monday, December 08, 2003 4:29 PM
To: Regexp Users List
Subject: RE: Jakarta RegEx vs Java Regex


Asked the same thing awhile back and the response was the jakarta stuff
is better (their track record would not call that in to question) and of
course it does not require a 1.4 JDK. One thing that did bug me about
the build-in was that the logger did not take an object as a constructor
so you had to give it the class object instead. Seemed like an annoying
step backward. Anyway, we are sticking with log4j for the time being. 

-Original Message-
From: Dubois, Jeff [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 08, 2003 1:02 PM
To: '[EMAIL PROTECTED]'
Subject: Jakarta RegEx vs Java Regex


What are the advantages of using the Jakarta's RegEx package versus
the Java built-in RegEx, now that Java has built-in RegEx's?

   Thanks!
  Jeff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Jakarta RegEx vs Java Regex

2003-12-08 Thread Rod Macpherson
DOH! I just realized you were talking about reg-ex versus the build-in
logging. I need more coffee. My first clue should have been this is the
regexp-user mailing list:) Anyway, same reasoning applies for going with
the jakarta package.  

-Original Message-
From: Dubois, Jeff [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 08, 2003 3:59 PM
To: 'Regexp Users List'
Subject: RE: Jakarta RegEx vs Java Regex


   Thanks for your response Rod!

   Can someone list for me exactly what the advantages of the jakarta
package are?

   It appears from the Java API documentation that the Java regex does
not
contain:

1. The conditional constructs (?{X}) and
(?(condition)X|Y).
2. The embedded code constructs (?{code}) and (??{code}).
3. The embedded comment syntax (?#comment).
4. The preprocessing operations \l \u, \L, and \U. 

   However, it appears to me that Items 2-4 are not really part of a
regular expressions/pattern matching, but are nice features.  That is,
there are easy workarounds for embedding comments in Patterns, and the
preprocessing operations are easily handled by the various String
methods:
String.toLowerCase() / String.toUpperCase() methods.  

I am not sure about the embedded code or the conditional constructs,
however, since I have never used them.  

If the embedded code construct simply calls a method passing in the
text of a particular matched group, then this would be easily
accomplished via Java's regex as well.

Also, can the functionality of conditional constructs be duplicated
by either 1) a more complex regular expression that contains additional
or-s |, or the use of an if-then-else statement and multiple patterns?
How are conditional constructs used?

It appears to me, that the Jakarta package may offer some nice
syntactic features for conditional constructs and embedded
code/comments, and it's syntax is similar to Perl's.  Would that
summarize the Jakarta advantage?

Also, what is the relationship between Jakarta ORO and regex?

Comment - are there any plans in the works to add named match groups
to Jakarta's regex offering?

Thanks!
   - Jeff


   
Hi Rod,
  Thanks

-Original Message-
From: Rod Macpherson [mailto:[EMAIL PROTECTED]
Sent: Monday, December 08, 2003 4:29 PM
To: Regexp Users List
Subject: RE: Jakarta RegEx vs Java Regex


Asked the same thing awhile back and the response was the jakarta stuff
is better (their track record would not call that in to question) and of
course it does not require a 1.4 JDK. One thing that did bug me about
the build-in was that the logger did not take an object as a constructor
so you had to give it the class object instead. Seemed like an annoying
step backward. Anyway, we are sticking with log4j for the time being. 

-Original Message-
From: Dubois, Jeff [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 08, 2003 1:02 PM
To: '[EMAIL PROTECTED]'
Subject: Jakarta RegEx vs Java Regex


What are the advantages of using the Jakarta's RegEx package versus
the Java built-in RegEx, now that Java has built-in RegEx's?

   Thanks!
  Jeff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]