dedeprecate Validator.escapeUrl() as there isn't a suitable replacement
Description
Activity
Aaron Zeckoski October 21, 2013 at 11:27 AM
Looks like this was resolved awhile ago
Hudson CI Server August 22, 2011 at 2:29 AM
Integrated in kernel-trunk #363 (See http://builds.sakaiproject.org:8080/job/kernel-trunk/363/)
https://sakaiproject.atlassian.net/browse/KNL-788#icft=KNL-788 Revert constant changes that crept in.
Matthew Buckett August 22, 2011 at 2:24 AM
The current comment:
@deprecated use java.net.URLEncode.encode()
seems misleading, as you can't just swap them out without looking carefully at the code. I was guessing it was deprecated because java.net.URLEncode.encode() was seen as a drop in replacement, but I don't think it is. As replacement isn't easy I was suggesting that maybe it shouldn't be deprecated, just noted that new code should look at the Java version for URL encoding.
Thanks David I've reverted the constant changes, I'm not sure how the changes crept in, I'm guessing it's a character encoding issue.
David Horwitz August 21, 2011 at 1:47 AM
2 things:
1) Do you mean we need better javadoc explaining the difference?
2) Your commit changed some of the constans in the file (I think this might be an error I did that once myself)
Matthew Buckett August 17, 2011 at 6:46 AM
Leaving it as deprecated encourages people to just switch to java.net.URLEncode.encode() without considering the differences.
At the moment Validator.escapeUrl() is deprecated stating that java.net.URLEncode.encode() should be used instead, but these two methods are not the same and produce different results. I think it's worth pointing people to URLEncode.encode() as the standard way todo URLEncoding but I don't this it's a case where code calling Validator.escapeUrl() can be replaced with URLEncode.encode() without consideration.