Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <23666350.1192450671156.JavaMail.jira@brutus>
Date: Mon, 15 Oct 2007 05:17:51 -0700 (PDT)
From: "Niall Pemberton (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (IO-128) NPE on
 FilenameUtils.equalsNormalizedOnSystem()
In-Reply-To: <21623006.1192214690893.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.