RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException

Joe Darcy joe.darcy at oracle.com
Tue Jul 8 16:24:33 UTC 2014


A comment on a ccc request for this kind of change below...

On 07/08/2014 05:25 AM, David Holmes wrote:
> On 8/07/2014 5:25 AM, Ivan Gerasimov wrote:
>> Thanks you Sherman for review!
>> On 07.07.2014 21:38, Xueming Shen wrote:
>>> On 07/07/2014 10:07 AM, Ivan Gerasimov wrote:
>>>> Hello!
>>>> The javadoc says that Pattern.compile(String regex, int flag) will
>>>> throw IllegalArgumentException, if flag contains an invalid bit set.
>>>> However, it fails to do so.
>>>> Would you please help review the simple fix for that?
>>>> Alternatively, we could just remove the corresponding @throws part,
>>>> but that would change the spec.
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8035975
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8035975/0/webrev/
>>>> Sincerely yours,
>>>> Ivan
>>> Looks fine. But given it's a behavior change, you probably still need
>>> a CCC for it.
>> Okay, just filed one.
> Complying with the spec probably doesn't need a CCC but this seems to 
> be a long standing non-compliance so I agree it is worthwhile. 
> Arguably this may introduce an incompatibility that we don't want to 
> introduce after all this time - so it might be better to relax the 
> spec to allow and exception to be thrown, but not require it.
> I'm surprised this is no JCK test that covers this.

On those rare occasions when it comes to our intention that the 
long-standing behavior of a method differs from its long-standing 
specification, the default resolution is to change the specification to 
match the implementation. Developers can and do rely on what the 
implementation actually does and we estimate change the specification 
has a lower compatibility impact overall.

There are certainly also times when the implementation is changed to 
match the specification instead; sorted out those trade-offs is part of 
the ccc process.


More information about the core-libs-dev mailing list