HttpCookie.domainMatches("hostname.local", "hostname") return false
Hi,
I find that HttpCookie.domainMatches("hostname.local", "hostname")
returns false, which may be a bug.
According to spec, the effective host name of "hostname" is
"hostname.local", which is string
exactly the same with the first parameter. Thus the method should return
true for this invocation.
I attached the simple testcase here:
// Testcase
import java.net.HttpCookie;
public class DomainMatchTest{
public static void main(String args[]){
// "true" should be printed, but get "false".
System.out.println(HttpCookie.domainMatches("hostname.local",
"hostname"));
}
}
// End of testcase
Any comments?
--
Best Regards,
Sean Chou
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Hi,
If there's no different opinions or objection, can someone raise a bug on
the Oracle bug system for me please?
Thanks.
2011/2/22 Sean Chou
> Hi,
>I find that HttpCookie.domainMatches("hostname.local", "hostname")
> returns false, which may be a bug.
>According to spec, the effective host name of "hostname" is
> "hostname.local", which is string
> exactly the same with the first parameter. Thus the method should return
> true for this invocation.
>
>I attached the simple testcase here:
> // Testcase
> import java.net.HttpCookie;
>
> public class DomainMatchTest{
>
>public static void main(String args[]){
> // "true" should be printed, but get "false".
> System.out.println(HttpCookie.domainMatches("hostname.local",
> "hostname"));
>}
>
> }
> // End of testcase
>
> Any comments?
>
> --
> Best Regards,
> Sean Chou
>
>
--
Best Regards,
Sean Chou
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Hi,
Is there any update to this issue? If not, I have a simple patch as
follows:
diff -r e947a98ea3c1 src/share/classes/java/net/HttpCookie.java
--- a/src/share/classes/java/net/HttpCookie.javaThu Mar 10 17:11:08 2011
-0800
+++ b/src/share/classes/java/net/HttpCookie.javaMon Mar 14 16:02:14 2011
+0800
@@ -771,6 +771,10 @@
host.equalsIgnoreCase(domain.substring(1)));
}
+if (isLocalDomain && domain.startWith(host)){
+return true;
+}
+
return false;
}
2011/3/2 Chris Hegarty
> On 03/ 2/11 01:50 AM, Sean Chou wrote:
>
>> Hi,
>>If there's no different opinions or objection, can someone raise a
>> bug on the Oracle bug system for me please?
>>
>
> Sorry, I though I replied to this.
>
> It would appear to be a bug. I filed CR 7023713,
> "HttpCookie.domainMatches("hostname.local", "hostname") should return true",
> for this issue.
>
> -Chris.
>
> Thanks.
>>
>>
>> 2011/2/22 Sean Chou > <mailto:zho...@linux.vnet.ibm.com>>
>>
>>Hi,
>>I find that HttpCookie.domainMatches("hostname.local",
>>"hostname") returns false, which may be a bug.
>>According to spec, the effective host name of "hostname" is
>>"hostname.local", which is string
>>exactly the same with the first parameter. Thus the method should
>>return true for this invocation.
>>
>>I attached the simple testcase here:
>>// Testcase
>>import java.net.HttpCookie;
>>
>>public class DomainMatchTest{
>>
>>public static void main(String args[]){
>> // "true" should be printed, but get "false".
>> System.out.println(HttpCookie.domainMatches("hostname.local",
>>"hostname"));
>>}
>>
>>}
>>// End of testcase
>>
>>Any comments?
>>
>>--
>>Best Regards,
>>Sean Chou
>>
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>
--
Best Regards,
Sean Chou
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Thank Chris.
Here is an alternative fix, with the TestHttpCookie.java updated
together.
diff -r 554adcfb615e src/share/classes/java/net/HttpCookie.java
--- a/src/share/classes/java/net/HttpCookie.java Wed Mar 16 15:01:07 2011
-0700
+++ b/src/share/classes/java/net/HttpCookie.java Thu Mar 17 13:35:24 2011
+0800
@@ -751,6 +751,9 @@
int firstDotInHost = host.indexOf('.');
if (firstDotInHost == -1 && isLocalDomain)
return true;
+// if the host name contains no dot and the domain name is
"host.local"
+if (firstDotInHost == -1 && domain.equalsIgnoreCase(host +
".local"))
+return true;
int domainLength = domain.length();
int lengthDiff = host.length() - domainLength;
diff -r 554adcfb615e test/java/net/CookieHandler/TestHttpCookie.java
--- a/test/java/net/CookieHandler/TestHttpCookie.java Wed Mar 16 15:01:07
2011 -0700
+++ b/test/java/net/CookieHandler/TestHttpCookie.java Thu Mar 17 13:35:24
2011 +0800
@@ -368,6 +368,7 @@
dm(".com.", "whatever.com", false);
dm(".ajax.com", "ajax.com", true);
dm(".local","example.local",true);
+dm("cocope.local", "cocope",true);
// bug 6277808
testCount++;
2011/3/17 Chris Hegarty
> Hi Sean,
>
> I applied your patch to my local repo and it doesn't compile, startWith ->
> startsWith ;-)
>
> More critically it doesn't resolve the problem, isLocalDomain will be false
> for 'hostname.local'.
>
> I am working on an alternative fix ( please feel free to work on an
> alternative fix also). Additional, we should update
> test/java/net/CookieHandler/TestHttpCookie.java ( under "Test domainMatches"
> ).
>
> -Chris.
>
>
> On 03/14/11 08:03 AM, Sean Chou wrote:
>
>> Hi,
>>
>>Is there any update to this issue? If not, I have a simple patch as
>> follows:
>>
>>
>> diff -r e947a98ea3c1 src/share/classes/java/net/HttpCookie.java
>> --- a/src/share/classes/java/net/HttpCookie.javaThu Mar 10 17:11:08
>> 2011 -0800
>> +++ b/src/share/classes/java/net/HttpCookie.javaMon Mar 14 16:02:14
>> 2011 +0800
>> @@ -771,6 +771,10 @@
>> host.equalsIgnoreCase(domain.substring(1)));
>> }
>>
>> +if (isLocalDomain && domain.startWith(host)){
>> +return true;
>> +}
>> +
>> return false;
>> }
>>
>>
>> 2011/3/2 Chris Hegarty > <mailto:chris.hega...@oracle.com>>
>>
>>On 03/ 2/11 01:50 AM, Sean Chou wrote:
>>
>>Hi,
>>If there's no different opinions or objection, can someone
>>raise a
>>bug on the Oracle bug system for me please?
>>
>>
>>Sorry, I though I replied to this.
>>
>>It would appear to be a bug. I filed CR 7023713,
>>"HttpCookie.domainMatches("hostname.local", "hostname") should
>>return true", for this issue.
>>
>>-Chris.
>>
>>Thanks.
>>
>>
>>2011/2/22 Sean Chou ><mailto:zho...@linux.vnet.ibm.com>
>><mailto:zho...@linux.vnet.ibm.com
>><mailto:zho...@linux.vnet.ibm.com>>>
>>
>>Hi,
>>I find that HttpCookie.domainMatches("hostname.local",
>>"hostname") returns false, which may be a bug.
>>According to spec, the effective host name of "hostname" is
>>"hostname.local", which is string
>>exactly the same with the first parameter. Thus the method
>>should
>> return true for this invocation.
>>
>> I attached the simple testcase here:
>>// Testcase
>>import java.net.HttpCookie;
>>
>>public class DomainMatchTest{
>>
>>public static void main(String args[]){
>> // "true" should be printed, but get "false".
>>
>>System.out.println(HttpCookie.domainMatches("hostname.local",
>>"hostname"));
>>}
>>
>>}
>>// End of testcase
>>
>>Any comments?
>>
>>--
>>Best Regards,
>>Sean Chou
>>
>>
>>
>>
>>--
>>Best Regards,
>>Sean Chou
>>
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>
--
Best Regards,
Sean Chou
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Hi Chris, Is there any progress on this issue? -- Best Regards, Sean Chou
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Hi guys,
Is there any update to this bug? or is it targeted to java8?
2011/3/17 Chris Hegarty
> Hi Sean,
>
> I applied your patch to my local repo and it doesn't compile, startWith ->
> startsWith ;-)
>
> More critically it doesn't resolve the problem, isLocalDomain will be false
> for 'hostname.local'.
>
> I am working on an alternative fix ( please feel free to work on an
> alternative fix also). Additional, we should update
> test/java/net/CookieHandler/**TestHttpCookie.java ( under "Test
> domainMatches" ).
>
> -Chris.
>
>
> On 03/14/11 08:03 AM, Sean Chou wrote:
>
>> Hi,
>>
>>Is there any update to this issue? If not, I have a simple patch as
>> follows:
>>
>>
>> diff -r e947a98ea3c1 src/share/classes/java/net/**HttpCookie.java
>> --- a/src/share/classes/java/net/**HttpCookie.javaThu Mar 10 17:11:08
>> 2011 -0800
>> +++ b/src/share/classes/java/net/**HttpCookie.javaMon Mar 14 16:02:14
>> 2011 +0800
>> @@ -771,6 +771,10 @@
>> host.equalsIgnoreCase(domain.**substring(1)));
>> }
>>
>> +if (isLocalDomain && domain.startWith(host)){
>> +return true;
>> +}
>> +
>> return false;
>> }
>>
>>
>> 2011/3/2 Chris Hegarty > <mailto:chris.hegarty@oracle.**com >>
>>
>>
>>On 03/ 2/11 01:50 AM, Sean Chou wrote:
>>
>>Hi,
>>If there's no different opinions or objection, can someone
>>raise a
>>bug on the Oracle bug system for me please?
>>
>>
>>Sorry, I though I replied to this.
>>
>>It would appear to be a bug. I filed CR 7023713,
>>"HttpCookie.domainMatches("**hostname.local", "hostname") should
>>return true", for this issue.
>>
>>-Chris.
>>
>>Thanks.
>>
>>
>>2011/2/22 Sean Chou ><mailto:zho...@linux.vnet.ibm.**com >
>><mailto:zho...@linux.vnet.ibm.**com
>><mailto:zho...@linux.vnet.ibm.**com >>>
>>
>>Hi,
>>I find that HttpCookie.domainMatches("**hostname.local",
>>"hostname") returns false, which may be a bug.
>>According to spec, the effective host name of "hostname" is
>>"hostname.local", which is string
>>exactly the same with the first parameter. Thus the method
>>should
>>return true for this invocation.
>>
>> I attached the simple testcase here:
>>// Testcase
>>import java.net.HttpCookie;
>>
>> public class DomainMatchTest{
>>
>>public static void main(String args[]){
>> // "true" should be printed, but get "false".
>>
>>System.out.println(HttpCookie.**domainMatches("hostname.local"**,
>>"hostname"));
>>}
>>
>>}
>>// End of testcase
>>
>>Any comments?
>>
>>--
>>Best Regards,
>>Sean Chou
>>
>>
>>
>>
>>--
>>Best Regards,
>>Sean Chou
>>
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>
--
Best Regards,
Sean Chou
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Hi all,
I checked with java8, this problem still exists; and I checked the patch,
it is still working.
The bug was filed with id 7023713 for java7, and the patch is here. So,
would anyone like to
take a look at it again? Thanks.
2011/2/22 Sean Chou
> Hi,
>I find that HttpCookie.domainMatches("hostname.local", "hostname")
> returns false, which may be a bug.
>According to spec, the effective host name of "hostname" is
> "hostname.local", which is string
> exactly the same with the first parameter. Thus the method should return
> true for this invocation.
>
>I attached the simple testcase here:
> // Testcase
> import java.net.HttpCookie;
>
> public class DomainMatchTest{
>
>public static void main(String args[]){
> // "true" should be printed, but get "false".
> System.out.println(HttpCookie.domainMatches("hostname.local",
> "hostname"));
>}
>
> }
> // End of testcase
>
> Any comments?
>
> --
> Best Regards,
> Sean Chou
>
>
--
Best Regards,
Sean Chou
localdomainmatch.patch
Description: Binary data
Re: HttpCookie.domainMatches("hostname.local", "hostname") return false
Thank you very much!
2011/8/19 Chris Hegarty
> Hi Sean,
>
> I submitted a JPRT job with you patch. If all builds and tests are
> successful I'll push this change for you.
>
> diff -r 46b53f80ab0a src/share/classes/java/net/**HttpCookie.java
> --- a/src/share/classes/java/net/**HttpCookie.javaFri Aug 19
> 10:55:05 2011 +0100
> +++ b/src/share/classes/java/net/**HttpCookie.javaFri Aug 19
> 15:16:36 2011 +0100
> @@ -751,6 +751,11 @@ public final class HttpCookie implements
> // if the host name contains no dot and the domain name is .local
>
> int firstDotInHost = host.indexOf('.');
> if (firstDotInHost == -1 && isLocalDomain)
> +return true;
> +
> +// if the host name contains no dot and the domain name is
> "host.local"
> +if (firstDotInHost == -1 &&
> +domain.equalsIgnoreCase(host + ".local"))
> return true;
>
> int domainLength = domain.length();
> diff -r 46b53f80ab0a test/java/net/CookieHandler/**TestHttpCookie.java
> --- a/test/java/net/CookieHandler/**TestHttpCookie.java Fri Aug 19
> 10:55:05 2011 +0100
> +++ b/test/java/net/CookieHandler/**TestHttpCookie.java Fri Aug 19
> 15:16:36 2011 +0100
> @@ -362,12 +362,13 @@ public class TestHttpCookie {
> eq(c1, c2, false);
>
> header("Test domainMatches()");
> -dm(".foo.com", "y.x.foo.com", false);
> -dm(".foo.com", "x.foo.com",true);
> -dm(".com", "whatever.com", false);
> -dm(".com.", "whatever.com", false);
>
> -dm(".ajax.com", "ajax.com", true);
> -dm(".local","example.local",true);
> +dm(".foo.com", "y.x.foo.com", false);
> +dm(".foo.com", "x.foo.com",true);
> +dm(".com", "whatever.com", false);
> +dm(".com.", "whatever.com", false);
>
> +dm(".ajax.com", "ajax.com", true);
> +dm(".local","example.local",true);
> +dm("example.local", "example", true);
>
> // bug 6277808
> testCount++;
>
> -Chris.
>
>
>
> On 04/08/2011 08:09, Sean Chou wrote:
>
>> Hi all,
>>
>>I checked with java8, this problem still exists; and I checked the
>> patch, it is still working.
>> The bug was filed with id 7023713 for java7, and the patch is here. So,
>> would anyone like to
>> take a look at it again? Thanks.
>>
>> 2011/2/22 Sean Chou > <mailto:zho...@linux.vnet.ibm.**com >>
>>
>>
>>Hi,
>>I find that HttpCookie.domainMatches("**hostname.local",
>>"hostname") returns false, which may be a bug.
>>According to spec, the effective host name of "hostname" is
>>"hostname.local", which is string
>>exactly the same with the first parameter. Thus the method should
>>return true for this invocation.
>>
>>I attached the simple testcase here:
>>// Testcase
>>import java.net.HttpCookie;
>>
>>public class DomainMatchTest{
>>
>>public static void main(String args[]){
>> // "true" should be printed, but get "false".
>> System.out.println(HttpCookie.**domainMatches("hostname.local"*
>> *,
>>"hostname"));
>>}
>>
>>}
>>// End of testcase
>>
>>Any comments?
>>
>>--
>>Best Regards,
>>Sean Chou
>>
>>
>>
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>
--
Best Regards,
Sean Chou
A behavior difference about reachable test for address zero
Hi all,
I found a behavior difference when running the testcase PingZero on
linux and windows.
On Linux, it prints "reachable" while on windows "unreachable", which is
the same with
the result of running "ping 0.0.0.0" on these two platforms.
Is it a bug or intended?
PingZero.java :
//
import java.net.*;
class PingZero {
public static void main(String args[]) {
try {
InetAddress inetAddress = InetAddress.getByAddress(new byte[] {
0,
0, 0, 0 });
boolean b = inetAddress.isReachable((int) (1.0 * 3000));
if (b) {
System.out.println(" 0.0.0.0 is reachable ! ");
} else {
System.out.println(" 0.0.0.0 is not reachable ! ");
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
//
--
Best Regards,
Sean Chou
PingZero.java
Description: Binary data
Re: A behavior difference about reachable test for address zero
Yes. ping 0.0.0.0 on linux works; while windows report not reachable. On Tue, Nov 22, 2011 at 9:22 PM, Alan Bateman wrote: > On 22/11/2011 08:40, Sean Chou wrote: > >> >> Hi all, >> >>I found a behavior difference when running the testcase PingZero on >> linux and windows. >> On Linux, it prints "reachable" while on windows "unreachable", which is >> the same with >> the result of running "ping 0.0.0.0" on these two platforms. >> >>Is it a bug or intended? >> >> Do you get the same thing when you use the ping command? > > -Alan > -- Best Regards, Sean Chou
Re: A behavior difference about reachable test for address zero
No. Once before a time there was a testcase about it, so I just make sure it's a testcase problem. Thanks anyway. On Fri, Nov 25, 2011 at 7:28 PM, Chris Hegarty wrote: > On 25/11/2011 05:58, Sean Chou wrote: > >> Yes. ping 0.0.0.0 on linux works; while windows report not reachable. >> > > Right, so InetAddress.isReachable is reporting the same result as the > native ping command. Is this an issue for you guys? > > -Chris. > > On Tue, Nov 22, 2011 at 9:22 PM, Alan Bateman > <mailto:Alan.Bateman@oracle.**com >> wrote: >> >>On 22/11/2011 08:40, Sean Chou wrote: >> >> >>Hi all, >> >>I found a behavior difference when running the testcase >>PingZero on linux and windows. >>On Linux, it prints "reachable" while on windows "unreachable", >>which is the same with >>the result of running "ping 0.0.0.0" on these two platforms. >> >> Is it a bug or intended? >> >>Do you get the same thing when you use the ping command? >> >>-Alan >> >> >> >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou
A little modification to error message
Hi all, We did some modification in these error messages because of some user feedback “It is confusing to realize if the OOM is from java heap or native heap”. So these error messages are modified from "heap allocation failed" to "Native heap allocation failed". And in some places a little more to help locate to functions like "send buffer heap allocation failed". Would any one like to take a look? webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.00/ . -- Best Regards, Sean Chou
Re: A little modification to error message
Hi Chris, They are not all native OOMs, I made a new one which includes all of them. Please take a look. webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.01/ On Thu, Jun 21, 2012 at 5:23 PM, Chris Hegarty wrote: > Sean, > > The updated error messages look fine to me. > > Are these all the possibly native OOM throw sites in the networking area, > or just some you came across? > > -Chris. > > > On 21/06/2012 06:41, Sean Chou wrote: > >> Hi all, >> >> We did some modification in these error messages because of some >> user feedback “It is confusing to realize if the OOM is from java heap >> or native heap”. So these error messages are modified from "heap >> allocation failed" to "Native heap allocation failed". And in some >> places a little more to help locate to functions like "send buffer heap >> allocation failed". >> Would any one like to take a look? >> >> webrev: >> http://cr.openjdk.java.net/~**zhouyx/OJDK-528/webrev.00/<http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.00/> >> . >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou
Re: A little modification to error message
Hello, Any one would like to take a look again ? -- Forwarded message -- From: Sean Chou Date: Tue, Jun 26, 2012 at 1:03 PM Subject: Re: A little modification to error message To: Chris Hegarty Cc: net-dev@openjdk.java.net Hi Chris, They are not all native OOMs, I made a new one which includes all of them. Please take a look. webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.01/ On Thu, Jun 21, 2012 at 5:23 PM, Chris Hegarty wrote: > Sean, > > The updated error messages look fine to me. > > Are these all the possibly native OOM throw sites in the networking area, > or just some you came across? > > -Chris. > > > On 21/06/2012 06:41, Sean Chou wrote: > >> Hi all, >> >> We did some modification in these error messages because of some >> user feedback “It is confusing to realize if the OOM is from java heap >> or native heap”. So these error messages are modified from "heap >> allocation failed" to "Native heap allocation failed". And in some >> places a little more to help locate to functions like "send buffer heap >> allocation failed". >> Would any one like to take a look? >> >> webrev: >> http://cr.openjdk.java.net/~**zhouyx/OJDK-528/webrev.00/<http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.00/> >> . >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou -- Best Regards, Sean Chou
Re: A little modification to error message
A bug is reported. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181353 . On Mon, Jul 2, 2012 at 3:57 PM, Chris Hegarty wrote: > Thanks Sean, looks fine to me. > > -Chris > > Sean Chou wrote: > > >Hello, > > > >Any one would like to take a look again ? > > > >-- Forwarded message -- > >From: Sean Chou > >Date: Tue, Jun 26, 2012 at 1:03 PM > >Subject: Re: A little modification to error message > >To: Chris Hegarty > >Cc: net-dev@openjdk.java.net > > > > > >Hi Chris, > > > >They are not all native OOMs, I made a new one which includes all of > >them. Please take a look. > > > >webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.01/ > > > > > >On Thu, Jun 21, 2012 at 5:23 PM, Chris Hegarty > > wrote: > > > >> Sean, > >> > >> The updated error messages look fine to me. > >> > >> Are these all the possibly native OOM throw sites in the networking > area, > >> or just some you came across? > >> > >> -Chris. > >> > >> > >> On 21/06/2012 06:41, Sean Chou wrote: > >> > >>> Hi all, > >>> > >>> We did some modification in these error messages because of some > >>> user feedback “It is confusing to realize if the OOM is from java heap > >>> or native heap”. So these error messages are modified from "heap > >>> allocation failed" to "Native heap allocation failed". And in some > >>> places a little more to help locate to functions like "send buffer heap > >>> allocation failed". > >>> Would any one like to take a look? > >>> > >>> webrev: http://cr.openjdk.java.net/~**zhouyx/OJDK-528/webrev.00/< > http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.00/> > >>> . > >>> > >>> -- > >>> Best Regards, > >>> Sean Chou > >>> > >>> > > > > > >-- > >Best Regards, > >Sean Chou > > > > > > > > > >-- > >Best Regards, > >Sean Chou > -- Best Regards, Sean Chou
Re: A little modification to error message
Thanks Jonathan and Chris. Verified. On Fri, Jul 6, 2012 at 10:44 AM, Jonathan Lu wrote: > Hi Sean, > > Patch committed > > Changeset: 15a6b0bceb1e > Author:zhouyx > Date: 2012-07-06 10:36 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15a6b0bceb1e > > 7181353: Update error message to distinguish native OOM and java OOM in net > Reviewed-by: chegar > > ! src/solaris/native/java/net/Inet4AddressImpl.c > ! src/solaris/native/java/net/Inet6AddressImpl.c > ! src/solaris/native/java/net/NetworkInterface.c > ! src/solaris/native/java/net/PlainDatagramSocketImpl.c > ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c > ! src/windows/native/java/net/Inet6AddressImpl.c > ! src/windows/native/java/net/NetworkInterface.c > ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c > > > Please verify > > Regards > Jonathan > > > On 07/03/2012 02:10 PM, Sean Chou wrote: > > > A bug is reported. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181353 . > > On Mon, Jul 2, 2012 at 3:57 PM, Chris Hegarty > wrote: > >> Thanks Sean, looks fine to me. >> >> -Chris >> >> Sean Chou wrote: >> >> >Hello, >> > >> >Any one would like to take a look again ? >> > >> >-- Forwarded message -- >> >From: Sean Chou >> >Date: Tue, Jun 26, 2012 at 1:03 PM >> >Subject: Re: A little modification to error message >> >To: Chris Hegarty >> >Cc: net-dev@openjdk.java.net >> > >> > >> >Hi Chris, >> > >> >They are not all native OOMs, I made a new one which includes all of >> >them. Please take a look. >> > >> >webrev: http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.01/ >> > >> > >> >On Thu, Jun 21, 2012 at 5:23 PM, Chris Hegarty > > >> > wrote: >> > >> >> Sean, >> >> >> >> The updated error messages look fine to me. >> >> >> >> Are these all the possibly native OOM throw sites in the networking >> area, >> >> or just some you came across? >> >> >> >> -Chris. >> >> >> >> >> >> On 21/06/2012 06:41, Sean Chou wrote: >> >> >> >>> Hi all, >> >>> >> >>> We did some modification in these error messages because of some >> >>> user feedback “It is confusing to realize if the OOM is from java heap >> >>> or native heap”. So these error messages are modified from "heap >> >>> allocation failed" to "Native heap allocation failed". And in some >> >>> places a little more to help locate to functions like "send buffer >> heap >> >>> allocation failed". >> >>> Would any one like to take a look? >> >>> >> >>> webrev: http://cr.openjdk.java.net/~**zhouyx/OJDK-528/webrev.00/< >> http://cr.openjdk.java.net/~zhouyx/OJDK-528/webrev.00/> >> >>> . >> >>> >> >>> -- >> >>> Best Regards, >> >>> Sean Chou >> >>> >> >>> >> > >> > >> >-- >> >Best Regards, >> >Sean Chou >> > >> > >> > >> > >> >-- >> >Best Regards, >> >Sean Chou >> > > > > -- > Best Regards, > Sean Chou > > > > -- Best Regards, Sean Chou
Re: Http client API
Is it possible to have methods like public abstract HTMLDocument getResponse(String request) in class HttpClient ? On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~**michaelm/httpclient/v0.3/<http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/> > > We would like to review the api on this mailing list. > So, all comments are welcome. > > Thanks > Michael McMahon. > -- Best Regards, Sean Chou
Re: Http client API
Hi Chris, That's exactly my concern. I agree this provides best flexibility and content convenient methods are not proper in this API. So, is there going to have content specific convenient APIs like java.nio.file.Files ? Although it is a wrapper, it may be useful and intuitive, and easy to use for those who just want to open a webpage but don't want to know request and response. And as well doesn't break modularization. Thanks. On Wed, Aug 8, 2012 at 5:52 PM, Chris Hegarty wrote: > On 08/08/2012 07:25, Sean Chou wrote: > >> >> Is it possible to have methods like >> >> public abstract HTMLDocument getResponse(String request) in class >> HttpClient ? >> > > Hi Sean, > > I think what you are suggesting is content specific convenience methods, > something akin to URLConnection.getContent(), right? In my experience, this > type of interface can be a little problematic and not all that widely used. > > I'm personally not in favor of such convenience methods. I can see their > potential value, but this would appear to be a low level API and I don't > think it should favor one specific content type over another. > > From my reading of the API it exposes various methods to access the > response body. It is quite easy to wrap one of these in a content specific > parser. For example, for xml you could do > > XMLInputFactory xif = ...; > > xif.createStreamReader(client.**getResponse(request).** > getBodyAsInputStream()); > > OR > SAXParserFactory spf = ...; > > spf.newSAXParser().parse(**client.getResponse(request).**getBodyAsInputStream(), > handler); > > I think this gives the best flexibility without favoring one content type > parser, or one programming model, over another. > > Does this make sense? Have I missed the point of your proposal? Maybe > others have a different view... > > -Chris. > > >> >> >> On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon >> > <mailto:michael.x.mcmahon@**oracle.com>> >> wrote: >> >> Hi, >> >> A new revision of the Http client API planned for jdk 8 can be viewed >> at the following link >> >> >> http://cr.openjdk.java.net/~__**michaelm/httpclient/v0.3/<http://cr.openjdk.java.net/~__michaelm/httpclient/v0.3/> >> >> >> <http://cr.openjdk.java.net/~**michaelm/httpclient/v0.3/<http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/> >> > >> >> We would like to review the api on this mailing list. >> So, all comments are welcome. >> >> Thanks >> Michael McMahon. >> >> >> >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou
