RE: Pattern Regular Expressions: Consecutive ORs not handled corr ectl y

Kayiti Devanandam <[email protected]> Tue, 3 May 2005 03:53:23 -0700
Newsgroups gmane.comp.jakarta.oro.user
Message-ID <A3E375FA108EF94496269A5A96AFCAC102E2187F@mailwest-e6>
------_=_NextPart_000_01C54FCE.52C1EBE8
Content-Type: text/plain

Hi Daniel,

Please do find attached the test case for it. (testRegEx.java which can be
compiled with putting "jakarta-oro-2.0.8.jar" in the classpath.)
With both the 2.0.5 and 2.0.8 versions I am finding the following results:

For the stringPattern -->> \d{3}|\d{3}(.)\d{2}
	123 -> Passed
	123.46 Failed (which shouldn't fail)

For the stringPattern -->> \d{3}(.)\d{2}|\d{3}
	123 -> Passed
	123.46 -> Passed

You can out the stringPattern in the main method (line no 65) and compile
and see the results by 
	java testRegEx 123 
Give the values to be validated as arguments in the command line. I think
now u can appreciate the problem very well. Sorry I couldn't attach the
testCase earlier.

Here in this case for the first case (\d{3}|\d{3}(.)\d{2}), 123.46 shouldn't
have been failed. Can u find out why this is happenning? 

Thanks and Regards
Dev



-----Original Message-----
From: Daniel F. Savarese [mailto:[email protected]] 
Sent: Tuesday, May 03, 2005 3:51 AM
To: ORO Users List
Subject: Re: Pattern Regular Expressions: Consecutive ORs not handled corr
ectl y 


In message <A3E375FA108EF94496269A5A96AFCAC102D99D1A@mailwest-e6>, Kayiti
Devan andam writes:
>For the regular Expression \d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}
>"123" string fails. But for 123.45 passes. (123 fails but it actually 
>should have successfully validated since it correctly validated by the 
>last OR Expression \d{3}...so it should have been validated.

Still need a test case that reproduces the problem.  For example, I still
don't know if you're talking about contains or matches.  In any case, I can
find no problem:

java examples.matchResultExample '\d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}'
123
Match: 123
Length: 3
Groups: 1
Begin offset: 0
End offset: 3
Groups: 

java examples.matchResultExample '\d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}'
123.45
Match: 123.45
Length: 6
Groups: 1
Begin offset: 0
End offset: 6
Groups: 

java examples.matchResultExample
'\d{3}[.]\d{2}[.]\d{2}|(\d{3}[.]\d{2}|\d{3})' 123
Match: 123
Length: 3
Groups: 2
Begin offset: 0
End offset: 3
Groups: 
1: 123
Begin: 0
End: 3

java examples.matchResultExample
'\d{3}[.]\d{2}[.]\d{2}|(\d{3}[.]\d{2}|\d{3})' 123.45
Match: 123.45
Length: 6
Groups: 2
Begin offset: 0
End offset: 6
Groups: 
1: 123.45
Begin: 0
End: 6

Those runs are using the matchResultExample program from src/java/examples.
I tested matches() using the demo applet with:

Perl5 Expression: \d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}
Search Input: 123
Search Results:
 Compiling regular expression.

 Searching

 The input IS an EXACT match.

Usually, the issue with matches() is the "foo|foot" issue, requiring one to
change the expression to start with ^ and end with $ to force the extra
backtracking.  But that doesn't seem to be the case here.

At any rate, I can't reproduce the behavior.  Assuming version 2.0.5 was not
a typo, then maybe there was a bug in 2.0.5 that was fixed by version 2.0.8.
However, just to be completely thorough, I downloaded version 2.0.5 and:

java -classpath ./jakarta-oro-2.0.5.jar:. examples.matchResultExample
'\d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}' 123
Match: 123
Length: 3
Groups: 1
Begin offset: 0
End offset: 3
Groups: 

I can't reproduce the reported behavior in any way.  Assuming the problem
exists in an even earlier version of the library, then perhaps you've got an
earlier version sitting in your classpath.  That happens sometimes when
using application servers since the software was included in most of the
major J2EE servers for a period of time.  But without a test program, all I
can do is speculate and guess.  The quickest way to resolve these issues is
to post self-contained code that reproduces the problem.  That way we can
figure out if the problem is in the library, in the code, or something else.

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



------_=_NextPart_000_01C54FCE.52C1EBE8
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
------_=_NextPart_000_01C54FCE.52C1EBE8--