Your component parts, potentially containing characters that must be escaped, should already have been escaped using URLEncoder before being concatenated into a URI.
If you have a URI with out-of-band characters in (like space, "<>[]{}\|^`, and non-ASCII bytes), it's not really a URI. You can try to fix them up by manually %-escaping them, but this is a last-ditch fix-up operation and not a standard form of encoding. This is usually necessary when you are accepting potentially-malformed URIs from user input, but it's not a standardised operation and I don't know of any built-in Java library function that will do it for you; you may have to hack something up yourself with a RegExp.
In the other direction, you must take your URI apart into its component parts (each separate path part, query parameter name and value, and so on) before you can unescape each part (using an URLDecoder). There is no sensible way to %-decode a whole URI in one go; you could try to ‘decode %-escapes that do not decode to delimiters’ (like /?=&;%) but you would be left with a strange inconsistent string that doesn't conform to any URI-processing standard.
URLEncoder/URLDecoder are fine for handling URI query components, both names and values. However they are not quite right for handling URI path part components. The difference is that the ‘+’ character does not mean a space in a path part. You can fix this up with a simple string replace: after URLEncoding, replace ‘+’ with ‘%20’; before URLDecoding, replace ‘+’ with ‘%2B’. You can ignore the difference if you are not planning to include segments containing spaces or pluses in your path.