tracker issue : CF-3753710

select a category, or use search below
(searches all categories and all time range)
Title:

String member functions break existing code that relies on java.lang.String member functions

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Sean Corfield / Sean Corfield (Sean Corfield)

Created: 05/01/2014

Components: Core Runtime

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Major / Some users will encounter

Locale/System: ALL / Mac 10.8 64-bit

Vote Count: 17

Listed in the version 11.0.03.292480 Issues Fixed doc
Problem Description: Code that relies on myStr.replace(a,b) to support a possibly being an empty string now breaks.

Steps to Reproduce:

<cfset s = "SOMETHING">
<cfset a = "">
<cfoutput>#s.replace(a,"")#</cfoutput>

Actual Result: Exception: Argument 2 of function Replace cannot be an empty value.

Expected Result: Should output SOMETHING like it did in all prior versions of ACF (and like it does in Railo, even current versions that support string member functions).

Any Workarounds: Add ugly conditional code to handle empty strings.

Several issues here:

1. The reason folks used s.replace() in the first place was because replace(s,"","") fails because it arbitrarily rejects the second argument being an empty string, whereas the underlying java.lang.String::replace() method is perfectly happy with an empty string.

2. The exception is very misleading - and I bet this applies to all member functions - because the argument numbers refer to the original Built-In Functions, not the member functions. In this case "Argument 2" is actually the _first_ argument to s.replace() and "Argument 3" would be the _second_ argument.

3. This shows you didn't even try to test this will FW/1 - one of the most popular CFML frameworks out there - because out of the box, several examples fail because they contain expressions like this (to account for the optional context root in Java web applications):

	variables.framework = {
		base = getDirectoryFromPath( CGI.SCRIPT_NAME ).replace( getContextRoot(), '' ) & 'introduction'
	};

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3753710

External Customer Info:
External Company:  
External Customer Name: SeanACorfield
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

"Found in Build*" should be updated to include the final release version!
Comment by External U.
12390 | May 01, 2014 06:30:48 PM GMT
FW1 MUST work in any new version of CF!
Vote by External U.
12398 | May 01, 2014 06:41:52 PM GMT
If the most popular frameworks can't run on it... then something needs to be looked at for backwards compatibility... otherwise you just eliminated ADOBE CF 11 as an option for a majority of its current customers.
Vote by External U.
12399 | May 01, 2014 06:42:05 PM GMT
Breaks all our FW1 code. Also breaks anything that uses the construct shown in this bug report. Big fail!
Vote by External U.
12400 | May 01, 2014 07:49:20 PM GMT
A workaround is to call .replaceFirst() instead of .replace() to avoid the new member function but that doesn't have the same behavior so it may not work for everyone. The real fix here is to change the replace() BIF - and string.memberFunction - to accept an empty string as the "second" argument, like Java's String.replace() does and like Railo's and OpenBD's replace() BIF do. Then there's no conflict and no backward compatibility. But seriously guys, you didn't even bother to test CF11 against the FW/1 framework?
Comment by External U.
12391 | May 01, 2014 08:39:54 PM GMT
You simply cannot break FW/1. Ever. Its like a PHP update breaking WordPress.
Vote by External U.
12401 | May 02, 2014 07:39:12 AM GMT
this needs to work and i need more chars for this vote...
Vote by External U.
12402 | May 02, 2014 09:12:15 AM GMT
Yes, you can't break FW1.
Vote by External U.
12403 | May 02, 2014 09:33:42 AM GMT
This needs to be patched ASAP, I reckon. -- Adam
Vote by External U.
12404 | May 02, 2014 10:41:08 AM GMT
Our corporate installation uses FW/1 and is trying to migrate to CF11 - fixing this bug (and adding FW/1 to your test suite) will be a great help.
Vote by External U.
12405 | May 02, 2014 11:39:11 AM GMT
pls fix this, should be simple right, adobe? :)
Vote by External U.
12406 | May 02, 2014 11:54:43 AM GMT
I think the issue here is broader than this one method; consideration needs to be given to the whole notion of CF member functions colliding with same-named Java methods. That said, perhaps deal with Sean's specific issue first (in the way he suggests) and do that ASAP, then revisit the bigger picture at a more leisurely pace. -- Adam
Comment by External U.
12392 | May 02, 2014 01:21:56 PM GMT
.replace() is the only conflict I see where the behavior of the equivalent BIF - replace() - has a weird behavior that would have driven people to use the Java method in the first place (namely disallowing an empty second argument). s.trim() - Java - matches trim(s) - CFML - so that's fine. s.toString() and toString(s) match. I'd have to go back over the new docs on string member functions to be sure there are no others.
Comment by External U.
12393 | May 02, 2014 01:55:42 PM GMT
OK, cool. -- Adam
Comment by External U.
12394 | May 02, 2014 01:58:00 PM GMT
Needs to be fixed before we'd consider upgrading.
Vote by External U.
12407 | May 02, 2014 03:53:41 PM GMT
This impacts my usage of FW/1 and my opinion of upgrading. Please add FW/1 to your tests.
Vote by External U.
12408 | May 02, 2014 04:40:17 PM GMT
Given that this breaks FW/1, this is a pretty big problem.
Vote by External U.
12409 | May 03, 2014 12:30:02 PM GMT
Just FYI FW/1 2.2.1 has been released with a workaround for this and the 2.5 snapshot includes it too. So folks who download the framework in future will be OK, but that doesn't help all those folks who have existing apps that use .replace() so a patch to address the empty second argument in the BIF replace() - and therefore the string member function - would make their migration to CF11 much easier.
Comment by External U.
12395 | May 03, 2014 12:53:15 PM GMT
Since this breaks FW/1, this will have a huge impact on many systems out there.
Vote by External U.
12410 | May 05, 2014 07:32:35 AM GMT
Breaking FW/1 is a major no-no. Let's get this issue corrected.
Vote by External U.
12411 | May 06, 2014 08:50:47 AM GMT
There are so many FW/1 apps out there that this must be considered a high priority bug.
Vote by External U.
12412 | May 07, 2014 10:47:02 AM GMT
Looking forward to this getting fixed. As a FW/1 user I cannot support CF11 in production until then.
Vote by External U.
12413 | May 13, 2014 06:30:07 AM GMT
Just FYI, Railo implemented string.replace() the exact same way, breaking code that relied on the underlying Java method accepting an empty string. They have fixed that (this morning) so that the built-in function and the member function both accept an empty string and return the original string unchanged: myStr.replace("","foo") == myStr
Comment by External U.
12396 | May 21, 2014 10:43:24 AM GMT
We cannot upgrade to CF11 if there are breaking changes in member functions on strings.
Vote by External U.
12414 | June 04, 2014 02:15:17 PM GMT
I've verified this is fixed in CF11 Update 3. Thanks!, -Aaron
Comment by External U.
12397 | November 05, 2014 06:06:33 AM GMT