Re: Parsing too strict in java.net.URI?

2017-12-01 Thread David Lloyd
On Mon, Nov 14, 2016 at 12:16 PM, Chris Hegarty
 wrote:
> David,
>
> On 14/11/16 16:47, David M. Lloyd wrote:
>>
>> The following statement:
>>
>> URI uri = URI.create("local:");
>>
>> fails with an exception like this:
[...]
>> However AFAICT scheme-only URIs are, while not strictly allowed by RFC
>> 2396 [1], in common usage (for example, "about:" in web browsers).
>
> This seems to be allowable in the "more recent" RFC [2], that obsoletes
> 2396, which of course java.net.URI does not, yet, support. There was an
> effort to support 3986 a number of years ago, but it was not successful.
> The desire to support, keep up with standards, etc, has caused us to
> give consideration to supporting 3986, but as of yet nothing concrete.

Have there been any recent developments, updates, or insights on this
issue?  I wonder if a gradual change to RFC 3986 support might be more
appropriate: for example, start with *just* accepting empty SSP.

If the compatibility requirements of java.net.URI are too stringent to
allow for any change, then surely all that can be done is to deprecate
& replace it, which would need no further delay that I can see.
-- 
- DML


Re: RFR:8190843 can not set/get extendedOptions to ServerSocket

2017-12-01 Thread Roger Riggs

Hi Vyom,

Looks fine

Roger


On 11/16/2017 4:03 AM, vyom tewari wrote:


Hi All,

Please review the small code change for the below issue.

Webrev : 
http://cr.openjdk.java.net/~vtewari/8190843/webrev0.0/index.html


BugId    : https://bugs.openjdk.java.net/browse/JDK-8190843

In this code change, i removed the check(getSocket() == null) which 
will always be true for ServerSocket as in case of server socket we 
set "serverSocket" not "socket".


Thanks,

Vyom