Using URLDecoder to decode URL-format paths is not safe unless paths have been encoded with URLEncoder.

Summary

If the instance (workspace), configuration or installation area or working directory of a built product contain a '+' at any point in the path, it is likely that at some point this problem will be encountered.

Currently the latest example of this is an installation that was located at C:\SysdynVensim_3+Simupedia and trying to run the product produced

java.lang.IllegalArgumentException: Invalid path for FastLZ library: C:\SysdynVensim_3 Simupedia\simantics-sysdyn\configuration\org.eclipse.osgi\324\0.cp\fastlz-windows-x86_64.dll

This particular problem case occurred with the configuration area.

Details

URLEncoder/Decoder work according to RFC 2396, which states:

        /* The list of characters that are not encoded has been
         * determined as follows:
         *
         * RFC 2396 states:
         * -----
         * Data characters that are allowed in a URI but do not have a
         * reserved purpose are called unreserved.  These include upper
         * and lower case letters, decimal digits, and a limited set of
         * punctuation marks and symbols.
         *
         * unreserved  = alphanum | mark
         *
         * mark        = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
         *
         * Unreserved characters can be escaped without changing the
         * semantics of the URI, but this should not be done unless the
         * URI is being used in a context that does not allow the
         * unescaped character to appear.
         * -----
         *
         * It appears that both Netscape and Internet Explorer escape
         * all special characters from this list with the exception
         * of "-", "_", ".", "*". While it is not clear why they are
         * escaping the other characters, perhaps it is safest to
         * assume that there might be contexts in which the others
         * are unsafe if not escaped. Therefore, we will use the same
         * list. It is also noteworthy that this is consistent with
         * O'Reilly's "HTML: The Definitive Guide" (page 164).
         *
         * As a last note, Intenet Explorer does not encode the "@"
         * character which is clearly not unreserved according to the
         * RFC. We are being consistent with the RFC in this matter,
         * as is Netscape.
         *
         */

URLEncoder does the following:

            if (dontNeedEncoding.get(c)) {
                if (c == ' ') {
                    c = '+';
                    needToChange = true;
                }
                //System.out.println("Storing: " + c);
                out.append((char)c);
                i++;
            } else {

and URLDecoder does the opposite - i.e. it encodes whitespace ' ' as '+' and decoder converts '+' back to ' '.

We use URLDecoder in tens of places to decode URL-encoded paths that have not been encoded with URLEncoder but paths coming from e.g. Eclipse's FileLocator which do not have the exact same encoding.

I'm unsure how to guarantee a backwards compatible fix for this. Needs more thought.