hg: jdk8/tl/langtools: 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations
Changeset: f3deeccbf4cf Author:vromero Date: 2013-08-07 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3deeccbf4cf 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java
hg: jdk8/tl/langtools: 8008274: javac should not reference/use sample code
Changeset: c7dcf899 Author:vromero Date: 2013-08-07 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7dcf899 8008274: javac should not reference/use sample code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java
hg: jdk8/tl/jdk: 7151062: [macosx] SCDynamicStore prints error messages to stderr
Changeset: 906dd23334c1 Author:weijun Date: 2013-08-07 19:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/906dd23334c1 7151062: [macosx] SCDynamicStore prints error messages to stderr Reviewed-by: xuelei ! src/macosx/native/java/util/SCDynamicStoreConfig.m
Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot
On 8/7/2013 12:06 AM, Matthew Hall wrote:
> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
> and the single dot represents the root zone. So you have to be
> careful making this sort of change to check the DNS RFCs first.
That's the first question we need to answer, whether IDN allow tailling
dots ("com."), zero-length root label ("."), and zero-length label ("",
for example ""example..com")?
Per the specification of IDN.toASCII():
===
"ToASCII operation can fail. ToASCII fails if any step of it fails. If
ToASCII operation fails, an IllegalArgumentException will be thrown. In
this case, the input string should not be used in an internationalized
domain name.
A label is an individual part of a domain name. The original ToASCII
operation, as defined in RFC 3490, only operates on a single label. This
method can handle both label and entire domain name, by assuming that
labels in a domain name are always separated by dots. ...
Throws IllegalArgumentException - if the input string doesn't conform to
RFC 3490 specification"
Per the specification of RFC 3490:
==
[section 2]
"A label is an individual part of a domain name. Labels are usually
shown separated by dots; for example, the domain name
"www.example.com" is composed of three labels: "www", "example", and
"com". (The zero-length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as in
"www.example.com", is not considered a label in this specification.)"
"An "internationalized label" is a label to which the ToASCII
operation (see section 4) can be applied without failing (with the
UseSTD3ASCIIRules flag unset). ...
Although most Unicode characters can appear in
internationalized labels, ToASCII will fail for some input strings,
and such strings are not valid internationalized labels."
"An "internationalized domain name" (IDN) is a domain name in which
every label is an internationalized label."
[Section 4.1]
"ToASCII consists of the following steps:
...
8. Verify that the number of code points is in the range 1 to 63
inclusive."
Here are the questions:
1. whether "example..com" is an valid IDN?
As dot is used as label separators, there are three labels,
"example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
"example..com" is not a valid IDN.
We need to address the issue in IDN.
2. whether "xyz." is an valid IDN?
It's an gray area, I think. We can treat the trailing "." as root
label, or a label separator.
If the trailing "." is treated as label separator, "xyz." is invalid
per RFC 3490.
if the trailing "." is treated as root label, what's the expected
return value of IDN.toASCII("xyz.")? I think the return value can be
either "xyz." or "xyz". The current implementation returns "xyz".
We may need not to update the implementation if tailing "." is
treated as root label.
3. whether "." is an valid IDN?
It's an gray area again, I think.
As above, if the trailing "." is treated as root label, I think the
return value can be either "." or "". The current implementation throws
a StringIndexOutOfBoundsException.
However, what empty domain name ("") really means? I would prefer to
return "." for "." instead.
We need to address the issue in IDN.
Here comes the solution, the IDN.toASCII() returns:
1. "." for ".";
2. "xyz" for "xyz.";
3. IAE for "example..com".
Does it make sense?
Thanks,
Xuelei
On 8/7/2013 1:35 AM, Michael McMahon wrote:
> I don't really understand the reason for the restriction in SNIHostName
> But, I guess that is where it should be enforced if it is required.
>
> Michael.
>
> On 06/08/13 17:43, Dmitry Samersoff wrote:
>> Xuelei,
>>
>> . (dot) is perfectly valid domain name and it means root domain so com.
>> is valid domain name as well.
>>
>> It thinks to me that in context of methods your change we should ignore
>> trailing dots, rather than throw exception.
>>
>> -Dmitry
>>
>>
>>
>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please review the bug fix to strict the illegal input checking in IDN.
>>>
>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>
>>> Here is two test cases, which are expected to get IAE.
>>>
>>> Case 1:
>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
>>> String index out of range: 0
>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>> at java.net.IDN.toASCII(IDN.java:118)
>>>
>>> Case 2:
>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>
>>> Thanks,
>>> Xuelei
>>>
>>
>
Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot
Xuelei,
root label is an empty label[1], dot is a label separator, so in printed
form domain names is dot-terminated.
Please see also below inline.
[1]
RFC rfc1034.txt:
Internally, programs that manipulate domain names should represent them
as sequences of labels, where each label is a length octet followed by
an octet string. Because all domain names end at the root, *which has a
null string for a label*, these internal representations can use a
length byte of zero to terminate a domain name.
On 2013-08-07 16:44, Xuelei Fan wrote:
> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>> and the single dot represents the root zone. So you have to be
>> careful making this sort of change to check the DNS RFCs first.
>
> That's the first question we need to answer, whether IDN allow tailling
> dots ("com."), zero-length root label ("."), and zero-length label ("",
> for example ""example..com")?
>
> Per the specification of IDN.toASCII():
> ===
> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
> ToASCII operation fails, an IllegalArgumentException will be thrown. In
> this case, the input string should not be used in an internationalized
> domain name.
>
> A label is an individual part of a domain name. The original ToASCII
> operation, as defined in RFC 3490, only operates on a single label. This
> method can handle both label and entire domain name, by assuming that
> labels in a domain name are always separated by dots. ...
>
> Throws IllegalArgumentException - if the input string doesn't conform to
> RFC 3490 specification"
>
> Per the specification of RFC 3490:
> ==
> [section 2]
> "A label is an individual part of a domain name. Labels are usually
> shown separated by dots; for example, the domain name
> "www.example.com" is composed of three labels: "www", "example", and
> "com". (The zero-length root label described in [STD13], which can
> be explicit as in "www.example.com." or implicit as in
> "www.example.com", is not considered a label in this specification.)"
>
> "An "internationalized label" is a label to which the ToASCII
> operation (see section 4) can be applied without failing (with the
> UseSTD3ASCIIRules flag unset). ...
> Although most Unicode characters can appear in
> internationalized labels, ToASCII will fail for some input strings,
> and such strings are not valid internationalized labels."
>
> "An "internationalized domain name" (IDN) is a domain name in which
> every label is an internationalized label."
>
> [Section 4.1]
> "ToASCII consists of the following steps:
>
> ...
>
> 8. Verify that the number of code points is in the range 1 to 63
> inclusive."
>
>
> Here are the questions:
> 1. whether "example..com" is an valid IDN?
>As dot is used as label separators, there are three labels,
> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
> "example..com" is not a valid IDN.
>
>We need to address the issue in IDN.
Root label can't appear in the middle of domain name, so example..com is
an invalid domain name and appropriate exception have to be thrown.
>
> 2. whether "xyz." is an valid IDN?
>It's an gray area, I think. We can treat the trailing "." as root
> label, or a label separator.
>If the trailing "." is treated as label separator, "xyz." is invalid
> per RFC 3490.
>if the trailing "." is treated as root label, what's the expected
> return value of IDN.toASCII("xyz.")? I think the return value can be
> either "xyz." or "xyz". The current implementation returns "xyz".
>
>We may need not to update the implementation if tailing "." is
> treated as root label.
Empty label at the end of domain names is valid per RFC 1034 and means
root label. So we should process this name and return all non-empty
labels.
> 3. whether "." is an valid IDN?
>It's an gray area again, I think.
>As above, if the trailing "." is treated as root label, I think the
> return value can be either "." or "". The current implementation throws
> a StringIndexOutOfBoundsException.
>
>However, what empty domain name ("") really means? I would prefer to
> return "." for "." instead.
>
>We need to address the issue in IDN.
As dot is a label separator and root (empty) label can't appear in the
middle of domain name, . (dot) is not valid name and this case is
similar to case (1) - we should throw an appropriate exception.
-Dmitry
>
> Here comes the solution, the IDN.toASCII() returns:
> 1. "." for ".";
> 2. "xyz" for "xyz.";
> 3. IAE for "example..com".
>
> Does it make sense?
>
> Thanks,
> Xuelei
>
>
> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>> I don't really understand the reason for the restriction in SNIHostName
>> But, I guess that is where it should be enforced if it is required.
>>
>> Michael.
>>
>> On 06/08/13 17:43, Dmitry Samersoff wr
hg: jdk8/tl/jdk: 8013809: deadlock in SSLSocketImpl between between write and close
Changeset: 8c7cf4926157 Author:xuelei Date: 2013-08-07 06:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c7cf4926157 8013809: deadlock in SSLSocketImpl between between write and close Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java
Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot
Resolvers seem to accept queries using trailing dots.
eg nslookup www.oracle.com.
or InetAddress.getByName("www.oracle.com.");
The part of RFC3490 quoted below seems to me to be saying
that the empty label implied by the trailing dot is not regarded
as a label so that you don't end up calling toAscii() or toUnicode()
with an empty string. I don't think it's saying the trailing dot can't
be there.
Michael
On 07/08/13 13:44, Xuelei Fan wrote:
On 8/7/2013 12:06 AM, Matthew Hall wrote:
Trailing dots are allowed in plain DNS (thus almost surely in IDN),
and the single dot represents the root zone. So you have to be
careful making this sort of change to check the DNS RFCs first.
That's the first question we need to answer, whether IDN allow tailling
dots ("com."), zero-length root label ("."), and zero-length label ("",
for example ""example..com")?
Per the specification of IDN.toASCII():
===
"ToASCII operation can fail. ToASCII fails if any step of it fails. If
ToASCII operation fails, an IllegalArgumentException will be thrown. In
this case, the input string should not be used in an internationalized
domain name.
A label is an individual part of a domain name. The original ToASCII
operation, as defined in RFC 3490, only operates on a single label. This
method can handle both label and entire domain name, by assuming that
labels in a domain name are always separated by dots. ...
Throws IllegalArgumentException - if the input string doesn't conform to
RFC 3490 specification"
Per the specification of RFC 3490:
==
[section 2]
"A label is an individual part of a domain name. Labels are usually
shown separated by dots; for example, the domain name
"www.example.com" is composed of three labels: "www", "example", and
"com". (The zero-length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as in
"www.example.com", is not considered a label in this specification.)"
"An "internationalized label" is a label to which the ToASCII
operation (see section 4) can be applied without failing (with the
UseSTD3ASCIIRules flag unset). ...
Although most Unicode characters can appear in
internationalized labels, ToASCII will fail for some input strings,
and such strings are not valid internationalized labels."
"An "internationalized domain name" (IDN) is a domain name in which
every label is an internationalized label."
[Section 4.1]
"ToASCII consists of the following steps:
...
8. Verify that the number of code points is in the range 1 to 63
inclusive."
Here are the questions:
1. whether "example..com" is an valid IDN?
As dot is used as label separators, there are three labels,
"example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
"example..com" is not a valid IDN.
We need to address the issue in IDN.
2. whether "xyz." is an valid IDN?
It's an gray area, I think. We can treat the trailing "." as root
label, or a label separator.
If the trailing "." is treated as label separator, "xyz." is invalid
per RFC 3490.
if the trailing "." is treated as root label, what's the expected
return value of IDN.toASCII("xyz.")? I think the return value can be
either "xyz." or "xyz". The current implementation returns "xyz".
We may need not to update the implementation if tailing "." is
treated as root label.
3. whether "." is an valid IDN?
It's an gray area again, I think.
As above, if the trailing "." is treated as root label, I think the
return value can be either "." or "". The current implementation throws
a StringIndexOutOfBoundsException.
However, what empty domain name ("") really means? I would prefer to
return "." for "." instead.
We need to address the issue in IDN.
Here comes the solution, the IDN.toASCII() returns:
1. "." for ".";
2. "xyz" for "xyz.";
3. IAE for "example..com".
Does it make sense?
Thanks,
Xuelei
On 8/7/2013 1:35 AM, Michael McMahon wrote:
I don't really understand the reason for the restriction in SNIHostName
But, I guess that is where it should be enforced if it is required.
Michael.
On 06/08/13 17:43, Dmitry Samersoff wrote:
Xuelei,
. (dot) is perfectly valid domain name and it means root domain so com.
is valid domain name as well.
It thinks to me that in context of methods your change we should ignore
trailing dots, rather than throw exception.
-Dmitry
On 2013-08-06 15:44, Xuelei Fan wrote:
Hi,
Please review the bug fix to strict the illegal input checking in IDN.
webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
Here is two test cases, which are expected to get IAE.
Case 1:
String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
String index out of range: 0
at java.lang.StringBuffer.charAt(StringBuffer.java:204)
at java.net.IDN.toASCIIInternal(IDN.java:279)
Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot
On 8/7/2013 10:05 PM, Michael McMahon wrote:
> Resolvers seem to accept queries using trailing dots.
>
> eg nslookup www.oracle.com.
>
> or InetAddress.getByName("www.oracle.com.");
>
> The part of RFC3490 quoted below seems to me to be saying
> that the empty label implied by the trailing dot is not regarded
> as a label so that you don't end up calling toAscii() or toUnicode()
> with an empty string. I don't think it's saying the trailing dot can't
> be there.
>
It makes sense.
What's your preference to return for IDN.toASCII("www.oracle.com."),
"www.oracle.com." or "www.oracle.com"? The current returned value is
"www.oracle.com". I would like to reserve the behavior in this update.
I think we are on same page soon.
Thanks,
Xuelei
> Michael
>
> On 07/08/13 13:44, Xuelei Fan wrote:
>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>> and the single dot represents the root zone. So you have to be
>>> careful making this sort of change to check the DNS RFCs first.
>> That's the first question we need to answer, whether IDN allow tailling
>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>> for example ""example..com")?
>>
>> Per the specification of IDN.toASCII():
>> ===
>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>> this case, the input string should not be used in an internationalized
>> domain name.
>>
>> A label is an individual part of a domain name. The original ToASCII
>> operation, as defined in RFC 3490, only operates on a single label. This
>> method can handle both label and entire domain name, by assuming that
>> labels in a domain name are always separated by dots. ...
>>
>> Throws IllegalArgumentException - if the input string doesn't conform to
>> RFC 3490 specification"
>>
>> Per the specification of RFC 3490:
>> ==
>> [section 2]
>> "A label is an individual part of a domain name. Labels are usually
>> shown separated by dots; for example, the domain name
>> "www.example.com" is composed of three labels: "www", "example", and
>> "com". (The zero-length root label described in [STD13], which can
>> be explicit as in "www.example.com." or implicit as in
>> "www.example.com", is not considered a label in this specification.)"
>>
>> "An "internationalized label" is a label to which the ToASCII
>> operation (see section 4) can be applied without failing (with the
>> UseSTD3ASCIIRules flag unset). ...
>> Although most Unicode characters can appear in
>> internationalized labels, ToASCII will fail for some input strings,
>> and such strings are not valid internationalized labels."
>>
>> "An "internationalized domain name" (IDN) is a domain name in which
>> every label is an internationalized label."
>>
>> [Section 4.1]
>> "ToASCII consists of the following steps:
>>
>> ...
>>
>> 8. Verify that the number of code points is in the range 1 to 63
>>inclusive."
>>
>>
>> Here are the questions:
>> 1. whether "example..com" is an valid IDN?
>> As dot is used as label separators, there are three labels,
>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>> "example..com" is not a valid IDN.
>>
>> We need to address the issue in IDN.
>>
>> 2. whether "xyz." is an valid IDN?
>> It's an gray area, I think. We can treat the trailing "." as root
>> label, or a label separator.
>> If the trailing "." is treated as label separator, "xyz." is invalid
>> per RFC 3490.
>> if the trailing "." is treated as root label, what's the expected
>> return value of IDN.toASCII("xyz.")? I think the return value can be
>> either "xyz." or "xyz". The current implementation returns "xyz".
>>
>> We may need not to update the implementation if tailing "." is
>> treated as root label.
>>
>> 3. whether "." is an valid IDN?
>> It's an gray area again, I think.
>> As above, if the trailing "." is treated as root label, I think the
>> return value can be either "." or "". The current implementation throws
>> a StringIndexOutOfBoundsException.
>>
>> However, what empty domain name ("") really means? I would prefer to
>> return "." for "." instead.
>>
>> We need to address the issue in IDN.
>>
>>
>> Here comes the solution, the IDN.toASCII() returns:
>> 1. "." for ".";
>> 2. "xyz" for "xyz.";
>> 3. IAE for "example..com".
>>
>> Does it make sense?
>>
>> Thanks,
>> Xuelei
>>
>>
>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>> I don't really understand the reason for the restriction in SNIHostName
>>> But, I guess that is where it should be enforced if it is required.
>>>
>>> Michael.
>>>
>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
Xuelei,
. (dot) is perfectly valid domain name and it means root domain so com.
is valid domain name as well.
Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot
On 07/08/13 15:13, Xuelei Fan wrote:
On 8/7/2013 10:05 PM, Michael McMahon wrote:
Resolvers seem to accept queries using trailing dots.
eg nslookup www.oracle.com.
or InetAddress.getByName("www.oracle.com.");
The part of RFC3490 quoted below seems to me to be saying
that the empty label implied by the trailing dot is not regarded
as a label so that you don't end up calling toAscii() or toUnicode()
with an empty string. I don't think it's saying the trailing dot can't
be there.
It makes sense.
What's your preference to return for IDN.toASCII("www.oracle.com."),
"www.oracle.com." or "www.oracle.com"? The current returned value is
"www.oracle.com". I would like to reserve the behavior in this update.
My opinion is to keep it as at present ie. "www.oracle.com."
Michael
I think we are on same page soon.
Thanks,
Xuelei
Michael
On 07/08/13 13:44, Xuelei Fan wrote:
On 8/7/2013 12:06 AM, Matthew Hall wrote:
Trailing dots are allowed in plain DNS (thus almost surely in IDN),
and the single dot represents the root zone. So you have to be
careful making this sort of change to check the DNS RFCs first.
That's the first question we need to answer, whether IDN allow tailling
dots ("com."), zero-length root label ("."), and zero-length label ("",
for example ""example..com")?
Per the specification of IDN.toASCII():
===
"ToASCII operation can fail. ToASCII fails if any step of it fails. If
ToASCII operation fails, an IllegalArgumentException will be thrown. In
this case, the input string should not be used in an internationalized
domain name.
A label is an individual part of a domain name. The original ToASCII
operation, as defined in RFC 3490, only operates on a single label. This
method can handle both label and entire domain name, by assuming that
labels in a domain name are always separated by dots. ...
Throws IllegalArgumentException - if the input string doesn't conform to
RFC 3490 specification"
Per the specification of RFC 3490:
==
[section 2]
"A label is an individual part of a domain name. Labels are usually
shown separated by dots; for example, the domain name
"www.example.com" is composed of three labels: "www", "example", and
"com". (The zero-length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as in
"www.example.com", is not considered a label in this specification.)"
"An "internationalized label" is a label to which the ToASCII
operation (see section 4) can be applied without failing (with the
UseSTD3ASCIIRules flag unset). ...
Although most Unicode characters can appear in
internationalized labels, ToASCII will fail for some input strings,
and such strings are not valid internationalized labels."
"An "internationalized domain name" (IDN) is a domain name in which
every label is an internationalized label."
[Section 4.1]
"ToASCII consists of the following steps:
...
8. Verify that the number of code points is in the range 1 to 63
inclusive."
Here are the questions:
1. whether "example..com" is an valid IDN?
As dot is used as label separators, there are three labels,
"example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
"example..com" is not a valid IDN.
We need to address the issue in IDN.
2. whether "xyz." is an valid IDN?
It's an gray area, I think. We can treat the trailing "." as root
label, or a label separator.
If the trailing "." is treated as label separator, "xyz." is invalid
per RFC 3490.
if the trailing "." is treated as root label, what's the expected
return value of IDN.toASCII("xyz.")? I think the return value can be
either "xyz." or "xyz". The current implementation returns "xyz".
We may need not to update the implementation if tailing "." is
treated as root label.
3. whether "." is an valid IDN?
It's an gray area again, I think.
As above, if the trailing "." is treated as root label, I think the
return value can be either "." or "". The current implementation throws
a StringIndexOutOfBoundsException.
However, what empty domain name ("") really means? I would prefer to
return "." for "." instead.
We need to address the issue in IDN.
Here comes the solution, the IDN.toASCII() returns:
1. "." for ".";
2. "xyz" for "xyz.";
3. IAE for "example..com".
Does it make sense?
Thanks,
Xuelei
On 8/7/2013 1:35 AM, Michael McMahon wrote:
I don't really understand the reason for the restriction in SNIHostName
But, I guess that is where it should be enforced if it is required.
Michael.
On 06/08/13 17:43, Dmitry Samersoff wrote:
Xuelei,
. (dot) is perfectly valid domain name and it means root domain so com.
is valid domain name as well.
It thinks to me that in context of methods your change we should ignore
trailing dots, rather than throw exception.
-Dmitry
On 2013-08-06 15:44, Xuelei Fan wrote:
Hi,
Please review the bug fix
Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot
Please review the new update:
http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
With this update, "com." is valid (return "com."); "." and
"example..com" are invalid. And IAE will be thrown for invalid IDN.
Thanks,
Xuelei
On 8/7/2013 10:18 PM, Michael McMahon wrote:
> On 07/08/13 15:13, Xuelei Fan wrote:
>> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>>> Resolvers seem to accept queries using trailing dots.
>>>
>>> eg nslookup www.oracle.com.
>>>
>>> or InetAddress.getByName("www.oracle.com.");
>>>
>>> The part of RFC3490 quoted below seems to me to be saying
>>> that the empty label implied by the trailing dot is not regarded
>>> as a label so that you don't end up calling toAscii() or toUnicode()
>>> with an empty string. I don't think it's saying the trailing dot can't
>>> be there.
>>>
>> It makes sense.
>>
>> What's your preference to return for IDN.toASCII("www.oracle.com."),
>> "www.oracle.com." or "www.oracle.com"? The current returned value is
>> "www.oracle.com". I would like to reserve the behavior in this update.
>
> My opinion is to keep it as at present ie. "www.oracle.com."
>
> Michael
>
>> I think we are on same page soon.
>>
>> Thanks,
>> Xuelei
>>
>>> Michael
>>>
>>> On 07/08/13 13:44, Xuelei Fan wrote:
On 8/7/2013 12:06 AM, Matthew Hall wrote:
> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
> and the single dot represents the root zone. So you have to be
> careful making this sort of change to check the DNS RFCs first.
That's the first question we need to answer, whether IDN allow tailling
dots ("com."), zero-length root label ("."), and zero-length label ("",
for example ""example..com")?
Per the specification of IDN.toASCII():
===
"ToASCII operation can fail. ToASCII fails if any step of it fails. If
ToASCII operation fails, an IllegalArgumentException will be thrown. In
this case, the input string should not be used in an internationalized
domain name.
A label is an individual part of a domain name. The original ToASCII
operation, as defined in RFC 3490, only operates on a single label.
This
method can handle both label and entire domain name, by assuming that
labels in a domain name are always separated by dots. ...
Throws IllegalArgumentException - if the input string doesn't
conform to
RFC 3490 specification"
Per the specification of RFC 3490:
==
[section 2]
"A label is an individual part of a domain name. Labels are usually
shown separated by dots; for example, the domain name
"www.example.com" is composed of three labels: "www", "example", and
"com". (The zero-length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as in
"www.example.com", is not considered a label in this
specification.)"
"An "internationalized label" is a label to which the ToASCII
operation (see section 4) can be applied without failing (with the
UseSTD3ASCIIRules flag unset). ...
Although most Unicode characters can appear in
internationalized labels, ToASCII will fail for some input strings,
and such strings are not valid internationalized labels."
"An "internationalized domain name" (IDN) is a domain name in which
every label is an internationalized label."
[Section 4.1]
"ToASCII consists of the following steps:
...
8. Verify that the number of code points is in the range 1 to 63
inclusive."
Here are the questions:
1. whether "example..com" is an valid IDN?
As dot is used as label separators, there are three labels,
"example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
"example..com" is not a valid IDN.
We need to address the issue in IDN.
2. whether "xyz." is an valid IDN?
It's an gray area, I think. We can treat the trailing "." as root
label, or a label separator.
If the trailing "." is treated as label separator, "xyz." is
invalid
per RFC 3490.
if the trailing "." is treated as root label, what's the expected
return value of IDN.toASCII("xyz.")? I think the return value can be
either "xyz." or "xyz". The current implementation returns "xyz".
We may need not to update the implementation if tailing "." is
treated as root label.
3. whether "." is an valid IDN?
It's an gray area again, I think.
As above, if the trailing "." is treated as root label, I think
the
return value can be either "." or "". The current implementation
throws
a StringIndexOutOfBoundsException.
However, what empty domain name ("") really means? I would
prefer
Re: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
I'm not sure if there is precedent for adding such release notes inline
in the javadoc (and subsequently removed in the next major release), but
I am not opposed to it in principle. I guess it may look something like:
* Note: In this release, this constructor no longer declares
* that it throws {@code SocketException}. Callers that explicitly
* handle {@code SocketException} ( or one of its superclasses )
* may need to remove this explicit exception handling.
Anyone every encounter this kind of comment before, or have a strong
opinion either way ( I'm personally on the fence ).
-Chris.
On 06/08/2013 20:25, Matthew Hall wrote:
On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
Documenting in release notes is okay too, but I suspect developers are not
likely to look there at first anyway. Thinking aloud, it would be nice if
some kind of annotation could be associated with the affected constructors
such that a more meaningful/customized error message could be emitted by
javac. But, perhaps there aren't sufficient other use cases to justify that.
Many of us use Eclipse, NetBeans, and JavaDoc.
So if we just had a comment in the JavaDoc, saying this was fixed, and what to
do, that ought to be more than adequate, and would prevent missing it if you
didn't see the relnotes.
Matthew.
Re: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
As a matter of interest, what (if any) precedent is there for such
source incompatible changes? Maybe it's more common that I thought.
Michael.
On 07/08/13 16:45, Chris Hegarty wrote:
I'm not sure if there is precedent for adding such release notes
inline in the javadoc (and subsequently removed in the next major
release), but I am not opposed to it in principle. I guess it may look
something like:
* Note: In this release, this constructor no longer declares
* that it throws {@code SocketException}. Callers that explicitly
* handle {@code SocketException} ( or one of its superclasses )
* may need to remove this explicit exception handling.
Anyone every encounter this kind of comment before, or have a strong
opinion either way ( I'm personally on the fence ).
-Chris.
On 06/08/2013 20:25, Matthew Hall wrote:
On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
Documenting in release notes is okay too, but I suspect developers
are not
likely to look there at first anyway. Thinking aloud, it would be
nice if
some kind of annotation could be associated with the affected
constructors
such that a more meaningful/customized error message could be
emitted by
javac. But, perhaps there aren't sufficient other use cases to
justify that.
Many of us use Eclipse, NetBeans, and JavaDoc.
So if we just had a comment in the JavaDoc, saying this was fixed,
and what to
do, that ought to be more than adequate, and would prevent missing it
if you
didn't see the relnotes.
Matthew.
Re: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
Hello,
Source incompatible changes of this magnitude (if not exact character),
have been made in major release before.
IMO, release notes are the proper mechanism to inform users of such a
change rather than the constructor javadoc. (Putting such time-sensitive
notes in javadoc tends to age poorly and become a distraction rather
than a help.)
Cheers,
-Joe
On 08/07/2013 08:49 AM, Michael McMahon wrote:
As a matter of interest, what (if any) precedent is there for such
source incompatible changes? Maybe it's more common that I thought.
Michael.
On 07/08/13 16:45, Chris Hegarty wrote:
I'm not sure if there is precedent for adding such release notes
inline in the javadoc (and subsequently removed in the next major
release), but I am not opposed to it in principle. I guess it may
look something like:
* Note: In this release, this constructor no longer declares
* that it throws {@code SocketException}. Callers that explicitly
* handle {@code SocketException} ( or one of its superclasses )
* may need to remove this explicit exception handling.
Anyone every encounter this kind of comment before, or have a strong
opinion either way ( I'm personally on the fence ).
-Chris.
On 06/08/2013 20:25, Matthew Hall wrote:
On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
Documenting in release notes is okay too, but I suspect developers
are not
likely to look there at first anyway. Thinking aloud, it would be
nice if
some kind of annotation could be associated with the affected
constructors
such that a more meaningful/customized error message could be
emitted by
javac. But, perhaps there aren't sufficient other use cases to
justify that.
Many of us use Eclipse, NetBeans, and JavaDoc.
So if we just had a comment in the JavaDoc, saying this was fixed,
and what to
do, that ought to be more than adequate, and would prevent missing
it if you
didn't see the relnotes.
Matthew.
Re: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
In that case, my vote would be to just put it in release notes. If there
are others in JDK 8, then maybe
they could be listed together.
Michael
On 07/08/13 17:03, Joe Darcy wrote:
Hello,
Source incompatible changes of this magnitude (if not exact
character), have been made in major release before.
IMO, release notes are the proper mechanism to inform users of such a
change rather than the constructor javadoc. (Putting such
time-sensitive notes in javadoc tends to age poorly and become a
distraction rather than a help.)
Cheers,
-Joe
On 08/07/2013 08:49 AM, Michael McMahon wrote:
As a matter of interest, what (if any) precedent is there for such
source incompatible changes? Maybe it's more common that I thought.
Michael.
On 07/08/13 16:45, Chris Hegarty wrote:
I'm not sure if there is precedent for adding such release notes
inline in the javadoc (and subsequently removed in the next major
release), but I am not opposed to it in principle. I guess it may
look something like:
* Note: In this release, this constructor no longer declares
* that it throws {@code SocketException}. Callers that explicitly
* handle {@code SocketException} ( or one of its superclasses )
* may need to remove this explicit exception handling.
Anyone every encounter this kind of comment before, or have a strong
opinion either way ( I'm personally on the fence ).
-Chris.
On 06/08/2013 20:25, Matthew Hall wrote:
On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
Documenting in release notes is okay too, but I suspect developers
are not
likely to look there at first anyway. Thinking aloud, it would be
nice if
some kind of annotation could be associated with the affected
constructors
such that a more meaningful/customized error message could be
emitted by
javac. But, perhaps there aren't sufficient other use cases to
justify that.
Many of us use Eclipse, NetBeans, and JavaDoc.
So if we just had a comment in the JavaDoc, saying this was fixed,
and what to
do, that ought to be more than adequate, and would prevent missing
it if you
didn't see the relnotes.
Matthew.
hg: jdk8/tl/jdk: 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools
Changeset: c1f129f62f36 Author:lagergren Date: 2013-08-07 08:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools Reviewed-by: darcy Contributed-by: marcus.lagerg...@oracle.com ! src/share/classes/java/net/SocketAddress.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/sun/tools/jar/JarException.java
hg: jdk8/tl/jdk: 8022554: Fix Warnings in sun.invoke.anon Package
Changeset: d1c82d5bee3f Author:dxu Date: 2013-08-07 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c82d5bee3f 8022554: Fix Warnings in sun.invoke.anon Package Reviewed-by: darcy, mduigou, lancea ! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java
Re: RFR [8022584] Memory leak in some NetworkInterface methods
(cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: Hello everybody! Some methods of NetworkInterface class were reported to leak memory. http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) Examples are isUp() and isLoopback(). Affected versions of jdk are 6, 7 and 8 Would you please review a simple fix that removes the unnecessary allocation? http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ Sincerely yours, Ivan
Re: RFR [8022584] Memory leak in some NetworkInterface methods
Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. Sincerely yours, Ivan On 08.08.2013 5:05, Alan Bateman wrote: (cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: Hello everybody! Some methods of NetworkInterface class were reported to leak memory. http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) Examples are isUp() and isLoopback(). Affected versions of jdk are 6, 7 and 8 Would you please review a simple fix that removes the unnecessary allocation? http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ Sincerely yours, Ivan
hg: jdk8/tl/jdk: 8022479: clean up warnings from sun.tools.asm
Changeset: 8c50c27418d3 Author:smarks Date: 2013-08-07 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c50c27418d3 8022479: clean up warnings from sun.tools.asm Reviewed-by: lancea, darcy ! src/share/classes/sun/tools/asm/Assembler.java ! src/share/classes/sun/tools/asm/ConstantPool.java ! src/share/classes/sun/tools/asm/Instruction.java ! src/share/classes/sun/tools/asm/SwitchData.java ! src/share/classes/sun/tools/asm/TryData.java
Re: RFR [8022584] Memory leak in some NetworkInterface methods
On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw OutOfMemoryError if it has memory issues, not abort the VM! I recommend that you check for NULL and/or a pending exception. David Sincerely yours, Ivan On 08.08.2013 5:05, Alan Bateman wrote: (cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: Hello everybody! Some methods of NetworkInterface class were reported to leak memory. http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) Examples are isUp() and isLoopback(). Affected versions of jdk are 6, 7 and 8 Would you please review a simple fix that removes the unnecessary allocation? http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ Sincerely yours, Ivan
Re: RFR [8022584] Memory leak in some NetworkInterface methods
On 07/08/2013 18:20, Ivan Gerasimov wrote: Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. GetStringUTFChars is supposed to return NULL in OOM situations so this may be a bug (but if you can, it would be good to handle it in the NetworkInterface code). -Alan
Re: RFR [8022584] Memory leak in some NetworkInterface methods
David, Alan, I added checking for NULL results and throwing OOMException if necessary. I've also added some spaces along the code to improve indentation. Would you please review the updated webrev? http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ Sincerely yours, Ivan On 08.08.2013 5:35, David Holmes wrote: On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw OutOfMemoryError if it has memory issues, not abort the VM! I recommend that you check for NULL and/or a pending exception. David Sincerely yours, Ivan On 08.08.2013 5:05, Alan Bateman wrote: (cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: Hello everybody! Some methods of NetworkInterface class were reported to leak memory. http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) Examples are isUp() and isLoopback(). Affected versions of jdk are 6, 7 and 8 Would you please review a simple fix that removes the unnecessary allocation? http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ Sincerely yours, Ivan
Re: RFR [8022584] Memory leak in some NetworkInterface methods
Ivan, On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: David, Alan, I added checking for NULL results and throwing OOMException if necessary. You don't need to throw it yourself: JNU_ThrowOutOfMemoryError(env, NULL); Assuming a correct VM implementation if NULL is returned then an OOME should already be pending and will be thrown as soon as your native code returns to Java. Thanks, David I've also added some spaces along the code to improve indentation. Would you please review the updated webrev? http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ Sincerely yours, Ivan On 08.08.2013 5:35, David Holmes wrote: On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw OutOfMemoryError if it has memory issues, not abort the VM! I recommend that you check for NULL and/or a pending exception. David Sincerely yours, Ivan On 08.08.2013 5:05, Alan Bateman wrote: (cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: Hello everybody! Some methods of NetworkInterface class were reported to leak memory. http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) Examples are isUp() and isLoopback(). Affected versions of jdk are 6, 7 and 8 Would you please review a simple fix that removes the unnecessary allocation? http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ Sincerely yours, Ivan
hg: jdk8/tl/jdk: 8015986: Incorrect Localization of HijrahChronology
Changeset: 0beaa65c90c8 Author:okutsu Date: 2013-08-08 13:51 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0beaa65c90c8 8015986: Incorrect Localization of HijrahChronology Reviewed-by: naoto Contributed-by: scolebou...@joda.org, roger.ri...@oracle.com ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java
