You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Antonio Gallardo (JIRA)" <ji...@apache.org> on 2007/10/12 20:44:50 UTC
[jira] Created: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
NPE on FilenameUtils.equalsNormalizedOnSystem()
-----------------------------------------------
Key: IO-128
URL: https://issues.apache.org/jira/browse/IO-128
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.3.1, 1.3, 1.2, 1.3.2
Reporter: Antonio Gallardo
The following code in commons-io (1.3.2) throws an NPE exception:
org.apache.commons.io.FilenameUtils
.equalsNormalizedOnSystem(
"//a.html",
"//ab.html");
And here is the exception:
java.lang.NullPointerException: The strings must not be null
at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
at CodeSnippet_32.run(CodeSnippet_32.java:4)
at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
Interesting is if both or 1 of the strings is null, it did not throws an exception.
Additional comment from Niall Pemberton (on the dev mail list):
The problem is that the FilenameUtils's normalize(String) method
returns "null" if it thinks the file names are invalid - which in your
case it seems to be doing so for both file names.
So I guess theres two issues here - you're right the error is
misleading and FilenameUtils should check the names again after
calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated IO-128:
-------------------------------
Attachment: IO-128.patch
OK heres a patch replacing the exception I added. It only compares the "un-normalized" file names if they are both invalid
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
> Attachments: IO-128.patch
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated IO-128:
-------------------------------
Attachment: IO-128.patch
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
> Attachments: IO-128.patch
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton reopened IO-128:
--------------------------------
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534452 ]
Niall Pemberton commented on IO-128:
------------------------------------
>From the dev list...
On 10/13/07, Antonio Gallardo <ag...@agssa.net> wrote:
> Hi Niall,
>
> Thanks for taking care of the issue, however it is not clear to me from
> the javadocs that we should expect an IllegalArgumentException returning
> from equalsNormalizedOnSystem(). IMHO, it states it calls first the
> normalize() and based on the javadocs of normalize(), it should silently
> fix, the link. On the javados, there is:
Unfortunately until today I had never looked at or used the normalize code - so I don't know what the original intention was. The javadocs for the normalize() method do say "the normalized filename, or null if invalid" for the return value (see http://tinyurl.com/2tczc8). So it seems clear that errors return null (and there are tests for error conditions in the test case (see http://tinyurl.com/3bh7ml).
On that basis I believe that we must cater for errors in the equals method. As it stands I think my change to throw an IllegalArgumentException with a relevant message and in the right place is better than a misleading NullPointerException elsewhere. However I am happy for anyone else to come up with better suggestions.
Whether a value like "//file.txt" should be causing a normalize error is another question though...
> //foo/.//bar --> /foo/bar
>
> Hence a user could assume that
>
> //file.txt --> /file.txt and not an IllegalArgumentException
>
> Is that correct?
Tracking through your issue one of the first things the doNormalize() method does is call getPrefixLength() and if it returns a negative value, then it returns null - indicating invalid.
In getPrefixLength() there is code that if the first two characters are file separators (which they are in your case) then it returns -1 if there are no other separator characters - so thats triggering the error here.
Therefore seems that someone has specifically coded to cause an error in your scenario. Hopefully someone with better knowledge will jump in and talk more sense than I can. Sorry :(
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated IO-128:
-------------------------------
Attachment: (was: IO-128.patch)
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
> Attachments: IO-128.patch
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534830 ]
Niall Pemberton commented on IO-128:
------------------------------------
I'l leave the UNC issue for others to decide/fix.
"For equals() the general contract is that if they are not equal then it returns false. object.equals(null) returns false for example. I don't think using the un-normalized name is the right way to go. "
If both file names are invalid (but different) and therefore both result in null after normalization then it would be strange IMO to return "true" from the equals method - which was the only reason I suggested using the un-normalized name if the normalized name is null.
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated IO-128:
-------------------------------
Attachment: IO-128-v2.patch
I've changed the IllegalArgumentException to a NullPointerException - so the way it stands now the behaviour is unchanged from the last released version - just has a better error message.
If others think the equals method shouldn't throw an exception (seems OK to me, otherwise it will just mask invalid "normalized" file names) then I have attached a suggested patch - I'll leave this for others to decide if/what changes are appropriate for this and the UNC names issue.
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
> Attachments: IO-128-v2.patch
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated IO-128:
-------------------------------
Attachment: (was: IO-128.patch)
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated IO-128:
-------------------------------
Fix Version/s: (was: 1.4)
AFTER-1.4
Moving this to post 1.4 - needs someone to step up and do the work
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: AFTER-1.4
>
> Attachments: IO-128-v2.patch
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton resolved IO-128.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Niall Pemberton
Antonio,
Tthanks for reporting this - I have added null checks after the file names have been "normalized" and if theres an error (i.e. they return null) then its now throwing an IllegalArgumentException with the message "Error normalizing one or both of the file names" - hopefully that will make it less confusing if errors occur when the names are "normalized".
http://svn.apache.org/viewvc?view=rev&revision=584325
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Stephen Colebourne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534606 ]
Stephen Colebourne commented on IO-128:
---------------------------------------
For equals() the general contract is that if they are not equal then it returns false. object.equals(null) returns false for example. I don't think using the un-normalized name is the right way to go.
The second question is whether normalize is trying to extract a UNC name, and if it decides it isn't then what to do. I suspect that its best to try and remove the UNC prefix, and if not then treat as per any other filename (ie. remove the double slash.)
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534541 ]
Niall Pemberton commented on IO-128:
------------------------------------
Stephen, thanks for helping with this...
"I believe that the intention was that all invalid inputs would result in null, not an exception, so the fix is incorrect. (But it should also not throw NPE)"
The problem is in the equals method which returns a primitive boolean, so returning null is not an option. It calls the normalize() method on the file names, so the question is what should that method do if the "normalized" file names are null? Currently it causes a confusing NPE - if an exception is not correct in the equals method then the question is what to do? Perhaps it should continue, but use the un-normalized file name for any that are invalid?
"Two options:
a) clarify that if the double slash is at the start, it has to refer to a UNC name
b) handle the case that a double slash at the start should be just normalized to a single slash if it is not a UNC name."
Seems to me that since the current "normalize" contract is to return null for invalid names then isn't option b) effectively changing the contract of that method? Or is it that although a file name such as //foo.txt is not a valid UNC name - it should be considered a valid file name?
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Antonio Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534721 ]
Antonio Gallardo commented on IO-128:
-------------------------------------
IMHO, the UNC for "\\" not "//" See: http://en.wikipedia.org/wiki/Path_%28computing%29#Uniform_Naming_Convention
Hence // should be fixed to a single slash. Makes sense?
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Stephen Colebourne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534481 ]
Stephen Colebourne commented on IO-128:
---------------------------------------
I believe that the intention was that all invalid inputs would result in null, not an exception, so the fix is incorrect. (But it should also not throw NPE)
A double slash at the start is taken to refer to a UNC server name. Since //file.txt isn't sufficient for a UNC server name, the getPrefixLength method returns null.
Two options:
a) clarify that if the double slash is at the start, it has to refer to a UNC name
b) handle the case that a double slash at the start should be just normalized to a single slash if it is not a UNC name.
(b) is probably better. Effectively you need to convert // to / before getting the prefix in this scenario.
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on
FilenameUtils.equalsNormalizedOnSystem()
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534837 ]
Niall Pemberton commented on IO-128:
------------------------------------
P.S. IOCase checkEquals throws a NullPointerException if either of the Strings are null
> NPE on FilenameUtils.equalsNormalizedOnSystem()
> -----------------------------------------------
>
> Key: IO-128
> URL: https://issues.apache.org/jira/browse/IO-128
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2
> Reporter: Antonio Gallardo
> Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> The following code in commons-io (1.3.2) throws an NPE exception:
> org.apache.commons.io.FilenameUtils
> .equalsNormalizedOnSystem(
> "//a.html",
> "//ab.html");
> And here is the exception:
> java.lang.NullPointerException: The strings must not be null
> at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141)
> at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984)
> at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956)
> at CodeSnippet_32.run(CodeSnippet_32.java:4)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54)
> at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35)
> I think it is wrong a message "The strings must not be null", since there is not a null string involved in the call.
> Interesting is if both or 1 of the strings is null, it did not throws an exception.
> Additional comment from Niall Pemberton (on the dev mail list):
> The problem is that the FilenameUtils's normalize(String) method
> returns "null" if it thinks the file names are invalid - which in your
> case it seems to be doing so for both file names.
> So I guess theres two issues here - you're right the error is
> misleading and FilenameUtils should check the names again after
> calling normalize() for nulls and throw a more appropriate message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.