Bug ID: JDK-6348622 java.net.URI.parseServerAuthority is not necessary any more and its javadoc has wrong statement

Type: Bug
Component: core-libs
Sub-Component: java.net
Affected Version: 6

Priority: P3
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2005-11-10
Updated: 2017-05-19
Resolved: 2006-01-07

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b67Fixed

Description of URI.parseServerAuthority contains phrase:

" This method is provided because the generic URI syntax specified in RFC 3986  cannot always distinguish a malformed server-based authority from a legitimate registry-based authority. It must therefore treat some instances of the former as instances of the latter. The authority component in the URI string "//foo:bar", for example, is not a legal server-based authority but it is legal as a registry-based authority."

Example above is wrong. Host name can't contain ':' symbol. (Now ':' is a memeber of 'gen-delims').

It seems that a malformed server-based authority can't be a valid registry-based authority now.
(RFC 3986 page 55: Registry-based naming authorities that use the generic syntax are now defined within the host rule.) => valid reg-based IS valid host IS valid server-based

Duplicate :	JDK-6363883 - java.net.URI(String) has to parse authority (and has to throw exception if fails)
Relates :	JDK-6380332 - SunTea applet fails to load under Mustang
Relates :	JDK-6394131 - Rollback URI class to Tiger version
Relates :	JDK-6350321 - java.net.URI: the 'path' component should be present in opaque URIs