From chris.hegarty at oracle.com Wed May 1 02:05:22 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 01 May 2013 09:05:22 +0000 Subject: hg: jdk8/tl/jdk: 6594296: NetworkInterface.getHardwareAddress returns zero length byte array Message-ID: <20130501090606.88DF148727@hg.openjdk.java.net> Changeset: dddd17cf61ff Author: chegar Date: 2013-05-01 10:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dddd17cf61ff 6594296: NetworkInterface.getHardwareAddress returns zero length byte array Reviewed-by: alanb ! src/windows/native/java/net/NetworkInterface_winXP.c ! test/java/net/NetworkInterface/Test.java From dmitry.samersoff at oracle.com Wed May 1 03:09:38 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 01 May 2013 14:09:38 +0400 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <517F9D34.3000705@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> Message-ID: <5180E9E2.5030900@oracle.com> Michael, > "GET,POST:Header1,Header2" Colon is a delimiter between http header and it's value. With this syntax we might have problems in a future if sometimes we will support different headers for different methods or add an ability to check header value as well. -Dmitry On 2013-04-30 14:30, Michael McMahon wrote: > Hi Kurchi, > > I can include such an example easily. Eg: > > "GET,POST:Header1,Header2" > > means one permission that permits either GET or POST with either or both > of the two headers. If you wanted to restrict one set of headers to GET > and another set to POST, then that would require two different > permissions. > > - Michael > > On 30/04/13 00:40, Kurchi Hazra wrote: >> Hi Michael, >> >> From the documentation, it is not clear to me how to represent >> both request-headers and method list together in an actions string for >> two or more methods. (Say I have two methods GET and POST and I want >> to specify a request-headers list for each, how do I do it?) Maybe >> another example will help. >> >> Thanks, >> Kurchi >> >> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>> On 28/04/13 09:01, Chris Hegarty wrote: >>>> In the main I link the new HttpURLPermission class. >>>> >>>> When reading the docs I found the references to "the URL" and "URL >>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>> cases you mean the URL string given when constructing the >>>> HttpURLPermission, right? >>>> >>> >>> Yes, that is what is meant. The class does not use j.n.URL at all, as >>> that would bring us back >>> to the old (undesirable) behavior with DNS lookups required for basic >>> operations like equals() and hashCode() >>> >>>> Another example is the equals method >>>> "Returns true if, this.getActions().equals(p.getActions()) and p's >>>> URL equals this's URL. Returns false otherwise." >>>> >>>> this is referring so a simple string comparison of the given URL >>>> string, right? This should be case insensitive too. Does it take >>>> into account default protocol ports, e.g. http://foo.com/ equal >>>> http://foo.com:80/ >>>> >>> >>> The implementation uses a java.net.URI internally. So URI takes care >>> of that. >>> >>>> implies() makes reference to the URL scheme, and other specific >>>> parts of the URL. Also, the constructors throw IAE 'if url is not a >>>> valid URL', but what does this mean. Should we just bite the bullet >>>> and just say that URI is used to parse the given string into its >>>> specific parts? Otherwise, how can this be validated. >>>> >>> >>> I originally didn't want to mention URI in the apidoc due to >>> potential confusion surrounding the use of URL in the permission >>> class name. But, maybe it would be clearer to be explicit about it, >>> particularly for the equals() behavior. >>> Otherwise we have to specify all of it in this class. >>> >>>> As for the additions to HttpURLConnection, what are the implications >>>> on proxies? Permissions, etc... >>>> >>> >>> There's no change in behavior with respect to proxies. Permission is >>> given to connect to proxies implicitly >>> except in cases where the caller specifies the proxy through the >>> URL.openConnection(Proxy) api. >>> There are other unusual cases like the Http "Use Proxy" response. >>> Explicit permission is required >>> for that case also. >>> >>> Thanks! >>> >>> Michael >>> >>>> -Chris. >>>> >>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>> Hi, >>>>> >>>>> The is the suggested API for one of the two new JEPs recently >>>>> submitted. >>>>> >>>>> This is for JEP 184: HTTP URL Permissions >>>>> >>>>> The idea here is to define a higher level http permission class >>>>> which "knows about" URLs, HTTP request methods and headers. >>>>> So, it is no longer necessary to grant blanket permission for any kind >>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>> restricts >>>>> access to only the Http protocol itself. Restrictions can also be >>>>> imposed >>>>> based on URL paths, specific request methods and request headers. >>>>> >>>>> The API change can be seen at the URL below: >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>> >>>>> In addition to defining a new permission class, HttpURLConnection >>>>> is modified to make use of it and the documentation change >>>>> describing this >>>>> can be seen at the link below: >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>> >>>>> All comments welcome. >>>>> >>>>> Thanks >>>>> >>>>> Michael. >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From chris.hegarty at oracle.com Wed May 1 03:16:55 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 01 May 2013 10:16:55 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130501101742.C20AA4872A@hg.openjdk.java.net> Changeset: 73793f2af80a Author: msheppar Date: 2013-04-30 16:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73793f2af80a 8007799: Base64.getEncoder(0, byte[]) returns an encoder that unexpectedly inserts line separators Reviewed-by: sherman, iris ! src/share/classes/java/util/Base64.java + test/java/util/Base64/Base64GetEncoderTest.java Changeset: 5941f7c9c76a Author: chegar Date: 2013-05-01 11:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5941f7c9c76a 8013723: ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt From michael.x.mcmahon at oracle.com Wed May 1 04:04:08 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 May 2013 12:04:08 +0100 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <5180E9E2.5030900@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> <5180E9E2.5030900@oracle.com> Message-ID: <5180F6A8.2080201@oracle.com> On 01/05/13 11:09, Dmitry Samersoff wrote: > Michael, > >> "GET,POST:Header1,Header2" > Colon is a delimiter between http header and it's value. > > With this syntax we might have problems in a future if sometimes we will > support different headers for different methods or add an ability to > check header value as well. > > -Dmitry Dmitry, It would complicate the syntax a lot if you wanted to support different headers for different methods. Would be a lot simpler to just grant separate permissions for the two cases. Eg. grant { permission java.net.HttpURLPermission "http://www.foo.com/-", "GET:Header1,Header2"; permission java.net.HttpURLPermission "http://www.foo.com/-", "POST:Header3,Header4"; }; Michael > On 2013-04-30 14:30, Michael McMahon wrote: >> Hi Kurchi, >> >> I can include such an example easily. Eg: >> >> "GET,POST:Header1,Header2" >> >> means one permission that permits either GET or POST with either or both >> of the two headers. If you wanted to restrict one set of headers to GET >> and another set to POST, then that would require two different >> permissions. >> >> - Michael >> >> On 30/04/13 00:40, Kurchi Hazra wrote: >>> Hi Michael, >>> >>> From the documentation, it is not clear to me how to represent >>> both request-headers and method list together in an actions string for >>> two or more methods. (Say I have two methods GET and POST and I want >>> to specify a request-headers list for each, how do I do it?) Maybe >>> another example will help. >>> >>> Thanks, >>> Kurchi >>> >>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>> In the main I link the new HttpURLPermission class. >>>>> >>>>> When reading the docs I found the references to "the URL" and "URL >>>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>> cases you mean the URL string given when constructing the >>>>> HttpURLPermission, right? >>>>> >>>> Yes, that is what is meant. The class does not use j.n.URL at all, as >>>> that would bring us back >>>> to the old (undesirable) behavior with DNS lookups required for basic >>>> operations like equals() and hashCode() >>>> >>>>> Another example is the equals method >>>>> "Returns true if, this.getActions().equals(p.getActions()) and p's >>>>> URL equals this's URL. Returns false otherwise." >>>>> >>>>> this is referring so a simple string comparison of the given URL >>>>> string, right? This should be case insensitive too. Does it take >>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>> http://foo.com:80/ >>>>> >>>> The implementation uses a java.net.URI internally. So URI takes care >>>> of that. >>>> >>>>> implies() makes reference to the URL scheme, and other specific >>>>> parts of the URL. Also, the constructors throw IAE 'if url is not a >>>>> valid URL', but what does this mean. Should we just bite the bullet >>>>> and just say that URI is used to parse the given string into its >>>>> specific parts? Otherwise, how can this be validated. >>>>> >>>> I originally didn't want to mention URI in the apidoc due to >>>> potential confusion surrounding the use of URL in the permission >>>> class name. But, maybe it would be clearer to be explicit about it, >>>> particularly for the equals() behavior. >>>> Otherwise we have to specify all of it in this class. >>>> >>>>> As for the additions to HttpURLConnection, what are the implications >>>>> on proxies? Permissions, etc... >>>>> >>>> There's no change in behavior with respect to proxies. Permission is >>>> given to connect to proxies implicitly >>>> except in cases where the caller specifies the proxy through the >>>> URL.openConnection(Proxy) api. >>>> There are other unusual cases like the Http "Use Proxy" response. >>>> Explicit permission is required >>>> for that case also. >>>> >>>> Thanks! >>>> >>>> Michael >>>> >>>>> -Chris. >>>>> >>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>> Hi, >>>>>> >>>>>> The is the suggested API for one of the two new JEPs recently >>>>>> submitted. >>>>>> >>>>>> This is for JEP 184: HTTP URL Permissions >>>>>> >>>>>> The idea here is to define a higher level http permission class >>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>> So, it is no longer necessary to grant blanket permission for any kind >>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>> restricts >>>>>> access to only the Http protocol itself. Restrictions can also be >>>>>> imposed >>>>>> based on URL paths, specific request methods and request headers. >>>>>> >>>>>> The API change can be seen at the URL below: >>>>>> >>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>> >>>>>> In addition to defining a new permission class, HttpURLConnection >>>>>> is modified to make use of it and the documentation change >>>>>> describing this >>>>>> can be seen at the link below: >>>>>> >>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>> >>>>>> All comments welcome. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Michael. > From dmitry.samersoff at oracle.com Wed May 1 04:11:11 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 01 May 2013 15:11:11 +0400 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <5180F6A8.2080201@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> <5180E9E2.5030900@oracle.com> <5180F6A8.2080201@oracle.com> Message-ID: <5180F84F.5000200@oracle.com> Michael, I'm just asking about replacing : (colon) to another character to be able to write something like: permission java.net.HttpURLPermission "http://www.foo.com/-", "GET Location: http://www.foo.com/*, Content-type: image/jpeg"; in a future -Dmitry. On 2013-05-01 15:04, Michael McMahon wrote: > On 01/05/13 11:09, Dmitry Samersoff wrote: >> Michael, >> >>> "GET,POST:Header1,Header2" >> Colon is a delimiter between http header and it's value. >> >> With this syntax we might have problems in a future if sometimes we will >> support different headers for different methods or add an ability to >> check header value as well. >> >> -Dmitry > > Dmitry, > > It would complicate the syntax a lot if you wanted to support > different headers for different methods. Would be a lot simpler > to just grant separate permissions for the two cases. Eg. > > grant { > permission java.net.HttpURLPermission "http://www.foo.com/-", > "GET:Header1,Header2"; > permission java.net.HttpURLPermission "http://www.foo.com/-", > "POST:Header3,Header4"; > }; > > Michael > >> On 2013-04-30 14:30, Michael McMahon wrote: >>> Hi Kurchi, >>> >>> I can include such an example easily. Eg: >>> >>> "GET,POST:Header1,Header2" >>> >>> means one permission that permits either GET or POST with either or both >>> of the two headers. If you wanted to restrict one set of headers to GET >>> and another set to POST, then that would require two different >>> permissions. >>> >>> - Michael >>> >>> On 30/04/13 00:40, Kurchi Hazra wrote: >>>> Hi Michael, >>>> >>>> From the documentation, it is not clear to me how to represent >>>> both request-headers and method list together in an actions string for >>>> two or more methods. (Say I have two methods GET and POST and I want >>>> to specify a request-headers list for each, how do I do it?) Maybe >>>> another example will help. >>>> >>>> Thanks, >>>> Kurchi >>>> >>>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>>> In the main I link the new HttpURLPermission class. >>>>>> >>>>>> When reading the docs I found the references to "the URL" and "URL >>>>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>>> cases you mean the URL string given when constructing the >>>>>> HttpURLPermission, right? >>>>>> >>>>> Yes, that is what is meant. The class does not use j.n.URL at all, as >>>>> that would bring us back >>>>> to the old (undesirable) behavior with DNS lookups required for basic >>>>> operations like equals() and hashCode() >>>>> >>>>>> Another example is the equals method >>>>>> "Returns true if, this.getActions().equals(p.getActions()) and p's >>>>>> URL equals this's URL. Returns false otherwise." >>>>>> >>>>>> this is referring so a simple string comparison of the given URL >>>>>> string, right? This should be case insensitive too. Does it take >>>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>>> http://foo.com:80/ >>>>>> >>>>> The implementation uses a java.net.URI internally. So URI takes care >>>>> of that. >>>>> >>>>>> implies() makes reference to the URL scheme, and other specific >>>>>> parts of the URL. Also, the constructors throw IAE 'if url is not a >>>>>> valid URL', but what does this mean. Should we just bite the bullet >>>>>> and just say that URI is used to parse the given string into its >>>>>> specific parts? Otherwise, how can this be validated. >>>>>> >>>>> I originally didn't want to mention URI in the apidoc due to >>>>> potential confusion surrounding the use of URL in the permission >>>>> class name. But, maybe it would be clearer to be explicit about it, >>>>> particularly for the equals() behavior. >>>>> Otherwise we have to specify all of it in this class. >>>>> >>>>>> As for the additions to HttpURLConnection, what are the implications >>>>>> on proxies? Permissions, etc... >>>>>> >>>>> There's no change in behavior with respect to proxies. Permission is >>>>> given to connect to proxies implicitly >>>>> except in cases where the caller specifies the proxy through the >>>>> URL.openConnection(Proxy) api. >>>>> There are other unusual cases like the Http "Use Proxy" response. >>>>> Explicit permission is required >>>>> for that case also. >>>>> >>>>> Thanks! >>>>> >>>>> Michael >>>>> >>>>>> -Chris. >>>>>> >>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The is the suggested API for one of the two new JEPs recently >>>>>>> submitted. >>>>>>> >>>>>>> This is for JEP 184: HTTP URL Permissions >>>>>>> >>>>>>> The idea here is to define a higher level http permission class >>>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>>> So, it is no longer necessary to grant blanket permission for any >>>>>>> kind >>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>>> restricts >>>>>>> access to only the Http protocol itself. Restrictions can also be >>>>>>> imposed >>>>>>> based on URL paths, specific request methods and request headers. >>>>>>> >>>>>>> The API change can be seen at the URL below: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>>> >>>>>>> In addition to defining a new permission class, HttpURLConnection >>>>>>> is modified to make use of it and the documentation change >>>>>>> describing this >>>>>>> can be seen at the link below: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>>> >>>>>>> All comments welcome. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Michael. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From michael.x.mcmahon at oracle.com Wed May 1 04:16:31 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 May 2013 12:16:31 +0100 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <5180F84F.5000200@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> <5180E9E2.5030900@oracle.com> <5180F6A8.2080201@oracle.com> <5180F84F.5000200@oracle.com> Message-ID: <5180F98F.8030300@oracle.com> Ah right. The permission only contains header names. It never contains header values. And header names are "tokens" in the Http spec that cannot contain a colon character. Michael On 01/05/13 12:11, Dmitry Samersoff wrote: > Michael, > > I'm just asking about replacing : (colon) to another character to be > able to write something like: > > permission > java.net.HttpURLPermission "http://www.foo.com/-", > "GET Location: http://www.foo.com/*, Content-type: image/jpeg"; > > in a future > > -Dmitry. > > On 2013-05-01 15:04, Michael McMahon wrote: >> On 01/05/13 11:09, Dmitry Samersoff wrote: >>> Michael, >>> >>>> "GET,POST:Header1,Header2" >>> Colon is a delimiter between http header and it's value. >>> >>> With this syntax we might have problems in a future if sometimes we will >>> support different headers for different methods or add an ability to >>> check header value as well. >>> >>> -Dmitry >> Dmitry, >> >> It would complicate the syntax a lot if you wanted to support >> different headers for different methods. Would be a lot simpler >> to just grant separate permissions for the two cases. Eg. >> >> grant { >> permission java.net.HttpURLPermission "http://www.foo.com/-", >> "GET:Header1,Header2"; >> permission java.net.HttpURLPermission "http://www.foo.com/-", >> "POST:Header3,Header4"; >> }; >> >> Michael >> >>> On 2013-04-30 14:30, Michael McMahon wrote: >>>> Hi Kurchi, >>>> >>>> I can include such an example easily. Eg: >>>> >>>> "GET,POST:Header1,Header2" >>>> >>>> means one permission that permits either GET or POST with either or both >>>> of the two headers. If you wanted to restrict one set of headers to GET >>>> and another set to POST, then that would require two different >>>> permissions. >>>> >>>> - Michael >>>> >>>> On 30/04/13 00:40, Kurchi Hazra wrote: >>>>> Hi Michael, >>>>> >>>>> From the documentation, it is not clear to me how to represent >>>>> both request-headers and method list together in an actions string for >>>>> two or more methods. (Say I have two methods GET and POST and I want >>>>> to specify a request-headers list for each, how do I do it?) Maybe >>>>> another example will help. >>>>> >>>>> Thanks, >>>>> Kurchi >>>>> >>>>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>>>> In the main I link the new HttpURLPermission class. >>>>>>> >>>>>>> When reading the docs I found the references to "the URL" and "URL >>>>>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>>>> cases you mean the URL string given when constructing the >>>>>>> HttpURLPermission, right? >>>>>>> >>>>>> Yes, that is what is meant. The class does not use j.n.URL at all, as >>>>>> that would bring us back >>>>>> to the old (undesirable) behavior with DNS lookups required for basic >>>>>> operations like equals() and hashCode() >>>>>> >>>>>>> Another example is the equals method >>>>>>> "Returns true if, this.getActions().equals(p.getActions()) and p's >>>>>>> URL equals this's URL. Returns false otherwise." >>>>>>> >>>>>>> this is referring so a simple string comparison of the given URL >>>>>>> string, right? This should be case insensitive too. Does it take >>>>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>>>> http://foo.com:80/ >>>>>>> >>>>>> The implementation uses a java.net.URI internally. So URI takes care >>>>>> of that. >>>>>> >>>>>>> implies() makes reference to the URL scheme, and other specific >>>>>>> parts of the URL. Also, the constructors throw IAE 'if url is not a >>>>>>> valid URL', but what does this mean. Should we just bite the bullet >>>>>>> and just say that URI is used to parse the given string into its >>>>>>> specific parts? Otherwise, how can this be validated. >>>>>>> >>>>>> I originally didn't want to mention URI in the apidoc due to >>>>>> potential confusion surrounding the use of URL in the permission >>>>>> class name. But, maybe it would be clearer to be explicit about it, >>>>>> particularly for the equals() behavior. >>>>>> Otherwise we have to specify all of it in this class. >>>>>> >>>>>>> As for the additions to HttpURLConnection, what are the implications >>>>>>> on proxies? Permissions, etc... >>>>>>> >>>>>> There's no change in behavior with respect to proxies. Permission is >>>>>> given to connect to proxies implicitly >>>>>> except in cases where the caller specifies the proxy through the >>>>>> URL.openConnection(Proxy) api. >>>>>> There are other unusual cases like the Http "Use Proxy" response. >>>>>> Explicit permission is required >>>>>> for that case also. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Michael >>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The is the suggested API for one of the two new JEPs recently >>>>>>>> submitted. >>>>>>>> >>>>>>>> This is for JEP 184: HTTP URL Permissions >>>>>>>> >>>>>>>> The idea here is to define a higher level http permission class >>>>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>>>> So, it is no longer necessary to grant blanket permission for any >>>>>>>> kind >>>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>>>> restricts >>>>>>>> access to only the Http protocol itself. Restrictions can also be >>>>>>>> imposed >>>>>>>> based on URL paths, specific request methods and request headers. >>>>>>>> >>>>>>>> The API change can be seen at the URL below: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>>>> >>>>>>>> In addition to defining a new permission class, HttpURLConnection >>>>>>>> is modified to make use of it and the documentation change >>>>>>>> describing this >>>>>>>> can be seen at the link below: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>>>> >>>>>>>> All comments welcome. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Michael. > From dmitry.samersoff at oracle.com Wed May 1 04:38:03 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 01 May 2013 15:38:03 +0400 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <5180F98F.8030300@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> <5180E9E2.5030900@oracle.com> <5180F6A8.2080201@oracle.com> <5180F84F.5000200@oracle.com> <5180F98F.8030300@oracle.com> Message-ID: <5180FE9B.4010104@oracle.com> Michael, Sorry for not being clean enough. On my opinion an ability to check header value as well as a header name is quite useful future for the real world. e.g. to being able to prevent redirection to other domain or limit certain content type etc. I understand, that these changes is out of scope of today work, but it quite possible that we implement it sometimes in a future. For (header-name: header-value) pair : (colon) is a native delimiter, so it's better not to use it to separate methods list and headers list. On my opinion, (space) is enough for this case and better reflect HTTP header i.e. "GET,POST Header1,Header2" -Dmitry On 2013-05-01 15:16, Michael McMahon wrote: > Ah right. The permission only contains header names. > It never contains header values. And header names are "tokens" > in the Http spec that cannot contain a colon character. > > Michael > > On 01/05/13 12:11, Dmitry Samersoff wrote: >> Michael, >> >> I'm just asking about replacing : (colon) to another character to be >> able to write something like: >> >> permission >> java.net.HttpURLPermission "http://www.foo.com/-", >> "GET Location: http://www.foo.com/*, Content-type: image/jpeg"; >> >> in a future >> >> -Dmitry. >> >> On 2013-05-01 15:04, Michael McMahon wrote: >>> On 01/05/13 11:09, Dmitry Samersoff wrote: >>>> Michael, >>>> >>>>> "GET,POST:Header1,Header2" >>>> Colon is a delimiter between http header and it's value. >>>> >>>> With this syntax we might have problems in a future if sometimes we >>>> will >>>> support different headers for different methods or add an ability to >>>> check header value as well. >>>> >>>> -Dmitry >>> Dmitry, >>> >>> It would complicate the syntax a lot if you wanted to support >>> different headers for different methods. Would be a lot simpler >>> to just grant separate permissions for the two cases. Eg. >>> >>> grant { >>> permission java.net.HttpURLPermission "http://www.foo.com/-", >>> "GET:Header1,Header2"; >>> permission java.net.HttpURLPermission "http://www.foo.com/-", >>> "POST:Header3,Header4"; >>> }; >>> >>> Michael >>> >>>> On 2013-04-30 14:30, Michael McMahon wrote: >>>>> Hi Kurchi, >>>>> >>>>> I can include such an example easily. Eg: >>>>> >>>>> "GET,POST:Header1,Header2" >>>>> >>>>> means one permission that permits either GET or POST with either or >>>>> both >>>>> of the two headers. If you wanted to restrict one set of headers to >>>>> GET >>>>> and another set to POST, then that would require two different >>>>> permissions. >>>>> >>>>> - Michael >>>>> >>>>> On 30/04/13 00:40, Kurchi Hazra wrote: >>>>>> Hi Michael, >>>>>> >>>>>> From the documentation, it is not clear to me how to represent >>>>>> both request-headers and method list together in an actions string >>>>>> for >>>>>> two or more methods. (Say I have two methods GET and POST and I want >>>>>> to specify a request-headers list for each, how do I do it?) Maybe >>>>>> another example will help. >>>>>> >>>>>> Thanks, >>>>>> Kurchi >>>>>> >>>>>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>>>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>>>>> In the main I link the new HttpURLPermission class. >>>>>>>> >>>>>>>> When reading the docs I found the references to "the URL" and "URL >>>>>>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>>>>> cases you mean the URL string given when constructing the >>>>>>>> HttpURLPermission, right? >>>>>>>> >>>>>>> Yes, that is what is meant. The class does not use j.n.URL at >>>>>>> all, as >>>>>>> that would bring us back >>>>>>> to the old (undesirable) behavior with DNS lookups required for >>>>>>> basic >>>>>>> operations like equals() and hashCode() >>>>>>> >>>>>>>> Another example is the equals method >>>>>>>> "Returns true if, this.getActions().equals(p.getActions()) >>>>>>>> and p's >>>>>>>> URL equals this's URL. Returns false otherwise." >>>>>>>> >>>>>>>> this is referring so a simple string comparison of the given URL >>>>>>>> string, right? This should be case insensitive too. Does it take >>>>>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>>>>> http://foo.com:80/ >>>>>>>> >>>>>>> The implementation uses a java.net.URI internally. So URI takes care >>>>>>> of that. >>>>>>> >>>>>>>> implies() makes reference to the URL scheme, and other specific >>>>>>>> parts of the URL. Also, the constructors throw IAE 'if url is >>>>>>>> not a >>>>>>>> valid URL', but what does this mean. Should we just bite the bullet >>>>>>>> and just say that URI is used to parse the given string into its >>>>>>>> specific parts? Otherwise, how can this be validated. >>>>>>>> >>>>>>> I originally didn't want to mention URI in the apidoc due to >>>>>>> potential confusion surrounding the use of URL in the permission >>>>>>> class name. But, maybe it would be clearer to be explicit about it, >>>>>>> particularly for the equals() behavior. >>>>>>> Otherwise we have to specify all of it in this class. >>>>>>> >>>>>>>> As for the additions to HttpURLConnection, what are the >>>>>>>> implications >>>>>>>> on proxies? Permissions, etc... >>>>>>>> >>>>>>> There's no change in behavior with respect to proxies. Permission is >>>>>>> given to connect to proxies implicitly >>>>>>> except in cases where the caller specifies the proxy through the >>>>>>> URL.openConnection(Proxy) api. >>>>>>> There are other unusual cases like the Http "Use Proxy" response. >>>>>>> Explicit permission is required >>>>>>> for that case also. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The is the suggested API for one of the two new JEPs recently >>>>>>>>> submitted. >>>>>>>>> >>>>>>>>> This is for JEP 184: HTTP URL Permissions >>>>>>>>> >>>>>>>>> The idea here is to define a higher level http permission class >>>>>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>>>>> So, it is no longer necessary to grant blanket permission for any >>>>>>>>> kind >>>>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>>>>> restricts >>>>>>>>> access to only the Http protocol itself. Restrictions can also be >>>>>>>>> imposed >>>>>>>>> based on URL paths, specific request methods and request headers. >>>>>>>>> >>>>>>>>> The API change can be seen at the URL below: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>>>>> >>>>>>>>> In addition to defining a new permission class, HttpURLConnection >>>>>>>>> is modified to make use of it and the documentation change >>>>>>>>> describing this >>>>>>>>> can be seen at the link below: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>>>>> >>>>>>>>> All comments welcome. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Michael. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From michael.x.mcmahon at oracle.com Wed May 1 05:40:54 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 May 2013 13:40:54 +0100 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <5180FE9B.4010104@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> <5180E9E2.5030900@oracle.com> <5180F6A8.2080201@oracle.com> <5180F84F.5000200@oracle.com> <5180F98F.8030300@oracle.com> <5180FE9B.4010104@oracle.com> Message-ID: <51810D56.7090000@oracle.com> Another possibility if we were to do that in the future, could be: "GET,POST:Header1=value 1,Header2=value 2" - Michael On 01/05/13 12:38, Dmitry Samersoff wrote: > Michael, > > Sorry for not being clean enough. > > On my opinion an ability to check header value as well as a header name > is quite useful future for the real world. > > e.g. to being able to prevent redirection to other domain or limit > certain content type etc. > > I understand, that these changes is out of scope of today work, but it > quite possible that we implement it sometimes in a future. > > For (header-name: header-value) pair : (colon) is a native delimiter, > so it's better not to use it to separate methods list and headers list. > > On my opinion, (space) is enough for this case and better reflect HTTP > header i.e. > > "GET,POST Header1,Header2" > > -Dmitry > > > > On 2013-05-01 15:16, Michael McMahon wrote: >> Ah right. The permission only contains header names. >> It never contains header values. And header names are "tokens" >> in the Http spec that cannot contain a colon character. >> >> Michael >> >> On 01/05/13 12:11, Dmitry Samersoff wrote: >>> Michael, >>> >>> I'm just asking about replacing : (colon) to another character to be >>> able to write something like: >>> >>> permission >>> java.net.HttpURLPermission "http://www.foo.com/-", >>> "GET Location: http://www.foo.com/*, Content-type: image/jpeg"; >>> >>> in a future >>> >>> -Dmitry. >>> >>> On 2013-05-01 15:04, Michael McMahon wrote: >>>> On 01/05/13 11:09, Dmitry Samersoff wrote: >>>>> Michael, >>>>> >>>>>> "GET,POST:Header1,Header2" >>>>> Colon is a delimiter between http header and it's value. >>>>> >>>>> With this syntax we might have problems in a future if sometimes we >>>>> will >>>>> support different headers for different methods or add an ability to >>>>> check header value as well. >>>>> >>>>> -Dmitry >>>> Dmitry, >>>> >>>> It would complicate the syntax a lot if you wanted to support >>>> different headers for different methods. Would be a lot simpler >>>> to just grant separate permissions for the two cases. Eg. >>>> >>>> grant { >>>> permission java.net.HttpURLPermission "http://www.foo.com/-", >>>> "GET:Header1,Header2"; >>>> permission java.net.HttpURLPermission "http://www.foo.com/-", >>>> "POST:Header3,Header4"; >>>> }; >>>> >>>> Michael >>>> >>>>> On 2013-04-30 14:30, Michael McMahon wrote: >>>>>> Hi Kurchi, >>>>>> >>>>>> I can include such an example easily. Eg: >>>>>> >>>>>> "GET,POST:Header1,Header2" >>>>>> >>>>>> means one permission that permits either GET or POST with either or >>>>>> both >>>>>> of the two headers. If you wanted to restrict one set of headers to >>>>>> GET >>>>>> and another set to POST, then that would require two different >>>>>> permissions. >>>>>> >>>>>> - Michael >>>>>> >>>>>> On 30/04/13 00:40, Kurchi Hazra wrote: >>>>>>> Hi Michael, >>>>>>> >>>>>>> From the documentation, it is not clear to me how to represent >>>>>>> both request-headers and method list together in an actions string >>>>>>> for >>>>>>> two or more methods. (Say I have two methods GET and POST and I want >>>>>>> to specify a request-headers list for each, how do I do it?) Maybe >>>>>>> another example will help. >>>>>>> >>>>>>> Thanks, >>>>>>> Kurchi >>>>>>> >>>>>>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>>>>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>>>>>> In the main I link the new HttpURLPermission class. >>>>>>>>> >>>>>>>>> When reading the docs I found the references to "the URL" and "URL >>>>>>>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>>>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>>>>>> cases you mean the URL string given when constructing the >>>>>>>>> HttpURLPermission, right? >>>>>>>>> >>>>>>>> Yes, that is what is meant. The class does not use j.n.URL at >>>>>>>> all, as >>>>>>>> that would bring us back >>>>>>>> to the old (undesirable) behavior with DNS lookups required for >>>>>>>> basic >>>>>>>> operations like equals() and hashCode() >>>>>>>> >>>>>>>>> Another example is the equals method >>>>>>>>> "Returns true if, this.getActions().equals(p.getActions()) >>>>>>>>> and p's >>>>>>>>> URL equals this's URL. Returns false otherwise." >>>>>>>>> >>>>>>>>> this is referring so a simple string comparison of the given URL >>>>>>>>> string, right? This should be case insensitive too. Does it take >>>>>>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>>>>>> http://foo.com:80/ >>>>>>>>> >>>>>>>> The implementation uses a java.net.URI internally. So URI takes care >>>>>>>> of that. >>>>>>>> >>>>>>>>> implies() makes reference to the URL scheme, and other specific >>>>>>>>> parts of the URL. Also, the constructors throw IAE 'if url is >>>>>>>>> not a >>>>>>>>> valid URL', but what does this mean. Should we just bite the bullet >>>>>>>>> and just say that URI is used to parse the given string into its >>>>>>>>> specific parts? Otherwise, how can this be validated. >>>>>>>>> >>>>>>>> I originally didn't want to mention URI in the apidoc due to >>>>>>>> potential confusion surrounding the use of URL in the permission >>>>>>>> class name. But, maybe it would be clearer to be explicit about it, >>>>>>>> particularly for the equals() behavior. >>>>>>>> Otherwise we have to specify all of it in this class. >>>>>>>> >>>>>>>>> As for the additions to HttpURLConnection, what are the >>>>>>>>> implications >>>>>>>>> on proxies? Permissions, etc... >>>>>>>>> >>>>>>>> There's no change in behavior with respect to proxies. Permission is >>>>>>>> given to connect to proxies implicitly >>>>>>>> except in cases where the caller specifies the proxy through the >>>>>>>> URL.openConnection(Proxy) api. >>>>>>>> There are other unusual cases like the Http "Use Proxy" response. >>>>>>>> Explicit permission is required >>>>>>>> for that case also. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The is the suggested API for one of the two new JEPs recently >>>>>>>>>> submitted. >>>>>>>>>> >>>>>>>>>> This is for JEP 184: HTTP URL Permissions >>>>>>>>>> >>>>>>>>>> The idea here is to define a higher level http permission class >>>>>>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>>>>>> So, it is no longer necessary to grant blanket permission for any >>>>>>>>>> kind >>>>>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>>>>>> restricts >>>>>>>>>> access to only the Http protocol itself. Restrictions can also be >>>>>>>>>> imposed >>>>>>>>>> based on URL paths, specific request methods and request headers. >>>>>>>>>> >>>>>>>>>> The API change can be seen at the URL below: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>>>>>> >>>>>>>>>> In addition to defining a new permission class, HttpURLConnection >>>>>>>>>> is modified to make use of it and the documentation change >>>>>>>>>> describing this >>>>>>>>>> can be seen at the link below: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>>>>>> >>>>>>>>>> All comments welcome. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Michael. > From dmitry.samersoff at oracle.com Wed May 1 06:21:48 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 01 May 2013 17:21:48 +0400 Subject: API change for 8010464: Evolve java networking same origin policy In-Reply-To: <51810D56.7090000@oracle.com> References: <517A90F9.1040503@oracle.com> <517CD741.9090109@oracle.com> <517E5147.7030800@oracle.com> <517F04D6.8090706@oracle.com> <517F9D34.3000705@oracle.com> <5180E9E2.5030900@oracle.com> <5180F6A8.2080201@oracle.com> <5180F84F.5000200@oracle.com> <5180F98F.8030300@oracle.com> <5180FE9B.4010104@oracle.com> <51810D56.7090000@oracle.com> Message-ID: <518116EC.4090000@oracle.com> Michael, On 2013-05-01 16:40, Michael McMahon wrote: > Another possibility if we were to do that in the future, could be: > > "GET,POST:Header1=value 1,Header2=value 2" Variant with space looks more natural for me as it follows HTTP header syntax. But it's up to you to make a decision. -Dmitry > > - Michael > > On 01/05/13 12:38, Dmitry Samersoff wrote: >> Michael, >> >> Sorry for not being clean enough. >> >> On my opinion an ability to check header value as well as a header name >> is quite useful future for the real world. >> >> e.g. to being able to prevent redirection to other domain or limit >> certain content type etc. >> >> I understand, that these changes is out of scope of today work, but it >> quite possible that we implement it sometimes in a future. >> >> For (header-name: header-value) pair : (colon) is a native delimiter, >> so it's better not to use it to separate methods list and headers list. >> >> On my opinion, (space) is enough for this case and better reflect HTTP >> header i.e. >> >> "GET,POST Header1,Header2" >> >> -Dmitry >> >> >> >> On 2013-05-01 15:16, Michael McMahon wrote: >>> Ah right. The permission only contains header names. >>> It never contains header values. And header names are "tokens" >>> in the Http spec that cannot contain a colon character. >>> >>> Michael >>> >>> On 01/05/13 12:11, Dmitry Samersoff wrote: >>>> Michael, >>>> >>>> I'm just asking about replacing : (colon) to another character to be >>>> able to write something like: >>>> >>>> permission >>>> java.net.HttpURLPermission "http://www.foo.com/-", >>>> "GET Location: http://www.foo.com/*, Content-type: image/jpeg"; >>>> >>>> in a future >>>> >>>> -Dmitry. >>>> >>>> On 2013-05-01 15:04, Michael McMahon wrote: >>>>> On 01/05/13 11:09, Dmitry Samersoff wrote: >>>>>> Michael, >>>>>> >>>>>>> "GET,POST:Header1,Header2" >>>>>> Colon is a delimiter between http header and it's value. >>>>>> >>>>>> With this syntax we might have problems in a future if sometimes we >>>>>> will >>>>>> support different headers for different methods or add an ability to >>>>>> check header value as well. >>>>>> >>>>>> -Dmitry >>>>> Dmitry, >>>>> >>>>> It would complicate the syntax a lot if you wanted to support >>>>> different headers for different methods. Would be a lot simpler >>>>> to just grant separate permissions for the two cases. Eg. >>>>> >>>>> grant { >>>>> permission java.net.HttpURLPermission "http://www.foo.com/-", >>>>> "GET:Header1,Header2"; >>>>> permission java.net.HttpURLPermission "http://www.foo.com/-", >>>>> "POST:Header3,Header4"; >>>>> }; >>>>> >>>>> Michael >>>>> >>>>>> On 2013-04-30 14:30, Michael McMahon wrote: >>>>>>> Hi Kurchi, >>>>>>> >>>>>>> I can include such an example easily. Eg: >>>>>>> >>>>>>> "GET,POST:Header1,Header2" >>>>>>> >>>>>>> means one permission that permits either GET or POST with either or >>>>>>> both >>>>>>> of the two headers. If you wanted to restrict one set of headers to >>>>>>> GET >>>>>>> and another set to POST, then that would require two different >>>>>>> permissions. >>>>>>> >>>>>>> - Michael >>>>>>> >>>>>>> On 30/04/13 00:40, Kurchi Hazra wrote: >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> From the documentation, it is not clear to me how to >>>>>>>> represent >>>>>>>> both request-headers and method list together in an actions string >>>>>>>> for >>>>>>>> two or more methods. (Say I have two methods GET and POST and I >>>>>>>> want >>>>>>>> to specify a request-headers list for each, how do I do it?) Maybe >>>>>>>> another example will help. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kurchi >>>>>>>> >>>>>>>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>>>>>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>>>>>>> In the main I link the new HttpURLPermission class. >>>>>>>>>> >>>>>>>>>> When reading the docs I found the references to "the URL" and >>>>>>>>>> "URL >>>>>>>>>> string" confusing ( it could be just me ). When I see capital >>>>>>>>>> 'URL' >>>>>>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>>>>>>> cases you mean the URL string given when constructing the >>>>>>>>>> HttpURLPermission, right? >>>>>>>>>> >>>>>>>>> Yes, that is what is meant. The class does not use j.n.URL at >>>>>>>>> all, as >>>>>>>>> that would bring us back >>>>>>>>> to the old (undesirable) behavior with DNS lookups required for >>>>>>>>> basic >>>>>>>>> operations like equals() and hashCode() >>>>>>>>> >>>>>>>>>> Another example is the equals method >>>>>>>>>> "Returns true if, this.getActions().equals(p.getActions()) >>>>>>>>>> and p's >>>>>>>>>> URL equals this's URL. Returns false otherwise." >>>>>>>>>> >>>>>>>>>> this is referring so a simple string comparison of the given URL >>>>>>>>>> string, right? This should be case insensitive too. Does it take >>>>>>>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>>>>>>> http://foo.com:80/ >>>>>>>>>> >>>>>>>>> The implementation uses a java.net.URI internally. So URI takes >>>>>>>>> care >>>>>>>>> of that. >>>>>>>>> >>>>>>>>>> implies() makes reference to the URL scheme, and other specific >>>>>>>>>> parts of the URL. Also, the constructors throw IAE 'if url is >>>>>>>>>> not a >>>>>>>>>> valid URL', but what does this mean. Should we just bite the >>>>>>>>>> bullet >>>>>>>>>> and just say that URI is used to parse the given string into its >>>>>>>>>> specific parts? Otherwise, how can this be validated. >>>>>>>>>> >>>>>>>>> I originally didn't want to mention URI in the apidoc due to >>>>>>>>> potential confusion surrounding the use of URL in the permission >>>>>>>>> class name. But, maybe it would be clearer to be explicit about >>>>>>>>> it, >>>>>>>>> particularly for the equals() behavior. >>>>>>>>> Otherwise we have to specify all of it in this class. >>>>>>>>> >>>>>>>>>> As for the additions to HttpURLConnection, what are the >>>>>>>>>> implications >>>>>>>>>> on proxies? Permissions, etc... >>>>>>>>>> >>>>>>>>> There's no change in behavior with respect to proxies. >>>>>>>>> Permission is >>>>>>>>> given to connect to proxies implicitly >>>>>>>>> except in cases where the caller specifies the proxy through the >>>>>>>>> URL.openConnection(Proxy) api. >>>>>>>>> There are other unusual cases like the Http "Use Proxy" response. >>>>>>>>> Explicit permission is required >>>>>>>>> for that case also. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Michael >>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> The is the suggested API for one of the two new JEPs recently >>>>>>>>>>> submitted. >>>>>>>>>>> >>>>>>>>>>> This is for JEP 184: HTTP URL Permissions >>>>>>>>>>> >>>>>>>>>>> The idea here is to define a higher level http permission class >>>>>>>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>>>>>>> So, it is no longer necessary to grant blanket permission for >>>>>>>>>>> any >>>>>>>>>>> kind >>>>>>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>>>>>>> restricts >>>>>>>>>>> access to only the Http protocol itself. Restrictions can >>>>>>>>>>> also be >>>>>>>>>>> imposed >>>>>>>>>>> based on URL paths, specific request methods and request >>>>>>>>>>> headers. >>>>>>>>>>> >>>>>>>>>>> The API change can be seen at the URL below: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>>>>>>> >>>>>>>>>>> In addition to defining a new permission class, >>>>>>>>>>> HttpURLConnection >>>>>>>>>>> is modified to make use of it and the documentation change >>>>>>>>>>> describing this >>>>>>>>>>> can be seen at the link below: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>>>>>>> >>>>>>>>>>> All comments welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Michael. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From weijun.wang at oracle.com Wed May 1 06:11:40 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 01 May 2013 13:11:40 +0000 Subject: hg: jdk8/tl/jdk: 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt Message-ID: <20130501131206.472EC4872D@hg.openjdk.java.net> Changeset: ae4a82e69da2 Author: weijun Date: 2013-05-01 21:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae4a82e69da2 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt Reviewed-by: vinnie ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java + test/sun/security/krb5/auto/SaslGSS.java From mike.duigou at oracle.com Wed May 1 08:37:19 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 01 May 2013 15:37:19 +0000 Subject: hg: jdk8/tl/jdk: 8012665: add CharSequence.chars, CharSequence.codePoints Message-ID: <20130501153732.3B74448732@hg.openjdk.java.net> Changeset: c6aef650e615 Author: mduigou Date: 2013-05-01 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6aef650e615 8012665: add CharSequence.chars, CharSequence.codePoints Reviewed-by: martin, alanb, ulfzibis, mduigou Contributed-by: Stuart Marks , Henry Jen ! src/share/classes/java/lang/CharSequence.java + test/java/lang/CharSequence/DefaultTest.java ! test/java/lang/StringBuffer/TestSynchronization.java From kurchi.subhra.hazra at oracle.com Wed May 1 17:03:39 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Wed, 01 May 2013 17:03:39 -0700 Subject: Code Review Request: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name In-Reply-To: <50A5DA31.3040409@oracle.com> References: <50A5DA31.3040409@oracle.com> Message-ID: <5181AD5B.40703@oracle.com> Hi, NetworkInterface.getByInetAddress() was crashing on solaris when the system had a network interface name longer than 15 characters, due to two instances in the native code for NetworkInterface where we were copying a char array of size 32 (LIFNAMSIZ) into a char array of size 16 (IFNAMSIZ), resulting in a buffer overflow with long names. The fix is to make sure that the space allocated for the interface name is consistent (16/32 bytes depending on the system), and to prevent overflows by using strncpy instead of strcpy. Bug: http://bugs.sun.com/view_bug.do?bug_id=8013140 Webrev: http://cr.openjdk.java.net/~khazra/8013140/webrev.00/ Thanks, - Kurchi From chris.hegarty at oracle.com Thu May 2 02:21:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 02 May 2013 10:21:44 +0100 Subject: Code Review Request: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name In-Reply-To: <5181AD5B.40703@oracle.com> References: <50A5DA31.3040409@oracle.com> <5181AD5B.40703@oracle.com> Message-ID: <51823028.4000307@oracle.com> Nice find Kurchi, It is surprising to me that we are building Solaris without LIFNAMSIZ defined, but I accept that we are. Your changes look good to me. -Chris. On 05/02/2013 01:03 AM, Kurchi Subhra Hazra wrote: > > Hi, > > NetworkInterface.getByInetAddress() was crashing on solaris when the > system had a network > interface name longer than 15 characters, due to two instances in the > native > code for NetworkInterface where we were copying a char array of size 32 > (LIFNAMSIZ) > into a char array of size 16 (IFNAMSIZ), resulting in a buffer overflow > with long names. > The fix is to make sure that the space allocated for the interface name > is consistent (16/32 > bytes depending on the system), and to prevent overflows by using > strncpy instead of strcpy. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8013140 > Webrev: http://cr.openjdk.java.net/~khazra/8013140/webrev.00/ > > > Thanks, > - Kurchi > > > From Alan.Bateman at oracle.com Thu May 2 03:50:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 11:50:19 +0100 Subject: Code Review Request: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name In-Reply-To: <5181AD5B.40703@oracle.com> References: <50A5DA31.3040409@oracle.com> <5181AD5B.40703@oracle.com> Message-ID: <518244EB.103@oracle.com> On 02/05/2013 01:03, Kurchi Subhra Hazra wrote: > > Hi, > > NetworkInterface.getByInetAddress() was crashing on solaris when > the system had a network > interface name longer than 15 characters, due to two instances in the > native > code for NetworkInterface where we were copying a char array of size > 32 (LIFNAMSIZ) > into a char array of size 16 (IFNAMSIZ), resulting in a buffer > overflow with long names. > The fix is to make sure that the space allocated for the interface > name is consistent (16/32 > bytes depending on the system), and to prevent overflows by using > strncpy instead of strcpy. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8013140 > Webrev: http://cr.openjdk.java.net/~khazra/8013140/webrev.00/ > > > Thanks, > - Kurchi A good fine, looks okay to me. An alternative would be sizeof(name) but what you have is fine. -Alan From kumar.x.srinivasan at oracle.com Thu May 2 05:49:58 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 02 May 2013 12:49:58 +0000 Subject: hg: jdk8/tl/jdk: 8013225: Refresh jdk's private ASM to the latest. Message-ID: <20130502125032.62CF048777@hg.openjdk.java.net> Changeset: 167d2dcaeeee Author: ksrini Date: 2013-05-01 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/167d2dcaeeee 8013225: Refresh jdk's private ASM to the latest. Reviewed-by: mduigou, sundar ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java ! src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Context.java ! src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handler.java ! src/share/classes/jdk/internal/org/objectweb/asm/Item.java ! src/share/classes/jdk/internal/org/objectweb/asm/Label.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/TypePath.java + src/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ParameterNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/version.txt From john.zavgren at oracle.com Thu May 2 07:35:32 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Thu, 2 May 2013 07:35:32 -0700 (PDT) Subject: RFR JDK7188517 Message-ID: <30c5678a-20c3-4561-8c49-10b03ba541b1@default> Greetings: Please consider the following change to the cookie constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ Basically there are two issues: 1.) the existing cookie constructor was allowing cookie names to have a dollar sign as their leading character, which is "illegal". The constructor code was modified to disallow these illegal names. 2.) the API document (notice the specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) prohibited the use of cookie names that are one of the tokens reserved for use by the cookie protocol, and this restriction is not necessary. Thanks! John Zavgren -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130502/ecf7fcc5/attachment.html From mike.duigou at oracle.com Thu May 2 09:25:01 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 02 May 2013 16:25:01 +0000 Subject: hg: jdk8/tl/jdk: 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile Message-ID: <20130502162514.B703948781@hg.openjdk.java.net> Changeset: 5045eb04a579 Author: mduigou Date: 2013-05-02 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5045eb04a579 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile Reviewed-by: mduigou, henryjen, alanb, martin, psandoz Contributed-by: akhil.arora at oracle.com, brian.goetz at oracle.com ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/BitSet/BitSetStreamTest.java + test/java/util/Random/RandomStreamTest.java + test/java/util/zip/ZipFile/StreamZipEntriesTest.java From john.zavgren at oracle.com Thu May 2 10:09:43 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Thu, 2 May 2013 10:09:43 -0700 (PDT) Subject: RFR JDK7188517 Message-ID: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> All: My original email was mangled by my email program (stbeehive/zimbra) ... so I'm sending a second correctly formatted copy. I'm sorry for the inconvenience. John --------------- Please consider the following change to the cookie constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ Basically there are two issues: 1.) the existing cookie constructor was allowing cookie names to have a dollar sign as their leading character, which is "illegal". The constructor code was modified to disallow these illegal names. 2.) the API document (notice the specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ ) prohibited the use of cookie names that are one of the tokens reserved for use by the cookie protocol, and this restriction is not necessary. Thanks! John Zavgren ----- Original Message ----- From: john.zavgren at oracle.com To: net-dev at openjdk.java.net Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern Subject: RFR JDK7188517 Greetings: Please consider the following change to the cookie constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ Basically there are two issues: 1.) the existing cookie constructor was allowing cookie names to have a dollar sign as their leading character, which is "illegal". The constructor code was modified to disallow these illegal names. 2.) the API document (notice the specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) prohibited the use of cookie names that are one of the tokens reserved for use by the cookie protocol, and this restriction is not necessary. Thanks! John Zavgren -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130502/f6aadab2/attachment.html From kurchi.subhra.hazra at oracle.com Thu May 2 14:17:51 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 02 May 2013 21:17:51 +0000 Subject: hg: jdk8/tl/jdk: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name Message-ID: <20130502211812.21CA248793@hg.openjdk.java.net> Changeset: 3062bf908281 Author: khazra Date: 2013-05-02 14:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062bf908281 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name Summary: Remove buffer overruns in native code Reviewed-by: alanb, chegar ! src/solaris/native/java/net/NetworkInterface.c From kurchi.subhra.hazra at oracle.com Thu May 2 15:11:23 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 02 May 2013 15:11:23 -0700 Subject: Code Review Request: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name In-Reply-To: <518244EB.103@oracle.com> References: <50A5DA31.3040409@oracle.com> <5181AD5B.40703@oracle.com> <518244EB.103@oracle.com> Message-ID: <5182E48B.1010808@oracle.com> Thank you, committed now. - Kurchi On 5/2/2013 3:50 AM, Alan Bateman wrote: > On 02/05/2013 01:03, Kurchi Subhra Hazra wrote: >> >> Hi, >> >> NetworkInterface.getByInetAddress() was crashing on solaris when >> the system had a network >> interface name longer than 15 characters, due to two instances in the >> native >> code for NetworkInterface where we were copying a char array of size >> 32 (LIFNAMSIZ) >> into a char array of size 16 (IFNAMSIZ), resulting in a buffer >> overflow with long names. >> The fix is to make sure that the space allocated for the interface >> name is consistent (16/32 >> bytes depending on the system), and to prevent overflows by using >> strncpy instead of strcpy. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8013140 >> Webrev: http://cr.openjdk.java.net/~khazra/8013140/webrev.00/ >> >> >> Thanks, >> - Kurchi > A good fine, looks okay to me. An alternative would be sizeof(name) > but what you have is fine. > > -Alan > -- -Kurchi From weijun.wang at oracle.com Thu May 2 19:44:40 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 03 May 2013 02:44:40 +0000 Subject: hg: jdk8/tl/jdk: 8013855: DigestMD5Client has not checked RealmChoiceCallback value Message-ID: <20130503024453.7B540487AC@hg.openjdk.java.net> Changeset: 81be41c7323f Author: weijun Date: 2013-05-03 10:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81be41c7323f 8013855: DigestMD5Client has not checked RealmChoiceCallback value Reviewed-by: xuelei, mullan ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java + test/com/sun/security/sasl/digest/AuthRealmChoices.java From jonathan.gibbons at oracle.com Fri May 3 09:57:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 May 2013 16:57:40 +0000 Subject: hg: jdk8/tl/langtools: 8012728: Normalize @ignore comments on langtools tests Message-ID: <20130503165746.D12F5487F0@hg.openjdk.java.net> Changeset: abd153854f16 Author: jjg Date: 2013-05-03 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/abd153854f16 8012728: Normalize @ignore comments on langtools tests Reviewed-by: vromero, mcimadamore ! test/com/sun/javadoc/_template/Template.java ! test/com/sun/javadoc/_template/TemplateComplete.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511b.java ! test/tools/javac/generics/OverrideBridge.java ! test/tools/javac/lambda/TargetType36.java ! test/tools/javac/lambda/TargetType53.java ! test/tools/javac/lambda/TargetType54.java ! test/tools/javac/lambda/TargetType58.java ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java ! test/tools/javap/output/RepeatingTypeAnnotations.java ! test/tools/javap/output/Tester.java From jonathan.gibbons at oracle.com Fri May 3 10:17:25 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 May 2013 17:17:25 +0000 Subject: hg: jdk8/tl/langtools: 8002387: Improve rendered HTML formatting for {@code} Message-ID: <20130503171727.C503F487F1@hg.openjdk.java.net> Changeset: 38c4bade0ec1 Author: jjg Date: 2013-05-03 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38c4bade0ec1 8002387: Improve rendered HTML formatting for {@code} Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javadoc/Comment.java + test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java + test/com/sun/javadoc/testLiteralCodeInPre/pkg/Test.java From mike.duigou at oracle.com Fri May 3 14:33:27 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 03 May 2013 21:33:27 +0000 Subject: hg: jdk8/tl/jdk: 8013528: Provide SharedSecrets access to String(char[], boolean) constructor Message-ID: <20130503213340.41D60487FF@hg.openjdk.java.net> Changeset: fc156b925259 Author: mduigou Date: 2013-05-03 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc156b925259 8013528: Provide SharedSecrets access to String(char[], boolean) constructor Reviewed-by: martin, alanb, chegar, plevart ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/sun/misc/JavaLangAccess/NewUnsafeString.java From jonathan.gibbons at oracle.com Fri May 3 15:11:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 May 2013 22:11:26 +0000 Subject: hg: jdk8/tl/langtools: 8000407: remove @GenerateNativeHeader Message-ID: <20130503221128.F392D48801@hg.openjdk.java.net> Changeset: a2889739cf21 Author: jjg Date: 2013-05-03 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a2889739cf21 8000407: remove @GenerateNativeHeader Reviewed-by: vromero, darcy ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java From jonathan.gibbons at oracle.com Fri May 3 17:46:41 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 04 May 2013 00:46:41 +0000 Subject: hg: jdk8/tl/langtools: 8008768: Using {@inheritDoc} in simple tag defined via -tag fails Message-ID: <20130504004644.180ED48807@hg.openjdk.java.net> Changeset: d918b63a5509 Author: jjg Date: 2013-05-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d918b63a5509 8008768: Using {@inheritDoc} in simple tag defined via -tag fails Reviewed-by: jjg, mduigou Contributed-by: jonathan.gibbons at oracle.com, mike.duigou at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java + test/com/sun/javadoc/InheritDocForUserTags/DocTest.java + test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java + test/com/sun/javadoc/testSimpleTagInherit/p/BaseClass.java + test/com/sun/javadoc/testSimpleTagInherit/p/TestClass.java From mkomu at cs.hut.fi Sat May 4 05:22:06 2013 From: mkomu at cs.hut.fi (Miika Komu) Date: Sat, 04 May 2013 15:22:06 +0300 Subject: suggestions for improvement in java.net APIs Message-ID: <5184FD6E.6040800@cs.hut.fi> Howdy, we investigated the APIs of java.net (OpenJDK Build b147) and published our findings in Ottawa Linux Symposium 2012: http://nw.dreamhosters.com/ols/ols2012/ols2012-komu.pdf We two types of improvements to java.net disclosed in full detail in section 4.3.1 of the publication. First, we suggest to fix a bug related to UDP in multihoming scenarios (i.e., a host has multiple IP addresses). Second, we suggest improvements that can improve either the user experience (i.e. by improving latency in IPv6 environments) or developers (after all, frameworks are a conveniency for the developers). The suggestions for improvements are briefly summarized below. Multihoming bug --------------- * R3.2: Server-side multihoming for UDP does not work properly. The framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg() interfaces in a proper way. Suggested improvements (for better end-user or developer experience) -------------------------------------------------------------------- * R2.2: The framework does not support parallel DNS look ups over IPv4 and IPv6 to optimize latency * R3.3: The framework does not support parallel connect() over IPv4 and IPv6 to minimize the latency for connection set-up Please refer to section 4.3.4 in the publication for a more elaborate discussion of the improvements. From Alan.Bateman at oracle.com Sun May 5 02:40:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 05 May 2013 10:40:25 +0100 Subject: suggestions for improvement in java.net APIs In-Reply-To: <5184FD6E.6040800@cs.hut.fi> References: <5184FD6E.6040800@cs.hut.fi> Message-ID: <51862909.4080101@oracle.com> On 04/05/2013 13:22, Miika Komu wrote: > : > > Multihoming bug > --------------- > * R3.2: Server-side multihoming for UDP does not work properly. The > framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg() > interfaces in a proper way. Thanks for sending the link to the survey. On SO_BINDTODEVICE, then I think the last time that this came up (a few years ago) that the issue was that it wasn't supported by many operating systems and on Linux I thought it required privileges/root. On sendmsg/recvmsg then there was an effort at one point to add support for looking at the destination address, I don't recall if setting the source address when sending was considered at the time. If you are interested in working on adding this support then it would be good to propose a patch. The main challenges be implementing it on all platforms or specifying in such a way it allows for some implementation-specific behavior/support. > > Suggested improvements (for better end-user or developer experience) > -------------------------------------------------------------------- > * R2.2: The framework does not support parallel DNS look ups over IPv4 > and IPv6 to optimize latency InetAddress will normally delegate to the platform's resolver so it might be parallel (newer versions of glibc? Also I think MacOSX has been doing this for some time). InetAddress can also be configured to use a pure-DNS or other provider so that the look ups can be controlled. I'm not aware of anyone looking into doing parallel look-ups over IPv4 and IPv6 but it would be an interesting patch for someone to work on if they are interested. > * R3.3: The framework does not support parallel connect() over IPv4 and > IPv6 to minimize the latency for connection set-up > > While there isn't API support, it is something that can be done at the application level. So if InetAddress.getAllByName return several addresses then it is possible to initiate connections to several addresses using a thread pool. Another approach might be to use several SocketChannel configured non-blocking plus a Selector. This may not be what you are thinking of course. -Alan. From dmitry.samersoff at oracle.com Sun May 5 04:19:45 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 05 May 2013 15:19:45 +0400 Subject: suggestions for improvement in java.net APIs In-Reply-To: <51862909.4080101@oracle.com> References: <5184FD6E.6040800@cs.hut.fi> <51862909.4080101@oracle.com> Message-ID: <51864051.6080600@oracle.com> Alan, SO_BINDTODEVICE shouldn't be used in modern applications because it causes more problems than solves. e.g. prevents application from handling on-fly device changes. Also it requires root (or be more precise RAW_SOCKET) permission and is not supported on some embedded platforms. -Dmitry On 2013-05-05 13:40, Alan Bateman wrote: > On 04/05/2013 13:22, Miika Komu wrote: >> : >> >> Multihoming bug >> --------------- >> * R3.2: Server-side multihoming for UDP does not work properly. The >> framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg() >> interfaces in a proper way. > Thanks for sending the link to the survey. > > On SO_BINDTODEVICE, then I think the last time that this came up (a few > years ago) that the issue was that it wasn't supported by many operating > systems and on Linux I thought it required privileges/root. > > On sendmsg/recvmsg then there was an effort at one point to add support > for looking at the destination address, I don't recall if setting the > source address when sending was considered at the time. > > If you are interested in working on adding this support then it would be > good to propose a patch. The main challenges be implementing it on all > platforms or specifying in such a way it allows for some > implementation-specific behavior/support. > >> >> Suggested improvements (for better end-user or developer experience) >> -------------------------------------------------------------------- >> * R2.2: The framework does not support parallel DNS look ups over IPv4 >> and IPv6 to optimize latency > > InetAddress will normally delegate to the platform's resolver so it > might be parallel (newer versions of glibc? Also I think MacOSX has been > doing this for some time). > > InetAddress can also be configured to use a pure-DNS or other provider > so that the look ups can be controlled. I'm not aware of anyone looking > into doing parallel look-ups over IPv4 and IPv6 but it would be an > interesting patch for someone to work on if they are interested. > >> * R3.3: The framework does not support parallel connect() over IPv4 and >> IPv6 to minimize the latency for connection set-up >> >> > While there isn't API support, it is something that can be done at the > application level. So if InetAddress.getAllByName return several > addresses then it is possible to initiate connections to several > addresses using a thread pool. Another approach might be to use several > SocketChannel configured non-blocking plus a Selector. This may not be > what you are thinking of course. > > -Alan. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From mkomu at cs.hut.fi Sun May 5 05:02:17 2013 From: mkomu at cs.hut.fi (Miika Komu) Date: Sun, 05 May 2013 15:02:17 +0300 Subject: suggestions for improvement in java.net APIs In-Reply-To: <51862909.4080101@oracle.com> References: <5184FD6E.6040800@cs.hut.fi> <51862909.4080101@oracle.com> Message-ID: <51864A49.9030205@cs.hut.fi> Hi, On 05/05/2013 12:40 PM, Alan Bateman wrote: > On 04/05/2013 13:22, Miika Komu wrote: >> : >> >> Multihoming bug >> --------------- >> * R3.2: Server-side multihoming for UDP does not work properly. The >> framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg() >> interfaces in a proper way. > Thanks for sending the link to the survey. > > On SO_BINDTODEVICE, then I think the last time that this came up (a few > years ago) that the issue was that it wasn't supported by many operating > systems and on Linux I thought it required privileges/root. > > On sendmsg/recvmsg then there was an effort at one point to add support > for looking at the destination address, I don't recall if setting the > source address when sending was considered at the time. I should note that this is actually a bug that we have verified manually: "We verified the UDP multihoming problem with example software provided with the java.net. We managed to repeat the UDP multihoming problem with connected sockets. This means that the java.net library shares the same bug as iperf, nc and nc6 as described earlier." Maybe it should be added to the bug tracker. > If you are interested in working on adding this support then it would be > good to propose a patch. The main challenges be implementing it on all > platforms or specifying in such a way it allows for some > implementation-specific behavior/support. > >> >> Suggested improvements (for better end-user or developer experience) >> -------------------------------------------------------------------- >> * R2.2: The framework does not support parallel DNS look ups over IPv4 >> and IPv6 to optimize latency > > InetAddress will normally delegate to the platform's resolver so it > might be parallel (newer versions of glibc? Also I think MacOSX has been > doing this for some time). > > InetAddress can also be configured to use a pure-DNS or other provider > so that the look ups can be controlled. I'm not aware of anyone looking > into doing parallel look-ups over IPv4 and IPv6 but it would be an > interesting patch for someone to work on if they are interested. > >> * R3.3: The framework does not support parallel connect() over IPv4 and >> IPv6 to minimize the latency for connection set-up >> >> > While there isn't API support, it is something that can be done at the > application level. So if InetAddress.getAllByName return several > addresses then it is possible to initiate connections to several > addresses using a thread pool. Another approach might be to use several > SocketChannel configured non-blocking plus a Selector. This may not be > what you are thinking of course. I was looking for a completely automated solution, without implementing this redundantly (and without repeating the mistakes) in each application. As IPv6 is catching up, all of the issues will become more interesting because IPv6 provides multiple addresses by default. (In python Twisted, the mentioned functionality is apparently implemented according to the developers) Personally, I don't have any time to work on these, but I'll let you know if I can find a student from our university to drill on these. From dag.wanvik at oracle.com Sun May 5 21:06:13 2013 From: dag.wanvik at oracle.com (dag.wanvik at oracle.com) Date: Mon, 06 May 2013 04:06:13 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130506040646.ADA004882A@hg.openjdk.java.net> Changeset: d8f01bfb1da4 Author: dwanvik Date: 2013-05-06 05:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8f01bfb1da4 8013403: Update JDK8 with Java DB 10.10.1.1. Summary: Drop Java DB 10.10.1.1 bits into JDK 8 and update image builds Reviewed-by: tbell ! make/common/Release.gmk ! makefiles/CompileDemos.gmk ! makefiles/Images.gmk Changeset: 398fe07f530f Author: dwanvik Date: 2013-05-06 06:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/398fe07f530f Merge - test/sun/reflect/CallerSensitive/MethodFinder.java From joe.darcy at oracle.com Sun May 5 21:05:14 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 06 May 2013 04:05:14 +0000 Subject: hg: jdk8/tl/langtools: 8013909: Fix doclint issues in javax.lang.model Message-ID: <20130506040520.B9DF648829@hg.openjdk.java.net> Changeset: e8987ce7fb4b Author: darcy Date: 2013-05-05 21:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e8987ce7fb4b 8013909: Fix doclint issues in javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/SupportedAnnotationTypes.java ! src/share/classes/javax/annotation/processing/SupportedOptions.java ! src/share/classes/javax/annotation/processing/SupportedSourceVersion.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/element/NestingKind.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/lang/model/util/Types.java From Alan.Bateman at oracle.com Mon May 6 00:28:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 06 May 2013 08:28:53 +0100 Subject: suggestions for improvement in java.net APIs In-Reply-To: <51864051.6080600@oracle.com> References: <5184FD6E.6040800@cs.hut.fi> <51862909.4080101@oracle.com> <51864051.6080600@oracle.com> Message-ID: <51875BB5.6070505@oracle.com> On 05/05/2013 12:19, Dmitry Samersoff wrote: > Alan, > > SO_BINDTODEVICE shouldn't be used in modern applications because it > causes more problems than solves. > > e.g. prevents application from handling on-fly device changes. > The use-case is where an application wants to control the network or source address. -Alan. From dan.xu at oracle.com Mon May 6 14:18:54 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Mon, 06 May 2013 21:18:54 +0000 Subject: hg: jdk8/tl/jdk: 8003992: File and other classes in java.io do not handle embedded nulls properly Message-ID: <20130506211907.94A234884E@hg.openjdk.java.net> Changeset: bd118033e44c Author: dxu Date: 2013-05-06 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd118033e44c 8003992: File and other classes in java.io do not handle embedded nulls properly Summary: Have every file operation done with File, FileInputStream, FileOutputStream, or RandomAccessFile that involves a file path containing NUL fail. Also reviewed by fweimer at redhat.com Reviewed-by: alanb, sherman, ahgross, mduigou, dholmes, aph, plevart, martin ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/File/NulFile.java From kurchi.subhra.hazra at oracle.com Mon May 6 14:28:51 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 6 May 2013 14:28:51 -0700 (PDT) Subject: RFR JDK7188517 In-Reply-To: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> Message-ID: <51882093.6030700@oracle.com> This looks okay to me. - Kurchi On 5/2/2013 10:09 AM, John Zavgren wrote: > All: > My original email was mangled by my email program (stbeehive/zimbra) > ... so I'm sending a second correctly formatted copy. > > I'm sorry for the inconvenience. > > John > --------------- > > Please consider the following change to the cookie constructor: > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ > > > Basically there are two issues: > > 1.) the existing cookie constructor was allowing cookie names to have > a dollar sign as their leading character, > which is "illegal". The constructor code was modified to disallow > these illegal names. > > 2.) the API document (notice the specdiff: > http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ > ) prohibited > the use of cookie names that are one of the tokens reserved for use by > the cookie protocol, and this restriction is not necessary. > > Thanks! > John Zavgren > > > ----- Original Message ----- > From: john.zavgren at oracle.com > To: net-dev at openjdk.java.net > Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern > Subject: RFR JDK7188517 > > Greetings: Please consider the following change to the cookie > constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ > Basically there are two issues: 1.) the existing cookie constructor > was allowing cookie names to have a dollar sign as their leading > character, which is "illegal". The constructor code was modified to > disallow these illegal names. 2.) the API document (notice the > specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) > prohibited the use of cookie names that are one of the tokens reserved > for use by the cookie protocol, and this restriction is not necessary. > Thanks! John Zavgren -- -Kurchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130506/ef938482/attachment.html From dmitry.samersoff at oracle.com Mon May 6 14:40:12 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 07 May 2013 01:40:12 +0400 Subject: suggestions for improvement in java.net APIs In-Reply-To: <51875BB5.6070505@oracle.com> References: <5184FD6E.6040800@cs.hut.fi> <51862909.4080101@oracle.com> <51864051.6080600@oracle.com> <51875BB5.6070505@oracle.com> Message-ID: <5188233C.6080801@oracle.com> Alan, Not sure what is real usecase for this requirements for ipv4. For ipv6 it should be done by sendmsg() and msg_control. -Dmitry On 2013-05-06 11:28, Alan Bateman wrote: > On 05/05/2013 12:19, Dmitry Samersoff wrote: >> Alan, >> >> SO_BINDTODEVICE shouldn't be used in modern applications because it >> causes more problems than solves. >> >> e.g. prevents application from handling on-fly device changes. >> > The use-case is where an application wants to control the network or > source address. > > -Alan. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From john.zavgren at oracle.com Mon May 6 18:18:13 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 6 May 2013 18:18:13 -0700 (PDT) Subject: suggestions for improvement in java.net APIs Message-ID: SO_BINDTODEVICE can be used in cases where an IP network application doesn't want the existing routing table entries to determine the interface that packets are transmitted from. This is often the case when one is writing a router that needs to do neighbor discovery. I used this extensively a few years back to create a "link aggregator" that dynamically and adaptively distributed traffic to a particular destination across multiple interfaces. (They were PPP interfaces that were created by unreliable unpredictable CDMA data cards, and we had to do the best with what mother nature gave us for sending high-bandwidth video. Even one good card couldn't support the video stream and the product looked like a porcupine studded with data cards.) An other reason for binding a socket to a device, is when Ethernet is used as a control plane inside a product. Packets intended to go between cards within a chassis cannot be allowed to leave the chassis, ever. You don't want bugs or misconfiguration to result in leaking control traffic. People who build "network appliances" use SO_BINDTODEVICE. And I can also imagine android developers wanting it for applications that want to use multiple interfaces intelligently (maybe to divert traffic from cellular data to WiFi when WiFi is available to save money and get better performance. You could write an App that will ONLY use the WiFi interface, regardless of what the routing table says.) I've used SO_BINDTODEVICE for years and when I started using Java last year, I was stunned that it wasn't available. I guess the question is whether or not there is a reason to support "network appliance" developers. ----- Original Message ----- From: dmitry.samersoff at oracle.com To: Alan.Bateman at oracle.com Cc: mkomu at cs.hut.fi, net-dev at openjdk.java.net Sent: Monday, May 6, 2013 5:50:06 PM GMT -05:00 US/Canada Eastern Subject: Re: suggestions for improvement in java.net APIs Alan, Not sure what is real usecase for this requirements for ipv4. For ipv6 it should be done by sendmsg() and msg_control. -Dmitry On 2013-05-06 11:28, Alan Bateman wrote: > On 05/05/2013 12:19, Dmitry Samersoff wrote: >> Alan, >> >> SO_BINDTODEVICE shouldn't be used in modern applications because it >> causes more problems than solves. >> >> e.g. prevents application from handling on-fly device changes. >> > The use-case is where an application wants to control the network or > source address. > > -Alan. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From mike.duigou at oracle.com Mon May 6 20:56:18 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 May 2013 03:56:18 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130507035652.E8C7F4885D@hg.openjdk.java.net> Changeset: e13cf31e5a96 Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e13cf31e5a96 8013712: Add Objects.nonNull and Objects.isNull Reviewed-by: mchung, darcy ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 3cbb65d9af9e Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cbb65d9af9e 8013150: Iterator.remove and forEachRemaining relationship not specified Reviewed-by: mduigou Contributed-by: Akhil Arora ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Vector.java + test/java/util/Iterator/IteratorDefaults.java Changeset: 8221c421490f Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8221c421490f 8003258: BufferedReader.lines() Reviewed-by: alanb, mduigou, psandoz Contributed-by: Brian Goetz , Henry Jen ! src/share/classes/java/io/BufferedReader.java + src/share/classes/java/io/UncheckedIOException.java + test/java/io/BufferedReader/Lines.java From xueming.shen at oracle.com Mon May 6 21:25:15 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 07 May 2013 04:25:15 +0000 Subject: hg: jdk8/tl/jdk: 8013252: Regex Matcher .start and .end should be accessible by group name; ... Message-ID: <20130507042526.D8ED64885E@hg.openjdk.java.net> Changeset: b4a013f4eff4 Author: sherman Date: 2013-05-06 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4a013f4eff4 8013252: Regex Matcher .start and .end should be accessible by group name 8013254: Constructor \w need update to add the support of \p{Join_Control} Summary: added the requested methods and updated the \w constructor Reviewed-by: mchung, alanb ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/regex/UnicodeProp.java ! test/java/util/regex/POSIX_Unicode.java ! test/java/util/regex/RegExTest.java From weijun.wang at oracle.com Mon May 6 21:32:02 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 07 May 2013 04:32:02 +0000 Subject: hg: jdk8/tl/jdk: 8010192: Enable native JGSS provider on Mac Message-ID: <20130507043213.AB25048861@hg.openjdk.java.net> Changeset: 814dcc08df52 Author: weijun Date: 2013-05-07 12:30 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/814dcc08df52 8010192: Enable native JGSS provider on Mac Reviewed-by: valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/native/sun/security/jgss/wrapper/gssapi.h ! test/sun/security/krb5/runNameEquals.sh From jonathan.gibbons at oracle.com Mon May 6 22:52:07 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 07 May 2013 05:52:07 +0000 Subject: hg: jdk8/tl/langtools: 8009724: Enhance the DocTree API with DocTreePath Message-ID: <20130507055210.2F0D948865@hg.openjdk.java.net> Changeset: a7ff36d06fa2 Author: jlahoda Date: 2013-05-06 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a7ff36d06fa2 8009724: Enhance the DocTree API with DocTreePath Summary: Adding DocTreePath and DocTreePathScanner similar to TreePath and TreePathScanner, respectively Reviewed-by: jjg Contributed-by: Ralph Benjamin Ruijs , Jan Lahoda + src/share/classes/com/sun/source/util/DocTreePath.java + src/share/classes/com/sun/source/util/DocTreePathScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/doctree/DocTreePathScannerTest.java ! test/tools/javac/doctree/ReferenceTest.java From daniel.fuchs at oracle.com Tue May 7 02:58:24 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 07 May 2013 09:58:24 +0000 Subject: hg: jdk8/tl/jaxp: 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Message-ID: <20130507095833.BA0374886F@hg.openjdk.java.net> Changeset: 452e1a182907 Author: dfuchs Date: 2013-05-06 18:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/452e1a182907 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Summary: Encodings.java sometimes creates EncodingInfo objects whose java names are not recognized by the Charset API. This patch fixes that issue. Reviewed-by: joehw, alanb ! src/com/sun/org/apache/xml/internal/serializer/Encodings.java From daniel.fuchs at oracle.com Tue May 7 02:59:09 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 07 May 2013 09:59:09 +0000 Subject: hg: jdk8/tl/jdk: 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Message-ID: <20130507100036.C35C948870@hg.openjdk.java.net> Changeset: 2602eab5f086 Author: dfuchs Date: 2013-05-07 11:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2602eab5f086 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Summary: Encodings.java sometimes creates EncodingInfo objects whose java names are not recognized by the Charset API. This patch fixes that issue. Reviewed-by: joehw, alanb + test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java From piotr at bzdyl.net Tue May 7 06:25:02 2013 From: piotr at bzdyl.net (Piotr Bzdyl) Date: Tue, 7 May 2013 15:25:02 +0200 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection Message-ID: Hello, This is my first post to this mailing list so I would like to say "Hi". The reason I subscribed and I am writing is that I believe I have found a bug in sun.*.HttpURLConnection class (in particular how it handles Expect: 100-continue header). I have already submitted a bug at bugs.sun.com but after almost 3 weeks I still cannot access the bug and check its status ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001773). I would like to ask if bugs.sun.com is alive or if it is possible to report the bug in the OpenJDK project or is there any other alternative procedure for submitting bug reports. Best regards, Piotr Bzdyl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130507/de09b0e4/attachment.html From chris.hegarty at oracle.com Tue May 7 06:43:45 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 May 2013 14:43:45 +0100 Subject: RFR JDK7188517 In-Reply-To: <51882093.6030700@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> Message-ID: <51890511.9090305@oracle.com> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: > This looks okay to me. Source changes look fine to me too. Probably best to add a test for '$' In fact, Michael actually removed such a test [1] during another change. We should get positive agreement from Michael before pushing this. -Chris. [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 > > - Kurchi > > > On 5/2/2013 10:09 AM, John Zavgren wrote: >> All: >> My original email was mangled by my email program (stbeehive/zimbra) >> ... so I'm sending a second correctly formatted copy. >> >> I'm sorry for the inconvenience. >> >> John >> --------------- >> >> Please consider the following change to the cookie constructor: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >> >> >> Basically there are two issues: >> >> 1.) the existing cookie constructor was allowing cookie names to have >> a dollar sign as their leading character, >> which is "illegal". The constructor code was modified to disallow >> these illegal names. >> >> 2.) the API document (notice the specdiff: >> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >> ) prohibited >> the use of cookie names that are one of the tokens reserved for use by >> the cookie protocol, and this restriction is not necessary. >> >> Thanks! >> John Zavgren >> >> >> ----- Original Message ----- >> From: john.zavgren at oracle.com >> To: net-dev at openjdk.java.net >> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern >> Subject: RFR JDK7188517 >> >> Greetings: Please consider the following change to the cookie >> constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >> Basically there are two issues: 1.) the existing cookie constructor >> was allowing cookie names to have a dollar sign as their leading >> character, which is "illegal". The constructor code was modified to >> disallow these illegal names. 2.) the API document (notice the >> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >> prohibited the use of cookie names that are one of the tokens reserved >> for use by the cookie protocol, and this restriction is not necessary. >> Thanks! John Zavgren > > -- > -Kurchi > From chris.hegarty at oracle.com Tue May 7 06:52:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 May 2013 14:52:35 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: References: Message-ID: <51890723.1020506@oracle.com> Hi Piotr, Your bug is accessible at http://bugs.sun.com/view_bug.do?bug_id=8012625 From my reading of the code the headers should be sent before waiting for the reply to continue. From sun/net/www/prtotocol/http/HttpURLConnection: getOutputStream() { .... if (!checkReuseConnection()) connect(); boolean expectContinue = false; String expects = requests.findValue("Expect"); if ("100-Continue".equalsIgnoreCase(expects)) { http.setIgnoreContinue(false); expectContinue = true; } if (streaming() && strOutputStream == null) { writeRequests(); // <<<< Here } if (expectContinue) { expect100Continue(); } .... } Are you seeing something different? -Chris. On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: > Hello, > > This is my first post to this mailing list so I would like to say "Hi". > > The reason I subscribed and I am writing is that I believe I have found > a bug in sun.*.HttpURLConnection class (in particular how it handles > Expect: 100-continue header). I have already submitted a bug at > bugs.sun.com but after almost 3 weeks I still > cannot access the bug and check its status > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001773). > > I would like to ask if bugs.sun.com is alive or if > it is possible to report the bug in the OpenJDK project or is there any > other alternative procedure for submitting bug reports. > > Best regards, > Piotr Bzdyl From piotr at bzdyl.net Tue May 7 06:59:22 2013 From: piotr at bzdyl.net (Piotr Bzdyl) Date: Tue, 7 May 2013 15:59:22 +0200 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <51890723.1020506@oracle.com> References: <51890723.1020506@oracle.com> Message-ID: Chris, When I used the URL provided by you I have indeed access to my bug report. It seems the notification email I got with confirmation of my report submission provides the misleading URL. Is it possible to fix it in the notification template? When I debug the code (using the test case I attached to the bug report), it doesn't go into the if (streaming() && strOutputStream == null) { writeRequests(); // <<<< Here } but goes directly to expect100Continue() in: if (expectContinue) { expect100Continue(); } On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty wrote: > Hi Piotr, > > Your bug is accessible at > http://bugs.sun.com/view_bug.**do?bug_id=8012625 > > From my reading of the code the headers should be sent before waiting for > the reply to continue. > > From sun/net/www/prtotocol/http/**HttpURLConnection: > > getOutputStream() { > .... > if (!checkReuseConnection()) > connect(); > > boolean expectContinue = false; > String expects = requests.findValue("Expect"); > if ("100-Continue".**equalsIgnoreCase(expects)) { > http.setIgnoreContinue(false); > expectContinue = true; > } > > if (streaming() && strOutputStream == null) { > writeRequests(); // <<<< Here > } > > if (expectContinue) { > expect100Continue(); > } > .... > > } > > Are you seeing something different? > > -Chris. > > > > On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: > >> Hello, >> >> This is my first post to this mailing list so I would like to say "Hi". >> >> The reason I subscribed and I am writing is that I believe I have found >> a bug in sun.*.HttpURLConnection class (in particular how it handles >> Expect: 100-continue header). I have already submitted a bug at >> bugs.sun.com but after almost 3 weeks I still >> >> cannot access the bug and check its status >> (http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=9001773 >> ). >> >> I would like to ask if bugs.sun.com is alive or if >> >> it is possible to report the bug in the OpenJDK project or is there any >> other alternative procedure for submitting bug reports. >> >> Best regards, >> Piotr Bzdyl >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130507/63002d84/attachment.html From chris.hegarty at oracle.com Tue May 7 07:05:28 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 May 2013 15:05:28 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: References: <51890723.1020506@oracle.com> Message-ID: <51890A28.9070404@oracle.com> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: > Chris, > > When I used the URL provided by you I have indeed access to my bug > report. It seems the notification email I got with confirmation of my > report submission provides the misleading URL. Is it possible to fix it > in the notification template? You are right the URL provided to you is pretty much useless, at this point. Not that is matters much, but there are separate JIRA projects for bugs moving from web screening to the "real" bug incidents. If it is any consolation, your issue has made it all the way ;-) > > When I debug the code (using the test case I attached to the bug > report), it doesn't go into the > > if (streaming() && strOutputStream == null) { > writeRequests(); // <<<< Here > } > > but goes directly to expect100Continue() in: > if (expectContinue) { > expect100Continue(); > } Ah ha. that is the bug. We should always writeRequests ( write headers ) when expectContinue is set. I'll update the bug with this clear comment, and then propose a patch for JDK8. -Chris. > > > > On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty > wrote: > > Hi Piotr, > > Your bug is accessible at > http://bugs.sun.com/view_bug.__do?bug_id=8012625 > > > From my reading of the code the headers should be sent before > waiting for the reply to continue. > > From sun/net/www/prtotocol/http/__HttpURLConnection: > > getOutputStream() { > .... > if (!checkReuseConnection()) > connect(); > > boolean expectContinue = false; > String expects = requests.findValue("Expect"); > if ("100-Continue".__equalsIgnoreCase(expects)) { > http.setIgnoreContinue(false); > expectContinue = true; > } > > if (streaming() && strOutputStream == null) { > writeRequests(); // <<<< Here > } > > if (expectContinue) { > expect100Continue(); > } > .... > > } > > Are you seeing something different? > > -Chris. > > > > On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: > > Hello, > > This is my first post to this mailing list so I would like to > say "Hi". > > The reason I subscribed and I am writing is that I believe I > have found > a bug in sun.*.HttpURLConnection class (in particular how it handles > Expect: 100-continue header). I have already submitted a bug at > bugs.sun.com but > after almost 3 weeks I still > > cannot access the bug and check its status > (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773 > ). > > I would like to ask if bugs.sun.com > is alive or if > > it is possible to report the bug in the OpenJDK project or is > there any > other alternative procedure for submitting bug reports. > > Best regards, > Piotr Bzdyl > > From piotr at bzdyl.net Tue May 7 07:22:02 2013 From: piotr at bzdyl.net (Piotr Bzdyl) Date: Tue, 7 May 2013 16:22:02 +0200 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <51890A28.9070404@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> Message-ID: Thank you very much for clarification! Best regards, Piotr On Tue, May 7, 2013 at 4:05 PM, Chris Hegarty wrote: > On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: > >> Chris, >> >> When I used the URL provided by you I have indeed access to my bug >> report. It seems the notification email I got with confirmation of my >> report submission provides the misleading URL. Is it possible to fix it >> in the notification template? >> > > You are right the URL provided to you is pretty much useless, at this > point. Not that is matters much, but there are separate JIRA projects for > bugs moving from web screening to the "real" bug incidents. If it is any > consolation, your issue has made it all the way ;-) > > > >> When I debug the code (using the test case I attached to the bug >> report), it doesn't go into the >> >> if (streaming() && strOutputStream == null) { >> writeRequests(); // <<<< Here >> } >> >> but goes directly to expect100Continue() in: >> if (expectContinue) { >> expect100Continue(); >> } >> > > Ah ha. that is the bug. We should always writeRequests ( write headers ) > when expectContinue is set. I'll update the bug with this clear comment, > and then propose a patch for JDK8. > > -Chris. > > >> >> >> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty > >> wrote: >> >> Hi Piotr, >> >> Your bug is accessible at >> http://bugs.sun.com/view_bug._**_do?bug_id=8012625 >> >> >> > >> >> From my reading of the code the headers should be sent before >> waiting for the reply to continue. >> >> From sun/net/www/prtotocol/http/__**HttpURLConnection: >> >> >> getOutputStream() { >> .... >> if (!checkReuseConnection()) >> connect(); >> >> boolean expectContinue = false; >> String expects = requests.findValue("Expect"); >> if ("100-Continue".__**equalsIgnoreCase(expects)) { >> >> http.setIgnoreContinue(false); >> expectContinue = true; >> } >> >> if (streaming() && strOutputStream == null) { >> writeRequests(); // <<<< Here >> } >> >> if (expectContinue) { >> expect100Continue(); >> } >> .... >> >> } >> >> Are you seeing something different? >> >> -Chris. >> >> >> >> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: >> >> Hello, >> >> This is my first post to this mailing list so I would like to >> say "Hi". >> >> The reason I subscribed and I am writing is that I believe I >> have found >> a bug in sun.*.HttpURLConnection class (in particular how it >> handles >> Expect: 100-continue header). I have already submitted a bug at >> bugs.sun.com but >> >> after almost 3 weeks I still >> >> cannot access the bug and check its status >> (http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >> id=9001773 >> >> >). >> >> >> I would like to ask if bugs.sun.com >> is alive or if >> >> it is possible to report the bug in the OpenJDK project or is >> there any >> other alternative procedure for submitting bug reports. >> >> Best regards, >> Piotr Bzdyl >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130507/00749b1e/attachment.html From chris.hegarty at oracle.com Tue May 7 07:29:54 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 May 2013 15:29:54 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <51890A28.9070404@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> Message-ID: <51890FE2.7070800@oracle.com> I replied too quick. This is not a bug per say, but a limitation of the existing API. Expect: 100-continue is only supported with streaming requests, i.e. setChunkedStreamingMode(int), or setFixedLengthStreamingMode(long). With the above API's the appropriate header, content-length or Transfer-Encoding: chunked, can be set before return the OutputStream ( from getOutputStream() ). Without either of the above calls the content-length is only determinable after the returned output stream is closed, and this happens after the return from getOutptuStream(). So I would say this is a limitation of the API. But the workaround is quite straight forward, use streaming. -Chris. On 05/07/2013 03:05 PM, Chris Hegarty wrote: > On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: >> Chris, >> >> When I used the URL provided by you I have indeed access to my bug >> report. It seems the notification email I got with confirmation of my >> report submission provides the misleading URL. Is it possible to fix it >> in the notification template? > > You are right the URL provided to you is pretty much useless, at this > point. Not that is matters much, but there are separate JIRA projects > for bugs moving from web screening to the "real" bug incidents. If it is > any consolation, your issue has made it all the way ;-) > >> >> When I debug the code (using the test case I attached to the bug >> report), it doesn't go into the >> >> if (streaming() && strOutputStream == null) { >> writeRequests(); // <<<< Here >> } >> >> but goes directly to expect100Continue() in: >> if (expectContinue) { >> expect100Continue(); >> } > > Ah ha. that is the bug. We should always writeRequests ( write headers ) > when expectContinue is set. I'll update the bug with this clear comment, > and then propose a patch for JDK8. > > -Chris. > >> >> >> >> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty > > wrote: >> >> Hi Piotr, >> >> Your bug is accessible at >> http://bugs.sun.com/view_bug.__do?bug_id=8012625 >> >> >> From my reading of the code the headers should be sent before >> waiting for the reply to continue. >> >> From sun/net/www/prtotocol/http/__HttpURLConnection: >> >> getOutputStream() { >> .... >> if (!checkReuseConnection()) >> connect(); >> >> boolean expectContinue = false; >> String expects = requests.findValue("Expect"); >> if ("100-Continue".__equalsIgnoreCase(expects)) { >> http.setIgnoreContinue(false); >> expectContinue = true; >> } >> >> if (streaming() && strOutputStream == null) { >> writeRequests(); // <<<< Here >> } >> >> if (expectContinue) { >> expect100Continue(); >> } >> .... >> >> } >> >> Are you seeing something different? >> >> -Chris. >> >> >> >> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: >> >> Hello, >> >> This is my first post to this mailing list so I would like to >> say "Hi". >> >> The reason I subscribed and I am writing is that I believe I >> have found >> a bug in sun.*.HttpURLConnection class (in particular how it >> handles >> Expect: 100-continue header). I have already submitted a bug at >> bugs.sun.com but >> after almost 3 weeks I still >> >> cannot access the bug and check its status >> (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773 >> ). >> >> I would like to ask if bugs.sun.com >> is alive or if >> >> it is possible to report the bug in the OpenJDK project or is >> there any >> other alternative procedure for submitting bug reports. >> >> Best regards, >> Piotr Bzdyl >> >> From piotr at bzdyl.net Tue May 7 07:40:20 2013 From: piotr at bzdyl.net (Piotr Bzdyl) Date: Tue, 7 May 2013 16:40:20 +0200 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <51890FE2.7070800@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> Message-ID: In this case I will have to double check the SAAJ SoapConnection (as we encountered the problem indirectly when using SAAJ SoapConnection). The code invoking the SOAP service was setting Expect: 100-continue header as the SOAP message header and SoapConnection propagated it to HttpURLConnection. I need to confirm that it is even allowed and if it is I will report the bug in SAAJ project. Best regards, Piotr On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty wrote: > I replied too quick. This is not a bug per say, but a limitation of the > existing API. > > Expect: 100-continue is only supported with streaming requests, i.e. > setChunkedStreamingMode(int), or setFixedLengthStreamingMode(**long). > > With the above API's the appropriate header, content-length or > Transfer-Encoding: chunked, can be set before return the OutputStream ( > from getOutputStream() ). Without either of the above calls the > content-length is only determinable after the returned output stream is > closed, and this happens after the return from getOutptuStream(). > > So I would say this is a limitation of the API. But the workaround is > quite straight forward, use streaming. > > -Chris. > > > On 05/07/2013 03:05 PM, Chris Hegarty wrote: > >> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: >> >>> Chris, >>> >>> When I used the URL provided by you I have indeed access to my bug >>> report. It seems the notification email I got with confirmation of my >>> report submission provides the misleading URL. Is it possible to fix it >>> in the notification template? >>> >> >> You are right the URL provided to you is pretty much useless, at this >> point. Not that is matters much, but there are separate JIRA projects >> for bugs moving from web screening to the "real" bug incidents. If it is >> any consolation, your issue has made it all the way ;-) >> >> >>> When I debug the code (using the test case I attached to the bug >>> report), it doesn't go into the >>> >>> if (streaming() && strOutputStream == null) { >>> writeRequests(); // <<<< Here >>> } >>> >>> but goes directly to expect100Continue() in: >>> if (expectContinue) { >>> expect100Continue(); >>> } >>> >> >> Ah ha. that is the bug. We should always writeRequests ( write headers ) >> when expectContinue is set. I'll update the bug with this clear comment, >> and then propose a patch for JDK8. >> >> -Chris. >> >> >>> >>> >>> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty >> >> wrote: >>> >>> Hi Piotr, >>> >>> Your bug is accessible at >>> http://bugs.sun.com/view_bug._**_do?bug_id=8012625 >>> >>> > >>> >>> From my reading of the code the headers should be sent before >>> waiting for the reply to continue. >>> >>> From sun/net/www/prtotocol/http/__**HttpURLConnection: >>> >>> getOutputStream() { >>> .... >>> if (!checkReuseConnection()) >>> connect(); >>> >>> boolean expectContinue = false; >>> String expects = requests.findValue("Expect"); >>> if ("100-Continue".__**equalsIgnoreCase(expects)) { >>> http.setIgnoreContinue(false); >>> expectContinue = true; >>> } >>> >>> if (streaming() && strOutputStream == null) { >>> writeRequests(); // <<<< Here >>> } >>> >>> if (expectContinue) { >>> expect100Continue(); >>> } >>> .... >>> >>> } >>> >>> Are you seeing something different? >>> >>> -Chris. >>> >>> >>> >>> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: >>> >>> Hello, >>> >>> This is my first post to this mailing list so I would like to >>> say "Hi". >>> >>> The reason I subscribed and I am writing is that I believe I >>> have found >>> a bug in sun.*.HttpURLConnection class (in particular how it >>> handles >>> Expect: 100-continue header). I have already submitted a bug at >>> bugs.sun.com but >>> after almost 3 weeks I still >>> >>> cannot access the bug and check its status >>> (http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >>> id=9001773 >>> >>> >). >>> >>> I would like to ask if bugs.sun.com >>> is alive or if >>> >>> it is possible to report the bug in the OpenJDK project or is >>> there any >>> other alternative procedure for submitting bug reports. >>> >>> Best regards, >>> Piotr Bzdyl >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130507/253c714e/attachment.html From staffan.larsen at oracle.com Tue May 7 10:58:16 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 07 May 2013 17:58:16 +0000 Subject: hg: jdk8/tl/jdk: 6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust when getMax() returns -1; ... Message-ID: <20130507175848.2F40E48885@hg.openjdk.java.net> Changeset: 7b40394ad944 Author: sla Date: 2013-05-07 19:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b40394ad944 6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust when getMax() returns -1 7181907: TEST_BUG: j/l/management/MemoryMXBean/ResetPeakMemoryUsage fails with NegativeArraySizeException 7148492: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java failing since update to hs23-b15 or b16 Reviewed-by: mchung, brutisso ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java From staffan.larsen at oracle.com Tue May 7 11:02:05 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 07 May 2013 18:02:05 +0000 Subject: hg: jdk8/tl/jdk: 8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true Message-ID: <20130507180217.528FF48886@hg.openjdk.java.net> Changeset: 100027950b05 Author: sla Date: 2013-05-07 20:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/100027950b05 8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true Reviewed-by: alanb, dsamersoff ! test/sun/tools/jinfo/Basic.sh From naoto.sato at oracle.com Tue May 7 11:31:45 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 07 May 2013 18:31:45 +0000 Subject: hg: jdk8/tl/jdk: 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied Message-ID: <20130507183159.253EB48896@hg.openjdk.java.net> Changeset: e30396e22c6f Author: naoto Date: 2013-05-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e30396e22c6f 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From mike.duigou at oracle.com Tue May 7 12:06:45 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 May 2013 19:06:45 +0000 Subject: hg: jdk8/tl/jdk: 4802647: Throw required NPEs from removeAll()/retainAll() Message-ID: <20130507190659.5BB8D4889A@hg.openjdk.java.net> Changeset: fe4e9bc2186f Author: mduigou Date: 2013-05-07 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe4e9bc2186f 4802647: Throw required NPEs from removeAll()/retainAll() Reviewed-by: mduigou, chegar, dholmes Contributed-by: Brandon Passanisi ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! test/java/util/Collection/MOAT.java From jonathan.gibbons at oracle.com Tue May 7 14:28:36 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 07 May 2013 21:28:36 +0000 Subject: hg: jdk8/tl/langtools: 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar Message-ID: <20130507212839.A34B0488A1@hg.openjdk.java.net> Changeset: 43c2f7cb9c76 Author: jjg Date: 2013-05-07 14:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/43c2f7cb9c76 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar Reviewed-by: vromero, mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + src/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! test/tools/javac/plugin/showtype/Test.java From mike.duigou at oracle.com Tue May 7 16:19:54 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 May 2013 23:19:54 +0000 Subject: hg: jdk8/tl/jdk: 8012664: Add tests for java.util.stream and lambda translation Message-ID: <20130507232015.C328D488B7@hg.openjdk.java.net> Changeset: 6feee75b0a8b Author: briangoetz Date: 2013-05-06 11:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6feee75b0a8b 8012664: Add tests for java.util.stream and lambda translation Reviewed-by: mduigou, briangoetz Contributed-by: Brian Goetz , Paul Sandoz , Mike Duigou , Robert Field , Jim Gish ! test/Makefile + test/java/util/concurrent/atomic/AtomicReferenceTest.java + test/java/util/stream/bootlib/TEST.properties + test/java/util/stream/bootlib/java/util/stream/CollectorOps.java + test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java + test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java + test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/OpTestCase.java + test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java + test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java + test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java + test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/TestData.java + test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java + test/java/util/stream/boottest/TEST.properties + test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java + test/java/util/stream/boottest/java/util/stream/FlagOpTest.java + test/java/util/stream/boottest/java/util/stream/IntNodeTest.java + test/java/util/stream/boottest/java/util/stream/LongNodeTest.java + test/java/util/stream/boottest/java/util/stream/NodeBuilderTest.java + test/java/util/stream/boottest/java/util/stream/NodeTest.java + test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java + test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java + test/java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java + test/java/util/stream/boottest/java/util/stream/StreamReuseTest.java + test/java/util/stream/boottest/java/util/stream/UnorderedTest.java + test/java/util/stream/test/TEST.properties + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FilterOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindAnyOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntReduceTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveAverageOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamParSeqTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/TeeOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java + test/jdk/lambda/ArrayCtorRefTest.java + test/jdk/lambda/FDTest.java + test/jdk/lambda/LambdaTranslationCompoundSamTest.java + test/jdk/lambda/LambdaTranslationInInterface.java + test/jdk/lambda/LambdaTranslationInnerConstructor.java + test/jdk/lambda/LambdaTranslationTest1.java + test/jdk/lambda/LambdaTranslationTest2.java + test/jdk/lambda/MethodReferenceTestFDCCE.java + test/jdk/lambda/MethodReferenceTestInnerDefault.java + test/jdk/lambda/MethodReferenceTestInnerInstance.java + test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java + test/jdk/lambda/MethodReferenceTestInstance.java + test/jdk/lambda/MethodReferenceTestInstanceMethod.java + test/jdk/lambda/MethodReferenceTestKinds.java + test/jdk/lambda/MethodReferenceTestNew.java + test/jdk/lambda/MethodReferenceTestNewInner.java + test/jdk/lambda/MethodReferenceTestSueCase1.java + test/jdk/lambda/MethodReferenceTestSueCase2.java + test/jdk/lambda/MethodReferenceTestSueCase4.java + test/jdk/lambda/MethodReferenceTestSuper.java + test/jdk/lambda/MethodReferenceTestSuperDefault.java + test/jdk/lambda/MethodReferenceTestTypeConversion.java + test/jdk/lambda/MethodReferenceTestVarArgs.java + test/jdk/lambda/MethodReferenceTestVarArgsExt.java + test/jdk/lambda/MethodReferenceTestVarArgsSuper.java + test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java + test/jdk/lambda/MethodReferenceTestVarArgsThis.java + test/jdk/lambda/TEST.properties + test/jdk/lambda/TestInnerCtorRef.java + test/jdk/lambda/TestPrivateCtorRef.java + test/jdk/lambda/separate/AttributeInjector.java + test/jdk/lambda/separate/ClassFile.java + test/jdk/lambda/separate/ClassFilePreprocessor.java + test/jdk/lambda/separate/ClassToInterfaceConverter.java + test/jdk/lambda/separate/Compiler.java + test/jdk/lambda/separate/DirectedClassLoader.java + test/jdk/lambda/separate/SourceModel.java + test/jdk/lambda/separate/TestHarness.java + test/jdk/lambda/shapegen/ClassCase.java + test/jdk/lambda/shapegen/Hierarchy.java + test/jdk/lambda/shapegen/HierarchyGenerator.java + test/jdk/lambda/shapegen/Rule.java + test/jdk/lambda/shapegen/RuleGroup.java + test/jdk/lambda/shapegen/TTNode.java + test/jdk/lambda/shapegen/TTParser.java + test/jdk/lambda/shapegen/TTShape.java + test/jdk/lambda/vm/DefaultMethodRegressionTests.java + test/jdk/lambda/vm/DefaultMethodsTest.java + test/jdk/lambda/vm/InterfaceAccessFlagsTest.java + test/jdk/lambda/vm/StrictfpDefault.java From weijun.wang at oracle.com Tue May 7 17:26:14 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 08 May 2013 00:26:14 +0000 Subject: hg: jdk8/tl/jdk: 8012679: Let allow_weak_crypto default to false Message-ID: <20130508002627.168F2488BB@hg.openjdk.java.net> Changeset: 7d89b0dd973c Author: weijun Date: 2013-05-08 08:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d89b0dd973c 8012679: Let allow_weak_crypto default to false Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/etype/WeakCrypto.java From michael.x.mcmahon at oracle.com Wed May 8 02:35:36 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 08 May 2013 10:35:36 +0100 Subject: RFR JDK7188517 In-Reply-To: <51890511.9090305@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> <51890511.9090305@oracle.com> Message-ID: <518A1C68.4000203@oracle.com> On 07/05/13 14:43, Chris Hegarty wrote: > On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >> This looks okay to me. > > Source changes look fine to me too. Probably best to add a test for '$' > > In fact, Michael actually removed such a test [1] during another > change. We should get positive agreement from Michael before pushing > this. > Yes, that was a positive test for for a cookie whose name began with '$'. I agree we should add a negative test now for a similar cookie. Source changes look fine to me too. Michael > -Chris. > > [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 > >> >> - Kurchi >> >> >> On 5/2/2013 10:09 AM, John Zavgren wrote: >>> All: >>> My original email was mangled by my email program (stbeehive/zimbra) >>> ... so I'm sending a second correctly formatted copy. >>> >>> I'm sorry for the inconvenience. >>> >>> John >>> --------------- >>> >>> Please consider the following change to the cookie constructor: >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>> >>> >>> Basically there are two issues: >>> >>> 1.) the existing cookie constructor was allowing cookie names to have >>> a dollar sign as their leading character, >>> which is "illegal". The constructor code was modified to disallow >>> these illegal names. >>> >>> 2.) the API document (notice the specdiff: >>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>> ) prohibited >>> the use of cookie names that are one of the tokens reserved for use by >>> the cookie protocol, and this restriction is not necessary. >>> >>> Thanks! >>> John Zavgren >>> >>> >>> ----- Original Message ----- >>> From: john.zavgren at oracle.com >>> To: net-dev at openjdk.java.net >>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern >>> Subject: RFR JDK7188517 >>> >>> Greetings: Please consider the following change to the cookie >>> constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>> Basically there are two issues: 1.) the existing cookie constructor >>> was allowing cookie names to have a dollar sign as their leading >>> character, which is "illegal". The constructor code was modified to >>> disallow these illegal names. 2.) the API document (notice the >>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>> prohibited the use of cookie names that are one of the tokens reserved >>> for use by the cookie protocol, and this restriction is not necessary. >>> Thanks! John Zavgren >> >> -- >> -Kurchi >> From chris.hegarty at oracle.com Wed May 8 01:50:51 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 08 May 2013 09:50:51 +0100 Subject: RFR JDK7188517 In-Reply-To: <518A1C68.4000203@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> <51890511.9090305@oracle.com> <518A1C68.4000203@oracle.com> Message-ID: <518A11EB.8030301@oracle.com> On 08/05/2013 10:35, Michael McMahon wrote: > On 07/05/13 14:43, Chris Hegarty wrote: >> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>> This looks okay to me. >> >> Source changes look fine to me too. Probably best to add a test for '$' >> >> In fact, Michael actually removed such a test [1] during another >> change. We should get positive agreement from Michael before pushing >> this. >> > > Yes, that was a positive test for for a cookie whose name began with '$'. > I agree we should add a negative test now for a similar cookie. > > Source changes look fine to me too. Thanks Michael, In which case, I believe the check that a cookie the name '$Customer' throws IAE can be re-instated in TestHttpCookie.java -Chris. > > Michael > >> -Chris. >> >> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >> >>> >>> - Kurchi >>> >>> >>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>> All: >>>> My original email was mangled by my email program (stbeehive/zimbra) >>>> ... so I'm sending a second correctly formatted copy. >>>> >>>> I'm sorry for the inconvenience. >>>> >>>> John >>>> --------------- >>>> >>>> Please consider the following change to the cookie constructor: >>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>> >>>> >>>> Basically there are two issues: >>>> >>>> 1.) the existing cookie constructor was allowing cookie names to have >>>> a dollar sign as their leading character, >>>> which is "illegal". The constructor code was modified to disallow >>>> these illegal names. >>>> >>>> 2.) the API document (notice the specdiff: >>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>> ) prohibited >>>> the use of cookie names that are one of the tokens reserved for use by >>>> the cookie protocol, and this restriction is not necessary. >>>> >>>> Thanks! >>>> John Zavgren >>>> >>>> >>>> ----- Original Message ----- >>>> From: john.zavgren at oracle.com >>>> To: net-dev at openjdk.java.net >>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern >>>> Subject: RFR JDK7188517 >>>> >>>> Greetings: Please consider the following change to the cookie >>>> constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>> Basically there are two issues: 1.) the existing cookie constructor >>>> was allowing cookie names to have a dollar sign as their leading >>>> character, which is "illegal". The constructor code was modified to >>>> disallow these illegal names. 2.) the API document (notice the >>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>> prohibited the use of cookie names that are one of the tokens reserved >>>> for use by the cookie protocol, and this restriction is not necessary. >>>> Thanks! John Zavgren >>> >>> -- >>> -Kurchi >>> > From michael.x.mcmahon at oracle.com Wed May 8 05:33:00 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 08 May 2013 13:33:00 +0100 Subject: RFR JDK7188517 In-Reply-To: <518A11EB.8030301@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> <51890511.9090305@oracle.com> <518A1C68.4000203@oracle.com> <518A11EB.8030301@oracle.com> Message-ID: <518A45FC.7040707@oracle.com> On 08/05/13 09:50, Chris Hegarty wrote: > On 08/05/2013 10:35, Michael McMahon wrote: >> On 07/05/13 14:43, Chris Hegarty wrote: >>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>> This looks okay to me. >>> >>> Source changes look fine to me too. Probably best to add a test for '$' >>> >>> In fact, Michael actually removed such a test [1] during another >>> change. We should get positive agreement from Michael before pushing >>> this. >>> >> >> Yes, that was a positive test for for a cookie whose name began with >> '$'. >> I agree we should add a negative test now for a similar cookie. >> >> Source changes look fine to me too. > > Thanks Michael, > > In which case, I believe the check that a cookie the name '$Customer' > throws IAE can be re-instated in TestHttpCookie.java > Right. I didn't realise the test was able to handle the IAE. I see now that it does and it should be possible to put the same test back. Michael > -Chris. > >> >> Michael >> >>> -Chris. >>> >>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>> >>>> >>>> - Kurchi >>>> >>>> >>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>> All: >>>>> My original email was mangled by my email program (stbeehive/zimbra) >>>>> ... so I'm sending a second correctly formatted copy. >>>>> >>>>> I'm sorry for the inconvenience. >>>>> >>>>> John >>>>> --------------- >>>>> >>>>> Please consider the following change to the cookie constructor: >>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>> >>>>> >>>>> Basically there are two issues: >>>>> >>>>> 1.) the existing cookie constructor was allowing cookie names to have >>>>> a dollar sign as their leading character, >>>>> which is "illegal". The constructor code was modified to disallow >>>>> these illegal names. >>>>> >>>>> 2.) the API document (notice the specdiff: >>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>> ) >>>>> prohibited >>>>> the use of cookie names that are one of the tokens reserved for >>>>> use by >>>>> the cookie protocol, and this restriction is not necessary. >>>>> >>>>> Thanks! >>>>> John Zavgren >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: john.zavgren at oracle.com >>>>> To: net-dev at openjdk.java.net >>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern >>>>> Subject: RFR JDK7188517 >>>>> >>>>> Greetings: Please consider the following change to the cookie >>>>> constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>> was allowing cookie names to have a dollar sign as their leading >>>>> character, which is "illegal". The constructor code was modified to >>>>> disallow these illegal names. 2.) the API document (notice the >>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>> prohibited the use of cookie names that are one of the tokens >>>>> reserved >>>>> for use by the cookie protocol, and this restriction is not >>>>> necessary. >>>>> Thanks! John Zavgren >>>> >>>> -- >>>> -Kurchi >>>> >> From alan.bateman at oracle.com Wed May 8 10:03:43 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 May 2013 17:03:43 +0000 Subject: hg: jdk8/tl/jdk: 8013652: (profiles) Add javax.script to compact1 Message-ID: <20130508170355.73850488E2@hg.openjdk.java.net> Changeset: c8f47674d105 Author: alanb Date: 2013-05-08 18:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8f47674d105 8013652: (profiles) Add javax.script to compact1 Reviewed-by: mchung, dholmes ! makefiles/profile-rtjar-includes.txt From john.zavgren at oracle.com Wed May 8 12:10:25 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Wed, 08 May 2013 15:10:25 -0400 Subject: RFR JDK7188517 In-Reply-To: <518A45FC.7040707@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> <51890511.9090305@oracle.com> <518A1C68.4000203@oracle.com> <518A11EB.8030301@oracle.com> <518A45FC.7040707@oracle.com> Message-ID: <518AA321.5040900@oracle.com> Greetings: I added a test for the leading dollar sign character in cookie names: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ Thanks! John On 05/08/2013 08:33 AM, Michael McMahon wrote: > On 08/05/13 09:50, Chris Hegarty wrote: >> On 08/05/2013 10:35, Michael McMahon wrote: >>> On 07/05/13 14:43, Chris Hegarty wrote: >>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>> This looks okay to me. >>>> >>>> Source changes look fine to me too. Probably best to add a test for >>>> '$' >>>> >>>> In fact, Michael actually removed such a test [1] during another >>>> change. We should get positive agreement from Michael before pushing >>>> this. >>>> >>> >>> Yes, that was a positive test for for a cookie whose name began with >>> '$'. >>> I agree we should add a negative test now for a similar cookie. >>> >>> Source changes look fine to me too. >> >> Thanks Michael, >> >> In which case, I believe the check that a cookie the name '$Customer' >> throws IAE can be re-instated in TestHttpCookie.java >> > > Right. I didn't realise the test was able to handle the IAE. I see now > that it does and it should > be possible to put the same test back. > > Michael >> -Chris. >> >>> >>> Michael >>> >>>> -Chris. >>>> >>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>> >>>>> >>>>> - Kurchi >>>>> >>>>> >>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>> All: >>>>>> My original email was mangled by my email program (stbeehive/zimbra) >>>>>> ... so I'm sending a second correctly formatted copy. >>>>>> >>>>>> I'm sorry for the inconvenience. >>>>>> >>>>>> John >>>>>> --------------- >>>>>> >>>>>> Please consider the following change to the cookie constructor: >>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>> >>>>>> >>>>>> Basically there are two issues: >>>>>> >>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>> have >>>>>> a dollar sign as their leading character, >>>>>> which is "illegal". The constructor code was modified to disallow >>>>>> these illegal names. >>>>>> >>>>>> 2.) the API document (notice the specdiff: >>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>> ) >>>>>> prohibited >>>>>> the use of cookie names that are one of the tokens reserved for >>>>>> use by >>>>>> the cookie protocol, and this restriction is not necessary. >>>>>> >>>>>> Thanks! >>>>>> John Zavgren >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: john.zavgren at oracle.com >>>>>> To: net-dev at openjdk.java.net >>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada Eastern >>>>>> Subject: RFR JDK7188517 >>>>>> >>>>>> Greetings: Please consider the following change to the cookie >>>>>> constructor: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>> character, which is "illegal". The constructor code was modified to >>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>> prohibited the use of cookie names that are one of the tokens >>>>>> reserved >>>>>> for use by the cookie protocol, and this restriction is not >>>>>> necessary. >>>>>> Thanks! John Zavgren >>>>> >>>>> -- >>>>> -Kurchi >>>>> >>> > -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From kurchi.subhra.hazra at oracle.com Wed May 8 13:02:50 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 08 May 2013 13:02:50 -0700 Subject: RFR JDK7188517 In-Reply-To: <518AA321.5040900@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> <51890511.9090305@oracle.com> <518A1C68.4000203@oracle.com> <518A11EB.8030301@oracle.com> <518A45FC.7040707@oracle.com> <518AA321.5040900@oracle.com> Message-ID: <518AAF6A.7040205@oracle.com> I would have thrown an exception if the IllegalArgumentException is not obtained, otherwise the test looses its purpose, and will pass silently if someone mistakenly removes the $ check in our code. - Kurchi On 5/8/2013 12:10 PM, John Zavgren wrote: > Greetings: > > I added a test for the leading dollar sign character in cookie names: > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ > > Thanks! > John > > > On 05/08/2013 08:33 AM, Michael McMahon wrote: >> On 08/05/13 09:50, Chris Hegarty wrote: >>> On 08/05/2013 10:35, Michael McMahon wrote: >>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>> This looks okay to me. >>>>> >>>>> Source changes look fine to me too. Probably best to add a test >>>>> for '$' >>>>> >>>>> In fact, Michael actually removed such a test [1] during another >>>>> change. We should get positive agreement from Michael before pushing >>>>> this. >>>>> >>>> >>>> Yes, that was a positive test for for a cookie whose name began >>>> with '$'. >>>> I agree we should add a negative test now for a similar cookie. >>>> >>>> Source changes look fine to me too. >>> >>> Thanks Michael, >>> >>> In which case, I believe the check that a cookie the name >>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>> >> >> Right. I didn't realise the test was able to handle the IAE. I see >> now that it does and it should >> be possible to put the same test back. >> >> Michael >>> -Chris. >>> >>>> >>>> Michael >>>> >>>>> -Chris. >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>> >>>>>> >>>>>> - Kurchi >>>>>> >>>>>> >>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>> All: >>>>>>> My original email was mangled by my email program >>>>>>> (stbeehive/zimbra) >>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>> >>>>>>> I'm sorry for the inconvenience. >>>>>>> >>>>>>> John >>>>>>> --------------- >>>>>>> >>>>>>> Please consider the following change to the cookie constructor: >>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>> >>>>>>> >>>>>>> Basically there are two issues: >>>>>>> >>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>> have >>>>>>> a dollar sign as their leading character, >>>>>>> which is "illegal". The constructor code was modified to disallow >>>>>>> these illegal names. >>>>>>> >>>>>>> 2.) the API document (notice the specdiff: >>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>> ) >>>>>>> prohibited >>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>> use by >>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>> >>>>>>> Thanks! >>>>>>> John Zavgren >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: john.zavgren at oracle.com >>>>>>> To: net-dev at openjdk.java.net >>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>> Eastern >>>>>>> Subject: RFR JDK7188517 >>>>>>> >>>>>>> Greetings: Please consider the following change to the cookie >>>>>>> constructor: >>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>> character, which is "illegal". The constructor code was modified to >>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>> reserved >>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>> necessary. >>>>>>> Thanks! John Zavgren >>>>>> >>>>>> -- >>>>>> -Kurchi >>>>>> >>>> >> > > -- -Kurchi From kurchi.subhra.hazra at oracle.com Wed May 8 16:06:10 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 08 May 2013 16:06:10 -0700 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <5181AD5B.40703@oracle.com> References: <5181AD5B.40703@oracle.com> Message-ID: <518ADA62.30808@oracle.com> Hi, com.sun.net.httpServer uses a selector to get notified about interesting events (such as arrival of a new connection, or data available to read on an existing connection when using keep-alive), but imposes a timeout of 1000 ms on the select() operation. Although this is not a problem when the server uses a ThreadPool with more than one thread, but for a single threaded server, this timeout gives rise to a bottleneck and should be reduced to a lower value. I have proposed 200 ms for the timeout here, but if anyone has preference for a greater or lower value, I am open to that too. Bug:http://bugs.sun.com/view_bug.do?bug_id=8014254 (To appear) Webrev:http://cr.openjdk.java.net/~khazra/8014254/webrev.00/ Thanks, - Kurchi From mhall at mhcomputing.net Wed May 8 16:35:08 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Wed, 8 May 2013 16:35:08 -0700 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <518ADA62.30808@oracle.com> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> Message-ID: <20130508233508.GA20009@mhcomputing.net> On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: > com.sun.net.httpServer uses a selector to get notified about interesting > events (such as arrival of a new connection, or data available to read > on an existing connection when using keep-alive), but imposes a timeout of > 1000 ms on the select() operation. Maybe I'm missing something since the bug is not viewable to the community, but, if I'm reading properly, this design by itself is not quite right, and the fix of 200 msec selector timeout is just a band-aid solution. Shouldn't it be registering interestOps for reading on the existing connections and accepting connections from the server socket in the selector? Otherwise why use any selector in the first place if it's not really selecting across all the right sockets and right events on them? Regards, Matthew. From kurchi.subhra.hazra at oracle.com Wed May 8 17:56:16 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 08 May 2013 17:56:16 -0700 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <20130508233508.GA20009@mhcomputing.net> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> <20130508233508.GA20009@mhcomputing.net> Message-ID: <518AF430.9080601@oracle.com> On 5/8/2013 4:35 PM, Matthew Hall wrote: > On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: >> com.sun.net.httpServer uses a selector to get notified about interesting >> events (such as arrival of a new connection, or data available to read >> on an existing connection when using keep-alive), but imposes a timeout of >> 1000 ms on the select() operation. > Maybe I'm missing something since the bug is not viewable to the community, > but, if I'm reading properly, this design by itself is not quite right, and > the fix of 200 msec selector timeout is just a band-aid solution. > > Shouldn't it be registering interestOps for reading on the existing > connections and accepting connections from the server socket in the selector? > Otherwise why use any selector in the first place if it's not really selecting > across all the right sockets and right events on them? - If you look at the implementation, this is exactly what is done. However, for keep-alive, the implementation delays the re-registering of a used channel for reading until after one select call, which results in the bottleneck. The other option is to re-register existing channels before the select call, this is what was done in jdk6. But I would need to understand why we walked away from that. Michael or Chris can shed some light on this. Thanks, - Kurchi From mike.duigou at oracle.com Wed May 8 21:43:23 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 09 May 2013 04:43:23 +0000 Subject: hg: jdk8/tl: 8014269: Add missing .PHONY targets to Main.gmk Message-ID: <20130509044323.7ECAC4891F@hg.openjdk.java.net> Changeset: e2eb6bc06621 Author: mduigou Date: 2013-05-08 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e2eb6bc06621 8014269: Add missing .PHONY targets to Main.gmk Reviewed-by: mchung, tbell ! common/makefiles/Main.gmk From Alan.Bateman at oracle.com Thu May 9 01:32:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 May 2013 09:32:05 +0100 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <518ADA62.30808@oracle.com> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> Message-ID: <518B5F05.7040101@oracle.com> On 09/05/2013 00:06, Kurchi Hazra wrote: > > > Hi, > > com.sun.net.httpServer uses a selector to get notified about > interesting > events (such as arrival of a new connection, or data available to read > on an existing connection when using keep-alive), but imposes a > timeout of > 1000 ms on the select() operation. Although this is not a problem when > the server uses a > ThreadPool with more than one thread, but for a single threaded > server, this timeout > gives rise to a bottleneck and should be reduced to a lower value. > > I have proposed 200 ms for the timeout here, but if anyone has > preference for a greater > or lower value, I am open to that too. > > Bug:http://bugs.sun.com/view_bug.do?bug_id=8014254 (To appear) > Webrev:http://cr.openjdk.java.net/~khazra/8014254/webrev.00/ > > Thanks, > - Kurchi > There's something fishy here. So are there are non I/O events queued up that will not be serviced more quickly? Shouldn't adding events cause the Selector to wakeup so that it doesn't matter what the timeout value is. -Alan. From chris.hegarty at oracle.com Thu May 9 01:39:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 May 2013 09:39:23 +0100 Subject: RFR JDK7188517 In-Reply-To: <518AAF6A.7040205@oracle.com> References: <5345a8e5-f5e7-4c6e-b8e8-ae78842958f0@default> <51882093.6030700@oracle.com> <51890511.9090305@oracle.com> <518A1C68.4000203@oracle.com> <518A11EB.8030301@oracle.com> <518A45FC.7040707@oracle.com> <518AA321.5040900@oracle.com> <518AAF6A.7040205@oracle.com> Message-ID: <518B60BB.2070605@oracle.com> John, I think you can simply reinstate http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java -Chris. On 05/08/2013 09:02 PM, Kurchi Hazra wrote: > I would have thrown an exception if the IllegalArgumentException is not > obtained, otherwise the test looses its > purpose, and will pass silently if someone mistakenly removes the $ > check in our code. > > - Kurchi > > On 5/8/2013 12:10 PM, John Zavgren wrote: >> Greetings: >> >> I added a test for the leading dollar sign character in cookie names: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >> >> Thanks! >> John >> >> >> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>> On 08/05/13 09:50, Chris Hegarty wrote: >>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>> This looks okay to me. >>>>>> >>>>>> Source changes look fine to me too. Probably best to add a test >>>>>> for '$' >>>>>> >>>>>> In fact, Michael actually removed such a test [1] during another >>>>>> change. We should get positive agreement from Michael before pushing >>>>>> this. >>>>>> >>>>> >>>>> Yes, that was a positive test for for a cookie whose name began >>>>> with '$'. >>>>> I agree we should add a negative test now for a similar cookie. >>>>> >>>>> Source changes look fine to me too. >>>> >>>> Thanks Michael, >>>> >>>> In which case, I believe the check that a cookie the name >>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>> >>> >>> Right. I didn't realise the test was able to handle the IAE. I see >>> now that it does and it should >>> be possible to put the same test back. >>> >>> Michael >>>> -Chris. >>>> >>>>> >>>>> Michael >>>>> >>>>>> -Chris. >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>> >>>>>>> >>>>>>> - Kurchi >>>>>>> >>>>>>> >>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>> All: >>>>>>>> My original email was mangled by my email program >>>>>>>> (stbeehive/zimbra) >>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>> >>>>>>>> I'm sorry for the inconvenience. >>>>>>>> >>>>>>>> John >>>>>>>> --------------- >>>>>>>> >>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> Basically there are two issues: >>>>>>>> >>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>> have >>>>>>>> a dollar sign as their leading character, >>>>>>>> which is "illegal". The constructor code was modified to disallow >>>>>>>> these illegal names. >>>>>>>> >>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>> ) >>>>>>>> prohibited >>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>> use by >>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> John Zavgren >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: john.zavgren at oracle.com >>>>>>>> To: net-dev at openjdk.java.net >>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>> Eastern >>>>>>>> Subject: RFR JDK7188517 >>>>>>>> >>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>> constructor: >>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>> character, which is "illegal". The constructor code was modified to >>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>> reserved >>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>> necessary. >>>>>>>> Thanks! John Zavgren >>>>>>> >>>>>>> -- >>>>>>> -Kurchi >>>>>>> >>>>> >>> >> >> > From chris.hegarty at oracle.com Thu May 9 01:45:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 May 2013 09:45:02 +0100 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <518AF430.9080601@oracle.com> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> <20130508233508.GA20009@mhcomputing.net> <518AF430.9080601@oracle.com> Message-ID: <518B620E.1070804@oracle.com> On 05/09/2013 01:56 AM, Kurchi Hazra wrote: > > On 5/8/2013 4:35 PM, Matthew Hall wrote: >> On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: >>> com.sun.net.httpServer uses a selector to get notified about interesting >>> events (such as arrival of a new connection, or data available to read >>> on an existing connection when using keep-alive), but imposes a >>> timeout of >>> 1000 ms on the select() operation. >> Maybe I'm missing something since the bug is not viewable to the >> community, >> but, if I'm reading properly, this design by itself is not quite >> right, and >> the fix of 200 msec selector timeout is just a band-aid solution. >> >> Shouldn't it be registering interestOps for reading on the existing >> connections and accepting connections from the server socket in the >> selector? >> Otherwise why use any selector in the first place if it's not really >> selecting >> across all the right sockets and right events on them? > > - If you look at the implementation, this is exactly what is done. > However, for keep-alive, the implementation delays the re-registering of > a used channel > for reading until after one select call, which results in the > bottleneck. The other option is to re-register existing channels before > the select call, this is what > was done in jdk6. But I would need to understand why we walked away from > that. Michael or Chris can shed some light on this. I'm not sure why this changed from jdk6, but I don't see any reason it cannot be reverted back. -Chris. > > > > Thanks, > - Kurchi From kurchi.subhra.hazra at oracle.com Thu May 9 07:25:38 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Thu, 09 May 2013 07:25:38 -0700 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <518B5F05.7040101@oracle.com> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> <518B5F05.7040101@oracle.com> Message-ID: <518BB1E2.7060805@oracle.com> >> > There's something fishy here. So are there are non I/O events queued > up that will not be serviced more quickly? Shouldn't adding events > cause the Selector to wakeup so that it doesn't matter what the > timeout value is. - This doesn't quite work if we have a single thread doing everything. (which is why this bug is a non-issue when the user has set a ThreadPool of size > 1 to be used by the server). - Kurchi From john.zavgren at oracle.com Thu May 9 07:42:40 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Thu, 9 May 2013 07:42:40 -0700 (PDT) Subject: RFR JDK7188517 Message-ID: <9be13b07-e48d-492a-b780-b5a6ab0af215@default> Chris, et alia: I put the reinstated the old test. http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ John ----- Original Message ----- From: chris.hegarty at oracle.com To: john.zavgren at oracle.com Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK7188517 John, I think you can simply reinstate http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java -Chris. On 05/08/2013 09:02 PM, Kurchi Hazra wrote: > I would have thrown an exception if the IllegalArgumentException is not > obtained, otherwise the test looses its > purpose, and will pass silently if someone mistakenly removes the $ > check in our code. > > - Kurchi > > On 5/8/2013 12:10 PM, John Zavgren wrote: >> Greetings: >> >> I added a test for the leading dollar sign character in cookie names: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >> >> Thanks! >> John >> >> >> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>> On 08/05/13 09:50, Chris Hegarty wrote: >>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>> This looks okay to me. >>>>>> >>>>>> Source changes look fine to me too. Probably best to add a test >>>>>> for '$' >>>>>> >>>>>> In fact, Michael actually removed such a test [1] during another >>>>>> change. We should get positive agreement from Michael before pushing >>>>>> this. >>>>>> >>>>> >>>>> Yes, that was a positive test for for a cookie whose name began >>>>> with '$'. >>>>> I agree we should add a negative test now for a similar cookie. >>>>> >>>>> Source changes look fine to me too. >>>> >>>> Thanks Michael, >>>> >>>> In which case, I believe the check that a cookie the name >>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>> >>> >>> Right. I didn't realise the test was able to handle the IAE. I see >>> now that it does and it should >>> be possible to put the same test back. >>> >>> Michael >>>> -Chris. >>>> >>>>> >>>>> Michael >>>>> >>>>>> -Chris. >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>> >>>>>>> >>>>>>> - Kurchi >>>>>>> >>>>>>> >>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>> All: >>>>>>>> My original email was mangled by my email program >>>>>>>> (stbeehive/zimbra) >>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>> >>>>>>>> I'm sorry for the inconvenience. >>>>>>>> >>>>>>>> John >>>>>>>> --------------- >>>>>>>> >>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> Basically there are two issues: >>>>>>>> >>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>> have >>>>>>>> a dollar sign as their leading character, >>>>>>>> which is "illegal". The constructor code was modified to disallow >>>>>>>> these illegal names. >>>>>>>> >>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>> ) >>>>>>>> prohibited >>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>> use by >>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> John Zavgren >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: john.zavgren at oracle.com >>>>>>>> To: net-dev at openjdk.java.net >>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>> Eastern >>>>>>>> Subject: RFR JDK7188517 >>>>>>>> >>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>> constructor: >>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>> character, which is "illegal". The constructor code was modified to >>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>> reserved >>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>> necessary. >>>>>>>> Thanks! John Zavgren >>>>>>> >>>>>>> -- >>>>>>> -Kurchi >>>>>>> >>>>> >>> >> >> > From chris.hegarty at oracle.com Thu May 9 08:09:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 May 2013 16:09:39 +0100 Subject: RFR JDK7188517 In-Reply-To: <9be13b07-e48d-492a-b780-b5a6ab0af215@default> References: <9be13b07-e48d-492a-b780-b5a6ab0af215@default> Message-ID: <518BBC33.1040807@oracle.com> Looks ok to me. -Chris. On 05/09/2013 03:42 PM, John Zavgren wrote: > Chris, et alia: > I put the reinstated the old test. > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ > > John > > ----- Original Message ----- > From: chris.hegarty at oracle.com > To: john.zavgren at oracle.com > Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net > Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR JDK7188517 > > John, > > I think you can simply reinstate > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java > > -Chris. > > On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >> I would have thrown an exception if the IllegalArgumentException is not >> obtained, otherwise the test looses its >> purpose, and will pass silently if someone mistakenly removes the $ >> check in our code. >> >> - Kurchi >> >> On 5/8/2013 12:10 PM, John Zavgren wrote: >>> Greetings: >>> >>> I added a test for the leading dollar sign character in cookie names: >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>> >>> Thanks! >>> John >>> >>> >>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>> This looks okay to me. >>>>>>> >>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>> for '$' >>>>>>> >>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>> change. We should get positive agreement from Michael before pushing >>>>>>> this. >>>>>>> >>>>>> >>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>> with '$'. >>>>>> I agree we should add a negative test now for a similar cookie. >>>>>> >>>>>> Source changes look fine to me too. >>>>> >>>>> Thanks Michael, >>>>> >>>>> In which case, I believe the check that a cookie the name >>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>> >>>> >>>> Right. I didn't realise the test was able to handle the IAE. I see >>>> now that it does and it should >>>> be possible to put the same test back. >>>> >>>> Michael >>>>> -Chris. >>>>> >>>>>> >>>>>> Michael >>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>> >>>>>>>> >>>>>>>> - Kurchi >>>>>>>> >>>>>>>> >>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>> All: >>>>>>>>> My original email was mangled by my email program >>>>>>>>> (stbeehive/zimbra) >>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>> >>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>> >>>>>>>>> John >>>>>>>>> --------------- >>>>>>>>> >>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Basically there are two issues: >>>>>>>>> >>>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>>> have >>>>>>>>> a dollar sign as their leading character, >>>>>>>>> which is "illegal". The constructor code was modified to disallow >>>>>>>>> these illegal names. >>>>>>>>> >>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>> ) >>>>>>>>> prohibited >>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>> use by >>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> John Zavgren >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>> Eastern >>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>> >>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>> constructor: >>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>>> character, which is "illegal". The constructor code was modified to >>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>> reserved >>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>> necessary. >>>>>>>>> Thanks! John Zavgren >>>>>>>> >>>>>>>> -- >>>>>>>> -Kurchi >>>>>>>> >>>>>> >>>> >>> >>> >> From kumar.x.srinivasan at oracle.com Thu May 9 08:10:16 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 09 May 2013 15:10:16 +0000 Subject: hg: jdk8/tl/jdk: 8013736: [launcher] cleanup code for correctness; ... Message-ID: <20130509151028.762904892B@hg.openjdk.java.net> Changeset: 3fd83f282c61 Author: ksrini Date: 2013-05-07 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fd83f282c61 8013736: [launcher] cleanup code for correctness 8005735: [parfait] False positive integer overflow in jdk/src/solaris/bin/jexec.c 8009873: [parfait] Memory leak at jdk/src/share/bin/wildcard.c 8005807: [parfait] Undefined return value at jdk/src/share/bin/java.c Reviewed-by: alanb, martin ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/wildcard.c ! src/solaris/bin/jexec.c From kurchi.subhra.hazra at oracle.com Thu May 9 10:39:35 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 09 May 2013 10:39:35 -0700 Subject: RFR JDK7188517 In-Reply-To: <518BBC33.1040807@oracle.com> References: <9be13b07-e48d-492a-b780-b5a6ab0af215@default> <518BBC33.1040807@oracle.com> Message-ID: <518BDF57.3050008@oracle.com> I am guessing you meant to send http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ which looks ok to me. - Kurchi On 5/9/2013 8:09 AM, Chris Hegarty wrote: > Looks ok to me. > > -Chris. > > On 05/09/2013 03:42 PM, John Zavgren wrote: >> Chris, et alia: >> I put the reinstated the old test. >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >> >> John >> >> ----- Original Message ----- >> From: chris.hegarty at oracle.com >> To: john.zavgren at oracle.com >> Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net >> Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern >> Subject: Re: RFR JDK7188517 >> >> John, >> >> I think you can simply reinstate >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java >> >> >> -Chris. >> >> On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >>> I would have thrown an exception if the IllegalArgumentException is not >>> obtained, otherwise the test looses its >>> purpose, and will pass silently if someone mistakenly removes the $ >>> check in our code. >>> >>> - Kurchi >>> >>> On 5/8/2013 12:10 PM, John Zavgren wrote: >>>> Greetings: >>>> >>>> I added a test for the leading dollar sign character in cookie names: >>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>> >>>> Thanks! >>>> John >>>> >>>> >>>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>>> This looks okay to me. >>>>>>>> >>>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>>> for '$' >>>>>>>> >>>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>>> change. We should get positive agreement from Michael before >>>>>>>> pushing >>>>>>>> this. >>>>>>>> >>>>>>> >>>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>>> with '$'. >>>>>>> I agree we should add a negative test now for a similar cookie. >>>>>>> >>>>>>> Source changes look fine to me too. >>>>>> >>>>>> Thanks Michael, >>>>>> >>>>>> In which case, I believe the check that a cookie the name >>>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>>> >>>>> >>>>> Right. I didn't realise the test was able to handle the IAE. I see >>>>> now that it does and it should >>>>> be possible to put the same test back. >>>>> >>>>> Michael >>>>>> -Chris. >>>>>> >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>>> >>>>>>>>> >>>>>>>>> - Kurchi >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>>> All: >>>>>>>>>> My original email was mangled by my email program >>>>>>>>>> (stbeehive/zimbra) >>>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>>> >>>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> --------------- >>>>>>>>>> >>>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Basically there are two issues: >>>>>>>>>> >>>>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>>>> have >>>>>>>>>> a dollar sign as their leading character, >>>>>>>>>> which is "illegal". The constructor code was modified to >>>>>>>>>> disallow >>>>>>>>>> these illegal names. >>>>>>>>>> >>>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>>> ) >>>>>>>>>> prohibited >>>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>>> use by >>>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> John Zavgren >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>>> Eastern >>>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>>> >>>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>>> constructor: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>> Basically there are two issues: 1.) the existing cookie >>>>>>>>>> constructor >>>>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>>>> character, which is "illegal". The constructor code was >>>>>>>>>> modified to >>>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>>> specdiff: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>>> reserved >>>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>>> necessary. >>>>>>>>>> Thanks! John Zavgren >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -Kurchi >>>>>>>>> >>>>>>> >>>>> >>>> >>>> >>> -- -Kurchi From john.zavgren at oracle.com Thu May 9 11:22:14 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Thu, 9 May 2013 11:22:14 -0700 (PDT) Subject: RFR JDK7188517 Message-ID: Greetings: I made a mistake in my last RFR posting... the URL for the latest modifications is: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ instead of: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ The most recent change is to reinstate the original test that tested for cookie names that lead with a dollar sign. I'm sorry about the confusion. Thanks! John On 05/09/2013 03:42 PM, John Zavgren wrote: > Chris, et alia: > I put the reinstated the old test. > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ > > John > > ----- Original Message ----- > From: chris.hegarty at oracle.com > To: john.zavgren at oracle.com > Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net > Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR JDK7188517 > > John, > > I think you can simply reinstate > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java > > -Chris. > > On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >> I would have thrown an exception if the IllegalArgumentException is not >> obtained, otherwise the test looses its >> purpose, and will pass silently if someone mistakenly removes the $ >> check in our code. >> >> - Kurchi >> >> On 5/8/2013 12:10 PM, John Zavgren wrote: >>> Greetings: >>> >>> I added a test for the leading dollar sign character in cookie names: >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>> >>> Thanks! >>> John >>> >>> >>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>> This looks okay to me. >>>>>>> >>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>> for '$' >>>>>>> >>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>> change. We should get positive agreement from Michael before pushing >>>>>>> this. >>>>>>> >>>>>> >>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>> with '$'. >>>>>> I agree we should add a negative test now for a similar cookie. >>>>>> >>>>>> Source changes look fine to me too. >>>>> >>>>> Thanks Michael, >>>>> >>>>> In which case, I believe the check that a cookie the name >>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>> >>>> >>>> Right. I didn't realise the test was able to handle the IAE. I see >>>> now that it does and it should >>>> be possible to put the same test back. >>>> >>>> Michael >>>>> -Chris. >>>>> >>>>>> >>>>>> Michael >>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>> >>>>>>>> >>>>>>>> - Kurchi >>>>>>>> >>>>>>>> >>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>> All: >>>>>>>>> My original email was mangled by my email program >>>>>>>>> (stbeehive/zimbra) >>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>> >>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>> >>>>>>>>> John >>>>>>>>> --------------- >>>>>>>>> >>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Basically there are two issues: >>>>>>>>> >>>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>>> have >>>>>>>>> a dollar sign as their leading character, >>>>>>>>> which is "illegal". The constructor code was modified to disallow >>>>>>>>> these illegal names. >>>>>>>>> >>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>> ) >>>>>>>>> prohibited >>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>> use by >>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> John Zavgren >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>> Eastern >>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>> >>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>> constructor: >>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>>> character, which is "illegal". The constructor code was modified to >>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>> reserved >>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>> necessary. >>>>>>>>> Thanks! John Zavgren >>>>>>>> >>>>>>>> -- >>>>>>>> -Kurchi >>>>>>>> >>>>>> >>>> >>> >>> >> From brian.call at soterawireless.com Thu May 9 13:49:02 2013 From: brian.call at soterawireless.com (Brian Call) Date: Thu, 9 May 2013 13:49:02 -0700 Subject: Non-standard socket options? Message-ID: Hi Guys, My name is Brian Call and I'm a software developer for Sotera Wireless. I'm currently developing a relatively complex multicast application using the jdk7 selector-based I/O for multicast and I've run in to a pretty major hurdle. By "complex", I mean that I have a single bound socket joining multiple groups and it's critical that the bound socket only receive traffic for groups it has joined. I'm hitting the "promiscuous" traffic problem... and while bound to 0.0.0.0 on linux I'm getting traffic for all multicast groups, even if they were not specifically joined. In essence, there is no IP stack-level filtering for datagrams by joined group on linux unless you explicitly tell the stack to do so. Solaris and windows does the filtering by default and Linux does not. Is there any way to make use of a non-standard socket option in Java? Having spoken with Neil Horman lead networking developer over at Red Hat, he mentioned that by passing in the socket option IP_MULTICAST_ALL with a value of '0' it will disable UDP multiplexing on Linux when bound to the wildcard address. This would definitely be the hot move... If you have any insight into resolving the promiscuous multicast traffic problem in Java, I'd be more than grateful. Thanks in advance for your help! Blessings, Brian Call brian.call at soterawireless.com PRIVILEGED AND CONFIDENTIAL COMMUNICATION: This electronic transmission, and any documents attached hereto, may contain confidential and/or legally privileged information. The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130509/853dd7cf/attachment.html From kurchi.subhra.hazra at oracle.com Thu May 9 14:15:36 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 09 May 2013 14:15:36 -0700 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <518B620E.1070804@oracle.com> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> <20130508233508.GA20009@mhcomputing.net> <518AF430.9080601@oracle.com> <518B620E.1070804@oracle.com> Message-ID: <518C11F8.1080407@oracle.com> I have re-arranged the code a little, so that the events are handled first, any freed up connections are then registered with the selector, post which select() is called. This removes the bottleneck in a single threaded server receiving requests from the same client with a high frequency. http://cr.openjdk.java.net/~khazra/8014254/webrev.01/ - Kurchi On 5/9/13 1:45 AM, Chris Hegarty wrote: > On 05/09/2013 01:56 AM, Kurchi Hazra wrote: >> >> On 5/8/2013 4:35 PM, Matthew Hall wrote: >>> On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: >>>> com.sun.net.httpServer uses a selector to get notified about >>>> interesting >>>> events (such as arrival of a new connection, or data available to read >>>> on an existing connection when using keep-alive), but imposes a >>>> timeout of >>>> 1000 ms on the select() operation. >>> Maybe I'm missing something since the bug is not viewable to the >>> community, >>> but, if I'm reading properly, this design by itself is not quite >>> right, and >>> the fix of 200 msec selector timeout is just a band-aid solution. >>> >>> Shouldn't it be registering interestOps for reading on the existing >>> connections and accepting connections from the server socket in the >>> selector? >>> Otherwise why use any selector in the first place if it's not really >>> selecting >>> across all the right sockets and right events on them? >> >> - If you look at the implementation, this is exactly what is done. >> However, for keep-alive, the implementation delays the re-registering of >> a used channel >> for reading until after one select call, which results in the >> bottleneck. The other option is to re-register existing channels before >> the select call, this is what >> was done in jdk6. But I would need to understand why we walked away from >> that. Michael or Chris can shed some light on this. > > I'm not sure why this changed from jdk6, but I don't see any reason it > cannot be reverted back. > > -Chris. > >> >> >> >> Thanks, >> - Kurchi From mhall at mhcomputing.net Thu May 9 14:11:22 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 9 May 2013 14:11:22 -0700 Subject: Non-standard socket options? In-Reply-To: References: Message-ID: <20130509211122.GA28417@mhcomputing.net> On Thu, May 09, 2013 at 01:49:02PM -0700, Brian Call wrote: > Is there any way to make use of a non-standard socket option in Java? Having > spoken with Neil Horman lead networking developer over at Red Hat, he > mentioned that by passing in the socket option IP_MULTICAST_ALL with a value > of '0' it will disable UDP multiplexing on Linux when bound to the wildcard > address. This would definitely be the hot move... Brian, That option is very new and non-standard so it doesn't appear anywhere in the JDK code. I think you'll have to make a native library, and use this method: http://stackoverflow.com/questions/11455803/most-efficient-way-to-pass-java-socket-file-descriptor-to-c-binary-file Matthew. From mhall at mhcomputing.net Thu May 9 14:13:14 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 9 May 2013 14:13:14 -0700 Subject: Non-standard socket options? In-Reply-To: <20130509211122.GA28417@mhcomputing.net> References: <20130509211122.GA28417@mhcomputing.net> Message-ID: <20130509211314.GB28417@mhcomputing.net> On Thu, May 09, 2013 at 02:11:22PM -0700, Matthew Hall wrote: > Brian, > > That option is very new and non-standard so it doesn't appear anywhere in the JDK code. > > I think you'll have to make a native library, and use this method: > > http://stackoverflow.com/questions/11455803/most-efficient-way-to-pass-java-socket-file-descriptor-to-c-binary-file > > Matthew. You can also use Java JNA: Java Native Access. That's probably simplay than using JNI. Matthew. From mike.duigou at oracle.com Thu May 9 14:18:50 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 09 May 2013 21:18:50 +0000 Subject: hg: jdk8/tl/jdk: 8012646: Pattern.splitAsStream Message-ID: <20130509211915.77F494894C@hg.openjdk.java.net> Changeset: 498ea4c3a4c6 Author: psandoz Date: 2013-05-01 18:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/498ea4c3a4c6 8012646: Pattern.splitAsStream Reviewed-by: forax, plevart, alanb Contributed-by: Ben Evans , Paul Sandoz ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From lana.steuck at oracle.com Thu May 9 16:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:19 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130509232223.5EDBE48971@hg.openjdk.java.net> Changeset: 1f13a798d1b8 Author: katleman Date: 2013-05-02 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1f13a798d1b8 Added tag jdk8-b88 for changeset 4e3a881ebb1e ! .hgtags Changeset: fe4150590ee5 Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe4150590ee5 Merge From lana.steuck at oracle.com Thu May 9 16:22:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:21 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20130509232222.9079848970@hg.openjdk.java.net> Changeset: 1dfcc874461e Author: omajid Date: 2013-04-29 12:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1dfcc874461e 8013480: fix zero build on arm Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: 7e7582e961ba Author: jwilhelm Date: 2013-04-25 16:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7e7582e961ba 7074926: create Solaris Studio IDE (Netbeans) project for hotspot sources Summary: Project files for hotspot delevopment in Solaris Studio and NetBeans. Also reviewed by vladimir.voskresensky at oracle.com Reviewed-by: erikj, dsamersoff + common/nb_native/nbproject/configurations.xml + common/nb_native/nbproject/project.xml Changeset: b9bf111a9547 Author: katleman Date: 2013-04-30 14:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b9bf111a9547 Merge Changeset: e404d321abc6 Author: erikj Date: 2013-05-02 15:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e404d321abc6 8013786: JDK-8013480 broke configure on solaris Reviewed-by: tbell ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/toolchain.m4 Changeset: e1a929afcfc4 Author: erikj Date: 2013-05-02 15:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e1a929afcfc4 8011687: Support correct dependencies from header files on windows and solaris Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/makefiles/NativeCompilation.gmk Changeset: 8fb91165e596 Author: katleman Date: 2013-05-02 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8fb91165e596 Added tag jdk8-b88 for changeset e1a929afcfc4 ! .hgtags Changeset: 892a0196d10c Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/892a0196d10c Merge ! common/makefiles/NativeCompilation.gmk Changeset: 49ea9293fa49 Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/49ea9293fa49 Merge From lana.steuck at oracle.com Thu May 9 16:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:19 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b88 for changeset 24fa5452e5d4 Message-ID: <20130509232229.8D32B48972@hg.openjdk.java.net> Changeset: 88838e08e4ef Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88838e08e4ef Added tag jdk8-b88 for changeset 24fa5452e5d4 ! .hgtags From lana.steuck at oracle.com Thu May 9 16:22:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:23 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130509232240.7620248974@hg.openjdk.java.net> Changeset: 21f75e572cb3 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/21f75e572cb3 Added tag jdk8-b88 for changeset 7122f7bb0fcc ! .hgtags Changeset: 893d2ba8bbea Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/893d2ba8bbea Merge Changeset: 6976616f5753 Author: lana Date: 2013-05-08 22:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6976616f5753 Merge Changeset: 9e4dfe933ba9 Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9e4dfe933ba9 Merge From lana.steuck at oracle.com Thu May 9 16:22:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:27 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130509232230.915E148973@hg.openjdk.java.net> Changeset: 501bc4aeb1b1 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/501bc4aeb1b1 Added tag jdk8-b88 for changeset 40c107d1ae6f ! .hgtags Changeset: 45ce27fbe272 Author: lana Date: 2013-05-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/45ce27fbe272 Merge - src/jdk/nashorn/internal/codegen/Frame.java - src/jdk/nashorn/internal/ir/DoWhileNode.java - src/jdk/nashorn/internal/ir/LabeledNode.java From lana.steuck at oracle.com Thu May 9 16:22:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:27 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130509232242.33B1148975@hg.openjdk.java.net> Changeset: adec2a5d510a Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/adec2a5d510a Added tag jdk8-b88 for changeset a1e10f3adc47 ! .hgtags Changeset: ec434cfd2752 Author: lana Date: 2013-05-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec434cfd2752 Merge - make/Makefile-classic Changeset: c68834236058 Author: lana Date: 2013-05-08 23:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c68834236058 Merge From lana.steuck at oracle.com Thu May 9 16:23:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:23:06 +0000 Subject: hg: jdk8/tl/hotspot: 66 new changesets Message-ID: <20130509232912.050B148978@hg.openjdk.java.net> Changeset: d0081bfc425c Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0081bfc425c Added tag jdk8-b88 for changeset 8482058e74bc ! .hgtags Changeset: 57ac6a688ae6 Author: amurillo Date: 2013-04-26 00:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57ac6a688ae6 8013227: new hotspot build - hs25-b31 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cc70cbbd422e Author: hseigel Date: 2013-04-24 09:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc70cbbd422e 8012695: Assertion message displays %u and %s text instead of actual values Summary: USe err_msg() to create a proper assertion message. Reviewed-by: twisti, coleenp, iklam ! src/share/vm/classfile/classFileParser.hpp Changeset: fbca7eaeac2e Author: zgu Date: 2013-04-24 14:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fbca7eaeac2e 8011218: Kitchensink hanged, likely NMT is to blame Summary: Made NMT query safepoint aware. Reviewed-by: dholmes, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memTracker.cpp Changeset: d587a5c30bd8 Author: coleenp Date: 2013-04-24 16:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d587a5c30bd8 8011803: release_C_heap_structures is never called for anonymous classes. Summary: Call this function from the ClassLoaderData destructor instead of the system dictionary walk. Reviewed-by: stefank, mgerdin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: d66a24adbe3f Author: coleenp Date: 2013-04-24 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d66a24adbe3f Merge Changeset: 15a99ca4ee34 Author: sspitsyn Date: 2013-04-25 03:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15a99ca4ee34 8007037: JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands Summary: References from operands to CP entries and back must be correct after CP merge Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: c115fac239eb Author: iklam Date: 2013-04-25 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c115fac239eb 8008962: NPG: Memory regression: One extra Monitor per ConstantPool Summary: Re-use InstanceKlass::_init_lock locking ConstantPool as well. Reviewed-by: dholmes, coleenp, acorn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 3c9b7ef92c61 Author: dcubed Date: 2013-04-26 08:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c9b7ef92c61 Merge Changeset: d1644a010f52 Author: emc Date: 2013-04-26 07:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1644a010f52 8007154: Remove support for u4 MethodParameter flags fields Summary: Remove support for parsing class files with four-byte flags fields in MethodParameters attributes Reviewed-by: jrose, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: f258c5828eb8 Author: hseigel Date: 2013-04-29 16:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f258c5828eb8 8011773: Some tests on Interned String crashed JVM with OOM Summary: Instead of terminating the VM, throw OutOfMemoryError exceptions. Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/whitebox.cpp Changeset: c53e49efe6a8 Author: hseigel Date: 2013-04-29 16:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c53e49efe6a8 Merge Changeset: f32b6c267d2e Author: mikael Date: 2013-04-29 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f32b6c267d2e 8012015: Use PROT_NONE when reserving memory Summary: Reserved memory had PROT_READ+PROT_WRITE access on Linux/bsd, now changed to PROT_NONE. Reviewed-by: dholmes, ctornqvi ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReserveMemory.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 9f96b7a853bc Author: sla Date: 2013-04-30 10:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f96b7a853bc 8013466: SA crashes when attaching to a process on OS X Reviewed-by: coleenp, rbackman, minqi ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 409d4b59e095 Author: sla Date: 2013-04-30 02:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/409d4b59e095 Merge Changeset: ed5a590835a4 Author: zgu Date: 2013-04-30 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed5a590835a4 8013214: BigApps fails due to 'fatal error: Illegal threadstate encountered: 6' Summary: Grab and drop SR_lock to get the thread to honor the safepoint protocol Reviewed-by: dcubed, coleenp ! src/share/vm/services/memBaseline.cpp Changeset: 746b070f5022 Author: ccheung Date: 2013-04-30 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/746b070f5022 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" Reviewed-by: coleenp, zgu, hseigel ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp Changeset: e4614b063fe1 Author: sla Date: 2013-04-30 21:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4614b063fe1 8013364: SA-JDI exceptions caused by lack of permissions on OSX should be more verbose about issue cause Reviewed-by: coleenp, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 376ff861f611 Author: sla Date: 2013-05-01 01:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/376ff861f611 Merge Changeset: b4081e9714ec Author: vladidan Date: 2013-04-30 17:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4081e9714ec 8013398: Adjust number of stack guard pages on systems with large memory page size Summary: Auto adjust number of stack guard pages on systems with large memory page size Reviewed-by: bobv, coleenp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 1847df492437 Author: vladidan Date: 2013-05-01 10:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1847df492437 Merge Changeset: 08236d966eea Author: bharadwaj Date: 2013-05-01 08:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/08236d966eea 8013418: assert(i == total_args_passed) in AdapterHandlerLibrary::get_adapter since 8-b87 Summary: Do not treat static methods as miranda methods. Reviewed-by: dholmes, acorn ! src/share/vm/oops/klassVtable.cpp + test/runtime/lambda-features/PublicStaticInterfaceMethodHandling.java Changeset: 8fe2542bdc8d Author: bharadwaj Date: 2013-05-01 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8fe2542bdc8d Merge Changeset: a6e09d6dd8e5 Author: dlong Date: 2013-04-24 20:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6e09d6dd8e5 8003853: specify offset of IC load in java_to_interp stub Summary: refactored code to allow platform-specific differences Reviewed-by: dlong, twisti Contributed-by: Goetz Lindenmaier + src/cpu/sparc/vm/compiledIC_sparc.cpp ! src/cpu/sparc/vm/sparc.ad + src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + src/cpu/zero/vm/compiledIC_zero.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/opto/output.cpp Changeset: e10e43e58e92 Author: dlong Date: 2013-04-24 21:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e10e43e58e92 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/output.cpp - test/gc/6941923/test6941923.sh - test/gc/TestVerifyBeforeGCDuringStartup.java - test/runtime/NMT/AllocTestType.java Changeset: 3c0584fec1e6 Author: dholmes Date: 2013-04-28 18:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c0584fec1e6 8010428: Special -agentpath checks needed with minimal VM to produce proper error message Reviewed-by: dholmes, alanb, cjplummer, olagneau Contributed-by: Carlos Lucasius ! src/share/vm/runtime/arguments.cpp Changeset: 78603aa58b1e Author: jiangli Date: 2013-04-26 16:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78603aa58b1e Merge ! src/cpu/x86/vm/x86_64.ad Changeset: e01e02a9fcb6 Author: jiangli Date: 2013-04-29 01:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e01e02a9fcb6 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 052caeaeb771 Author: jiangli Date: 2013-05-02 12:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/052caeaeb771 Merge Changeset: 8f9fae155577 Author: jiangli Date: 2013-05-02 13:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f9fae155577 Merge Changeset: c23dbf0e8ab7 Author: jmasa Date: 2013-03-01 10:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c23dbf0e8ab7 8011268: NPG: Free unused VirtualSpaceNodes Reviewed-by: mgerdin, coleenp, johnc ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: bfe3be9ebd6c Author: kevinw Date: 2013-04-18 17:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bfe3be9ebd6c 7109087: gc/7072527/TestFullGCCount.java fails when GC is set in command-line Reviewed-by: mgerdin ! test/gc/7072527/TestFullGCCount.java Changeset: 12927badda81 Author: kevinw Date: 2013-04-19 05:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12927badda81 Merge Changeset: d391427ddc29 Author: mgerdin Date: 2013-04-22 10:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d391427ddc29 Merge Changeset: a08c80e9e1e5 Author: stefank Date: 2013-04-22 20:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a08c80e9e1e5 8012687: Remove unused is_root checks and closures Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: ebded0261dfc Author: jmasa Date: 2013-04-22 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ebded0261dfc 8012111: Remove warning about CMS generation shrinking. Reviewed-by: johnc, brutisso, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/GuardShrinkWarning.java Changeset: 1cb4795305b9 Author: mgerdin Date: 2013-04-23 08:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb4795305b9 8011802: NPG: init_dependencies in class loader data graph can cause invalid CLD Summary: Restructure initialization of ClassLoaderData to not add a new instance if init_dependencies fail Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp Changeset: 5c93c1f61226 Author: johnc Date: 2013-04-18 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c93c1f61226 8011724: G1: Stack allocate instances of HeapRegionRemSetIterator Summary: Stack allocate instances of HeapRegionRemSetIterator during RSet scanning. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 868d87ed63c8 Author: jmasa Date: 2013-02-12 14:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/868d87ed63c8 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions Reviewed-by: mgerdin, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 9d75bcd7c890 Author: mgerdin Date: 2013-04-24 19:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d75bcd7c890 8013136: NPG: Parallel class loading tests fail after fix for JDK-8011802 Summary: Move initialization of dependencies to before allocation of CLD Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp Changeset: d50cc62e94ff Author: johnc Date: 2013-04-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d50cc62e94ff 8012715: G1: GraphKit accesses PtrQueue::_index as int but is size_t Summary: In graphKit INT operations were generated to access PtrQueue::_index which has type size_t. This is 64 bit on 64-bit machines. No problems occur on little endian machines as long as the index fits into 32 bit, but on big endian machines the upper part is read, which is zero. This leads to unnecessary branches to the slow path in the runtime. Reviewed-by: twisti, johnc Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp Changeset: b06ac540229e Author: stefank Date: 2013-04-24 20:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b06ac540229e 8013132: Add a flag to turn off the output of the verbose verification code Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: b294421fa3c5 Author: brutisso Date: 2013-04-26 09:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b294421fa3c5 8012915: ReservedSpace::align_reserved_region() broken on Windows Summary: remove unused constructors and helper methods for ReservedHeapSpace and ReservedSpace Reviewed-by: mgerdin, jmasa, johnc, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 2f50bc369470 Author: stefank Date: 2013-04-26 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f50bc369470 8013160: NPG: Remove unnecessary mark stack draining after CodeCache::do_unloading Reviewed-by: coleenp, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: 3edf23423bb2 Author: johnc Date: 2013-04-26 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3edf23423bb2 8011898: gc/TestVerifyBeforeGCDuringStartup.java: java.lang.RuntimeException: '[Verifying' missing from stdout/stderr: [Error: Could not find or load main class] Summary: System.getProperty("test.java.opts") can return NULL, which gets converted to to the empty string, and the child java command then interprets that as the name of the main class. Reviewed-by: jmasa, brutisso ! test/gc/TestVerifyDuringStartup.java Changeset: caac22686b17 Author: mgerdin Date: 2013-04-29 09:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/caac22686b17 Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/runtime/thread.cpp Changeset: 601183f604b2 Author: mgerdin Date: 2013-04-29 13:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/601183f604b2 8013129: Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking Summary: Change Metaspace::deallocate to take lock with _no_safepoint_check_flag Reviewed-by: coleenp, jmasa, dholmes ! src/share/vm/memory/metaspace.cpp Changeset: 9075044ed66b Author: ehelin Date: 2013-04-30 16:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9075044ed66b 8008541: Remove old code in HotSpot that supported the jmap -permstat functionality Reviewed-by: sla, brutisso ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java Changeset: d58c62b7447d Author: mgerdin Date: 2013-05-02 19:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d58c62b7447d Merge ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: cbd4ce58f1f3 Author: mgerdin Date: 2013-05-02 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cbd4ce58f1f3 Merge Changeset: e12c9b3740db Author: vlivanov Date: 2013-04-25 11:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e12c9b3740db 8012260: ciReplay: Include PID into the name of replay data file Reviewed-by: kvn, twisti ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: dc7db03f5aa2 Author: iignatyev Date: 2013-04-25 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc7db03f5aa2 8012337: Change Whitebox implementation to make absence of method in Whitebox.class not fatal Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp + test/sanity/WhiteBox.java Changeset: 7b23cb975cf2 Author: iignatyev Date: 2013-04-25 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b23cb975cf2 8011675: adding compilation level to replay data Reviewed-by: kvn, vlivanov - agent/doc/c2replay.html + agent/doc/cireplay.html ! agent/doc/clhsdb.html ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/ciReplay/TestSA.sh + test/compiler/ciReplay/TestVM.sh + test/compiler/ciReplay/TestVM_no_comp_level.sh + test/compiler/ciReplay/common.sh Changeset: 247342108a11 Author: neliasso Date: 2013-04-23 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/247342108a11 8010332: removed unused method: ciMethod::uses_monitors Reviewed-by: twisti, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/ci/ciMethod.hpp Changeset: a5c95fcf7cb7 Author: neliasso Date: 2013-04-23 18:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5c95fcf7cb7 8012157: removed unused code in SharedRuntime::handle_wrong_method Reviewed-by: kvn, roland, rbackman Contributed-by: albert.noll at oracle.com ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d1c9384eecb4 Author: iignatyev Date: 2013-04-26 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1c9384eecb4 8012322: Tiered: CompilationPolicy::can_be_compiled(CompLevel_all) mistakenly return false Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: 93b8272814cf Author: vlivanov Date: 2013-04-26 08:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/93b8272814cf Merge Changeset: 0b55a78c6be5 Author: bharadwaj Date: 2013-04-26 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b55a78c6be5 Merge - agent/doc/c2replay.html ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fd49109d0d88 Author: bharadwaj Date: 2013-04-26 14:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd49109d0d88 Merge Changeset: 487d442ef257 Author: jiangli Date: 2013-04-26 16:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/487d442ef257 8013036: vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL). Summary: Change the assert to if check as MethodCounters could be NULL under TieredCompilation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 62b683108582 Author: jiangli Date: 2013-04-26 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62b683108582 Merge Changeset: 0cfa93c2fcc4 Author: neliasso Date: 2013-04-29 13:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0cfa93c2fcc4 8012547: Code cache flushing can get stuck reclaming of memory Summary: Keep sweeping regardless of if we are flushing Reviewed-by: kvn, twisti ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: e4e131b15d5c Author: roland Date: 2013-05-02 10:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4e131b15d5c 8013532: Remove unused parameter "compiler" from DTRACE_METHOD_COMPILE* macros Summary: remove unused parameter in dtrace macros Reviewed-by: kvn, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/compiler/compileBroker.cpp Changeset: 9ce110b1d14a Author: kvn Date: 2013-05-02 18:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ce110b1d14a Merge - agent/doc/c2replay.html ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 4ec913499722 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ec913499722 Merge - agent/doc/c2replay.html Changeset: 9c1fe0b419b4 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c1fe0b419b4 Added tag hs25-b31 for changeset 4ec913499722 ! .hgtags From lana.steuck at oracle.com Thu May 9 16:26:02 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:26:02 +0000 Subject: hg: jdk8/tl/jdk: 30 new changesets Message-ID: <20130509233415.263C54897B@hg.openjdk.java.net> Changeset: 78d08fc2dd12 Author: mullan Date: 2013-04-25 11:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78d08fc2dd12 8011313: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout not defined Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 3e282678a885 Author: mullan Date: 2013-04-25 15:48 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e282678a885 8013228: Create new system properties to control allowable OCSP clock skew and CRL connection timeout Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java Changeset: 7c4eb715c5e8 Author: ngthomas Date: 2013-04-30 21:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c4eb715c5e8 Merge Changeset: 12af7c32c648 Author: omajid Date: 2013-04-29 12:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12af7c32c648 8013480: fix zero build on arm Reviewed-by: erikj ! makefiles/GensrcX11Wrappers.gmk Changeset: 7a96ead5ea89 Author: katleman Date: 2013-04-30 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a96ead5ea89 Merge Changeset: 55c7b90fe57e Author: katleman Date: 2013-05-01 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55c7b90fe57e Merge Changeset: 8dbb4b159e04 Author: erikj Date: 2013-05-02 15:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8dbb4b159e04 8013552: Add build support for different man pages for OpenJDK and OracleJDK Reviewed-by: tbell, omajid ! makefiles/Images.gmk Changeset: 1daef88acff2 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1daef88acff2 Added tag jdk8-b88 for changeset 8dbb4b159e04 ! .hgtags Changeset: b0c41789f500 Author: jgodinez Date: 2013-04-25 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0c41789f500 8009199: Printed text become garbage on Mac OSX Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: f4aa34a7a44d Author: jchen Date: 2013-04-29 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4aa34a7a44d 8005302: [findbugs] public methods return internal arrays; may be private Reviewed-by: bae, prr ! src/share/classes/sun/java2d/pipe/AAShapePipe.java Changeset: 46686202aa23 Author: lana Date: 2013-04-30 22:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46686202aa23 Merge Changeset: c70346f4c0a9 Author: pchelko Date: 2013-04-18 15:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c70346f4c0a9 8011686: AWT accidentally disables the NSApplicationDelegate of SWT, causing loss of OS X integration functionality Reviewed-by: anthony, serb Contributed-by: Markus Persson ! src/macosx/native/sun/awt/awt.m Changeset: ac92ac05dde4 Author: kshefov Date: 2013-04-22 18:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac92ac05dde4 8011230: [TEST_BUG] java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java failed on solaris Reviewed-by: serb, anthony ! test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 578fb8766200 Author: leonidr Date: 2013-04-22 19:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/578fb8766200 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 0894b8476a49 Author: lana Date: 2013-04-23 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0894b8476a49 Merge - src/share/classes/java/time/chrono/HijrahDeviationReader.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java - src/share/classes/java/time/temporal/Adjusters.java - src/share/classes/java/time/temporal/Queries.java - src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM - src/share/native/java/lang/ResourceBundle.c - test/java/time/tck/java/time/TestChronology.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/java/util/ComparatorsTest.java Changeset: 7103434eefe2 Author: kshefov Date: 2013-04-24 11:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7103434eefe2 8011186: [TEST_BUG] java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java failed on windows 8 Reviewed-by: anthony, serb, ant - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java + test/java/awt/Focus/SimpleWindowActivationTest/SimpleWindowActivationTest.java Changeset: 854f60ec4bfb Author: anthony Date: 2013-04-26 18:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/854f60ec4bfb 8012586: [x11] Modal dialogs for fullscreen window may show behind its owner Summary: Use the _NET_WM_WINDOW_TYPE_DIALOG type for owned windows Reviewed-by: anthony, art, serb Contributed-by: Vladimir Kravets ! src/solaris/classes/sun/awt/X11/XWindowPeer.java + test/java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java Changeset: e76f3e8e653f Author: malenkov Date: 2013-04-29 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76f3e8e653f 8007458: [findbugs] One more beans issue, with ReflectionUtils Reviewed-by: art, alexsch ! src/share/classes/java/beans/MetaData.java - src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLEncoder.java ! test/java/beans/XMLEncoder/AbstractTest.java ! test/java/beans/XMLEncoder/BeanValidator.java ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4679556.java ! test/java/beans/XMLEncoder/java_awt_BorderLayout.java + test/java/beans/XMLEncoder/java_awt_CardLayout.java + test/java/beans/XMLEncoder/java_awt_GridBagLayout.java ! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java Changeset: 358acb00cb2d Author: mcherkas Date: 2013-04-30 13:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/358acb00cb2d 8012004: JInternalFrame not being finalized after closing Reviewed-by: alexsch, alexp ! src/share/classes/javax/swing/JDesktopPane.java + test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: 31e111f82993 Author: serb Date: 2013-04-30 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31e111f82993 7166296: closed/java/awt/Frame/DisabledParentOfToplevel/DisabledParentOfToplevel.html failed since 1.8.0b36 Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: caeedce39396 Author: serb Date: 2013-05-01 12:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/caeedce39396 8009012: [macosx] DisplayChangedListener is not implemented in LWWindowPeer/CGraphicsEnvironment Reviewed-by: anthony, bae ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/CGraphicsEnv.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: c357c11f076f Author: lana Date: 2013-05-01 09:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c357c11f076f Merge Changeset: 920ad6c95d93 Author: lana Date: 2013-05-01 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/920ad6c95d93 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: f6f2802f980c Author: lana Date: 2013-05-01 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6f2802f980c Merge - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 336a110f1196 Author: lana Date: 2013-05-06 11:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336a110f1196 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 88125d32eb06 Author: andrew Date: 2013-05-04 17:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88125d32eb06 8011366: Enable debug info on all libraries for OpenJDK builds Summary: The build should not be turning off debugging if it has been requested. Reviewed-by: erikj, dholmes ! makefiles/CompileNativeLibraries.gmk Changeset: 7ba77fff0ef6 Author: katleman Date: 2013-05-07 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ba77fff0ef6 Merge Changeset: 845025546e35 Author: katleman Date: 2013-05-07 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/845025546e35 Merge Changeset: 573a593379cb Author: lana Date: 2013-05-08 23:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/573a593379cb Merge ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 2023e3d573eb Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2023e3d573eb Merge - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java From mhall at mhcomputing.net Thu May 9 18:38:41 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 9 May 2013 18:38:41 -0700 Subject: SSL/TLS cipher selection Message-ID: <20130510013841.GA29131@mhcomputing.net> Hello, I discovered some unexpected behavior in how Java chooses cipher suites for SSL/TLS. I wanted to know if its method of cipher suite selection is documented somewhere so I could understand why it's not working right for me in certain cases. Notably, if I configure this preference list: public static String[] CIPHERS = { "TLS_RSA_WITH_AES_128_CBC_SHA", "SSL_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA", "TLS_DHE_RSA_WITH_AES_256_CBC_SHA" }; and then use the default "openssl ciphers" list for OpenSSL 1.0.1e, only SSL_RSA_WITH_3DES_EDE_CBC_SHA gets selected even though the server preference places it below TLS_RSA_WITH_AES_128_CBC_SHA, which, while allowed by the RFC, is not what is normally done, and will reduce performance quite a bit. When you look at the "openssl ciphers" list, you can see that they ranked 3DES above AES128 on their side, but it would really be better if the server preference took precedence instead of the client preference. Another thing which would be nice to fix, would be if the javax.net.debug=ssl output would print the server-side cipher preferences in effect as well as the client-side ones like it does presently. Thoughts? Matthew. From Alan.Bateman at oracle.com Fri May 10 04:22:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 May 2013 12:22:34 +0100 Subject: Non-standard socket options? In-Reply-To: References: Message-ID: <518CD87A.1000900@oracle.com> On 09/05/2013 21:49, Brian Call wrote: > Hi Guys, > > My name is Brian Call and I'm a software developer for Sotera > Wireless. I'm currently developing a relatively complex multicast > application using the jdk7 selector-based I/O for multicast and I've > run in to a pretty major hurdle. By "complex", I mean that I have a > single bound socket joining multiple groups and it's critical that the > bound socket only receive traffic for groups it has joined. I'm > hitting the "promiscuous" traffic problem... and while bound to > 0.0.0.0 on linux I'm getting traffic for all multicast groups, even if > they were not specifically joined. In essence, there is no IP > stack-level filtering for datagrams by joined group on linux unless > you explicitly tell the stack to do so. Solaris and windows does the > filtering by default and Linux does not. > > Is there any way to make use of a non-standard socket option in Java? > Having spoken with Neil Horman lead networking developer over at Red > Hat, he mentioned that by passing in the socket option > IP_MULTICAST_ALL with a value of '0' it will disable UDP multiplexing > on Linux when bound to the wildcard address. This would definitely be > the hot move... > > If you have any insight into resolving the promiscuous multicast > traffic problem in Java, I'd be more than grateful. Thanks for you mail. I wasn't aware of IP_MULTICAST_ALL, this is very useful to know because multicasting behavior on Linux has been painful because of works differently to other platforms (particularly Solaris, Mac and Windows). It may be that we need to consider setting IP_MULTICAST_ALL to 0 by default. As regards platform specific socket options then it is possible for a JDK implementation to expose socket options beyond those specified. This is the rational for the NetworkChannel setOption/getOption methods. This isn't exactly what you want though, it's not a means to "bolt on" support for other socket options to an existing JDK build. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130510/5082edd7/attachment.html From michael.x.mcmahon at oracle.com Fri May 10 04:34:39 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 May 2013 12:34:39 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy Message-ID: <518CDB4F.5010607@oracle.com> Hi, This is the webrev for the HttpURLPermission addition. As well as the new permission class, the change includes the use of the permission in java.net.HttpURLConnection. The code basically checks for a HttpURLPermission in plainConnect(), getInputStream() and getOutputStream() for the request and if the caller has permission the request is executed in a doPrivileged() block. When the limited doPrivileged feature is integrated, I will change the doPrivileged() call to limit the privilege elevation to a single SocketPermission (as shown in the code comments). The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ Thanks Michael From chris.hegarty at oracle.com Fri May 10 06:04:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 May 2013 14:04:14 +0100 Subject: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive In-Reply-To: <518C11F8.1080407@oracle.com> References: <5181AD5B.40703@oracle.com> <518ADA62.30808@oracle.com> <20130508233508.GA20009@mhcomputing.net> <518AF430.9080601@oracle.com> <518B620E.1070804@oracle.com> <518C11F8.1080407@oracle.com> Message-ID: <518CF04E.2080909@oracle.com> Thanks Kurchi, the changes look fine to me. -Chris. On 09/05/2013 22:15, Kurchi Hazra wrote: > I have re-arranged the code a little, so that the events are handled > first, any freed up > connections are then registered with the selector, post which select() > is called. This > removes the bottleneck in a single threaded server receiving requests > from the same client > with a high frequency. > > http://cr.openjdk.java.net/~khazra/8014254/webrev.01/ > > - Kurchi > > On 5/9/13 1:45 AM, Chris Hegarty wrote: >> On 05/09/2013 01:56 AM, Kurchi Hazra wrote: >>> >>> On 5/8/2013 4:35 PM, Matthew Hall wrote: >>>> On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: >>>>> com.sun.net.httpServer uses a selector to get notified about >>>>> interesting >>>>> events (such as arrival of a new connection, or data available to read >>>>> on an existing connection when using keep-alive), but imposes a >>>>> timeout of >>>>> 1000 ms on the select() operation. >>>> Maybe I'm missing something since the bug is not viewable to the >>>> community, >>>> but, if I'm reading properly, this design by itself is not quite >>>> right, and >>>> the fix of 200 msec selector timeout is just a band-aid solution. >>>> >>>> Shouldn't it be registering interestOps for reading on the existing >>>> connections and accepting connections from the server socket in the >>>> selector? >>>> Otherwise why use any selector in the first place if it's not really >>>> selecting >>>> across all the right sockets and right events on them? >>> >>> - If you look at the implementation, this is exactly what is done. >>> However, for keep-alive, the implementation delays the re-registering of >>> a used channel >>> for reading until after one select call, which results in the >>> bottleneck. The other option is to re-register existing channels before >>> the select call, this is what >>> was done in jdk6. But I would need to understand why we walked away from >>> that. Michael or Chris can shed some light on this. >> >> I'm not sure why this changed from jdk6, but I don't see any reason it >> cannot be reverted back. >> >> -Chris. >> >>> >>> >>> >>> Thanks, >>> - Kurchi > From alan.bateman at oracle.com Fri May 10 06:56:10 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 10 May 2013 13:56:10 +0000 Subject: hg: jdk8/tl/jdk: 8011128: (fs) Files.createDirectory fails if the resolved path is exactly 248 characters long Message-ID: <20130510135635.C1221489AC@hg.openjdk.java.net> Changeset: 09a3b08c986f Author: alanb Date: 2013-05-10 14:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a3b08c986f 8011128: (fs) Files.createDirectory fails if the resolved path is exactly 248 characters long Reviewed-by: khazra, chegar ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsPath.java + test/java/nio/file/Files/NameLimits.java From alan.bateman at oracle.com Fri May 10 08:15:09 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 10 May 2013 15:15:09 +0000 Subject: hg: jdk8/tl/langtools: 8014318: tools/javac/profiles/ProfileOptionTest.java needs modifying now that javax.script is in compact1 Message-ID: <20130510151517.4C2C5489AD@hg.openjdk.java.net> Changeset: ce7e1674eb73 Author: alanb Date: 2013-05-10 16:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce7e1674eb73 8014318: tools/javac/profiles/ProfileOptionTest.java needs modifying now that javax.script is in compact1 Reviewed-by: mchung ! test/tools/javac/profiles/ProfileOptionTest.java From joe.darcy at oracle.com Fri May 10 08:56:31 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 15:56:31 +0000 Subject: hg: jdk8/tl/jdk: 8014249: Add Modifer.parameterModifiers() Message-ID: <20130510155653.EED71489B2@hg.openjdk.java.net> Changeset: ece61e21782d Author: darcy Date: 2013-05-10 08:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ece61e21782d 8014249: Add Modifer.parameterModifiers() Reviewed-by: mduigou, mchung ! src/share/classes/java/lang/reflect/Modifier.java From joe.darcy at oracle.com Fri May 10 09:07:16 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 16:07:16 +0000 Subject: hg: jdk8/tl/jdk: 8014296: DivModTests should not compare pointers Message-ID: <20130510160728.8CBAC489B3@hg.openjdk.java.net> Changeset: c26e0d29249a Author: rriggs Date: 2013-05-10 09:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c26e0d29249a 8014296: DivModTests should not compare pointers Reviewed-by: darcy ! test/java/lang/Math/DivModTests.java From brian.call at soterawireless.com Fri May 10 09:14:06 2013 From: brian.call at soterawireless.com (Brian Call) Date: Fri, 10 May 2013 09:14:06 -0700 Subject: Non-standard socket options? In-Reply-To: <518CD87A.1000900@oracle.com> References: <518CD87A.1000900@oracle.com> Message-ID: Thanks for your help guys! It would be most excellent to have that socket option turned off by default. It would certainly make multicast receivers written in java behave the same way across all the major platforms. Not sure why this wasn't considered a bug in Linux and, in fact, it's vehemently defended as absolutely adhering to the multicast spec. For further context, please have a look at: https://bugzilla.redhat.com/show_bug.cgi?id=231899 Blessings, Brian On May 10, 2013, at 4:22 AM, Alan Bateman wrote: > On 09/05/2013 21:49, Brian Call wrote: >> >> Hi Guys, >> >> My name is Brian Call and I'm a software developer for Sotera Wireless. I'm currently developing a relatively complex multicast application using the jdk7 selector-based I/O for multicast and I've run in to a pretty major hurdle. By "complex", I mean that I have a single bound socket joining multiple groups and it's critical that the bound socket only receive traffic for groups it has joined. I'm hitting the "promiscuous" traffic problem... and while bound to 0.0.0.0 on linux I'm getting traffic for all multicast groups, even if they were not specifically joined. In essence, there is no IP stack-level filtering for datagrams by joined group on linux unless you explicitly tell the stack to do so. Solaris and windows does the filtering by default and Linux does not. >> >> Is there any way to make use of a non-standard socket option in Java? Having spoken with Neil Horman lead networking developer over at Red Hat, he mentioned that by passing in the socket option IP_MULTICAST_ALL with a value of '0' it will disable UDP multiplexing on Linux when bound to the wildcard address. This would definitely be the hot move... >> >> If you have any insight into resolving the promiscuous multicast traffic problem in Java, I'd be more than grateful. > Thanks for you mail. I wasn't aware of IP_MULTICAST_ALL, this is very useful to know because multicasting behavior on Linux has been painful because of works differently to other platforms (particularly Solaris, Mac and Windows). It may be that we need to consider setting IP_MULTICAST_ALL to 0 by default. > > As regards platform specific socket options then it is possible for a JDK implementation to expose socket options beyond those specified. This is the rational for the NetworkChannel setOption/getOption methods. This isn't exactly what you want though, it's not a means to "bolt on" support for other socket options to an existing JDK build. > > -Alan Blessings, Brian Call brian.call at soterawireless.com PRIVILEGED AND CONFIDENTIAL COMMUNICATION: This electronic transmission, and any documents attached hereto, may contain confidential and/or legally privileged information. The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130510/055eda82/attachment.html From mike.duigou at oracle.com Fri May 10 10:13:33 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 10 May 2013 17:13:33 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130510171357.D0F0C489D3@hg.openjdk.java.net> Changeset: 2490769abdfa Author: mduigou Date: 2013-05-10 09:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2490769abdfa 8014316: Use Method Refs in j.u.stream.MatchOps Reviewed-by: dholmes ! src/share/classes/java/util/stream/MatchOps.java Changeset: 9891e4d7d5b3 Author: mduigou Date: 2013-05-10 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9891e4d7d5b3 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java From joe.darcy at oracle.com Fri May 10 12:25:50 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 19:25:50 +0000 Subject: hg: jdk8/tl/jdk: 8014357: Minor refactorings to sun.reflect.generics.reflectiveObjects.* Message-ID: <20130510192612.8D50F489E7@hg.openjdk.java.net> Changeset: f84b5498b2bb Author: darcy Date: 2013-05-10 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f84b5498b2bb 8014357: Minor refactorings to sun.reflect.generics.reflectiveObjects.* Reviewed-by: mchung ! src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java From joe.darcy at oracle.com Fri May 10 14:32:00 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 21:32:00 +0000 Subject: hg: jdk8/tl/langtools: 8014365: Restore Objects.requireNonNull(T, Supplier) Message-ID: <20130510213206.719BD489F4@hg.openjdk.java.net> Changeset: 1c43236f6d69 Author: darcy Date: 2013-05-10 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1c43236f6d69 8014365: Restore Objects.requireNonNull(T, Supplier) Reviewed-by: jjg ! makefiles/BuildLangtools.gmk From kurchi.subhra.hazra at oracle.com Fri May 10 16:35:05 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 10 May 2013 16:35:05 -0700 Subject: Code Review Request: 6328537: Improve javadocs for Socket class by adding references to SocketOptions In-Reply-To: <518ADA62.30808@oracle.com> References: <518ADA62.30808@oracle.com> Message-ID: <518D8429.7060903@oracle.com> Hi, This is a simple improvement in the javadocs of the Socket and ServerSocket classes, to cross-reference the SocketOptions class where appropriate. It looks like a lot of changes in the webrev, only because I have re-justified the text in some cases. Bug: http://bugs.sun.com/view_bug.do?bug_id=6328537 Webrev:http://cr.openjdk.java.net/~khazra/6328537/webrev.00/ The specdiff isn't very helpful, but here it is: http://cr.openjdk.java.net/~khazra/6328537/specdiff.00/ Thanks, - Kurchi From Alan.Bateman at oracle.com Sat May 11 08:42:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 May 2013 16:42:58 +0100 Subject: Non-standard socket options? In-Reply-To: References: <518CD87A.1000900@oracle.com> Message-ID: <518E6702.2000509@oracle.com> On 10/05/2013 17:14, Brian Call wrote: > Thanks for your help guys! > > It would be most excellent to have that socket option turned off by > default. It would certainly make multicast receivers written in java > behave the same way across all the major platforms. Not sure why this > wasn't considered a bug in Linux and, in fact, it's vehemently > defended as absolutely adhering to the multicast spec. > There is a long history there. One thing that isn't clear about IP_MULTICAST_ALL is whether there is an equivalent for IPv6, that might need more investigation. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130511/432c2a34/attachment.html From Alan.Bateman at oracle.com Sun May 12 00:13:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 May 2013 08:13:46 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <518CDB4F.5010607@oracle.com> References: <518CDB4F.5010607@oracle.com> Message-ID: <518F412A.8040902@oracle.com> On 10/05/2013 12:34, Michael McMahon wrote: > Hi, > > This is the webrev for the HttpURLPermission addition. > As well as the new permission class, the change > includes the use of the permission in java.net.HttpURLConnection. > > The code basically checks for a HttpURLPermission in plainConnect(), > getInputStream() and getOutputStream() for the request and if > the caller has permission the request is executed in a doPrivileged() > block. When the limited doPrivileged feature is integrated, I will > change the doPrivileged() call to limit the privilege elevation to a > single > SocketPermission (as shown in the code comments). > > The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ A partial review, focusing mostly on the spec as we've been through a few rounds on that part already. Overall I think the javadoc looks quite good. I realize someone suggested using lowercase "url" in the javadoc but as the usage is as an acronym then it might be clearer if it were in uppercase, maybe "URL string" to avoid any confusion with java.net.URL. I assume you'll add a copyright header to HttpURLPermission before pushing this. A minor comment on the javadoc tags is that you probably should use @throws instead of @exception. At a high-level it would be nice if the fields were final but I guess the parsing of actions and being serialized complicates this. setURI - this parses the URI rather than "sets" it so maybe it should be renamed. If you use URI.create then it would avoid needing to catch the URISyntaxException. normalizeMethods/normalizeHeaders- I assume these could use an ArrayList. HttpURLConnection - "if a security manager is installed", should this be "set"? MessageHeader - some of the methods are synchronized, some are not. I can't quite tell if getHeaderNames needs to be synchronized. Also is there any reason why this can't use Arrays.asList? HttpURLConnection.setRequestMethod - "connection being open" -> "connect in progress"? That's all I have for now but I think there is further review work required on HttpURLConnection as some of that is tricky. -Alan. From dmitry.degrave at oracle.com Sun May 12 07:54:37 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Sun, 12 May 2013 14:54:37 +0000 Subject: hg: jdk8/tl/jdk: 7021870: GzipInputStream closes underlying stream during reading Message-ID: <20130512145515.EF53A48A18@hg.openjdk.java.net> Changeset: 90f715cceaae Author: dmeetry Date: 2013-05-10 23:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90f715cceaae 7021870: GzipInputStream closes underlying stream during reading Reviewed-by: mduigou Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/java/util/zip/GZIPInputStream.java + test/java/util/zip/GZIP/GZIPInZip.java From dmitry.samersoff at oracle.com Sun May 12 11:25:26 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 12 May 2013 22:25:26 +0400 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <518CDB4F.5010607@oracle.com> References: <518CDB4F.5010607@oracle.com> Message-ID: <518FDE96.1040806@oracle.com> Michael, It might be better to narrow permissions right now with code like below: private static AccessControlContext withPermissions(Permission ... perms){ Permissions col = new Permissions(); for (Permission thePerm : perms ) { col.add(thePerm); } final ProtectionDomain pd = new ProtectionDomain(null, col); return new AccessControlContext( new ProtectionDomain[] { pd }); } AccessController.doPrivileged( new PrivilegedExceptionAction() { public Void run() throws IOException { plainConnect0(); return null; }, withPermissions(p) ); -Dmitry On 2013-05-10 15:34, Michael McMahon wrote: > Hi, > > This is the webrev for the HttpURLPermission addition. > As well as the new permission class, the change > includes the use of the permission in java.net.HttpURLConnection. > > The code basically checks for a HttpURLPermission in plainConnect(), > getInputStream() and getOutputStream() for the request and if > the caller has permission the request is executed in a doPrivileged() > block. When the limited doPrivileged feature is integrated, I will > change the doPrivileged() call to limit the privilege elevation to a single > SocketPermission (as shown in the code comments). > > The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ > > Thanks > Michael -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From jonathan.gibbons at oracle.com Sun May 12 18:19:58 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 May 2013 01:19:58 +0000 Subject: hg: jdk8/tl/langtools: 8014363: javac test class ToolTester handles classpath incorrectly Message-ID: <20130513012005.3FE4948A1E@hg.openjdk.java.net> Changeset: e39669aea0bd Author: jjg Date: 2013-05-12 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e39669aea0bd 8014363: javac test class ToolTester handles classpath incorrectly Reviewed-by: ksrini ! test/tools/javac/api/6406133/T6406133.java ! test/tools/javac/api/6410643/T6410643.java ! test/tools/javac/api/6411310/T6411310.java ! test/tools/javac/api/6411333/T6411333.java ! test/tools/javac/api/6412656/T6412656.java ! test/tools/javac/api/6415780/T6415780.java ! test/tools/javac/api/6418694/T6418694.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6421756/T6421756.java ! test/tools/javac/api/6422215/T6422215.java ! test/tools/javac/api/6422327/T6422327.java ! test/tools/javac/api/6423003/T6423003.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/6437349/T6437349.java ! test/tools/javac/api/6437999/T6437999.java ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/6733837/T6733837.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/guide/Test.java ! test/tools/javac/api/lib/ToolTester.java From chris.hegarty at oracle.com Mon May 13 01:37:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 09:37:09 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <518F412A.8040902@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> Message-ID: <5190A635.6070600@oracle.com> On 12/05/2013 08:13, Alan Bateman wrote: > .... > A partial review, focusing mostly on the spec as we've been through a > few rounds on that part already. Overall I think the javadoc looks quite > good. I realize someone suggested using lowercase "url" in the javadoc > but as the usage is as an acronym then it might be clearer if it were in > uppercase, maybe "URL string" to avoid any confusion with java.net.URL. This may be as a result of my comments. You are right, lowercase url is not quite right. I like "URL string", or 1) {code url}, since the given arg is named 'url' 2) "the given/specified {@code url}" -Chris. From Alan.Bateman at oracle.com Mon May 13 02:34:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 10:34:44 +0100 Subject: Code Review Request: 6328537: Improve javadocs for Socket class by adding references to SocketOptions In-Reply-To: <518D8429.7060903@oracle.com> References: <518ADA62.30808@oracle.com> <518D8429.7060903@oracle.com> Message-ID: <5190B3B4.5000505@oracle.com> On 11/05/2013 00:35, Kurchi Hazra wrote: > > > Hi, > > This is a simple improvement in the javadocs of the Socket and > ServerSocket > classes, to cross-reference the SocketOptions class where appropriate. > It looks > like a lot of changes in the webrev, only because I have re-justified > the text > in some cases. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=6328537 > Webrev:http://cr.openjdk.java.net/~khazra/6328537/webrev.00/ > > The specdiff isn't very helpful, but here it is: > http://cr.openjdk.java.net/~khazra/6328537/specdiff.00/ > > Thanks, > - Kurchi > This looks okay to me but at some point we need to sort out the relationship to StandardSocketOptions where there is more complete (and more up to date) description. -Alan From chris.hegarty at oracle.com Mon May 13 03:08:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 11:08:26 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <518F412A.8040902@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> Message-ID: <5190BB9A.3040108@oracle.com> On 12/05/2013 08:13, Alan Bateman wrote: > .... > At a high-level it would be nice if the fields were final but I guess > the parsing of actions and being serialized complicates this. This would be my preference too. You could use the serialization proxy pattern, and with some restructuring I think the fields could be made final. But, I ok with what you have. We can re-visit later to see if this makes sense. I don't see where the socketPermission field is used in HttpURLConnection, I suspect it should be set in URLtoSocketPermission? I think it should be possible to add the GPL header to the new test policy files. Otherwise, nice to see this moving forward. -Chris. From chris.hegarty at oracle.com Mon May 13 03:19:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 11:19:19 +0100 Subject: Code Review Request: 6328537: Improve javadocs for Socket class by adding references to SocketOptions In-Reply-To: <518D8429.7060903@oracle.com> References: <518ADA62.30808@oracle.com> <518D8429.7060903@oracle.com> Message-ID: <5190BE27.6060708@oracle.com> On 11/05/2013 00:35, Kurchi Hazra wrote: > This is a simple improvement in the javadocs of the Socket and ServerSocket > classes, to cross-reference the SocketOptions class where appropriate. > It looks > like a lot of changes in the webrev, only because I have re-justified > the text > in some cases. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=6328537 > Webrev:http://cr.openjdk.java.net/~khazra/6328537/webrev.00/ This will make navigating from these API's to the specification for their respective options much easier. A simple change, but very user friendly. > The specdiff isn't very helpful, but here it is: > http://cr.openjdk.java.net/~khazra/6328537/specdiff.00/ Not at all. It gives confidence that nothing untoward has accidentally changed. Especially, as you say, when there is significant realignment of the method descriptions. As Alan pointed out, at some point we need to sort out the relationship to StandardSocketOptions, but what you have is fine for now. Thanks, -Chris. > > Thanks, > - Kurchi From michael.x.mcmahon at oracle.com Mon May 13 03:41:59 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 11:41:59 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <518F412A.8040902@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> Message-ID: <5190C377.3000007@oracle.com> Thanks for the review. On the javadoc comments, there are a couple of small spec changes that will probably happen after feature freeze anyway. So, that might be the best time to address the other javadoc issues. I agree with your other comments. On the synchronized method in MessageHeader, I don't believe it needs to be synchronized since the method is not relying on consistency between object fields, and the returned object can be modified before, during or after the method is called anyway. Michael On 12/05/13 08:13, Alan Bateman wrote: > On 10/05/2013 12:34, Michael McMahon wrote: >> Hi, >> >> This is the webrev for the HttpURLPermission addition. >> As well as the new permission class, the change >> includes the use of the permission in java.net.HttpURLConnection. >> >> The code basically checks for a HttpURLPermission in plainConnect(), >> getInputStream() and getOutputStream() for the request and if >> the caller has permission the request is executed in a doPrivileged() >> block. When the limited doPrivileged feature is integrated, I will >> change the doPrivileged() call to limit the privilege elevation to a >> single >> SocketPermission (as shown in the code comments). >> >> The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ > A partial review, focusing mostly on the spec as we've been through a > few rounds on that part already. Overall I think the javadoc looks > quite good. I realize someone suggested using lowercase "url" in the > javadoc but as the usage is as an acronym then it might be clearer if > it were in uppercase, maybe "URL string" to avoid any confusion with > java.net.URL. > > I assume you'll add a copyright header to HttpURLPermission before > pushing this. > > A minor comment on the javadoc tags is that you probably should use > @throws instead of @exception. > > At a high-level it would be nice if the fields were final but I guess > the parsing of actions and being serialized complicates this. > > setURI - this parses the URI rather than "sets" it so maybe it should > be renamed. If you use URI.create then it would avoid needing to catch > the URISyntaxException. > > normalizeMethods/normalizeHeaders- I assume these could use an ArrayList. > > HttpURLConnection - "if a security manager is installed", should this > be "set"? > > MessageHeader - some of the methods are synchronized, some are not. I > can't quite tell if getHeaderNames needs to be synchronized. Also is > there any reason why this can't use Arrays.asList? > > HttpURLConnection.setRequestMethod - "connection being open" -> > "connect in progress"? > > That's all I have for now but I think there is further review work > required on HttpURLConnection as some of that is tricky. > > -Alan. From michael.x.mcmahon at oracle.com Mon May 13 03:45:30 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 11:45:30 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190BB9A.3040108@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190BB9A.3040108@oracle.com> Message-ID: <5190C44A.3080509@oracle.com> On 13/05/13 11:08, Chris Hegarty wrote: > > On 12/05/2013 08:13, Alan Bateman wrote: >> .... >> At a high-level it would be nice if the fields were final but I guess >> the parsing of actions and being serialized complicates this. > > This would be my preference too. You could use the serialization proxy > pattern, and with some restructuring I think the fields could be made > final. But, I ok with what you have. We can re-visit later to see if > this makes sense. > Yes, maybe revisit later, especially if this means using sun.misc.Unsafe again. I'm still not convinced about the benefit of that (being worth the ugliness) > I don't see where the socketPermission field is used in > HttpURLConnection, I suspect it should be set in URLtoSocketPermission? > right, good catch. > I think it should be possible to add the GPL header to the new test > policy files. > okay Thanks! Michael From vitalyd at gmail.com Mon May 13 05:30:46 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 May 2013 08:30:46 -0400 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190C377.3000007@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> Message-ID: Hi Michael, On the synchronized issue, I think you do need it; if someone, e.g., calls reset() while this method is running, you'll get NPE. Maybe pull the keys array into a local then and iterate over the local instead? Also, why LinkedList instead of ArrayList(or Arrays.asList, as Alan mentioned, although maybe caller is expected to modify the returned list)? Thanks Sent from my phone On May 13, 2013 6:42 AM, "Michael McMahon" wrote: > Thanks for the review. On the javadoc comments, there are a couple > of small spec changes that will probably happen after feature freeze > anyway. > So, that might be the best time to address the other javadoc issues. > > I agree with your other comments. On the synchronized method in > MessageHeader, > I don't believe it needs to be synchronized since the method is not > relying on > consistency between object fields, and the returned object can be > modified before, during or after the method is called anyway. > > Michael > > On 12/05/13 08:13, Alan Bateman wrote: > >> On 10/05/2013 12:34, Michael McMahon wrote: >> >>> Hi, >>> >>> This is the webrev for the HttpURLPermission addition. >>> As well as the new permission class, the change >>> includes the use of the permission in java.net.HttpURLConnection. >>> >>> The code basically checks for a HttpURLPermission in plainConnect(), >>> getInputStream() and getOutputStream() for the request and if >>> the caller has permission the request is executed in a doPrivileged() >>> block. When the limited doPrivileged feature is integrated, I will >>> change the doPrivileged() call to limit the privilege elevation to a >>> single >>> SocketPermission (as shown in the code comments). >>> >>> The webrev is at http://cr.openjdk.java.net/~** >>> michaelm/8010464/webrev.1/ >>> >> A partial review, focusing mostly on the spec as we've been through a few >> rounds on that part already. Overall I think the javadoc looks quite good. >> I realize someone suggested using lowercase "url" in the javadoc but as the >> usage is as an acronym then it might be clearer if it were in uppercase, >> maybe "URL string" to avoid any confusion with java.net.URL. >> >> I assume you'll add a copyright header to HttpURLPermission before >> pushing this. >> >> A minor comment on the javadoc tags is that you probably should use >> @throws instead of @exception. >> >> At a high-level it would be nice if the fields were final but I guess the >> parsing of actions and being serialized complicates this. >> >> setURI - this parses the URI rather than "sets" it so maybe it should be >> renamed. If you use URI.create then it would avoid needing to catch the >> URISyntaxException. >> >> normalizeMethods/**normalizeHeaders- I assume these could use an >> ArrayList. >> >> HttpURLConnection - "if a security manager is installed", should this be >> "set"? >> >> MessageHeader - some of the methods are synchronized, some are not. I >> can't quite tell if getHeaderNames needs to be synchronized. Also is there >> any reason why this can't use Arrays.asList? >> >> HttpURLConnection.**setRequestMethod - "connection being open" -> >> "connect in progress"? >> >> That's all I have for now but I think there is further review work >> required on HttpURLConnection as some of that is tricky. >> >> -Alan. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/31a06ce0/attachment.html From vitalyd at gmail.com Mon May 13 05:36:13 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 May 2013 08:36:13 -0400 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> Message-ID: Actually, local may not work since getHeaders uses nkeys as well - can run into AIOBE. Probably best to just synchronize given current implementation. Sent from my phone On May 13, 2013 8:30 AM, "Vitaly Davidovich" wrote: > Hi Michael, > > On the synchronized issue, I think you do need it; if someone, e.g., calls > reset() while this method is running, you'll get NPE. Maybe pull the keys > array into a local then and iterate over the local instead? > > Also, why LinkedList instead of ArrayList(or Arrays.asList, as Alan > mentioned, although maybe caller is expected to modify the returned list)? > > Thanks > > Sent from my phone > On May 13, 2013 6:42 AM, "Michael McMahon" > wrote: > >> Thanks for the review. On the javadoc comments, there are a couple >> of small spec changes that will probably happen after feature freeze >> anyway. >> So, that might be the best time to address the other javadoc issues. >> >> I agree with your other comments. On the synchronized method in >> MessageHeader, >> I don't believe it needs to be synchronized since the method is not >> relying on >> consistency between object fields, and the returned object can be >> modified before, during or after the method is called anyway. >> >> Michael >> >> On 12/05/13 08:13, Alan Bateman wrote: >> >>> On 10/05/2013 12:34, Michael McMahon wrote: >>> >>>> Hi, >>>> >>>> This is the webrev for the HttpURLPermission addition. >>>> As well as the new permission class, the change >>>> includes the use of the permission in java.net.HttpURLConnection. >>>> >>>> The code basically checks for a HttpURLPermission in plainConnect(), >>>> getInputStream() and getOutputStream() for the request and if >>>> the caller has permission the request is executed in a doPrivileged() >>>> block. When the limited doPrivileged feature is integrated, I will >>>> change the doPrivileged() call to limit the privilege elevation to a >>>> single >>>> SocketPermission (as shown in the code comments). >>>> >>>> The webrev is at http://cr.openjdk.java.net/~** >>>> michaelm/8010464/webrev.1/ >>>> >>> A partial review, focusing mostly on the spec as we've been through a >>> few rounds on that part already. Overall I think the javadoc looks quite >>> good. I realize someone suggested using lowercase "url" in the javadoc but >>> as the usage is as an acronym then it might be clearer if it were in >>> uppercase, maybe "URL string" to avoid any confusion with java.net.URL. >>> >>> I assume you'll add a copyright header to HttpURLPermission before >>> pushing this. >>> >>> A minor comment on the javadoc tags is that you probably should use >>> @throws instead of @exception. >>> >>> At a high-level it would be nice if the fields were final but I guess >>> the parsing of actions and being serialized complicates this. >>> >>> setURI - this parses the URI rather than "sets" it so maybe it should be >>> renamed. If you use URI.create then it would avoid needing to catch the >>> URISyntaxException. >>> >>> normalizeMethods/**normalizeHeaders- I assume these could use an >>> ArrayList. >>> >>> HttpURLConnection - "if a security manager is installed", should this be >>> "set"? >>> >>> MessageHeader - some of the methods are synchronized, some are not. I >>> can't quite tell if getHeaderNames needs to be synchronized. Also is there >>> any reason why this can't use Arrays.asList? >>> >>> HttpURLConnection.**setRequestMethod - "connection being open" -> >>> "connect in progress"? >>> >>> That's all I have for now but I think there is further review work >>> required on HttpURLConnection as some of that is tricky. >>> >>> -Alan. >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/6ae57df8/attachment.html From xuelei.fan at oracle.com Mon May 13 05:43:32 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 13 May 2013 12:43:32 +0000 Subject: hg: jdk8/tl/jdk: 8005535: SSLSessionImpl should have protected finalize() Message-ID: <20130513124354.6003748A28@hg.openjdk.java.net> Changeset: 76998d11a643 Author: xuelei Date: 2013-05-13 05:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76998d11a643 8005535: SSLSessionImpl should have protected finalize() Reviewed-by: weijun, wetmore ! src/share/classes/sun/security/ssl/SSLSessionImpl.java From michael.x.mcmahon at oracle.com Mon May 13 06:05:17 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 14:05:17 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> Message-ID: <5190E50D.8090609@oracle.com> Hi Vitali, I was going to switch to use Arrays.asList() as you and Alan suggested. So getHeaderNames() would look like: public List getHeaderNames() { return Arrays.asList(keys); } So, it turns out synchronizing nkeys and keys is no longer necessary. It's true that reset() could be called during the call. But, it could (in theory) be called before or after either. In practice that won't happen, since the request headers aren't ever reset. Michael On 13/05/13 13:36, Vitaly Davidovich wrote: > > Actually, local may not work since getHeaders uses nkeys as well - can > run into AIOBE. Probably best to just synchronize given current > implementation. > > Sent from my phone > > On May 13, 2013 8:30 AM, "Vitaly Davidovich" > wrote: > > Hi Michael, > > On the synchronized issue, I think you do need it; if someone, > e.g., calls reset() while this method is running, you'll get NPE. > Maybe pull the keys array into a local then and iterate over the > local instead? > > Also, why LinkedList instead of ArrayList(or Arrays.asList, as > Alan mentioned, although maybe caller is expected to modify the > returned list)? > > Thanks > > Sent from my phone > > On May 13, 2013 6:42 AM, "Michael McMahon" > > wrote: > > Thanks for the review. On the javadoc comments, there are a couple > of small spec changes that will probably happen after feature > freeze anyway. > So, that might be the best time to address the other javadoc > issues. > > I agree with your other comments. On the synchronized method > in MessageHeader, > I don't believe it needs to be synchronized since the method > is not relying on > consistency between object fields, and the returned object can be > modified before, during or after the method is called anyway. > > Michael > > On 12/05/13 08:13, Alan Bateman wrote: > > On 10/05/2013 12:34, Michael McMahon wrote: > > Hi, > > This is the webrev for the HttpURLPermission addition. > As well as the new permission class, the change > includes the use of the permission in > java.net.HttpURLConnection. > > The code basically checks for a HttpURLPermission in > plainConnect(), > getInputStream() and getOutputStream() for the request > and if > the caller has permission the request is executed in a > doPrivileged() > block. When the limited doPrivileged feature is > integrated, I will > change the doPrivileged() call to limit the privilege > elevation to a single > SocketPermission (as shown in the code comments). > > The webrev is at > http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ > > > A partial review, focusing mostly on the spec as we've > been through a few rounds on that part already. Overall I > think the javadoc looks quite good. I realize someone > suggested using lowercase "url" in the javadoc but as the > usage is as an acronym then it might be clearer if it were > in uppercase, maybe "URL string" to avoid any confusion > with java.net.URL. > > I assume you'll add a copyright header to > HttpURLPermission before pushing this. > > A minor comment on the javadoc tags is that you probably > should use @throws instead of @exception. > > At a high-level it would be nice if the fields were final > but I guess the parsing of actions and being serialized > complicates this. > > setURI - this parses the URI rather than "sets" it so > maybe it should be renamed. If you use URI.create then it > would avoid needing to catch the URISyntaxException. > > normalizeMethods/normalizeHeaders- I assume these could > use an ArrayList. > > HttpURLConnection - "if a security manager is installed", > should this be "set"? > > MessageHeader - some of the methods are synchronized, some > are not. I can't quite tell if getHeaderNames needs to be > synchronized. Also is there any reason why this can't use > Arrays.asList? > > HttpURLConnection.setRequestMethod - "connection being > open" -> "connect in progress"? > > That's all I have for now but I think there is further > review work required on HttpURLConnection as some of that > is tricky. > > -Alan. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/2b8f0a8f/attachment.html From xuelei.fan at oracle.com Mon May 13 06:07:03 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 13 May 2013 13:07:03 +0000 Subject: hg: jdk8/tl/jdk: 8005598: (reopened) Need to clone array of input/output parameters Message-ID: <20130513130715.CBCE148A2C@hg.openjdk.java.net> Changeset: 46db0e633240 Author: xuelei Date: 2013-05-13 06:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46db0e633240 8005598: (reopened) Need to clone array of input/output parameters Reviewed-by: weijun ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java From vitalyd at gmail.com Mon May 13 06:12:00 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 May 2013 09:12:00 -0400 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190E50D.8090609@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> Message-ID: I get what you're saying about before/after, but the difference would be that if it's called during then you get an exception purely due to missing synchronization; in the before/after case, caller may observe "stale" entries but that's fine, as you say. Maybe headers aren't reset in practice, but this code looks suspect to someone reading it. :) Sent from my phone On May 13, 2013 9:05 AM, "Michael McMahon" wrote: > Hi Vitali, > > I was going to switch to use Arrays.asList() as you and Alan suggested. So > getHeaderNames() would look like: > > public List getHeaderNames() { > return Arrays.asList(keys); > } > > So, it turns out synchronizing nkeys and keys is no longer necessary. > It's true that reset() could be called during the call. But, it could (in > theory) be called > before or after either. In practice that won't happen, since the request > headers > aren't ever reset. > > Michael > > > > On 13/05/13 13:36, Vitaly Davidovich wrote: > > Actually, local may not work since getHeaders uses nkeys as well - can run > into AIOBE. Probably best to just synchronize given current implementation. > > Sent from my phone > On May 13, 2013 8:30 AM, "Vitaly Davidovich" wrote: > >> Hi Michael, >> >> On the synchronized issue, I think you do need it; if someone, e.g., >> calls reset() while this method is running, you'll get NPE. Maybe pull the >> keys array into a local then and iterate over the local instead? >> >> Also, why LinkedList instead of ArrayList(or Arrays.asList, as Alan >> mentioned, although maybe caller is expected to modify the returned list)? >> >> Thanks >> >> Sent from my phone >> On May 13, 2013 6:42 AM, "Michael McMahon" >> wrote: >> >>> Thanks for the review. On the javadoc comments, there are a couple >>> of small spec changes that will probably happen after feature freeze >>> anyway. >>> So, that might be the best time to address the other javadoc issues. >>> >>> I agree with your other comments. On the synchronized method in >>> MessageHeader, >>> I don't believe it needs to be synchronized since the method is not >>> relying on >>> consistency between object fields, and the returned object can be >>> modified before, during or after the method is called anyway. >>> >>> Michael >>> >>> On 12/05/13 08:13, Alan Bateman wrote: >>> >>>> On 10/05/2013 12:34, Michael McMahon wrote: >>>> >>>>> Hi, >>>>> >>>>> This is the webrev for the HttpURLPermission addition. >>>>> As well as the new permission class, the change >>>>> includes the use of the permission in java.net.HttpURLConnection. >>>>> >>>>> The code basically checks for a HttpURLPermission in plainConnect(), >>>>> getInputStream() and getOutputStream() for the request and if >>>>> the caller has permission the request is executed in a doPrivileged() >>>>> block. When the limited doPrivileged feature is integrated, I will >>>>> change the doPrivileged() call to limit the privilege elevation to a >>>>> single >>>>> SocketPermission (as shown in the code comments). >>>>> >>>>> The webrev is at >>>>> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>>>> >>>> A partial review, focusing mostly on the spec as we've been through a >>>> few rounds on that part already. Overall I think the javadoc looks quite >>>> good. I realize someone suggested using lowercase "url" in the javadoc but >>>> as the usage is as an acronym then it might be clearer if it were in >>>> uppercase, maybe "URL string" to avoid any confusion with java.net.URL. >>>> >>>> I assume you'll add a copyright header to HttpURLPermission before >>>> pushing this. >>>> >>>> A minor comment on the javadoc tags is that you probably should use >>>> @throws instead of @exception. >>>> >>>> At a high-level it would be nice if the fields were final but I guess >>>> the parsing of actions and being serialized complicates this. >>>> >>>> setURI - this parses the URI rather than "sets" it so maybe it should >>>> be renamed. If you use URI.create then it would avoid needing to catch the >>>> URISyntaxException. >>>> >>>> normalizeMethods/normalizeHeaders- I assume these could use an >>>> ArrayList. >>>> >>>> HttpURLConnection - "if a security manager is installed", should this >>>> be "set"? >>>> >>>> MessageHeader - some of the methods are synchronized, some are not. I >>>> can't quite tell if getHeaderNames needs to be synchronized. Also is there >>>> any reason why this can't use Arrays.asList? >>>> >>>> HttpURLConnection.setRequestMethod - "connection being open" -> >>>> "connect in progress"? >>>> >>>> That's all I have for now but I think there is further review work >>>> required on HttpURLConnection as some of that is tricky. >>>> >>>> -Alan. >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/9e32b54c/attachment.html From weijun.wang at oracle.com Mon May 13 06:29:05 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 May 2013 21:29:05 +0800 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <518CDB4F.5010607@oracle.com> References: <518CDB4F.5010607@oracle.com> Message-ID: <5190EAA1.2030401@oracle.com> Hi Michael Until now, for all types of permissions, the "actions" property takes the form of a comma separated list, and it's always accumulative. For example, it can be "read", or "write", or "read, write". In fact, the policytool makes use of this style so that you can click on single actions items to create a combined one. Now with HttpURLPermission, this is no longer true. Of course, there is no way to list single items for HttpURLPermission (no wellknown header name) so the new style doesn't really affect policytool that much. It's just that I realized this difference when trying to support this new Permission type in policytool. To use the old style, "GET,POST:Header1,Header2" will have to be rewritten to "GET:Header1, GET:Header2, POST: Header1, POST:Header2". The more the items are, the more complicated it will be. I am not sure how many methods and headers you would need in a typical use case. Thanks Max On 5/10/13 7:34 PM, Michael McMahon wrote: > Hi, > > This is the webrev for the HttpURLPermission addition. > As well as the new permission class, the change > includes the use of the permission in java.net.HttpURLConnection. > > The code basically checks for a HttpURLPermission in plainConnect(), > getInputStream() and getOutputStream() for the request and if > the caller has permission the request is executed in a doPrivileged() > block. When the limited doPrivileged feature is integrated, I will > change the doPrivileged() call to limit the privilege elevation to a single > SocketPermission (as shown in the code comments). > > The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ > > Thanks > Michael From michael.x.mcmahon at oracle.com Mon May 13 06:38:53 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 14:38:53 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190EAA1.2030401@oracle.com> References: <518CDB4F.5010607@oracle.com> <5190EAA1.2030401@oracle.com> Message-ID: <5190ECED.6050305@oracle.com> On 13/05/13 14:29, Weijun Wang wrote: > Hi Michael > > Until now, for all types of permissions, the "actions" property takes > the form of a comma separated list, and it's always accumulative. For > example, it can be "read", or "write", or "read, write". In fact, the > policytool makes use of this style so that you can click on single > actions items to create a combined one. > > Now with HttpURLPermission, this is no longer true. > > Of course, there is no way to list single items for HttpURLPermission > (no wellknown header name) so the new style doesn't really affect > policytool that much. It's just that I realized this difference when > trying to support this new Permission type in policytool. > Max If I understand you right, the difference isn't the fact that the list elements "accumulate", but that the range of possible values is unlimited. Of course, there is a syntax difference (with the ":" char) also. > To use the old style, "GET,POST:Header1,Header2" will have to be > rewritten to "GET:Header1, GET:Header2, POST: Header1, POST:Header2". > The more the items are, the more complicated it will be. I am not sure > how many methods and headers you would need in a typical use case. > I'm not sure I follow this. The second example isn't supported in HttpURLPermission. You would just create four separate permission objects if that's what you want to grant. I imagine that typically only small numbers of headers (5 or less?) would typically be used. Michael > Thanks > Max > > > On 5/10/13 7:34 PM, Michael McMahon wrote: >> Hi, >> >> This is the webrev for the HttpURLPermission addition. >> As well as the new permission class, the change >> includes the use of the permission in java.net.HttpURLConnection. >> >> The code basically checks for a HttpURLPermission in plainConnect(), >> getInputStream() and getOutputStream() for the request and if >> the caller has permission the request is executed in a doPrivileged() >> block. When the limited doPrivileged feature is integrated, I will >> change the doPrivileged() call to limit the privilege elevation to a >> single >> SocketPermission (as shown in the code comments). >> >> The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >> >> Thanks >> Michael From michael.x.mcmahon at oracle.com Mon May 13 06:45:01 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 14:45:01 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> Message-ID: <5190EE5D.3040607@oracle.com> On 13/05/13 14:12, Vitaly Davidovich wrote: > > I get what you're saying about before/after, but the difference would > be that if it's called during then you get an exception purely due to > missing synchronization; in the before/after case, caller may observe > "stale" entries but that's fine, as you say. > How would that be? The only effect of synchronization is to ensure that the other call occurs before or after (so to speak). > Maybe headers aren't reset in practice, but this code looks suspect to > someone reading it. :) > Right, we shouldn't be depending on caller behavior, but I still don't see a problem to be fixed. Michael > Sent from my phone > > On May 13, 2013 9:05 AM, "Michael McMahon" > > > wrote: > > Hi Vitali, > > I was going to switch to use Arrays.asList() as you and Alan > suggested. So getHeaderNames() would look like: > > public List getHeaderNames() { > return Arrays.asList(keys); > } > > So, it turns out synchronizing nkeys and keys is no longer necessary. > It's true that reset() could be called during the call. But, it > could (in theory) be called > before or after either. In practice that won't happen, since the > request headers > aren't ever reset. > > Michael > > > > On 13/05/13 13:36, Vitaly Davidovich wrote: >> >> Actually, local may not work since getHeaders uses nkeys as well >> - can run into AIOBE. Probably best to just synchronize given >> current implementation. >> >> Sent from my phone >> >> On May 13, 2013 8:30 AM, "Vitaly Davidovich" > > wrote: >> >> Hi Michael, >> >> On the synchronized issue, I think you do need it; if >> someone, e.g., calls reset() while this method is running, >> you'll get NPE. Maybe pull the keys array into a local then >> and iterate over the local instead? >> >> Also, why LinkedList instead of ArrayList(or Arrays.asList, >> as Alan mentioned, although maybe caller is expected to >> modify the returned list)? >> >> Thanks >> >> Sent from my phone >> >> On May 13, 2013 6:42 AM, "Michael McMahon" >> > > wrote: >> >> Thanks for the review. On the javadoc comments, there are >> a couple >> of small spec changes that will probably happen after >> feature freeze anyway. >> So, that might be the best time to address the other >> javadoc issues. >> >> I agree with your other comments. On the synchronized >> method in MessageHeader, >> I don't believe it needs to be synchronized since the >> method is not relying on >> consistency between object fields, and the returned >> object can be >> modified before, during or after the method is called anyway. >> >> Michael >> >> On 12/05/13 08:13, Alan Bateman wrote: >> >> On 10/05/2013 12:34, Michael McMahon wrote: >> >> Hi, >> >> This is the webrev for the HttpURLPermission >> addition. >> As well as the new permission class, the change >> includes the use of the permission in >> java.net.HttpURLConnection. >> >> The code basically checks for a HttpURLPermission >> in plainConnect(), >> getInputStream() and getOutputStream() for the >> request and if >> the caller has permission the request is executed >> in a doPrivileged() >> block. When the limited doPrivileged feature is >> integrated, I will >> change the doPrivileged() call to limit the >> privilege elevation to a single >> SocketPermission (as shown in the code comments). >> >> The webrev is at >> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >> >> >> A partial review, focusing mostly on the spec as >> we've been through a few rounds on that part already. >> Overall I think the javadoc looks quite good. I >> realize someone suggested using lowercase "url" in >> the javadoc but as the usage is as an acronym then it >> might be clearer if it were in uppercase, maybe "URL >> string" to avoid any confusion with java.net.URL. >> >> I assume you'll add a copyright header to >> HttpURLPermission before pushing this. >> >> A minor comment on the javadoc tags is that you >> probably should use @throws instead of @exception. >> >> At a high-level it would be nice if the fields were >> final but I guess the parsing of actions and being >> serialized complicates this. >> >> setURI - this parses the URI rather than "sets" it so >> maybe it should be renamed. If you use URI.create >> then it would avoid needing to catch the >> URISyntaxException. >> >> normalizeMethods/normalizeHeaders- I assume these >> could use an ArrayList. >> >> HttpURLConnection - "if a security manager is >> installed", should this be "set"? >> >> MessageHeader - some of the methods are synchronized, >> some are not. I can't quite tell if getHeaderNames >> needs to be synchronized. Also is there any reason >> why this can't use Arrays.asList? >> >> HttpURLConnection.setRequestMethod - "connection >> being open" -> "connect in progress"? >> >> That's all I have for now but I think there is >> further review work required on HttpURLConnection as >> some of that is tricky. >> >> -Alan. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/e75eeb42/attachment.html From weijun.wang at oracle.com Mon May 13 06:54:47 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 May 2013 21:54:47 +0800 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190ECED.6050305@oracle.com> References: <518CDB4F.5010607@oracle.com> <5190EAA1.2030401@oracle.com> <5190ECED.6050305@oracle.com> Message-ID: <5190F0A7.80408@oracle.com> On 5/13/13 9:38 PM, Michael McMahon wrote: > On 13/05/13 14:29, Weijun Wang wrote: >> Hi Michael >> >> Until now, for all types of permissions, the "actions" property takes >> the form of a comma separated list, and it's always accumulative. For >> example, it can be "read", or "write", or "read, write". In fact, the >> policytool makes use of this style so that you can click on single >> actions items to create a combined one. >> >> Now with HttpURLPermission, this is no longer true. >> >> Of course, there is no way to list single items for HttpURLPermission >> (no wellknown header name) so the new style doesn't really affect >> policytool that much. It's just that I realized this difference when >> trying to support this new Permission type in policytool. >> > Max > > If I understand you right, the difference isn't the fact that the list > elements "accumulate", but that > the range of possible values is unlimited. Of course, there is a syntax > difference (with the ":" char) also. The components on the two sides of ":" have different meanings, so you cannot make "A:B:C:D" from "A:B" and "C:D". That's what I mean "not accumulative", at least, cannot be accumulated use simple string concatenation. Yes, for existing Permission types, actions only have limited possible values, but it's not restrictive to 1 or 2. > >> To use the old style, "GET,POST:Header1,Header2" will have to be >> rewritten to "GET:Header1, GET:Header2, POST: Header1, POST:Header2". >> The more the items are, the more complicated it will be. I am not sure >> how many methods and headers you would need in a typical use case. >> > > I'm not sure I follow this. The second example isn't supported in > HttpURLPermission. Yes, I can see that from the CCC. > You would > just create four separate permission objects if that's what you want to > grant. I imagine that typically > only small numbers of headers (5 or less?) would typically be used. And you normally need multiple methods as well? Thanks Max > > Michael > >> Thanks >> Max >> >> >> On 5/10/13 7:34 PM, Michael McMahon wrote: >>> Hi, >>> >>> This is the webrev for the HttpURLPermission addition. >>> As well as the new permission class, the change >>> includes the use of the permission in java.net.HttpURLConnection. >>> >>> The code basically checks for a HttpURLPermission in plainConnect(), >>> getInputStream() and getOutputStream() for the request and if >>> the caller has permission the request is executed in a doPrivileged() >>> block. When the limited doPrivileged feature is integrated, I will >>> change the doPrivileged() call to limit the privilege elevation to a >>> single >>> SocketPermission (as shown in the code comments). >>> >>> The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>> >>> Thanks >>> Michael > From michael.x.mcmahon at oracle.com Mon May 13 07:13:02 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 15:13:02 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190F0A7.80408@oracle.com> References: <518CDB4F.5010607@oracle.com> <5190EAA1.2030401@oracle.com> <5190ECED.6050305@oracle.com> <5190F0A7.80408@oracle.com> Message-ID: <5190F4EE.1050200@oracle.com> Okay, I get you now. I think this is just a (complicating) consequence of the syntax. I don't think there is anything we can do about it. BTW, I probably should warn you that we are looking at changing the spec again to allow port number ranges, the same as SocketPermission... - Michael On 13/05/13 14:54, Weijun Wang wrote: > > > On 5/13/13 9:38 PM, Michael McMahon wrote: >> On 13/05/13 14:29, Weijun Wang wrote: >>> Hi Michael >>> >>> Until now, for all types of permissions, the "actions" property takes >>> the form of a comma separated list, and it's always accumulative. For >>> example, it can be "read", or "write", or "read, write". In fact, the >>> policytool makes use of this style so that you can click on single >>> actions items to create a combined one. >>> >>> Now with HttpURLPermission, this is no longer true. >>> >>> Of course, there is no way to list single items for HttpURLPermission >>> (no wellknown header name) so the new style doesn't really affect >>> policytool that much. It's just that I realized this difference when >>> trying to support this new Permission type in policytool. >>> >> Max >> >> If I understand you right, the difference isn't the fact that the list >> elements "accumulate", but that >> the range of possible values is unlimited. Of course, there is a syntax >> difference (with the ":" char) also. > > The components on the two sides of ":" have different meanings, so you > cannot make "A:B:C:D" from "A:B" and "C:D". That's what I mean "not > accumulative", at least, cannot be accumulated use simple string > concatenation. > > Yes, for existing Permission types, actions only have limited possible > values, but it's not restrictive to 1 or 2. > >> >>> To use the old style, "GET,POST:Header1,Header2" will have to be >>> rewritten to "GET:Header1, GET:Header2, POST: Header1, POST:Header2". >>> The more the items are, the more complicated it will be. I am not sure >>> how many methods and headers you would need in a typical use case. >>> >> >> I'm not sure I follow this. The second example isn't supported in >> HttpURLPermission. > > Yes, I can see that from the CCC. > >> You would >> just create four separate permission objects if that's what you want to >> grant. I imagine that typically >> only small numbers of headers (5 or less?) would typically be used. > > And you normally need multiple methods as well? > > Thanks > Max > >> >> Michael >> >>> Thanks >>> Max >>> >>> >>> On 5/10/13 7:34 PM, Michael McMahon wrote: >>>> Hi, >>>> >>>> This is the webrev for the HttpURLPermission addition. >>>> As well as the new permission class, the change >>>> includes the use of the permission in java.net.HttpURLConnection. >>>> >>>> The code basically checks for a HttpURLPermission in plainConnect(), >>>> getInputStream() and getOutputStream() for the request and if >>>> the caller has permission the request is executed in a doPrivileged() >>>> block. When the limited doPrivileged feature is integrated, I will >>>> change the doPrivileged() call to limit the privilege elevation to a >>>> single >>>> SocketPermission (as shown in the code comments). >>>> >>>> The webrev is at >>>> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>>> >>>> Thanks >>>> Michael >> From vitalyd at gmail.com Mon May 13 07:19:54 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 May 2013 10:19:54 -0400 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190EE5D.3040607@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> Message-ID: If the array or nkeys is modified while getHeaders is running, you can get NPE or ArrayIndexOutOfBoundsException. If you synchronize, the method returns some list of headers, and it's true that as soon as it returns some other thread can mutate the headers and thus the returned list isn't "in-sync" with current headers, but there's no exception. Sent from my phone On May 13, 2013 9:45 AM, "Michael McMahon" wrote: > On 13/05/13 14:12, Vitaly Davidovich wrote: > > I get what you're saying about before/after, but the difference would be > that if it's called during then you get an exception purely due to missing > synchronization; in the before/after case, caller may observe "stale" > entries but that's fine, as you say. > > > How would that be? The only effect of synchronization is to ensure that > the other call > occurs before or after (so to speak). > > Maybe headers aren't reset in practice, but this code looks suspect to > someone reading it. :) > > > Right, we shouldn't be depending on caller behavior, but I still don't see > a problem to be fixed. > > Michael > > Sent from my phone > On May 13, 2013 9:05 AM, "Michael McMahon" > wrote: > >> Hi Vitali, >> >> I was going to switch to use Arrays.asList() as you and Alan suggested. >> So getHeaderNames() would look like: >> >> public List getHeaderNames() { >> return Arrays.asList(keys); >> } >> >> So, it turns out synchronizing nkeys and keys is no longer necessary. >> It's true that reset() could be called during the call. But, it could (in >> theory) be called >> before or after either. In practice that won't happen, since the request >> headers >> aren't ever reset. >> >> Michael >> >> >> >> On 13/05/13 13:36, Vitaly Davidovich wrote: >> >> Actually, local may not work since getHeaders uses nkeys as well - can >> run into AIOBE. Probably best to just synchronize given current >> implementation. >> >> Sent from my phone >> On May 13, 2013 8:30 AM, "Vitaly Davidovich" wrote: >> >>> Hi Michael, >>> >>> On the synchronized issue, I think you do need it; if someone, e.g., >>> calls reset() while this method is running, you'll get NPE. Maybe pull the >>> keys array into a local then and iterate over the local instead? >>> >>> Also, why LinkedList instead of ArrayList(or Arrays.asList, as Alan >>> mentioned, although maybe caller is expected to modify the returned list)? >>> >>> Thanks >>> >>> Sent from my phone >>> On May 13, 2013 6:42 AM, "Michael McMahon" >>> wrote: >>> >>>> Thanks for the review. On the javadoc comments, there are a couple >>>> of small spec changes that will probably happen after feature freeze >>>> anyway. >>>> So, that might be the best time to address the other javadoc issues. >>>> >>>> I agree with your other comments. On the synchronized method in >>>> MessageHeader, >>>> I don't believe it needs to be synchronized since the method is not >>>> relying on >>>> consistency between object fields, and the returned object can be >>>> modified before, during or after the method is called anyway. >>>> >>>> Michael >>>> >>>> On 12/05/13 08:13, Alan Bateman wrote: >>>> >>>>> On 10/05/2013 12:34, Michael McMahon wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the webrev for the HttpURLPermission addition. >>>>>> As well as the new permission class, the change >>>>>> includes the use of the permission in java.net.HttpURLConnection. >>>>>> >>>>>> The code basically checks for a HttpURLPermission in plainConnect(), >>>>>> getInputStream() and getOutputStream() for the request and if >>>>>> the caller has permission the request is executed in a doPrivileged() >>>>>> block. When the limited doPrivileged feature is integrated, I will >>>>>> change the doPrivileged() call to limit the privilege elevation to a >>>>>> single >>>>>> SocketPermission (as shown in the code comments). >>>>>> >>>>>> The webrev is at >>>>>> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>>>>> >>>>> A partial review, focusing mostly on the spec as we've been through a >>>>> few rounds on that part already. Overall I think the javadoc looks quite >>>>> good. I realize someone suggested using lowercase "url" in the javadoc but >>>>> as the usage is as an acronym then it might be clearer if it were in >>>>> uppercase, maybe "URL string" to avoid any confusion with java.net.URL. >>>>> >>>>> I assume you'll add a copyright header to HttpURLPermission before >>>>> pushing this. >>>>> >>>>> A minor comment on the javadoc tags is that you probably should use >>>>> @throws instead of @exception. >>>>> >>>>> At a high-level it would be nice if the fields were final but I guess >>>>> the parsing of actions and being serialized complicates this. >>>>> >>>>> setURI - this parses the URI rather than "sets" it so maybe it should >>>>> be renamed. If you use URI.create then it would avoid needing to catch the >>>>> URISyntaxException. >>>>> >>>>> normalizeMethods/normalizeHeaders- I assume these could use an >>>>> ArrayList. >>>>> >>>>> HttpURLConnection - "if a security manager is installed", should this >>>>> be "set"? >>>>> >>>>> MessageHeader - some of the methods are synchronized, some are not. I >>>>> can't quite tell if getHeaderNames needs to be synchronized. Also is there >>>>> any reason why this can't use Arrays.asList? >>>>> >>>>> HttpURLConnection.setRequestMethod - "connection being open" -> >>>>> "connect in progress"? >>>>> >>>>> That's all I have for now but I think there is further review work >>>>> required on HttpURLConnection as some of that is tricky. >>>>> >>>>> -Alan. >>>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/5f6dfea4/attachment.html From michael.x.mcmahon at oracle.com Mon May 13 07:43:40 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 15:43:40 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> Message-ID: <5190FC1C.8000402@oracle.com> Okay, adding or removing elements would do that (though it won't happen in practice) as opposed to reset(). So, I guess it's better practice to make it synchronized. Thanks Michael. On 13/05/13 15:19, Vitaly Davidovich wrote: > > If the array or nkeys is modified while getHeaders is running, you can > get NPE or ArrayIndexOutOfBoundsException. If you synchronize, the > method returns some list of headers, and it's true that as soon as it > returns some other thread can mutate the headers and thus the returned > list isn't "in-sync" with current headers, but there's no exception. > > Sent from my phone > > On May 13, 2013 9:45 AM, "Michael McMahon" > > > wrote: > > On 13/05/13 14:12, Vitaly Davidovich wrote: >> >> I get what you're saying about before/after, but the difference >> would be that if it's called during then you get an exception >> purely due to missing synchronization; in the before/after case, >> caller may observe "stale" entries but that's fine, as you say. >> > > How would that be? The only effect of synchronization is to ensure > that the other call > occurs before or after (so to speak). > >> Maybe headers aren't reset in practice, but this code looks >> suspect to someone reading it. :) >> > > Right, we shouldn't be depending on caller behavior, but I still > don't see a problem to be fixed. > > Michael > >> Sent from my phone >> >> On May 13, 2013 9:05 AM, "Michael McMahon" >> > > wrote: >> >> Hi Vitali, >> >> I was going to switch to use Arrays.asList() as you and Alan >> suggested. So getHeaderNames() would look like: >> >> public List getHeaderNames() { >> return Arrays.asList(keys); >> } >> >> So, it turns out synchronizing nkeys and keys is no longer >> necessary. >> It's true that reset() could be called during the call. But, >> it could (in theory) be called >> before or after either. In practice that won't happen, since >> the request headers >> aren't ever reset. >> >> Michael >> >> >> >> On 13/05/13 13:36, Vitaly Davidovich wrote: >>> >>> Actually, local may not work since getHeaders uses nkeys as >>> well - can run into AIOBE. Probably best to just >>> synchronize given current implementation. >>> >>> Sent from my phone >>> >>> On May 13, 2013 8:30 AM, "Vitaly Davidovich" >>> > wrote: >>> >>> Hi Michael, >>> >>> On the synchronized issue, I think you do need it; if >>> someone, e.g., calls reset() while this method is >>> running, you'll get NPE. Maybe pull the keys array into >>> a local then and iterate over the local instead? >>> >>> Also, why LinkedList instead of ArrayList(or >>> Arrays.asList, as Alan mentioned, although maybe caller >>> is expected to modify the returned list)? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On May 13, 2013 6:42 AM, "Michael McMahon" >>> >> > wrote: >>> >>> Thanks for the review. On the javadoc comments, >>> there are a couple >>> of small spec changes that will probably happen >>> after feature freeze anyway. >>> So, that might be the best time to address the other >>> javadoc issues. >>> >>> I agree with your other comments. On the >>> synchronized method in MessageHeader, >>> I don't believe it needs to be synchronized since >>> the method is not relying on >>> consistency between object fields, and the returned >>> object can be >>> modified before, during or after the method is >>> called anyway. >>> >>> Michael >>> >>> On 12/05/13 08:13, Alan Bateman wrote: >>> >>> On 10/05/2013 12:34, Michael McMahon wrote: >>> >>> Hi, >>> >>> This is the webrev for the HttpURLPermission >>> addition. >>> As well as the new permission class, the change >>> includes the use of the permission in >>> java.net.HttpURLConnection. >>> >>> The code basically checks for a >>> HttpURLPermission in plainConnect(), >>> getInputStream() and getOutputStream() for >>> the request and if >>> the caller has permission the request is >>> executed in a doPrivileged() >>> block. When the limited doPrivileged feature >>> is integrated, I will >>> change the doPrivileged() call to limit the >>> privilege elevation to a single >>> SocketPermission (as shown in the code >>> comments). >>> >>> The webrev is at >>> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>> >>> >>> A partial review, focusing mostly on the spec as >>> we've been through a few rounds on that part >>> already. Overall I think the javadoc looks quite >>> good. I realize someone suggested using >>> lowercase "url" in the javadoc but as the usage >>> is as an acronym then it might be clearer if it >>> were in uppercase, maybe "URL string" to avoid >>> any confusion with java.net.URL. >>> >>> I assume you'll add a copyright header to >>> HttpURLPermission before pushing this. >>> >>> A minor comment on the javadoc tags is that you >>> probably should use @throws instead of @exception. >>> >>> At a high-level it would be nice if the fields >>> were final but I guess the parsing of actions >>> and being serialized complicates this. >>> >>> setURI - this parses the URI rather than "sets" >>> it so maybe it should be renamed. If you use >>> URI.create then it would avoid needing to catch >>> the URISyntaxException. >>> >>> normalizeMethods/normalizeHeaders- I assume >>> these could use an ArrayList. >>> >>> HttpURLConnection - "if a security manager is >>> installed", should this be "set"? >>> >>> MessageHeader - some of the methods are >>> synchronized, some are not. I can't quite tell >>> if getHeaderNames needs to be synchronized. Also >>> is there any reason why this can't use >>> Arrays.asList? >>> >>> HttpURLConnection.setRequestMethod - "connection >>> being open" -> "connect in progress"? >>> >>> That's all I have for now but I think there is >>> further review work required on >>> HttpURLConnection as some of that is tricky. >>> >>> -Alan. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/26d87ca3/attachment.html From vitalyd at gmail.com Mon May 13 08:10:44 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 13 May 2013 11:10:44 -0400 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <5190FC1C.8000402@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> Message-ID: If the headers are supposed to be parsed and then readonly, then the class can be made immutable? Don't know how much work that would entail. To minimize synch overhead, I think you can assign the array and nkeys to locals inside a synch region and then do the copying outside of it. Sent from my phone On May 13, 2013 10:43 AM, "Michael McMahon" wrote: > Okay, adding or removing elements would do that (though it won't happen > in practice) > as opposed to reset(). So, I guess it's better practice to make it > synchronized. > > Thanks > Michael. > > On 13/05/13 15:19, Vitaly Davidovich wrote: > > If the array or nkeys is modified while getHeaders is running, you can get > NPE or ArrayIndexOutOfBoundsException. If you synchronize, the method > returns some list of headers, and it's true that as soon as it returns some > other thread can mutate the headers and thus the returned list isn't > "in-sync" with current headers, but there's no exception. > > Sent from my phone > On May 13, 2013 9:45 AM, "Michael McMahon" > wrote: > >> On 13/05/13 14:12, Vitaly Davidovich wrote: >> >> I get what you're saying about before/after, but the difference would be >> that if it's called during then you get an exception purely due to missing >> synchronization; in the before/after case, caller may observe "stale" >> entries but that's fine, as you say. >> >> >> How would that be? The only effect of synchronization is to ensure that >> the other call >> occurs before or after (so to speak). >> >> Maybe headers aren't reset in practice, but this code looks suspect to >> someone reading it. :) >> >> >> Right, we shouldn't be depending on caller behavior, but I still don't >> see a problem to be fixed. >> >> Michael >> >> Sent from my phone >> On May 13, 2013 9:05 AM, "Michael McMahon" >> wrote: >> >>> Hi Vitali, >>> >>> I was going to switch to use Arrays.asList() as you and Alan suggested. >>> So getHeaderNames() would look like: >>> >>> public List getHeaderNames() { >>> return Arrays.asList(keys); >>> } >>> >>> So, it turns out synchronizing nkeys and keys is no longer necessary. >>> It's true that reset() could be called during the call. But, it could >>> (in theory) be called >>> before or after either. In practice that won't happen, since the request >>> headers >>> aren't ever reset. >>> >>> Michael >>> >>> >>> >>> On 13/05/13 13:36, Vitaly Davidovich wrote: >>> >>> Actually, local may not work since getHeaders uses nkeys as well - can >>> run into AIOBE. Probably best to just synchronize given current >>> implementation. >>> >>> Sent from my phone >>> On May 13, 2013 8:30 AM, "Vitaly Davidovich" wrote: >>> >>>> Hi Michael, >>>> >>>> On the synchronized issue, I think you do need it; if someone, e.g., >>>> calls reset() while this method is running, you'll get NPE. Maybe pull the >>>> keys array into a local then and iterate over the local instead? >>>> >>>> Also, why LinkedList instead of ArrayList(or Arrays.asList, as Alan >>>> mentioned, although maybe caller is expected to modify the returned list)? >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> On May 13, 2013 6:42 AM, "Michael McMahon" < >>>> michael.x.mcmahon at oracle.com> wrote: >>>> >>>>> Thanks for the review. On the javadoc comments, there are a couple >>>>> of small spec changes that will probably happen after feature freeze >>>>> anyway. >>>>> So, that might be the best time to address the other javadoc issues. >>>>> >>>>> I agree with your other comments. On the synchronized method in >>>>> MessageHeader, >>>>> I don't believe it needs to be synchronized since the method is not >>>>> relying on >>>>> consistency between object fields, and the returned object can be >>>>> modified before, during or after the method is called anyway. >>>>> >>>>> Michael >>>>> >>>>> On 12/05/13 08:13, Alan Bateman wrote: >>>>> >>>>>> On 10/05/2013 12:34, Michael McMahon wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is the webrev for the HttpURLPermission addition. >>>>>>> As well as the new permission class, the change >>>>>>> includes the use of the permission in java.net.HttpURLConnection. >>>>>>> >>>>>>> The code basically checks for a HttpURLPermission in plainConnect(), >>>>>>> getInputStream() and getOutputStream() for the request and if >>>>>>> the caller has permission the request is executed in a doPrivileged() >>>>>>> block. When the limited doPrivileged feature is integrated, I will >>>>>>> change the doPrivileged() call to limit the privilege elevation to a >>>>>>> single >>>>>>> SocketPermission (as shown in the code comments). >>>>>>> >>>>>>> The webrev is at >>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>>>>>> >>>>>> A partial review, focusing mostly on the spec as we've been through a >>>>>> few rounds on that part already. Overall I think the javadoc looks quite >>>>>> good. I realize someone suggested using lowercase "url" in the javadoc but >>>>>> as the usage is as an acronym then it might be clearer if it were in >>>>>> uppercase, maybe "URL string" to avoid any confusion with java.net.URL. >>>>>> >>>>>> I assume you'll add a copyright header to HttpURLPermission before >>>>>> pushing this. >>>>>> >>>>>> A minor comment on the javadoc tags is that you probably should use >>>>>> @throws instead of @exception. >>>>>> >>>>>> At a high-level it would be nice if the fields were final but I guess >>>>>> the parsing of actions and being serialized complicates this. >>>>>> >>>>>> setURI - this parses the URI rather than "sets" it so maybe it should >>>>>> be renamed. If you use URI.create then it would avoid needing to catch the >>>>>> URISyntaxException. >>>>>> >>>>>> normalizeMethods/normalizeHeaders- I assume these could use an >>>>>> ArrayList. >>>>>> >>>>>> HttpURLConnection - "if a security manager is installed", should this >>>>>> be "set"? >>>>>> >>>>>> MessageHeader - some of the methods are synchronized, some are not. I >>>>>> can't quite tell if getHeaderNames needs to be synchronized. Also is there >>>>>> any reason why this can't use Arrays.asList? >>>>>> >>>>>> HttpURLConnection.setRequestMethod - "connection being open" -> >>>>>> "connect in progress"? >>>>>> >>>>>> That's all I have for now but I think there is further review work >>>>>> required on HttpURLConnection as some of that is tricky. >>>>>> >>>>>> -Alan. >>>>>> >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/0dda67c1/attachment.html From michael.x.mcmahon at oracle.com Mon May 13 08:28:33 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 May 2013 16:28:33 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> Message-ID: <519106A1.7040704@oracle.com> No, the class is used for both request and response headers. Also, Arrays.asList() doesn't work in this case because we have to account for the number of elements used. So, something like what you are suggesting below should work. Michael On 13/05/13 16:10, Vitaly Davidovich wrote: > > If the headers are supposed to be parsed and then readonly, then the > class can be made immutable? Don't know how much work that would entail. > > To minimize synch overhead, I think you can assign the array and nkeys > to locals inside a synch region and then do the copying outside of it. > > Sent from my phone > > On May 13, 2013 10:43 AM, "Michael McMahon" > > > wrote: > > Okay, adding or removing elements would do that (though it won't > happen in practice) > as opposed to reset(). So, I guess it's better practice to make it > synchronized. > > Thanks > Michael. > > On 13/05/13 15:19, Vitaly Davidovich wrote: >> >> If the array or nkeys is modified while getHeaders is running, >> you can get NPE or ArrayIndexOutOfBoundsException. If you >> synchronize, the method returns some list of headers, and it's >> true that as soon as it returns some other thread can mutate the >> headers and thus the returned list isn't "in-sync" with current >> headers, but there's no exception. >> >> Sent from my phone >> >> On May 13, 2013 9:45 AM, "Michael McMahon" >> > > wrote: >> >> On 13/05/13 14:12, Vitaly Davidovich wrote: >>> >>> I get what you're saying about before/after, but the >>> difference would be that if it's called during then you get >>> an exception purely due to missing synchronization; in the >>> before/after case, caller may observe "stale" entries but >>> that's fine, as you say. >>> >> >> How would that be? The only effect of synchronization is to >> ensure that the other call >> occurs before or after (so to speak). >> >>> Maybe headers aren't reset in practice, but this code looks >>> suspect to someone reading it. :) >>> >> >> Right, we shouldn't be depending on caller behavior, but I >> still don't see a problem to be fixed. >> >> Michael >> >>> Sent from my phone >>> >>> On May 13, 2013 9:05 AM, "Michael McMahon" >>> >> > wrote: >>> >>> Hi Vitali, >>> >>> I was going to switch to use Arrays.asList() as you and >>> Alan suggested. So getHeaderNames() would look like: >>> >>> public List getHeaderNames() { >>> return Arrays.asList(keys); >>> } >>> >>> So, it turns out synchronizing nkeys and keys is no >>> longer necessary. >>> It's true that reset() could be called during the call. >>> But, it could (in theory) be called >>> before or after either. In practice that won't happen, >>> since the request headers >>> aren't ever reset. >>> >>> Michael >>> >>> >>> >>> On 13/05/13 13:36, Vitaly Davidovich wrote: >>>> >>>> Actually, local may not work since getHeaders uses >>>> nkeys as well - can run into AIOBE. Probably best to >>>> just synchronize given current implementation. >>>> >>>> Sent from my phone >>>> >>>> On May 13, 2013 8:30 AM, "Vitaly Davidovich" >>>> > wrote: >>>> >>>> Hi Michael, >>>> >>>> On the synchronized issue, I think you do need it; >>>> if someone, e.g., calls reset() while this method >>>> is running, you'll get NPE. Maybe pull the keys >>>> array into a local then and iterate over the local >>>> instead? >>>> >>>> Also, why LinkedList instead of ArrayList(or >>>> Arrays.asList, as Alan mentioned, although maybe >>>> caller is expected to modify the returned list)? >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On May 13, 2013 6:42 AM, "Michael McMahon" >>>> >>> > wrote: >>>> >>>> Thanks for the review. On the javadoc comments, >>>> there are a couple >>>> of small spec changes that will probably happen >>>> after feature freeze anyway. >>>> So, that might be the best time to address the >>>> other javadoc issues. >>>> >>>> I agree with your other comments. On the >>>> synchronized method in MessageHeader, >>>> I don't believe it needs to be synchronized >>>> since the method is not relying on >>>> consistency between object fields, and the >>>> returned object can be >>>> modified before, during or after the method is >>>> called anyway. >>>> >>>> Michael >>>> >>>> On 12/05/13 08:13, Alan Bateman wrote: >>>> >>>> On 10/05/2013 12:34, Michael McMahon wrote: >>>> >>>> Hi, >>>> >>>> This is the webrev for the >>>> HttpURLPermission addition. >>>> As well as the new permission class, >>>> the change >>>> includes the use of the permission in >>>> java.net.HttpURLConnection. >>>> >>>> The code basically checks for a >>>> HttpURLPermission in plainConnect(), >>>> getInputStream() and getOutputStream() >>>> for the request and if >>>> the caller has permission the request >>>> is executed in a doPrivileged() >>>> block. When the limited doPrivileged >>>> feature is integrated, I will >>>> change the doPrivileged() call to limit >>>> the privilege elevation to a single >>>> SocketPermission (as shown in the code >>>> comments). >>>> >>>> The webrev is at >>>> http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/ >>>> >>>> >>>> A partial review, focusing mostly on the >>>> spec as we've been through a few rounds on >>>> that part already. Overall I think the >>>> javadoc looks quite good. I realize someone >>>> suggested using lowercase "url" in the >>>> javadoc but as the usage is as an acronym >>>> then it might be clearer if it were in >>>> uppercase, maybe "URL string" to avoid any >>>> confusion with java.net.URL. >>>> >>>> I assume you'll add a copyright header to >>>> HttpURLPermission before pushing this. >>>> >>>> A minor comment on the javadoc tags is that >>>> you probably should use @throws instead of >>>> @exception. >>>> >>>> At a high-level it would be nice if the >>>> fields were final but I guess the parsing >>>> of actions and being serialized complicates >>>> this. >>>> >>>> setURI - this parses the URI rather than >>>> "sets" it so maybe it should be renamed. If >>>> you use URI.create then it would avoid >>>> needing to catch the URISyntaxException. >>>> >>>> normalizeMethods/normalizeHeaders- I assume >>>> these could use an ArrayList. >>>> >>>> HttpURLConnection - "if a security manager >>>> is installed", should this be "set"? >>>> >>>> MessageHeader - some of the methods are >>>> synchronized, some are not. I can't quite >>>> tell if getHeaderNames needs to be >>>> synchronized. Also is there any reason why >>>> this can't use Arrays.asList? >>>> >>>> HttpURLConnection.setRequestMethod - >>>> "connection being open" -> "connect in >>>> progress"? >>>> >>>> That's all I have for now but I think there >>>> is further review work required on >>>> HttpURLConnection as some of that is tricky. >>>> >>>> -Alan. >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130513/f2d59628/attachment.html From kurchi.subhra.hazra at oracle.com Mon May 13 12:17:18 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 13 May 2013 12:17:18 -0700 Subject: Code Review Request: 6328537: Improve javadocs for Socket class by adding references to SocketOptions In-Reply-To: <5190BE27.6060708@oracle.com> References: <518ADA62.30808@oracle.com> <518D8429.7060903@oracle.com> <5190BE27.6060708@oracle.com> Message-ID: <51913C3E.8060206@oracle.com> On 5/13/2013 3:19 AM, Chris Hegarty wrote: > On 11/05/2013 00:35, Kurchi Hazra wrote: >> This is a simple improvement in the javadocs of the Socket and >> ServerSocket >> classes, to cross-reference the SocketOptions class where appropriate. >> It looks >> like a lot of changes in the webrev, only because I have re-justified >> the text >> in some cases. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=6328537 >> Webrev:http://cr.openjdk.java.net/~khazra/6328537/webrev.00/ > > This will make navigating from these API's to the specification for > their respective options much easier. A simple change, but very user > friendly. > >> The specdiff isn't very helpful, but here it is: >> http://cr.openjdk.java.net/~khazra/6328537/specdiff.00/ > > Not at all. It gives confidence that nothing untoward has accidentally > changed. Especially, as you say, when there is significant realignment > of the method descriptions. - Right, I did not think of it in that way. > > As Alan pointed out, at some point we need to sort out the > relationship to StandardSocketOptions, but what you have is fine for now. - Thanks for reviewing, I'll push it post a CCC approval. - Kurchi From john.zavgren at oracle.com Mon May 13 13:14:07 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Mon, 13 May 2013 16:14:07 -0400 Subject: RFR JDK-8008972 In-Reply-To: <5134E539.80007@oracle.com> References: <5134E539.80007@oracle.com> Message-ID: <5191498F.2070508@oracle.com> Greetings: I posted a new webrev image: http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/ that fixes a memory leak. The leak in src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c is caused by an unfortunate interplay between two actions: 1.) dynamically allocating a larger packet buffer when the length of an incoming packet exceeds MAX_BUFFER_LEN. 2.) truncating a received packet so that it's length equals MAX_PACKET_LEN, when it exceeds this value. Action number two was embedded inside the code that implemented action number one, and action number two can change the length of the packet. Unfortunately, the original packet length was used as an indication that the packet buffer needed to be freed, and because the length of the packet may have changed after the allocation, the free() statement wasn't being executed in some cases. I fixed the problem by moving action number two so that it always precedes action number 1. This ensures that the packet length retains the same value across the malloc() and the free() operations, and therefore packet length can now be used as a reliable indication that dynamically allocated memory must be freed. I also noticed that there is a procedure in src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c that also dynamically allocates memory in a similar way, but it doesn't implement action number two. I added it. I also took advantage of this opportunity to fix spelling errors in other files in the same directory as the two previously mentioned files. On 03/04/2013 01:17 PM, Chris Hegarty wrote: > On 03/04/2013 04:28 PM, John Zavgren wrote: >> Greetings: >> >> I've posted a webrev image of a memory leak fix: >> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/ > > Sorry John, I don't see what the problem is that you are trying to > solve? Can you please explain why the original code has problems? > > Also, note that there are other places in the same function that do > the very same check. > > -Chris. > >> >> Thanks! >> John >> -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From mike.duigou at oracle.com Mon May 13 13:29:10 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 13 May 2013 20:29:10 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130513202933.B2B9C48A3A@hg.openjdk.java.net> Changeset: 6175fe5b07aa Author: bharadwaj Date: 2013-05-13 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6175fe5b07aa 8008687: MethodHandle code: allow static and invokespecial calls to interface methods Summary: Changes to support invocation of lambda methods compiled either as static interface methods and or private instance methods. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: f7fcfb204a69 Author: mduigou Date: 2013-05-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fcfb204a69 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java From kurchi.subhra.hazra at oracle.com Mon May 13 13:38:48 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Mon, 13 May 2013 20:38:48 +0000 Subject: hg: jdk8/tl/jdk: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive Message-ID: <20130513203900.39ACD48A3B@hg.openjdk.java.net> Changeset: 86c1e8c799f5 Author: khazra Date: 2013-05-13 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c1e8c799f5 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive Summary: Rearrange event-handling code to remove bottle-neck. Also reviewed by mhall at mhcomputing.net. Reviewed-by: chegar, alanb ! src/share/classes/sun/net/httpserver/ServerImpl.java From jonathan.gibbons at oracle.com Mon May 13 15:29:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 May 2013 22:29:30 +0000 Subject: hg: jdk8/tl/langtools: 8012929: Trees.getElement should work not only for declaration trees, but also for use-trees Message-ID: <20130513222934.CF4D748A3E@hg.openjdk.java.net> Changeset: 8dd528992c15 Author: jlahoda Date: 2013-05-10 15:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8dd528992c15 8012929: Trees.getElement should work not only for declaration trees, but also for use-trees Reviewed-by: jjg Contributed-by: Dusan Balek , Jan Lahoda ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/api/TestGetElementReference.java + test/tools/javac/api/TestGetElementReferenceData.java From xueming.shen at oracle.com Mon May 13 20:37:16 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 14 May 2013 03:37:16 +0000 Subject: hg: jdk8/tl/jdk: 8013386: (tz) Support tzdata2013c Message-ID: <20130514033738.288CA48A4A@hg.openjdk.java.net> Changeset: ae35fdbab949 Author: sherman Date: 2013-05-13 20:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae35fdbab949 8013386: (tz) Support tzdata2013c Summary: updated tz data to version 2013c Reviewed-by: peytoia, okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/Rule.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab From joe.darcy at oracle.com Mon May 13 22:17:06 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 14 May 2013 05:17:06 +0000 Subject: hg: jdk8/tl/jdk: 8014365: Restore Objects.requireNonNull(T, Supplier) Message-ID: <20130514051719.2348548A4D@hg.openjdk.java.net> Changeset: a50bad038f31 Author: darcy Date: 2013-05-13 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50bad038f31 8014365: Restore Objects.requireNonNull(T, Supplier) Reviewed-by: mduigou ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java From michael.x.mcmahon at oracle.com Tue May 14 04:54:29 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 14 May 2013 12:54:29 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <519106A1.7040704@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> Message-ID: <519225F5.2050303@oracle.com> I have updated the webrev for this at: http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/ Thanks Michael. From alan.bateman at oracle.com Tue May 14 06:34:06 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 14 May 2013 13:34:06 +0000 Subject: hg: jdk8/tl/jdk: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Message-ID: <20130514133439.831AD48A64@hg.openjdk.java.net> Changeset: b315cb9a7544 Author: alanb Date: 2013-05-14 14:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b315cb9a7544 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Reviewed-by: lancea ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java From jonathan.gibbons at oracle.com Tue May 14 10:17:50 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 17:17:50 +0000 Subject: hg: jdk8/tl/langtools: 17 new changesets Message-ID: <20130514171841.689DE48A7C@hg.openjdk.java.net> Changeset: 8ea30d59ac41 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8ea30d59ac41 8010440: Replace int constants in LinkInfoImpl with enum Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java Changeset: 74cd21f2c2fe Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/74cd21f2c2fe 8011642: Remove LinkOutput in favor of direct use of Content Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java Changeset: 7a9ef837e57f Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a9ef837e57f 8011650: reduce use of RawHtml nodes in doclet Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java Changeset: 6ea964c78845 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6ea964c78845 8011651: simplify LinkInfoImpl API Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java Changeset: e6c5b5ee9fac Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6c5b5ee9fac 8011662: Remove single instance of resource with HTML from doclet resource bundle Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: ce4f0769b4b2 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce4f0769b4b2 8011668: Allow HTMLWriter.getResource to take Content args Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: 4c43e51433ba Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4c43e51433ba 8011288: Erratic/inconsistent indentation of signatures Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java + test/com/sun/javadoc/testIndentation/TestIndentation.java + test/com/sun/javadoc/testIndentation/p/Indent.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java Changeset: 7af0fa419a2b Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7af0fa419a2b 8012174: {@literal} and {@code} should use \"new\" Taglet, not old. Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java Changeset: 6a5288a298fd Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6a5288a298fd 8012175: Convert TagletOutputImpl to use ContentBuilder instead of StringBuilder Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java Changeset: 76a691e3e961 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76a691e3e961 8012176: reduce use of TagletOutputImpl.toString Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java Changeset: 937aa020c667 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/937aa020c667 8012177: HTMLDocletWriter methods should generate Content, not Strings Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java Changeset: bd51ca92c013 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bd51ca92c013 8012178: Cleanup use of Util.escapeHtmlChars Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: df4f44800923 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/df4f44800923 8012183: replace some uses of Configuration.getText with Configuration.getResource Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: 051b728cfe90 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/051b728cfe90 8012180: Speed up removeNonInlineHtmlTags Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 25c89a492f14 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25c89a492f14 8012295: Cleanup JavaFX features in standard doclet Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: 081d7c72ee92 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/081d7c72ee92 8012311: Cleanup names and duplicatre code in TagletManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: ca8808c88f94 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca8808c88f94 8012308: Remove TagletOutput in favor of direct use of Content Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java From kurchi.subhra.hazra at oracle.com Tue May 14 11:51:57 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Tue, 14 May 2013 18:51:57 +0000 Subject: hg: jdk8/tl/jdk: 6328537: Improve javadocs for Socket class by adding references to SocketOptions Message-ID: <20130514185220.F24EA48A80@hg.openjdk.java.net> Changeset: 790d292ee761 Author: khazra Date: 2013-05-14 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/790d292ee761 6328537: Improve javadocs for Socket class by adding references to SocketOptions Summary: Insert references to SocketOptions.java where applicable Reviewed-by: alanb, chegar ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java From jonathan.gibbons at oracle.com Tue May 14 12:57:22 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 19:57:22 +0000 Subject: hg: jdk8/tl/langtools: 8014461: genstubs creates default native methods Message-ID: <20130514195727.3331448A8C@hg.openjdk.java.net> Changeset: 46b9c25f7024 Author: jjg Date: 2013-05-14 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46b9c25f7024 8014461: genstubs creates default native methods Reviewed-by: alanb ! make/tools/genstubs/GenStubs.java From jonathan.gibbons at oracle.com Tue May 14 13:55:46 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 20:55:46 +0000 Subject: hg: jdk8/tl/langtools: 8014557: Mutable static field in HtmlDocletWriter Message-ID: <20130514205552.B3A5848A90@hg.openjdk.java.net> Changeset: 0384683c64be Author: jjg Date: 2013-05-14 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0384683c64be 8014557: Mutable static field in HtmlDocletWriter Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java From xueming.shen at oracle.com Tue May 14 14:11:20 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 14 May 2013 21:11:20 +0000 Subject: hg: jdk8/tl/jdk: 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Message-ID: <20130514211142.A5B6C48A92@hg.openjdk.java.net> Changeset: 08ef70f60e0d Author: sherman Date: 2013-05-14 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08ef70f60e0d 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Summary: removed the race condition risk from ExtendedCahrset access code Reviewed-by: mchung, alanb ! make/sun/nio/cs/Makefile ! makefiles/CreateJars.gmk ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java From xueming.shen at oracle.com Tue May 14 14:21:54 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 14 May 2013 21:21:54 +0000 Subject: hg: jdk8/tl/jdk: 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit Message-ID: <20130514212206.9FF1848A93@hg.openjdk.java.net> Changeset: c70fff3db913 Author: sherman Date: 2013-05-14 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c70fff3db913 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit Summary: to throw IOE for malformed final unit in base64 stream Reviewed-by: chegar, alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From jonathan.gibbons at oracle.com Tue May 14 15:05:12 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 22:05:12 +0000 Subject: hg: jdk8/tl/langtools: 8013852: update reference impl for type-annotations Message-ID: <20130514220518.77FDF48A96@hg.openjdk.java.net> Changeset: ddb4a2bfcd82 Author: jjg Date: 2013-05-14 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ddb4a2bfcd82 8013852: update reference impl for type-annotations Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com, joel.franck at oracle.com, alex.buckley at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java ! test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java + test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java + test/tools/javac/annotations/typeAnnotations/classfile/T8008769.java + test/tools/javac/annotations/typeAnnotations/classfile/T8010015.java + test/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java + test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out + test/tools/javac/annotations/typeAnnotations/failures/T8008751.java + test/tools/javac/annotations/typeAnnotations/failures/T8009360.java + test/tools/javac/annotations/typeAnnotations/failures/T8011722.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DeclarationAnnotation.out + test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Initializers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Test.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/diags/examples/ArrayAndReceiver.java + test/tools/javac/diags/examples/IncorrectConstructorReceiverName.java + test/tools/javac/diags/examples/IncorrectConstructorReceiverType.java + test/tools/javac/diags/examples/IncorrectReceiverName.java + test/tools/javac/diags/examples/ReceiverParameterNotApplicableConstructor.java + test/tools/javac/diags/examples/VarargsAndReceiver.java ! test/tools/javac/lib/DPrinter.java + test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/tree/SourceTreeScannerTest.java ! test/tools/javap/output/RepeatingTypeAnnotations.java ! test/tools/javap/typeAnnotations/NewArray.java ! test/tools/javap/typeAnnotations/Presence.java ! test/tools/javap/typeAnnotations/TypeCasts.java From jonathan.gibbons at oracle.com Tue May 14 18:03:21 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 May 2013 01:03:21 +0000 Subject: hg: jdk8/tl/langtools: 8013163: Convert 4 tools multicatch tests to jtreg format Message-ID: <20130515010324.C4E7048A9D@hg.openjdk.java.net> Changeset: 53b389eb39c1 Author: sogoel Date: 2013-05-14 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/53b389eb39c1 8013163: Convert 4 tools multicatch tests to jtreg format Reviewed-by: jjg + test/tools/javac/multicatch/Pos11.java + test/tools/javac/multicatch/Pos12.java From jonathan.gibbons at oracle.com Tue May 14 21:10:15 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 May 2013 04:10:15 +0000 Subject: hg: jdk8/tl/langtools: 8014323: Add VariableTree.getNameExpression Message-ID: <20130515041020.ED5C348AA0@hg.openjdk.java.net> Changeset: 529fb3ed5d2a Author: jjg Date: 2013-05-14 21:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/529fb3ed5d2a 8014323: Add VariableTree.getNameExpression Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! test/tools/javac/tree/SourceTreeScannerTest.java From david.holmes at oracle.com Tue May 14 21:46:51 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 15 May 2013 04:46:51 +0000 Subject: hg: jdk8/tl/jdk: 8013395: StringBuffer.toString performance regression impacting embedded benchmarks Message-ID: <20130515044703.2C79148AA4@hg.openjdk.java.net> Changeset: a3d79a4c2a24 Author: dholmes Date: 2013-05-15 00:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3d79a4c2a24 8013395: StringBuffer.toString performance regression impacting embedded benchmarks Summary: cache a copy of the char[] to use with toString() and clear it when ever the sb content is modified Reviewed-by: alanb, plevart, mduigou, forax ! src/share/classes/java/lang/StringBuffer.java + test/java/lang/StringBuffer/ToStringCache.java From joe.darcy at oracle.com Wed May 15 00:01:03 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 15 May 2013 07:01:03 +0000 Subject: hg: jdk8/tl/langtools: 8004133: Provide javax.lang.model.* implementation backed by core reflection Message-ID: <20130515070112.226A448AA6@hg.openjdk.java.net> Changeset: bcd927639039 Author: darcy Date: 2013-05-15 00:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bcd927639039 8004133: Provide javax.lang.model.* implementation backed by core reflection Summary: Joint work by darcy and jfranck to provide sample code for JEP 119. Reviewed-by: jjg Contributed-by: joe.darcy at oracle.com, joel.franck at oracle.com + src/share/sample/language/model/CoreReflectionFactory.java From chris.hegarty at oracle.com Wed May 15 02:09:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 10:09:15 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <519225F5.2050303@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> Message-ID: <519350BB.7010604@oracle.com> What you have in the latest version of this webrev look fine to me. -Chris. On 14/05/2013 12:54, Michael McMahon wrote: > I have updated the webrev for this at: > > http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/ > > Thanks > Michael. From michael.x.mcmahon at oracle.com Wed May 15 03:02:32 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 May 2013 11:02:32 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <519350BB.7010604@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> <519350BB.7010604@oracle.com> Message-ID: <51935D38.90607@oracle.com> On 15/05/13 10:09, Chris Hegarty wrote: > What you have in the latest version of this webrev look fine to me. > Thanks Chris! Michael > -Chris. > > On 14/05/2013 12:54, Michael McMahon wrote: >> I have updated the webrev for this at: >> >> http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/ >> >> Thanks >> Michael. From Alan.Bateman at oracle.com Wed May 15 03:04:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 11:04:27 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <519225F5.2050303@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> Message-ID: <51935DAB.2010009@oracle.com> On 14/05/2013 12:54, Michael McMahon wrote: > I have updated the webrev for this at: > > http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/ I took a pass over the updated webrev and it mostly looks good to me. In HttpURLConnection then I wonder if it would be better if getInputStream, getOutputStream and followRedirect set the connecting flag rather than URLtoSocketPermission. The side effect on the protocol handler state is a bit surprising in this method. Alternatively then maybe the method needs a better name. On MessageHeader then getHeaderNamesInList could use java.util.StringJoiner to avoid rolling your own. Are you planning to add @bug to the tests? I wonder if about dependency on SimpleSSLContext in the test as I don't think that test was originally intended to be a "test library". -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/d8d188c1/attachment.html From michael.x.mcmahon at oracle.com Wed May 15 03:34:55 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 May 2013 11:34:55 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <51935DAB.2010009@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> <51935DAB.2010009@oracle.com> Message-ID: <519364CF.6020005@oracle.com> On 15/05/13 11:04, Alan Bateman wrote: > On 14/05/2013 12:54, Michael McMahon wrote: >> I have updated the webrev for this at: >> >> http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/ > I took a pass over the updated webrev and it mostly looks good to me. > > In HttpURLConnection then I wonder if it would be better if > getInputStream, getOutputStream and followRedirect set the connecting > flag rather than URLtoSocketPermission. The side effect on the > protocol handler state is a bit surprising in this method. > Alternatively then maybe the method needs a better name. > Yes, that did looks a little incongruous. So, I think moving it to getInputStream, getOutputStream and connect() would make sense. > On MessageHeader then getHeaderNamesInList could use > java.util.StringJoiner to avoid rolling your own. > I can see the benefit of using StringJoiner (and a lambda) if I am starting off from a Collection and this is something that only struck me when looking at this. I was surprised to see that Arrays.asList() doesn't have a variant that limits the number of elements coming from the array. So, I can't use it here. Maybe this is something we could look at again later, with the other changes we're contemplating? > Are you planning to add @bug to the tests? > Yes, will do that. > I wonder if about dependency on SimpleSSLContext in the test as I > don't think that test was originally intended to be a "test library". > SimpleSSLContext isn't a test. All it does is provide the glue to build an SSLContext. I've used it as a kind of library before. I'll post one more webrev, and push it soon afterwards as I'd like to make the code freeze today. Thanks Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/0178c3f1/attachment.html From Alan.Bateman at oracle.com Wed May 15 04:02:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 12:02:20 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <519364CF.6020005@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> <51935DAB.2010009@oracle.com> <519364CF.6020005@oracle.com> Message-ID: <51936B3C.1090702@oracle.com> On 15/05/2013 11:34, Michael McMahon wrote: > : > >> On MessageHeader then getHeaderNamesInList could use >> java.util.StringJoiner to avoid rolling your own. >> > > I can see the benefit of using StringJoiner (and a lambda) if I am > starting off from a Collection > and this is something that only struck me when looking at this. I was > surprised > to see that Arrays.asList() doesn't have a variant that limits the > number of > elements coming from the array. So, I can't use it here. Maybe this is > something > we could look at again later, with the other changes we're contemplating? I think getHeaderNamesInList needs to be checked anyway as it looks to me that it just appends the keys and will never insert a comma. The only reason I suggested StringJoiner here is because I thought this method was trying to do this: StringJoiner joiner = new StringJoiner(","); for (int i=0; i > I'll post one more webrev, and push it soon afterwards as I'd like to > make the > code freeze today. Okay. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/13f61073/attachment.html From michael.x.mcmahon at oracle.com Wed May 15 04:12:59 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 May 2013 12:12:59 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <51936B3C.1090702@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> <51935DAB.2010009@oracle.com> <519364CF.6020005@oracle.com> <51936B3C.1090702@oracle.com> Message-ID: <51936DBB.9070101@oracle.com> On 15/05/13 12:02, Alan Bateman wrote: > On 15/05/2013 11:34, Michael McMahon wrote: >> : >> >>> On MessageHeader then getHeaderNamesInList could use >>> java.util.StringJoiner to avoid rolling your own. >>> >> >> I can see the benefit of using StringJoiner (and a lambda) if I am >> starting off from a Collection >> and this is something that only struck me when looking at this. I was >> surprised >> to see that Arrays.asList() doesn't have a variant that limits the >> number of >> elements coming from the array. So, I can't use it here. Maybe this >> is something >> we could look at again later, with the other changes we're contemplating? > I think getHeaderNamesInList needs to be checked anyway as it looks to > me that it just appends the keys and will never insert a comma. > > The only reason I suggested StringJoiner here is because I thought > this method was trying to do this: > > StringJoiner joiner = new StringJoiner(","); > for (int i=0; i joiner.add(keys[i]); > } > return joiner.toString(); > well spotted and that's a simpler way of doing it. I messed the change up from the previous revision. It's unfortunate the actual end to end HttpURLConnection tests only use one header in each request. So, they didn't catch that. I'll update the test as well. Thanks Michael >> >> I'll post one more webrev, and push it soon afterwards as I'd like to >> make the >> code freeze today. > Okay. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/f74e04ea/attachment.html From michael.x.mcmahon at oracle.com Wed May 15 04:46:51 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 May 2013 12:46:51 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <51936DBB.9070101@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> <51935DAB.2010009@oracle.com> <519364CF.6020005@oracle.com> <51936B3C.1090702@oracle.com> <51936DBB.9070101@oracle.com> Message-ID: <519375AB.6090607@oracle.com> On 15/05/13 12:12, Michael McMahon wrote: > On 15/05/13 12:02, Alan Bateman wrote: >> On 15/05/2013 11:34, Michael McMahon wrote: >>> ... >>> >>> I'll post one more webrev, and push it soon afterwards as I'd like >>> to make the >>> code freeze today. >> Okay. > updated here: http://cr.openjdk.java.net/~michaelm/8010464/webrev.3/ Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/a3001eaa/attachment.html From Alan.Bateman at oracle.com Wed May 15 04:53:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 12:53:11 +0100 Subject: Code review: 8010464: Evolve java networking same origin policy In-Reply-To: <519375AB.6090607@oracle.com> References: <518CDB4F.5010607@oracle.com> <518F412A.8040902@oracle.com> <5190C377.3000007@oracle.com> <5190E50D.8090609@oracle.com> <5190EE5D.3040607@oracle.com> <5190FC1C.8000402@oracle.com> <519106A1.7040704@oracle.com> <519225F5.2050303@oracle.com> <51935DAB.2010009@oracle.com> <519364CF.6020005@oracle.com> <51936B3C.1090702@oracle.com> <51936DBB.9070101@oracle.com> <519375AB.6090607@oracle.com> Message-ID: <51937727.2030603@oracle.com> On 15/05/2013 12:46, Michael McMahon wrote: > > updated here: > > http://cr.openjdk.java.net/~michaelm/8010464/webrev.3/ > > Michael. > This looks much better. In HttpURLConnection then odd formatting in the declaration of followRedirect0 (which probably needs a better name, maybe implFollowRedirect?) A couple of indentation issues that probably should be fixed too, L980 and L2951 for example. I don't see any other issues. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/6c966c18/attachment.html From john.zavgren at oracle.com Wed May 15 04:54:01 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Wed, 15 May 2013 07:54:01 -0400 Subject: RFR JDK7188517 In-Reply-To: References: Message-ID: <51937759.5070507@oracle.com> Greetings: Can I get a show of hands on this RFR (http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)? It's CCC request has been accepted and I'd like to wrap it up ASAP. Thanks! John Zavgren On 05/09/2013 02:22 PM, John Zavgren wrote: > Greetings: > I made a mistake in my last RFR posting... the URL for the latest modifications is: > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ > instead of: > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ > > The most recent change is to reinstate the original test that tested for cookie names that lead with a dollar sign. > > I'm sorry about the confusion. > > Thanks! > John > > > On 05/09/2013 03:42 PM, John Zavgren wrote: >> Chris, et alia: >> I put the reinstated the old test. >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >> >> John >> >> ----- Original Message ----- >> From: chris.hegarty at oracle.com >> To: john.zavgren at oracle.com >> Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net >> Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern >> Subject: Re: RFR JDK7188517 >> >> John, >> >> I think you can simply reinstate >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java >> >> -Chris. >> >> On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >>> I would have thrown an exception if the IllegalArgumentException is not >>> obtained, otherwise the test looses its >>> purpose, and will pass silently if someone mistakenly removes the $ >>> check in our code. >>> >>> - Kurchi >>> >>> On 5/8/2013 12:10 PM, John Zavgren wrote: >>>> Greetings: >>>> >>>> I added a test for the leading dollar sign character in cookie names: >>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>> >>>> Thanks! >>>> John >>>> >>>> >>>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>>> This looks okay to me. >>>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>>> for '$' >>>>>>>> >>>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>>> change. We should get positive agreement from Michael before pushing >>>>>>>> this. >>>>>>>> >>>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>>> with '$'. >>>>>>> I agree we should add a negative test now for a similar cookie. >>>>>>> >>>>>>> Source changes look fine to me too. >>>>>> Thanks Michael, >>>>>> >>>>>> In which case, I believe the check that a cookie the name >>>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>>> >>>>> Right. I didn't realise the test was able to handle the IAE. I see >>>>> now that it does and it should >>>>> be possible to put the same test back. >>>>> >>>>> Michael >>>>>> -Chris. >>>>>> >>>>>>> Michael >>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>>> >>>>>>>>> - Kurchi >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>>> All: >>>>>>>>>> My original email was mangled by my email program >>>>>>>>>> (stbeehive/zimbra) >>>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>>> >>>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> --------------- >>>>>>>>>> >>>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Basically there are two issues: >>>>>>>>>> >>>>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>>>> have >>>>>>>>>> a dollar sign as their leading character, >>>>>>>>>> which is "illegal". The constructor code was modified to disallow >>>>>>>>>> these illegal names. >>>>>>>>>> >>>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>>> ) >>>>>>>>>> prohibited >>>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>>> use by >>>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> John Zavgren >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>>> Eastern >>>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>>> >>>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>>> constructor: >>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>> Basically there are two issues: 1.) the existing cookie constructor >>>>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>>>> character, which is "illegal". The constructor code was modified to >>>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>>> specdiff: http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>>> reserved >>>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>>> necessary. >>>>>>>>>> Thanks! John Zavgren >>>>>>>>> -- >>>>>>>>> -Kurchi >>>>>>>>> >>>> -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From chris.hegarty at oracle.com Wed May 15 05:02:49 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 13:02:49 +0100 Subject: [OFFLIST] Re: RFR JDK7188517 In-Reply-To: <51937759.5070507@oracle.com> References: <51937759.5070507@oracle.com> Message-ID: <51937969.70602@oracle.com> [OFFLIST] I believe the reviews on the open list are complete. The CCC has been accepted, nut it needs to be make final, then the CCC committee need to vote again. I did send mail to you about making it final ( one step process ), but you may not have seen it. -Chris. On 15/05/2013 12:54, John Zavgren wrote: > Greetings: > > Can I get a show of hands on this RFR > (http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)? > It's CCC request has been accepted and I'd like to wrap it up ASAP. > > Thanks! > John Zavgren > > On 05/09/2013 02:22 PM, John Zavgren wrote: >> Greetings: >> I made a mistake in my last RFR posting... the URL for the latest >> modifications is: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ >> instead of: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >> >> The most recent change is to reinstate the original test that tested >> for cookie names that lead with a dollar sign. >> >> I'm sorry about the confusion. >> >> Thanks! >> John >> >> >> On 05/09/2013 03:42 PM, John Zavgren wrote: >>> Chris, et alia: >>> I put the reinstated the old test. >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>> >>> John >>> >>> ----- Original Message ----- >>> From: chris.hegarty at oracle.com >>> To: john.zavgren at oracle.com >>> Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net >>> Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern >>> Subject: Re: RFR JDK7188517 >>> >>> John, >>> >>> I think you can simply reinstate >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java >>> >>> >>> -Chris. >>> >>> On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >>>> I would have thrown an exception if the IllegalArgumentException is not >>>> obtained, otherwise the test looses its >>>> purpose, and will pass silently if someone mistakenly removes the $ >>>> check in our code. >>>> >>>> - Kurchi >>>> >>>> On 5/8/2013 12:10 PM, John Zavgren wrote: >>>>> Greetings: >>>>> >>>>> I added a test for the leading dollar sign character in cookie names: >>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>>> >>>>> Thanks! >>>>> John >>>>> >>>>> >>>>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>>>> This looks okay to me. >>>>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>>>> for '$' >>>>>>>>> >>>>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>>>> change. We should get positive agreement from Michael before >>>>>>>>> pushing >>>>>>>>> this. >>>>>>>>> >>>>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>>>> with '$'. >>>>>>>> I agree we should add a negative test now for a similar cookie. >>>>>>>> >>>>>>>> Source changes look fine to me too. >>>>>>> Thanks Michael, >>>>>>> >>>>>>> In which case, I believe the check that a cookie the name >>>>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>>>> >>>>>> Right. I didn't realise the test was able to handle the IAE. I see >>>>>> now that it does and it should >>>>>> be possible to put the same test back. >>>>>> >>>>>> Michael >>>>>>> -Chris. >>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>>>> >>>>>>>>>> - Kurchi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>>>> All: >>>>>>>>>>> My original email was mangled by my email program >>>>>>>>>>> (stbeehive/zimbra) >>>>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>>>> >>>>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Basically there are two issues: >>>>>>>>>>> >>>>>>>>>>> 1.) the existing cookie constructor was allowing cookie names to >>>>>>>>>>> have >>>>>>>>>>> a dollar sign as their leading character, >>>>>>>>>>> which is "illegal". The constructor code was modified to >>>>>>>>>>> disallow >>>>>>>>>>> these illegal names. >>>>>>>>>>> >>>>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>>>> ) >>>>>>>>>>> prohibited >>>>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>>>> use by >>>>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> John Zavgren >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>>>> Eastern >>>>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>>>> >>>>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>>>> constructor: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>> Basically there are two issues: 1.) the existing cookie >>>>>>>>>>> constructor >>>>>>>>>>> was allowing cookie names to have a dollar sign as their leading >>>>>>>>>>> character, which is "illegal". The constructor code was >>>>>>>>>>> modified to >>>>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>>>> specdiff: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>>>> reserved >>>>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>>>> necessary. >>>>>>>>>>> Thanks! John Zavgren >>>>>>>>>> -- >>>>>>>>>> -Kurchi >>>>>>>>>> >>>>> > > From chris.hegarty at oracle.com Wed May 15 05:23:31 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 13:23:31 +0100 Subject: RFR JDK7188517 In-Reply-To: <51937969.70602@oracle.com> References: <51937759.5070507@oracle.com> <51937969.70602@oracle.com> Message-ID: <51937E43.60600@oracle.com> On 15/05/2013 13:02, Chris Hegarty wrote: >.... > I believe the reviews on the open list are complete. The CCC has been > accepted, nut it needs to be make final, then the CCC committee need to > vote again. > > I did send mail to you about making it final ( one step process ), but > you may not have seen it. Sorry about the noise on the list, this mail was intended for John only. But the point still stands. -Chris. From maurizio.cimadamore at oracle.com Wed May 15 06:04:19 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 May 2013 13:04:19 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130515130430.BE5EE48AC0@hg.openjdk.java.net> Changeset: 05ec778794d0 Author: mcimadamore Date: 2013-05-15 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05ec778794d0 8012003: Method diagnostics resolution need to be simplified in some cases Summary: Unfold method resolution diagnostics when they mention errors in poly expressions Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/Diagnostics/compressed/T8012003a.java + test/tools/javac/Diagnostics/compressed/T8012003a.out + test/tools/javac/Diagnostics/compressed/T8012003b.java + test/tools/javac/Diagnostics/compressed/T8012003b.out + test/tools/javac/Diagnostics/compressed/T8012003c.java + test/tools/javac/Diagnostics/compressed/T8012003c.out ! test/tools/javac/diags/examples/BadArgTypesInLambda.java + test/tools/javac/diags/examples/CompressedDiags.java ! test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/ProbFoundReqFragment.java ! test/tools/javac/lambda/TargetType66.out Changeset: 33d1937af1a3 Author: mcimadamore Date: 2013-05-15 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33d1937af1a3 8012685: Spurious raw types warning when using unbound method references Summary: Spurious raw type warning when unbound method reference qualifier parameter types are inferred from target Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/MethodReference67.java + test/tools/javac/lambda/MethodReference67.out Changeset: 78717f2d00e8 Author: mcimadamore Date: 2013-05-15 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/78717f2d00e8 8013222: Javac issues spurious raw type warnings when lambda has implicit parameter types Summary: Bad warnings and position for lambda inferred parameter types Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/NoWarnOnImplicitParams.java + test/tools/javac/lambda/NoWarnOnImplicitParams.out From michael.x.mcmahon at oracle.com Wed May 15 07:02:29 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 15 May 2013 14:02:29 +0000 Subject: hg: jdk8/tl/jdk: 8010464: Evolve java networking same origin policy Message-ID: <20130515140249.4F36C48AC3@hg.openjdk.java.net> Changeset: 93a268759ec3 Author: michaelm Date: 2013-05-15 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 8010464: Evolve java networking same origin policy Reviewed-by: alanb, chegar, dsamersoff, weijun ! src/share/classes/java/net/HttpURLConnection.java + src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLPermission/HttpURLPermissionTest.java + test/java/net/HttpURLPermission/URLTest.java + test/java/net/HttpURLPermission/policy.1 + test/java/net/HttpURLPermission/policy.2 + test/java/net/HttpURLPermission/policy.3 From xueming.shen at oracle.com Wed May 15 07:50:54 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 15 May 2013 14:50:54 +0000 Subject: hg: jdk8/tl/jdk: 8013730: JSR 310 DateTime API Updates III Message-ID: <20130515145126.167A448AC6@hg.openjdk.java.net> Changeset: ef04044f77d2 Author: sherman Date: 2013-05-15 07:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef04044f77d2 8013730: JSR 310 DateTime API Updates III Summary: Integration of JSR310 Date/Time API update III Reviewed-by: naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DateTimeException.java ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Ser.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/HijrahEra.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimeParseException.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/DecimalStyle.java ! src/share/classes/java/time/format/FormatStyle.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/format/ResolverStyle.java ! src/share/classes/java/time/format/SignStyle.java ! src/share/classes/java/time/format/TextStyle.java ! src/share/classes/java/time/format/package-info.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesException.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java + test/java/time/tck/java/time/format/TCKDecimalStyle.java + test/java/time/tck/java/time/format/TCKInstantPrinterParser.java ! test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java ! test/java/time/test/java/time/chrono/TestChronologyPerf.java ! test/java/time/test/java/time/chrono/TestExampleCode.java + test/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/java/time/test/java/time/format/AbstractTestPrinterParser.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java + test/java/time/test/java/time/format/TestDecimalStyle.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java From michael.x.mcmahon at oracle.com Wed May 15 09:03:48 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 May 2013 17:03:48 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> Message-ID: <5193B1E4.1090100@oracle.com> Piotr, We took a look at this issue again, and while it is still the case that to get Expect: Continue to work properly, you need to enable one of the streaming modes. However, prior to jdk7 there was partial support for this mechanism, where it obeyed the protocol at least when you set the Expect header. What it didn't do is delay sending the request body until the 100 response is received. However, that might not have been a problem in many cases, and it looks like in jdk7 this specific mode is not working exactly the same as before. One problem is that a 5 second delay can be seen. Anyhow, we will fix the problem in jdk 8 so that the exact same behavior as jdk 6 is seen. I'll send a webrev with a fix soon. Thanks Michael On 07/05/13 15:40, Piotr Bzdyl wrote: > In this case I will have to double check the SAAJ SoapConnection (as > we encountered the problem indirectly when using SAAJ SoapConnection). > The code invoking the SOAP service was setting Expect: 100-continue > header as the SOAP message header and SoapConnection propagated it to > HttpURLConnection. I need to confirm that it is even allowed and if it > is I will report the bug in SAAJ project. > > Best regards, > Piotr > > On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty > > wrote: > > I replied too quick. This is not a bug per say, but a limitation > of the existing API. > > Expect: 100-continue is only supported with streaming requests, > i.e. setChunkedStreamingMode(int), or > setFixedLengthStreamingMode(long). > > With the above API's the appropriate header, content-length or > Transfer-Encoding: chunked, can be set before return the > OutputStream ( from getOutputStream() ). Without either of the > above calls the content-length is only determinable after the > returned output stream is closed, and this happens after the > return from getOutptuStream(). > > So I would say this is a limitation of the API. But the workaround > is quite straight forward, use streaming. > > -Chris. > > > On 05/07/2013 03:05 PM, Chris Hegarty wrote: > > On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: > > Chris, > > When I used the URL provided by you I have indeed access > to my bug > report. It seems the notification email I got with > confirmation of my > report submission provides the misleading URL. Is it > possible to fix it > in the notification template? > > > You are right the URL provided to you is pretty much useless, > at this > point. Not that is matters much, but there are separate JIRA > projects > for bugs moving from web screening to the "real" bug > incidents. If it is > any consolation, your issue has made it all the way ;-) > > > When I debug the code (using the test case I attached to > the bug > report), it doesn't go into the > > if (streaming() && strOutputStream == null) { > writeRequests(); // <<<< Here > } > > but goes directly to expect100Continue() in: > if (expectContinue) { > expect100Continue(); > } > > > Ah ha. that is the bug. We should always writeRequests ( write > headers ) > when expectContinue is set. I'll update the bug with this > clear comment, > and then propose a patch for JDK8. > > -Chris. > > > > > On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty > > >> wrote: > > Hi Piotr, > > Your bug is accessible at > http://bugs.sun.com/view_bug.__do?bug_id=8012625 > > > From my reading of the code the headers should be > sent before > waiting for the reply to continue. > > From sun/net/www/prtotocol/http/__HttpURLConnection: > > getOutputStream() { > .... > if (!checkReuseConnection()) > connect(); > > boolean expectContinue = false; > String expects = requests.findValue("Expect"); > if ("100-Continue".__equalsIgnoreCase(expects)) { > http.setIgnoreContinue(false); > expectContinue = true; > } > > if (streaming() && strOutputStream == null) { > writeRequests(); // <<<< Here > } > > if (expectContinue) { > expect100Continue(); > } > .... > > } > > Are you seeing something different? > > -Chris. > > > > On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: > > Hello, > > This is my first post to this mailing list so I > would like to > say "Hi". > > The reason I subscribed and I am writing is that I > believe I > have found > a bug in sun.*.HttpURLConnection class (in > particular how it > handles > Expect: 100-continue header). I have already > submitted a bug at > bugs.sun.com > but > after almost 3 weeks I still > > cannot access the bug and check its status > > (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773 > > ). > > I would like to ask if bugs.sun.com > > is alive or if > > it is possible to report the bug in the OpenJDK > project or is > there any > other alternative procedure for submitting bug > reports. > > Best regards, > Piotr Bzdyl > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/948f07a6/attachment.html From michael.x.mcmahon at oracle.com Wed May 15 09:33:04 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 May 2013 17:33:04 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <5193B1E4.1090100@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> <5193B1E4.1090100@oracle.com> Message-ID: <5193B8C0.20208@oracle.com> This is the webrev for the bug http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/ Thanks Michael On 15/05/13 17:03, Michael McMahon wrote: > Piotr, > > We took a look at this issue again, and while it is still the case > that to get Expect: Continue > to work properly, you need to enable one of the streaming modes. > However, prior to jdk7 > there was partial support for this mechanism, where it obeyed the > protocol at least > when you set the Expect header. What it didn't do is delay sending the > request body until > the 100 response is received. However, that might not have been a > problem in many cases, > and it looks like in jdk7 this specific mode is not working exactly > the same as before. One problem > is that a 5 second delay can be seen. > > Anyhow, we will fix the problem in jdk 8 so that the exact same > behavior as jdk 6 is seen. > I'll send a webrev with a fix soon. > > Thanks > Michael > > On 07/05/13 15:40, Piotr Bzdyl wrote: >> In this case I will have to double check the SAAJ SoapConnection (as >> we encountered the problem indirectly when using SAAJ >> SoapConnection). The code invoking the SOAP service was setting >> Expect: 100-continue header as the SOAP message header and >> SoapConnection propagated it to HttpURLConnection. I need to confirm >> that it is even allowed and if it is I will report the bug in SAAJ >> project. >> >> Best regards, >> Piotr >> >> On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty >> > wrote: >> >> I replied too quick. This is not a bug per say, but a limitation >> of the existing API. >> >> Expect: 100-continue is only supported with streaming requests, >> i.e. setChunkedStreamingMode(int), or >> setFixedLengthStreamingMode(long). >> >> With the above API's the appropriate header, content-length or >> Transfer-Encoding: chunked, can be set before return the >> OutputStream ( from getOutputStream() ). Without either of the >> above calls the content-length is only determinable after the >> returned output stream is closed, and this happens after the >> return from getOutptuStream(). >> >> So I would say this is a limitation of the API. But the >> workaround is quite straight forward, use streaming. >> >> -Chris. >> >> >> On 05/07/2013 03:05 PM, Chris Hegarty wrote: >> >> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: >> >> Chris, >> >> When I used the URL provided by you I have indeed access >> to my bug >> report. It seems the notification email I got with >> confirmation of my >> report submission provides the misleading URL. Is it >> possible to fix it >> in the notification template? >> >> >> You are right the URL provided to you is pretty much useless, >> at this >> point. Not that is matters much, but there are separate JIRA >> projects >> for bugs moving from web screening to the "real" bug >> incidents. If it is >> any consolation, your issue has made it all the way ;-) >> >> >> When I debug the code (using the test case I attached to >> the bug >> report), it doesn't go into the >> >> if (streaming() && strOutputStream == null) { >> writeRequests(); // <<<< Here >> } >> >> but goes directly to expect100Continue() in: >> if (expectContinue) { >> expect100Continue(); >> } >> >> >> Ah ha. that is the bug. We should always writeRequests ( >> write headers ) >> when expectContinue is set. I'll update the bug with this >> clear comment, >> and then propose a patch for JDK8. >> >> -Chris. >> >> >> >> >> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty >> >> > >> wrote: >> >> Hi Piotr, >> >> Your bug is accessible at >> http://bugs.sun.com/view_bug.__do?bug_id=8012625 >> >> >> From my reading of the code the headers should be >> sent before >> waiting for the reply to continue. >> >> From sun/net/www/prtotocol/http/__HttpURLConnection: >> >> getOutputStream() { >> .... >> if (!checkReuseConnection()) >> connect(); >> >> boolean expectContinue = false; >> String expects = requests.findValue("Expect"); >> if >> ("100-Continue".__equalsIgnoreCase(expects)) { >> http.setIgnoreContinue(false); >> expectContinue = true; >> } >> >> if (streaming() && strOutputStream == null) { >> writeRequests(); // <<<< Here >> } >> >> if (expectContinue) { >> expect100Continue(); >> } >> .... >> >> } >> >> Are you seeing something different? >> >> -Chris. >> >> >> >> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: >> >> Hello, >> >> This is my first post to this mailing list so I >> would like to >> say "Hi". >> >> The reason I subscribed and I am writing is that >> I believe I >> have found >> a bug in sun.*.HttpURLConnection class (in >> particular how it >> handles >> Expect: 100-continue header). I have already >> submitted a bug at >> bugs.sun.com >> but >> after almost 3 weeks I still >> >> cannot access the bug and check its status >> >> (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773 >> >> ). >> >> I would like to ask if bugs.sun.com >> >> is alive or if >> >> it is possible to report the bug in the OpenJDK >> project or is >> there any >> other alternative procedure for submitting bug >> reports. >> >> Best regards, >> Piotr Bzdyl >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/108a7b77/attachment.html From joe.darcy at oracle.com Wed May 15 09:54:45 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 15 May 2013 16:54:45 +0000 Subject: hg: jdk8/tl/jdk: 8014677: Correct docs warning for Objects.requireNonNull(T, Supplier) Message-ID: <20130515165503.95F7C48AD2@hg.openjdk.java.net> Changeset: bad8f5237f10 Author: darcy Date: 2013-05-15 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bad8f5237f10 8014677: Correct docs warning for Objects.requireNonNull(T, Supplier) Reviewed-by: alanb ! src/share/classes/java/util/Objects.java From chris.hegarty at oracle.com Wed May 15 10:09:49 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 18:09:49 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <5193B8C0.20208@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> <5193B1E4.1090100@oracle.com> <5193B8C0.20208@oracle.com> Message-ID: The change looks fine to me. -Chris On 15 May 2013, at 17:33, Michael McMahon wrote: > This is the webrev for the bug > > http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/ > > Thanks > Michael > > On 15/05/13 17:03, Michael McMahon wrote: >> Piotr, >> >> We took a look at this issue again, and while it is still the case that to get Expect: Continue >> to work properly, you need to enable one of the streaming modes. However, prior to jdk7 >> there was partial support for this mechanism, where it obeyed the protocol at least >> when you set the Expect header. What it didn't do is delay sending the request body until >> the 100 response is received. However, that might not have been a problem in many cases, >> and it looks like in jdk7 this specific mode is not working exactly the same as before. One problem >> is that a 5 second delay can be seen. >> >> Anyhow, we will fix the problem in jdk 8 so that the exact same behavior as jdk 6 is seen. >> I'll send a webrev with a fix soon. >> >> Thanks >> Michael >> >> On 07/05/13 15:40, Piotr Bzdyl wrote: >>> In this case I will have to double check the SAAJ SoapConnection (as we encountered the problem indirectly when using SAAJ SoapConnection). The code invoking the SOAP service was setting Expect: 100-continue header as the SOAP message header and SoapConnection propagated it to HttpURLConnection. I need to confirm that it is even allowed and if it is I will report the bug in SAAJ project. >>> >>> Best regards, >>> Piotr >>> >>> On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty wrote: >>>> I replied too quick. This is not a bug per say, but a limitation of the existing API. >>>> >>>> Expect: 100-continue is only supported with streaming requests, i.e. setChunkedStreamingMode(int), or setFixedLengthStreamingMode(long). >>>> >>>> With the above API's the appropriate header, content-length or Transfer-Encoding: chunked, can be set before return the OutputStream ( from getOutputStream() ). Without either of the above calls the content-length is only determinable after the returned output stream is closed, and this happens after the return from getOutptuStream(). >>>> >>>> So I would say this is a limitation of the API. But the workaround is quite straight forward, use streaming. >>>> >>>> -Chris. >>>> >>>> >>>> On 05/07/2013 03:05 PM, Chris Hegarty wrote: >>>>> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: >>>>>> Chris, >>>>>> >>>>>> When I used the URL provided by you I have indeed access to my bug >>>>>> report. It seems the notification email I got with confirmation of my >>>>>> report submission provides the misleading URL. Is it possible to fix it >>>>>> in the notification template? >>>>> >>>>> You are right the URL provided to you is pretty much useless, at this >>>>> point. Not that is matters much, but there are separate JIRA projects >>>>> for bugs moving from web screening to the "real" bug incidents. If it is >>>>> any consolation, your issue has made it all the way ;-) >>>>> >>>>>> >>>>>> When I debug the code (using the test case I attached to the bug >>>>>> report), it doesn't go into the >>>>>> >>>>>> if (streaming() && strOutputStream == null) { >>>>>> writeRequests(); // <<<< Here >>>>>> } >>>>>> >>>>>> but goes directly to expect100Continue() in: >>>>>> if (expectContinue) { >>>>>> expect100Continue(); >>>>>> } >>>>> >>>>> Ah ha. that is the bug. We should always writeRequests ( write headers ) >>>>> when expectContinue is set. I'll update the bug with this clear comment, >>>>> and then propose a patch for JDK8. >>>>> >>>>> -Chris. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty >>>>> > wrote: >>>>>> >>>>>> Hi Piotr, >>>>>> >>>>>> Your bug is accessible at >>>>>> http://bugs.sun.com/view_bug.__do?bug_id=8012625 >>>>>> >>>>>> >>>>>> From my reading of the code the headers should be sent before >>>>>> waiting for the reply to continue. >>>>>> >>>>>> From sun/net/www/prtotocol/http/__HttpURLConnection: >>>>>> >>>>>> getOutputStream() { >>>>>> .... >>>>>> if (!checkReuseConnection()) >>>>>> connect(); >>>>>> >>>>>> boolean expectContinue = false; >>>>>> String expects = requests.findValue("Expect"); >>>>>> if ("100-Continue".__equalsIgnoreCase(expects)) { >>>>>> http.setIgnoreContinue(false); >>>>>> expectContinue = true; >>>>>> } >>>>>> >>>>>> if (streaming() && strOutputStream == null) { >>>>>> writeRequests(); // <<<< Here >>>>>> } >>>>>> >>>>>> if (expectContinue) { >>>>>> expect100Continue(); >>>>>> } >>>>>> .... >>>>>> >>>>>> } >>>>>> >>>>>> Are you seeing something different? >>>>>> >>>>>> -Chris. >>>>>> >>>>>> >>>>>> >>>>>> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> This is my first post to this mailing list so I would like to >>>>>> say "Hi". >>>>>> >>>>>> The reason I subscribed and I am writing is that I believe I >>>>>> have found >>>>>> a bug in sun.*.HttpURLConnection class (in particular how it >>>>>> handles >>>>>> Expect: 100-continue header). I have already submitted a bug at >>>>>> bugs.sun.com but >>>>>> after almost 3 weeks I still >>>>>> >>>>>> cannot access the bug and check its status >>>>>> (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773 >>>>>> ). >>>>>> >>>>>> I would like to ask if bugs.sun.com >>>>>> is alive or if >>>>>> >>>>>> it is possible to report the bug in the OpenJDK project or is >>>>>> there any >>>>>> other alternative procedure for submitting bug reports. >>>>>> >>>>>> Best regards, >>>>>> Piotr Bzdyl > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/69ec9f87/attachment.html From jonathan.gibbons at oracle.com Wed May 15 10:40:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 May 2013 17:40:05 +0000 Subject: hg: jdk8/tl/langtools: 8006879: Detection of windows in sjavac fails. Message-ID: <20130515174013.9F55448AD3@hg.openjdk.java.net> Changeset: 445b8b5ae9f4 Author: jjg Date: 2013-05-15 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/445b8b5ae9f4 8006879: Detection of windows in sjavac fails. Reviewed-by: jjg Contributed-by: erik.joelsson at oracle.com ! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java From Alan.Bateman at oracle.com Wed May 15 11:22:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 19:22:12 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> <5193B1E4.1090100@oracle.com> <5193B8C0.20208@oracle.com> Message-ID: <5193D254.9000407@oracle.com> On 15/05/2013 18:09, Chris Hegarty wrote: > The change looks fine to me. > > -Chris > > On 15 May 2013, at 17:33, Michael McMahon > > > wrote: > >> This is the webrev for the bug >> >> http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/ >> >> Thanks >> Michael The fix looks okay to me too. For the test then is there any reason that is has to run in othervm mode? Just wondering if you could shutdown the http server when done. Also not clear why the fields are static when they are initialized in the ctor. Alignment issue at L93. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/8772216e/attachment.html From piotr at bzdyl.net Wed May 15 13:16:26 2013 From: piotr at bzdyl.net (Piotr Bzdyl) Date: Wed, 15 May 2013 22:16:26 +0200 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <5193B8C0.20208@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> <5193B1E4.1090100@oracle.com> <5193B8C0.20208@oracle.com> Message-ID: Thank you again for taking time to look at the issue. The proposed fix will eliminate the surprise we encountered as there will be no delay when Expect header and no streaming is used. Best regards, Piotr On Wed, May 15, 2013 at 6:33 PM, Michael McMahon < michael.x.mcmahon at oracle.com> wrote: > This is the webrev for the bug > > http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/ > > Thanks > Michael > > > On 15/05/13 17:03, Michael McMahon wrote: > > Piotr, > > We took a look at this issue again, and while it is still the case that to > get Expect: Continue > to work properly, you need to enable one of the streaming modes. However, > prior to jdk7 > there was partial support for this mechanism, where it obeyed the protocol > at least > when you set the Expect header. What it didn't do is delay sending the > request body until > the 100 response is received. However, that might not have been a problem > in many cases, > and it looks like in jdk7 this specific mode is not working exactly the > same as before. One problem > is that a 5 second delay can be seen. > > Anyhow, we will fix the problem in jdk 8 so that the exact same behavior > as jdk 6 is seen. > I'll send a webrev with a fix soon. > > Thanks > Michael > > On 07/05/13 15:40, Piotr Bzdyl wrote: > > In this case I will have to double check the SAAJ SoapConnection (as we > encountered the problem indirectly when using SAAJ SoapConnection). The > code invoking the SOAP service was setting Expect: 100-continue header as > the SOAP message header and SoapConnection propagated it to > HttpURLConnection. I need to confirm that it is even allowed and if it is I > will report the bug in SAAJ project. > > Best regards, > Piotr > > On Tue, May 7, 2013 at 4:29 PM, Chris Hegarty wrote: > >> I replied too quick. This is not a bug per say, but a limitation of the >> existing API. >> >> Expect: 100-continue is only supported with streaming requests, i.e. >> setChunkedStreamingMode(int), or setFixedLengthStreamingMode(long). >> >> With the above API's the appropriate header, content-length or >> Transfer-Encoding: chunked, can be set before return the OutputStream ( >> from getOutputStream() ). Without either of the above calls the >> content-length is only determinable after the returned output stream is >> closed, and this happens after the return from getOutptuStream(). >> >> So I would say this is a limitation of the API. But the workaround is >> quite straight forward, use streaming. >> >> -Chris. >> >> >> On 05/07/2013 03:05 PM, Chris Hegarty wrote: >> >>> On 05/07/2013 02:59 PM, Piotr Bzdyl wrote: >>> >>>> Chris, >>>> >>>> When I used the URL provided by you I have indeed access to my bug >>>> report. It seems the notification email I got with confirmation of my >>>> report submission provides the misleading URL. Is it possible to fix it >>>> in the notification template? >>>> >>> >>> You are right the URL provided to you is pretty much useless, at this >>> point. Not that is matters much, but there are separate JIRA projects >>> for bugs moving from web screening to the "real" bug incidents. If it is >>> any consolation, your issue has made it all the way ;-) >>> >>> >>>> When I debug the code (using the test case I attached to the bug >>>> report), it doesn't go into the >>>> >>>> if (streaming() && strOutputStream == null) { >>>> writeRequests(); // <<<< Here >>>> } >>>> >>>> but goes directly to expect100Continue() in: >>>> if (expectContinue) { >>>> expect100Continue(); >>>> } >>>> >>> >>> Ah ha. that is the bug. We should always writeRequests ( write headers ) >>> when expectContinue is set. I'll update the bug with this clear comment, >>> and then propose a patch for JDK8. >>> >>> -Chris. >>> >>> >>>> >>>> >>>> On Tue, May 7, 2013 at 3:52 PM, Chris Hegarty >>> > wrote: >>>> >>>> Hi Piotr, >>>> >>>> Your bug is accessible at >>>> http://bugs.sun.com/view_bug.__do?bug_id=8012625 >>>> >>>> >>>> From my reading of the code the headers should be sent before >>>> waiting for the reply to continue. >>>> >>>> From sun/net/www/prtotocol/http/__HttpURLConnection: >>>> >>>> getOutputStream() { >>>> .... >>>> if (!checkReuseConnection()) >>>> connect(); >>>> >>>> boolean expectContinue = false; >>>> String expects = requests.findValue("Expect"); >>>> if ("100-Continue".__equalsIgnoreCase(expects)) { >>>> http.setIgnoreContinue(false); >>>> expectContinue = true; >>>> } >>>> >>>> if (streaming() && strOutputStream == null) { >>>> writeRequests(); // <<<< Here >>>> } >>>> >>>> if (expectContinue) { >>>> expect100Continue(); >>>> } >>>> .... >>>> >>>> } >>>> >>>> Are you seeing something different? >>>> >>>> -Chris. >>>> >>>> >>>> >>>> On 05/07/2013 02:25 PM, Piotr Bzdyl wrote: >>>> >>>> Hello, >>>> >>>> This is my first post to this mailing list so I would like to >>>> say "Hi". >>>> >>>> The reason I subscribed and I am writing is that I believe I >>>> have found >>>> a bug in sun.*.HttpURLConnection class (in particular how it >>>> handles >>>> Expect: 100-continue header). I have already submitted a bug at >>>> bugs.sun.com but >>>> after almost 3 weeks I still >>>> >>>> cannot access the bug and check its status >>>> (http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=9001773 >>>> ). >>>> >>>> I would like to ask if bugs.sun.com >>>> is alive or if >>>> >>>> it is possible to report the bug in the OpenJDK project or is >>>> there any >>>> other alternative procedure for submitting bug reports. >>>> >>>> Best regards, >>>> Piotr Bzdyl >>>> >>>> >>>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/b4cf16b0/attachment.html From brian.call at soterawireless.com Wed May 15 14:28:06 2013 From: brian.call at soterawireless.com (Brian Call) Date: Wed, 15 May 2013 14:28:06 -0700 Subject: Non-standard socket options? In-Reply-To: <518E6702.2000509@oracle.com> References: <518CD87A.1000900@oracle.com> <518E6702.2000509@oracle.com> Message-ID: <25F3043E-5901-4E84-9002-ADA026A19584@soterawireless.com> I just asked Neil if that option was supported for ipv6 and he said that he doesn't think so... Likely once adoption of ipv6 reaches critical mass and enough people complain, it will be added. We can only hope... Please let me know if I can be of any more assistance. -Brian On May 11, 2013, at 8:42 AM, Alan Bateman wrote: > On 10/05/2013 17:14, Brian Call wrote: >> >> Thanks for your help guys! >> >> It would be most excellent to have that socket option turned off by default. It would certainly make multicast receivers written in java behave the same way across all the major platforms. Not sure why this wasn't considered a bug in Linux and, in fact, it's vehemently defended as absolutely adhering to the multicast spec. >> > There is a long history there. > > One thing that isn't clear about IP_MULTICAST_ALL is whether there is an equivalent for IPv6, that might need more investigation. > > -Alan > Blessings, Brian Call brian.call at soterawireless.com PRIVILEGED AND CONFIDENTIAL COMMUNICATION: This electronic transmission, and any documents attached hereto, may contain confidential and/or legally privileged information. The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/aeb32f8a/attachment.html From kurchi.subhra.hazra at oracle.com Wed May 15 15:18:22 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 15 May 2013 15:18:22 -0700 Subject: Code Review Request: 7150552: network test hangs [macosx] In-Reply-To: <518D8429.7060903@oracle.com> References: <518D8429.7060903@oracle.com> Message-ID: <519409AE.6050506@oracle.com> Hi, Two regression tests in jdk/test were hanging on Mac OS X intermittently. Although it is difficult to reproduce the problem, I suspect it is the use of the buggy httpserver test library (jdk/test/sun/net/www/httptest) - we anyway want to move away from using it. I have re-written parts of these tests to use com.sun.net.httpserver instead. I have also unleashed the tests from the ProblemList and will keep a closer watch on test runs. Bug: http://bugs.sun.com/view_bug.do?bug_id=7150552 Webrev: http://cr.openjdk.java.net/~khazra/7150552/webrev.00/ Thanks! Kurchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130515/f755339c/attachment.html From naoto.sato at oracle.com Wed May 15 16:49:20 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 15 May 2013 23:49:20 +0000 Subject: hg: jdk8/tl/jdk: 8013233: java/util/Locale/LocaleProviders.sh fails Message-ID: <20130515234940.4A42048AE0@hg.openjdk.java.net> Changeset: 3d9f25dc630c Author: naoto Date: 2013-05-15 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d9f25dc630c 8013233: java/util/Locale/LocaleProviders.sh fails Reviewed-by: okutsu ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From valerie.peng at oracle.com Wed May 15 18:43:12 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 16 May 2013 01:43:12 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130516014410.ECFD148AE4@hg.openjdk.java.net> Changeset: 2ec31660cc0e Author: valeriep Date: 2013-05-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ec31660cc0e 8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps should be protected Summary: Change the finalize method of PKCS11 class to be protected. Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java Changeset: 991420add35d Author: valeriep Date: 2013-05-07 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/991420add35d 7196009: SunPkcs11 provider fails to parse config path containing parenthesis Summary: Enhanced to allow quoted string as library path values. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java ! test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/cspQuotedPath.cfg Changeset: 804da1e9bd04 Author: ascarpino Date: 2013-05-07 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/804da1e9bd04 8001284: Buffer problems with SunPKCS11-Solaris and CKM_AES_CTR Summary: Changed output length calculation to include incomplete blocks for CTR mode. Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: fc70416beef3 Author: valeriep Date: 2013-05-13 16:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc70416beef3 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 59357ea7f131 Author: valeriep Date: 2013-05-15 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59357ea7f131 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java From chris.hegarty at oracle.com Thu May 16 01:51:29 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 May 2013 09:51:29 +0100 Subject: Code Review Request: 7150552: network test hangs [macosx] In-Reply-To: <519409AE.6050506@oracle.com> References: <518D8429.7060903@oracle.com> <519409AE.6050506@oracle.com> Message-ID: <51949E11.8010207@oracle.com> What you have looks fine. Thanks for liberating CookieManagerTest, and for removing another dependency on test/sun/net/www/httptest. -Chris. On 05/15/2013 11:18 PM, Kurchi Hazra wrote: > > > Hi, > > Two regression tests in jdk/test were hanging on Mac OS X > intermittently. Although it is difficult to reproduce > the problem, I suspect it is the use of the buggy httpserver test > library (jdk/test/sun/net/www/httptest) - we anyway want > to move away from using it. I have re-written parts of these tests to > use com.sun.net.httpserver instead. > > I have also unleashed the tests from the ProblemList and will keep a > closer watch on test runs. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7150552 > Webrev: http://cr.openjdk.java.net/~khazra/7150552/webrev.00/ > > > Thanks! > Kurchi > > From michael.x.mcmahon at oracle.com Thu May 16 01:54:07 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 16 May 2013 09:54:07 +0100 Subject: Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection In-Reply-To: <5193D254.9000407@oracle.com> References: <51890723.1020506@oracle.com> <51890A28.9070404@oracle.com> <51890FE2.7070800@oracle.com> <5193B1E4.1090100@oracle.com> <5193B8C0.20208@oracle.com> <5193D254.9000407@oracle.com> Message-ID: <51949EAF.5020201@oracle.com> On 15/05/13 19:22, Alan Bateman wrote: > On 15/05/2013 18:09, Chris Hegarty wrote: >> The change looks fine to me. >> >> -Chris >> >> On 15 May 2013, at 17:33, Michael McMahon >> > >> wrote: >> >>> This is the webrev for the bug >>> >>> http://cr.openjdk.java.net/~michaelm/8012625/webrev.1/ >>> >>> Thanks >>> Michael > The fix looks okay to me too. > > For the test then is there any reason that is has to run in othervm > mode? Just wondering if you could shutdown the http server when done. > Also not clear why the fields are static when they are initialized in > the ctor. Alignment issue at L93. > Probably doesn't need to be othervm, as it is cleaning up already. The test was written quickly, hence the static/instance field confusion. That can be changed easily too. Thanks Michael > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130516/26f5f8e7/attachment.html From chris.hegarty at oracle.com Thu May 16 03:06:05 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 16 May 2013 10:06:05 +0000 Subject: hg: jdk8/tl/jdk: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up Message-ID: <20130516100639.24F4548AF8@hg.openjdk.java.net> Changeset: bb01cc14223c Author: ewang Date: 2013-05-16 10:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb01cc14223c 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up Reviewed-by: alanb, dholmes, chegar ! test/java/lang/Thread/GenerifyStackTraces.java - test/java/lang/Thread/StackTraces.java From xuelei.fan at oracle.com Thu May 16 04:32:05 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 16 May 2013 11:32:05 +0000 Subject: hg: jdk8/tl/jdk: 8010814: More buffers are stored or returned without cloning Message-ID: <20130516113218.341CD48AF9@hg.openjdk.java.net> Changeset: b198389f9da4 Author: xuelei Date: 2013-05-16 04:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b198389f9da4 8010814: More buffers are stored or returned without cloning Reviewed-by: lancea ! src/share/classes/com/sun/jndi/ldap/BerDecoder.java ! src/share/classes/com/sun/jndi/ldap/BerEncoder.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java From Alan.Bateman at oracle.com Thu May 16 04:44:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 12:44:30 +0100 Subject: Non-standard socket options? In-Reply-To: <25F3043E-5901-4E84-9002-ADA026A19584@soterawireless.com> References: <518CD87A.1000900@oracle.com> <518E6702.2000509@oracle.com> <25F3043E-5901-4E84-9002-ADA026A19584@soterawireless.com> Message-ID: <5194C69E.1050009@oracle.com> On 15/05/2013 22:28, Brian Call wrote: > I just asked Neil if that option was supported for ipv6 and he said > that he doesn't think so... Likely once adoption of ipv6 reaches > critical mass and enough people complain, it will be added. We can > only hope... > > Please let me know if I can be of any more assistance. > > -Brian > Thanks for checking, I suspected this was the case. We've created two bugs to track this (one for DatagramChannel, one for legacy MulticastSocket). You can find them here (including a link to a prototype and test case): http://bugs.sun.com/view_bug.do?bug_id=8014377 http://bugs.sun.com/view_bug.do?bug_id=8014499 -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130516/aedfdfe1/attachment.html From dmitry.degrave at oracle.com Thu May 16 09:30:48 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 16 May 2013 16:30:48 +0000 Subject: hg: jdk8/tl/jdk: 8014676: Java debugger may fail to run Message-ID: <20130516163105.B15E948B04@hg.openjdk.java.net> Changeset: 81c449fd18fe Author: dmeetry Date: 2013-05-16 19:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81c449fd18fe 8014676: Java debugger may fail to run Summary: The problem is observed when the binaries for windows are placed under a path which contains a space Reviewed-by: sla, alanb Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java From michael.x.mcmahon at oracle.com Thu May 16 09:32:08 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 16 May 2013 16:32:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130516163231.64FEE48B05@hg.openjdk.java.net> Changeset: 74f91b7f4b66 Author: michaelm Date: 2013-05-16 17:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74f91b7f4b66 8012625: Incorrect handling of HTTP/1.1 " Expect: 100-continue " in HttpURLConnection Reviewed-by: alanb, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/B8012625.java Changeset: d02d1b18d828 Author: michaelm Date: 2013-05-16 17:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d02d1b18d828 Merge From daniel.fuchs at oracle.com Thu May 16 09:41:20 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Thu, 16 May 2013 16:41:20 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130516164146.B2CAB48B06@hg.openjdk.java.net> Changeset: da203779cb33 Author: jgish Date: 2013-05-16 11:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da203779cb33 8013380: Removal of stack walk to find resource bundle breaks Glassfish startup Summary: Use caller's classloader to load resource as an alternative to thread context classloader and system classloader Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/bundlesearch/IndirectlyLoadABundle.java - test/java/util/logging/bundlesearch/LoadItUp.java + test/java/util/logging/bundlesearch/LoadItUp1.java + test/java/util/logging/bundlesearch/LoadItUp2.java + test/java/util/logging/bundlesearch/LoadItUp2Invoker.java ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java + test/java/util/logging/bundlesearch/TwiceIndirectlyLoadABundle.java + test/java/util/logging/bundlesearch/resources/CallerSearchableResource_en.properties Changeset: df133f9cc4c9 Author: dfuchs Date: 2013-05-16 18:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df133f9cc4c9 Merge From kurchi.subhra.hazra at oracle.com Thu May 16 10:48:47 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 16 May 2013 17:48:47 +0000 Subject: hg: jdk8/tl/jdk: 7150552: network test hangs [macosx] Message-ID: <20130516174910.E623248B08@hg.openjdk.java.net> Changeset: a8be9405bb4b Author: khazra Date: 2013-05-16 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8be9405bb4b 7150552: network test hangs [macosx] Summary: Remove usage of test/sun/net/www/httptest Reviewed-by: chegar ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieManagerTest.java ! test/sun/net/www/protocol/http/B6299712.java From kumar.x.srinivasan at oracle.com Thu May 16 11:13:57 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 16 May 2013 18:13:57 +0000 Subject: hg: jdk8/tl/jdk: 8001163: [pack200] should support attributes introduced by JSR-308 Message-ID: <20130516181409.97BD148B0A@hg.openjdk.java.net> Changeset: a13de892cefd Author: ksrini Date: 2013-05-15 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a13de892cefd 8001163: [pack200] should support attributes introduced by JSR-308 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java + test/tools/pack200/BandIntegrity.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java + test/tools/pack200/typeannos/Lambda.java + test/tools/pack200/typeannos/Readme.txt + test/tools/pack200/typeannos/TargetTypes.java + test/tools/pack200/typeannos/TestTypeAnnotations.java + test/tools/pack200/typeannos/TypeUseTarget.java From vincent.x.ryan at oracle.com Thu May 16 13:27:29 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 16 May 2013 20:27:29 +0000 Subject: hg: jdk8/tl/jdk: 6 new changesets Message-ID: <20130516202851.8AD0048B18@hg.openjdk.java.net> Changeset: 9abf5dc83823 Author: vinnie Date: 2013-05-14 18:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9abf5dc83823 7194075: Various classes of sunec.jar are duplicated in rt.jar Reviewed-by: mullan, vinnie Contributed-by: Stephen Flores ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! makefiles/CreateJars.gmk + src/share/classes/sun/security/ec/CurveDB.java ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/NamedCurve.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/ssl/JsseJce.java + src/share/classes/sun/security/util/ECKeySizeParameterSpec.java + src/share/classes/sun/security/util/ECUtil.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/ec/TestECDH2.java ! test/sun/security/pkcs11/ec/TestECDSA2.java Changeset: fdf082cddb69 Author: vinnie Date: 2013-05-14 18:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fdf082cddb69 Merge Changeset: a399b8be56ae Author: vinnie Date: 2013-05-15 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a399b8be56ae Merge ! makefiles/CreateJars.gmk - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider Changeset: 5153f5154162 Author: vinnie Date: 2013-05-15 15:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5153f5154162 Merge Changeset: 0465f27f19f5 Author: vinnie Date: 2013-05-16 02:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0465f27f19f5 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java Changeset: 9783f07d43e6 Author: vinnie Date: 2013-05-16 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9783f07d43e6 Merge - test/java/lang/Thread/StackTraces.java - test/java/util/logging/bundlesearch/LoadItUp.java From mandy.chung at oracle.com Thu May 16 15:09:08 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 16 May 2013 22:09:08 +0000 Subject: hg: jdk8/tl/jdk: 4487672: (proxy) Proxy constructor should check for null argument Message-ID: <20130516220926.D7A1648B1C@hg.openjdk.java.net> Changeset: 5e8959ab64af Author: mchung Date: 2013-05-16 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e8959ab64af 4487672: (proxy) Proxy constructor should check for null argument Reviewed-by: alanb, lancea ! src/share/classes/java/lang/reflect/Proxy.java ! test/java/lang/reflect/Proxy/Basic1.java From weijun.wang at oracle.com Thu May 16 19:17:05 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 May 2013 10:17:05 +0800 Subject: RFR: 8012261: update policytool to support java.net.HttpURLPermission Message-ID: <51959321.9030204@oracle.com> Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8012261/webrev.00/ which supports the new HttpURLPermission type introduced in 8010464: Evolve java networking same origin policy http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 Noreg-trivial. Thanks Max From tom.hawtin at oracle.com Fri May 17 02:50:17 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 17 May 2013 10:50:17 +0100 Subject: RFR: 8012261: update policytool to support java.net.HttpURLPermission In-Reply-To: <51959321.9030204@oracle.com> References: <51959321.9030204@oracle.com> Message-ID: <5195FD59.5070105@oracle.com> On 17/05/2013 03:17, Weijun Wang wrote: > which supports the new HttpURLPermission type introduced in > > 8010464: Evolve java networking same origin policy > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 Not looked through it thoroughly, but are we sure we want url.toString()? Tom From weijun.wang at oracle.com Fri May 17 03:07:47 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 May 2013 18:07:47 +0800 Subject: 8010464 (was Re: RFR: 8012261: update policytool to support java.net.HttpURLPermission) In-Reply-To: <5195FD59.5070105@oracle.com> References: <51959321.9030204@oracle.com> <5195FD59.5070105@oracle.com> Message-ID: <51960173.4020300@oracle.com> On 5/17/13 5:50 PM, Tom Hawtin wrote: > On 17/05/2013 03:17, Weijun Wang wrote: > >> which supports the new HttpURLPermission type introduced in >> >> 8010464: Evolve java networking same origin policy >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 > > Not looked through it thoroughly, but are we sure we want url.toString()? I think this comment is on Michael's (already-pushed) changeset above. -Max > > Tom From chris.hegarty at oracle.com Fri May 17 03:24:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 11:24:13 +0100 Subject: 8010464 (was Re: RFR: 8012261: update policytool to support java.net.HttpURLPermission) In-Reply-To: <51960173.4020300@oracle.com> References: <51959321.9030204@oracle.com> <5195FD59.5070105@oracle.com> <51960173.4020300@oracle.com> Message-ID: <5196054D.30204@oracle.com> On 17/05/2013 11:07, Weijun Wang wrote: > > > On 5/17/13 5:50 PM, Tom Hawtin wrote: >> On 17/05/2013 03:17, Weijun Wang wrote: >> >>> which supports the new HttpURLPermission type introduced in >>> >>> 8010464: Evolve java networking same origin policy >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 >> >> Not looked through it thoroughly, but are we sure we want url.toString()? > > I think this comment is on Michael's (already-pushed) changeset above. D'oh. I missed this in the review. I think it should be using sun.net.util.URLUtil.urlNoFragString(URL) -Chris > > -Max > >> >> Tom From daniel.fuchs at oracle.com Fri May 17 03:22:15 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 17 May 2013 10:22:15 +0000 Subject: hg: jdk8/tl/jdk: 8013900: More warnings compiling jaxp. Message-ID: <20130517102228.AD98548B64@hg.openjdk.java.net> Changeset: 68209420aac2 Author: dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68209420aac2 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This patch adds hashCode() methods that are consistent with equals(). Reviewed-by: chegar, joehw + test/javax/xml/jaxp/PrecisionDecimalDV/XPrecisionDecimalToString.java From daniel.fuchs at oracle.com Fri May 17 03:21:54 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 17 May 2013 10:21:54 +0000 Subject: hg: jdk8/tl/jaxp: 8013900: More warnings compiling jaxp. Message-ID: <20130517102159.5ACAF48B63@hg.openjdk.java.net> Changeset: 6443f5627744 Author: dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6443f5627744 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This patch adds hashCode() methods that are consistent with equals(). Reviewed-by: chegar, joehw ! src/com/sun/org/apache/bcel/internal/generic/BasicType.java ! src/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java ! src/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java ! src/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java ! src/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java ! src/com/sun/org/apache/bcel/internal/generic/ReturnaddressType.java ! src/com/sun/org/apache/bcel/internal/generic/Select.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRefBase.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/DecimalDV.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/PrecisionDecimalDV.java ! src/com/sun/org/apache/xerces/internal/util/URI.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java ! src/com/sun/org/apache/xml/internal/serializer/utils/URI.java ! src/com/sun/org/apache/xml/internal/utils/URI.java ! src/com/sun/org/apache/xpath/internal/Arg.java From chris.hegarty at oracle.com Fri May 17 03:54:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 11:54:15 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) Message-ID: <51960C57.9010907@oracle.com> There are a few networking tests failing recently. All have bugs against them. These bugs will be address shortly, but since tl is integrating into master, for b91, next Tuesday, it is best to add them to the ProblemList so that the failures don't escape into master. diff -r 06b410feed49 -r 1e860864089a test/ProblemList.txt --- a/test/ProblemList.txt Fri May 17 11:05:43 2013 +0100 +++ b/test/ProblemList.txt Fri May 17 11:40:54 2013 +0100 @@ -205,6 +205,18 @@ java/net/MulticastSocket/Test.java #7143960 java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all +#8014783 +java/net/HttpURLPermission/HttpURLPermissionTest.java windows-all + +#8014720 +java/net/ResponseCache/B6181108.java generic-all + +#8014723 +sun/misc/URLClassPath/ClassnameCharTest.java generic-all + +#8014719 +sun/net/www/http/HttpClient/ProxyTest.java generic-all + -Chris. From Alan.Bateman at oracle.com Fri May 17 04:22:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 May 2013 12:22:22 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) In-Reply-To: <51960C57.9010907@oracle.com> References: <51960C57.9010907@oracle.com> Message-ID: <519612EE.4060202@oracle.com> On 17/05/2013 11:54, Chris Hegarty wrote: > There are a few networking tests failing recently. All have bugs > against them. These bugs will be address shortly, but since tl is > integrating into master, for b91, next Tuesday, it is best to add them > to the ProblemList so that the failures don't escape into master. > > diff -r 06b410feed49 -r 1e860864089a test/ProblemList.txt > --- a/test/ProblemList.txt Fri May 17 11:05:43 2013 +0100 > +++ b/test/ProblemList.txt Fri May 17 11:40:54 2013 +0100 > @@ -205,6 +205,18 @@ java/net/MulticastSocket/Test.java > #7143960 > java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all > > +#8014783 > +java/net/HttpURLPermission/HttpURLPermissionTest.java windows-all > + > +#8014720 > +java/net/ResponseCache/B6181108.java generic-all > + > +#8014723 > +sun/misc/URLClassPath/ClassnameCharTest.java generic-all > + > +#8014719 > +sun/net/www/http/HttpClient/ProxyTest.java generic-all > + > > -Chris. For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume that using try-with-resources around the code that opens the .ser files will sort this out (meaning might be as quick to just fix this one). For the rest then I agree, these need to be excluded until HttpURLPermission can support proxying of ftp connections. The long standing format has been to put a space before the bug number, I don't know if we have any grep-like tools that depend on that. As an aside, we need to re-format this file at some point to put the bug numbers onto the same line as the test. That's the format that jtreg prefers and would it be generally more grep-friendly. This needs to be done in conjunction with taking an axe to jdk/test/Makefile and I think on Mike's list. -Alan From sean.mullan at oracle.com Fri May 17 05:19:07 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 May 2013 08:19:07 -0400 Subject: RFR: 8012261: update policytool to support java.net.HttpURLPermission In-Reply-To: <51959321.9030204@oracle.com> References: <51959321.9030204@oracle.com> Message-ID: <5196203B.1060508@oracle.com> Looks fine to me. --Sean On 05/16/2013 10:17 PM, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8012261/webrev.00/ > > which supports the new HttpURLPermission type introduced in > > 8010464: Evolve java networking same origin policy > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 > > Noreg-trivial. > > Thanks > Max From chris.hegarty at oracle.com Fri May 17 06:49:05 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 14:49:05 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) In-Reply-To: <519612EE.4060202@oracle.com> References: <51960C57.9010907@oracle.com> <519612EE.4060202@oracle.com> Message-ID: <51963551.4060706@oracle.com> Thanks Alan, I'll make the changes to the formatting ( add space ), remove the addition of HttpURLPermissionTest, then push the change. -Chris. On 17/05/2013 12:22, Alan Bateman wrote: > On 17/05/2013 11:54, Chris Hegarty wrote: >> There are a few networking tests failing recently. All have bugs >> against them. These bugs will be address shortly, but since tl is >> integrating into master, for b91, next Tuesday, it is best to add them >> to the ProblemList so that the failures don't escape into master. >> >> diff -r 06b410feed49 -r 1e860864089a test/ProblemList.txt >> --- a/test/ProblemList.txt Fri May 17 11:05:43 2013 +0100 >> +++ b/test/ProblemList.txt Fri May 17 11:40:54 2013 +0100 >> @@ -205,6 +205,18 @@ java/net/MulticastSocket/Test.java >> #7143960 >> java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all >> >> +#8014783 >> +java/net/HttpURLPermission/HttpURLPermissionTest.java windows-all >> + >> +#8014720 >> +java/net/ResponseCache/B6181108.java generic-all >> + >> +#8014723 >> +sun/misc/URLClassPath/ClassnameCharTest.java generic-all >> + >> +#8014719 >> +sun/net/www/http/HttpClient/ProxyTest.java generic-all >> + >> >> -Chris. > For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume > that using try-with-resources around the code that opens the .ser files > will sort this out (meaning might be as quick to just fix this one). > > For the rest then I agree, these need to be excluded until > HttpURLPermission can support proxying of ftp connections. > > The long standing format has been to put a space before the bug number, > I don't know if we have any grep-like tools that depend on that. > > As an aside, we need to re-format this file at some point to put the bug > numbers onto the same line as the test. That's the format that jtreg > prefers and would it be generally more grep-friendly. This needs to be > done in conjunction with taking an axe to jdk/test/Makefile and I think > on Mike's list. > > -Alan From chris.hegarty at oracle.com Fri May 17 07:22:39 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 17 May 2013 14:22:39 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130517142318.6ED9548B6D@hg.openjdk.java.net> Changeset: 3981ad7ec458 Author: chegar Date: 2013-05-17 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3981ad7ec458 8014791: More ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: fab0e4b682e8 Author: chegar Date: 2013-05-17 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fab0e4b682e8 Merge ! test/ProblemList.txt - test/java/util/logging/bundlesearch/LoadItUp.java From chris.hegarty at oracle.com Fri May 17 07:40:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 15:40:44 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) In-Reply-To: <519612EE.4060202@oracle.com> References: <51960C57.9010907@oracle.com> <519612EE.4060202@oracle.com> Message-ID: <5196416C.8040608@oracle.com> On 17/05/2013 12:22, Alan Bateman wrote: > .... > For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume > that using try-with-resources around the code that opens the .ser files > will sort this out (meaning might be as quick to just fix this one). For this, I propose to simply replace the use of the file as a holder for the serial byte, with ByteArrayOutputStream. hg diff HttpURLPermissionTest.java diff -r fab0e4b682e8 test/java/net/HttpURLPermission/HttpURLPermissionTest.java --- a/test/java/net/HttpURLPermission/HttpURLPermissionTest.java Fri May 17 15:18:40 2013 +0100 +++ b/test/java/net/HttpURLPermission/HttpURLPermissionTest.java Fri May 17 15:34:54 2013 +0100 @@ -187,11 +187,12 @@ public class HttpURLPermissionTest { throws Exception { HttpURLPermission out = new HttpURLPermission(name, actions); - FileOutputStream fos = new FileOutputStream("out.ser"); - ObjectOutputStream o = new ObjectOutputStream(fos); + + ByteArrayOutputStream baos = new ByteArrayOutputStream(); + ObjectOutputStream o = new ObjectOutputStream(baos); o.writeObject(out); - FileInputStream fis = new FileInputStream("out.ser"); - ObjectInputStream i = new ObjectInputStream(fis); + ByteArrayInputStream bain = new ByteArrayInputStream(baos.toByteArray()); + ObjectInputStream i = new ObjectInputStream(bain); HttpURLPermission in = (HttpURLPermission)i.readObject(); if (!in.equals(out)) { System.out.println ("FAIL"); -Chris. From chris.hegarty at oracle.com Fri May 17 08:46:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 17 May 2013 15:46:14 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130517154656.85C3548B6F@hg.openjdk.java.net> Changeset: 222da3d4692a Author: chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/222da3d4692a 8014783: java/net/HttpURLPermission/HttpURLPermissionTest.java leaves files open Reviewed-by: michaelm ! test/java/net/HttpURLPermission/HttpURLPermissionTest.java Changeset: fed779a87670 Author: chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fed779a87670 Merge - test/java/util/logging/bundlesearch/LoadItUp.java From dan.xu at oracle.com Fri May 17 12:04:51 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 17 May 2013 19:04:51 +0000 Subject: hg: jdk8/tl/jdk: 8011136: FileInputStream.available and skip inconsistencies Message-ID: <20130517190511.F304148B7B@hg.openjdk.java.net> Changeset: 3b1450ee2bb9 Author: dxu Date: 2013-05-17 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b1450ee2bb9 8011136: FileInputStream.available and skip inconsistencies Summary: Correct the behavior of available() and update related java specs for available() and skip() in InputStream and FileInputStream classes. Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/InputStream.java ! src/share/native/java/io/FileInputStream.c ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/FileInputStream/NegativeAvailable.java From jonathan.gibbons at oracle.com Fri May 17 13:49:09 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 17 May 2013 20:49:09 +0000 Subject: hg: jdk8/tl/langtools: 6885876: add comments to javac/util/Convert.java Message-ID: <20130517204912.98CB448B82@hg.openjdk.java.net> Changeset: 0928f2cfbf8e Author: jjg Date: 2013-05-17 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0928f2cfbf8e 6885876: add comments to javac/util/Convert.java Reviewed-by: mduigou ! src/share/classes/com/sun/tools/javac/util/Convert.java From weijun.wang at oracle.com Fri May 17 19:13:16 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 18 May 2013 10:13:16 +0800 Subject: RFR: 8012261: update policytool to support java.net.HttpURLPermission In-Reply-To: <51969AAC.7050000@oracle.com> References: <51959321.9030204@oracle.com> <51969AAC.7050000@oracle.com> Message-ID: <5196E3BC.8070201@oracle.com> Hi Christophe No regression test. If there is an existing manual test checking all permissions supported, I'll be glad to update the description to cover this new type. Thanks Max On 5/18/13 5:01 AM, Christophe Ravel wrote: > Hi Max, > > What is your plan for regression tests for this change ? > > Regards, > Christophe. > >> Weijun Wang >> May 16, 2013 7:17 PM >> Hi All >> >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8012261/webrev.00/ >> >> which supports the new HttpURLPermission type introduced in >> >> 8010464: Evolve java networking same origin policy >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 >> >> Noreg-trivial. >> >> Thanks >> Max > > -- > Christophe Ravel | Principal Member of Technical Staff | +1.650.506.2162 > OracleJava SQE - Security > 4220 Network Circle, Office 2140, Santa Clara, CA 95054 > From weijun.wang at oracle.com Fri May 17 19:16:13 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 18 May 2013 02:16:13 +0000 Subject: hg: jdk8/tl/jdk: 8012261: update policytool to support java.net.HttpURLPermission Message-ID: <20130518021637.F2CF848B91@hg.openjdk.java.net> Changeset: 0f7aaabed25f Author: weijun Date: 2013-05-18 10:15 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f7aaabed25f 8012261: update policytool to support java.net.HttpURLPermission Reviewed-by: mullan ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java From mike.duigou at oracle.com Sat May 18 18:58:34 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sun, 19 May 2013 01:58:34 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130519020304.C0B5148B9F@hg.openjdk.java.net> Changeset: e8b40b034fcd Author: psandoz Date: 2013-05-15 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8b40b034fcd 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit Summary: this changeset also contains some minor, non spec, related fixes to tidy up other areas of the JavaDoc. Reviewed-by: plevart, darcy Contributed-by: John Rose , Mike Duigou , Paul Sandoz ! src/share/classes/java/util/Spliterator.java Changeset: 6bbc2816d936 Author: psandoz Date: 2013-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bbc2816d936 8014133: Spliterator.OfPrimitive Reviewed-by: mduigou, forax Contributed-by: Paul Sandoz , Brian Goetz ! src/share/classes/java/util/Spliterator.java Changeset: dc5cf74c8c9c Author: mduigou Date: 2013-05-17 10:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc5cf74c8c9c 8004015: Additional static and instance utils for functional interfaces. 8011010: Spec j.u.f.Predicate doesn't specify NPEs thrown by the SE8's Reference Implementation Reviewed-by: briangoetz, dholmes, chegar ! src/share/classes/java/util/function/BiConsumer.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BooleanSupplier.java ! src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/ObjDoubleConsumer.java ! src/share/classes/java/util/function/ObjIntConsumer.java ! src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java ! src/share/classes/java/util/function/ToDoubleFunction.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/ToIntFunction.java ! src/share/classes/java/util/function/ToLongBiFunction.java ! src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java Changeset: 23e75751554a Author: henryjen Date: 2013-05-09 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23e75751554a 8006884: (fs) Add Files.list, lines and find Reviewed-by: briangoetz, mduigou Contributed-by: alan.bateman at oracle.com, henry.jen at oracle.com + src/share/classes/java/nio/file/FileTreeIterator.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/FaultyFileSystem.java ! test/java/nio/file/Files/PassThroughFileSystem.java + test/java/nio/file/Files/StreamTest.java Changeset: b9b26b424bfc Author: mduigou Date: 2013-05-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9b26b424bfc Merge From david.holmes at oracle.com Sun May 19 20:58:45 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 20 May 2013 03:58:45 +0000 Subject: hg: jdk8/tl/jdk: 8014477: (str) Race condition in String.contentEquals when comparing with StringBuffer Message-ID: <20130520035909.51B0A48BAE@hg.openjdk.java.net> Changeset: 08ebdb2b53cc Author: plevart Date: 2013-05-17 14:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08ebdb2b53cc 8014477: (str) Race condition in String.contentEquals when comparing with StringBuffer Reviewed-by: alanb, mduigou, dholmes ! src/share/classes/java/lang/String.java + test/java/lang/String/StringContentEqualsBug.java From xueming.shen at oracle.com Mon May 20 11:59:29 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 20 May 2013 18:59:29 +0000 Subject: hg: jdk8/tl/jdk: 8004789: (zipfs) zip provider doesn't work correctly with file systems providers rather than the default Message-ID: <20130520185952.A40F548BC7@hg.openjdk.java.net> Changeset: 6a9148865139 Author: sherman Date: 2013-05-20 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a9148865139 8004789: (zipfs) zip provider doesn't work correctly with file systems providers rather than the default Summary: to use Files.createTempFile(...) to create the temp file on the same fs as the targeted path. Reviewed-by: alanb, sherman Contributed-by: philippe.marschall at gmail.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java From david.holmes at oracle.com Mon May 20 22:18:38 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 21 May 2013 05:18:38 +0000 Subject: hg: jdk8/tl/jdk: 8014857: Enable ergonomic VM selection in arm/jvm.cfg Message-ID: <20130521051851.0FA6348BDB@hg.openjdk.java.net> Changeset: 1baf3d7fe2f1 Author: dholmes Date: 2013-05-21 01:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1baf3d7fe2f1 8014857: Enable ergonomic VM selection in arm/jvm.cfg Reviewed-by: darcy ! src/solaris/bin/arm/jvm.cfg From alan.bateman at oracle.com Tue May 21 00:58:57 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 May 2013 07:58:57 +0000 Subject: hg: jdk8/tl/jdk: 8014892: More ProblemList.txt updates (5/2013) Message-ID: <20130521075910.6E4FC48BE3@hg.openjdk.java.net> Changeset: 20925206aef8 Author: alanb Date: 2013-05-21 08:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20925206aef8 8014892: More ProblemList.txt updates (5/2013) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From vicente.romero at oracle.com Tue May 21 03:42:05 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 10:42:05 +0000 Subject: hg: jdk8/tl/langtools: 7177168: Redundant array copy in UnsharedNameTable Message-ID: <20130521104209.7400548BEB@hg.openjdk.java.net> Changeset: 824932ecdbc8 Author: vromero Date: 2013-05-21 11:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/824932ecdbc8 7177168: Redundant array copy in UnsharedNameTable Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java From vicente.romero at oracle.com Tue May 21 04:18:20 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 11:18:20 +0000 Subject: hg: jdk8/tl/langtools: 7060779: test/tools/javac/diags/Example.java leaves directories in tempdir Message-ID: <20130521111823.EE51348BEC@hg.openjdk.java.net> Changeset: 3d9750039fff Author: vromero Date: 2013-05-21 12:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d9750039fff 7060779: test/tools/javac/diags/Example.java leaves directories in tempdir Reviewed-by: mcimadamore ! test/tools/javac/diags/Example.java From vicente.romero at oracle.com Tue May 21 05:51:37 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 12:51:37 +0000 Subject: hg: jdk8/tl/langtools: 8005207: test has 2 @bug tags Message-ID: <20130521125141.2FAA948BF3@hg.openjdk.java.net> Changeset: 37295244f534 Author: vromero Date: 2013-05-21 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37295244f534 8005207: test has 2 @bug tags Reviewed-by: mcimadamore ! test/tools/doclint/RunTest.java ! test/tools/javac/5045412/Bar.java ! test/tools/javac/5045412/Foo.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/policy/test3/Test.java From vicente.romero at oracle.com Tue May 21 06:33:41 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 13:33:41 +0000 Subject: hg: jdk8/tl/langtools: 7164114: Two jtreg tests are not run due to no file extension on the test files Message-ID: <20130521133343.D6F9F48BF5@hg.openjdk.java.net> Changeset: 08daea43a7f8 Author: vromero Date: 2013-05-21 14:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/08daea43a7f8 7164114: Two jtreg tests are not run due to no file extension on the test files Reviewed-by: mcimadamore - test/tools/javac/HiddenAbstractMethod/Test + test/tools/javac/HiddenAbstractMethod/Test.java - test/tools/javac/NonAmbiguousField/Test + test/tools/javac/NonAmbiguousField/Test.java ! test/tools/javac/NonAmbiguousField/two/Child2.java From chris.hegarty at oracle.com Wed May 22 05:52:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 22 May 2013 12:52:14 +0000 Subject: hg: jdk8/tl/jdk: 8010182: Thread safety of Thread get/setName() Message-ID: <20130522125238.761DE48C39@hg.openjdk.java.net> Changeset: 48e8a6e0c805 Author: chegar Date: 2013-05-22 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48e8a6e0c805 8010182: Thread safety of Thread get/setName() Reviewed-by: dholmes, alanb, mduigou ! src/share/classes/java/lang/Thread.java From mike.duigou at oracle.com Wed May 22 10:01:19 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 22 May 2013 17:01:19 +0000 Subject: hg: jdk8/tl/jdk: 8014819: set max size for jtreg testvms Message-ID: <20130522170130.DB0FB48C45@hg.openjdk.java.net> Changeset: 4b555b53dc57 Author: mduigou Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b555b53dc57 8014819: set max size for jtreg testvms Reviewed-by: alanb, darcy ! test/Makefile From lana.steuck at oracle.com Wed May 22 12:10:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:35 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130522191041.2549C48C48@hg.openjdk.java.net> Changeset: c8286839d0df Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c8286839d0df Added tag jdk8-b89 for changeset fe4150590ee5 ! .hgtags Changeset: 8f7ffb296385 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8f7ffb296385 Added tag jdk8-b90 for changeset c8286839d0df ! .hgtags From lana.steuck at oracle.com Wed May 22 12:10:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:46 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130522191052.83F2548C4A@hg.openjdk.java.net> Changeset: 67ca019e3713 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/67ca019e3713 Added tag jdk8-b89 for changeset 45ce27fbe272 ! .hgtags Changeset: 4ce88eec5078 Author: katleman Date: 2013-05-16 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4ce88eec5078 Added tag jdk8-b90 for changeset 67ca019e3713 ! .hgtags Changeset: 6b9f41203800 Author: lana Date: 2013-05-17 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6b9f41203800 Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - src/jdk/nashorn/internal/runtime/SpillProperty.java - test/script/trusted/logcoverage.js Changeset: e955e64fd15d Author: lana Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e955e64fd15d Merge From lana.steuck at oracle.com Wed May 22 12:10:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:39 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130522191052.0425148C49@hg.openjdk.java.net> Changeset: 3e5b9ea5ac35 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3e5b9ea5ac35 Added tag jdk8-b89 for changeset 88838e08e4ef ! .hgtags Changeset: 0bb1a9fa56b0 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/0bb1a9fa56b0 Added tag jdk8-b90 for changeset 3e5b9ea5ac35 ! .hgtags From lana.steuck at oracle.com Wed May 22 12:10:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:36 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20130522191037.28CF948C47@hg.openjdk.java.net> Changeset: 69b773a221b9 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/69b773a221b9 Added tag jdk8-b89 for changeset 892a0196d10c ! .hgtags Changeset: 83b519cafa68 Author: katleman Date: 2013-05-16 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/83b519cafa68 Added tag jdk8-b90 for changeset 69b773a221b9 ! .hgtags Changeset: 40bba0507f76 Author: lana Date: 2013-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/40bba0507f76 Merge From lana.steuck at oracle.com Wed May 22 12:10:43 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:43 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130522191101.4839A48C4B@hg.openjdk.java.net> Changeset: 668acc0e1034 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/668acc0e1034 Added tag jdk8-b89 for changeset 893d2ba8bbea ! .hgtags Changeset: f39d61028d2f Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f39d61028d2f Added tag jdk8-b90 for changeset 668acc0e1034 ! .hgtags Changeset: e3065fb07877 Author: lana Date: 2013-05-17 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e3065fb07877 Merge Changeset: 0765806dcc58 Author: lana Date: 2013-05-22 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0765806dcc58 Merge From lana.steuck at oracle.com Wed May 22 12:11:05 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:11:05 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130522191126.05AF248C4C@hg.openjdk.java.net> Changeset: e19283cd30a4 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e19283cd30a4 Added tag jdk8-b89 for changeset ec434cfd2752 ! .hgtags Changeset: 9717b9523d46 Author: katleman Date: 2013-05-16 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9717b9523d46 Added tag jdk8-b90 for changeset e19283cd30a4 ! .hgtags Changeset: 997c0fae2b12 Author: lana Date: 2013-05-17 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/997c0fae2b12 Merge - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java Changeset: 31344e8e3343 Author: lana Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/31344e8e3343 Merge From lana.steuck at oracle.com Wed May 22 12:11:40 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:11:40 +0000 Subject: hg: jdk8/tl/hotspot: 86 new changesets Message-ID: <20130522191500.B5E4848C4D@hg.openjdk.java.net> Changeset: 7d56b68a9672 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d56b68a9672 Added tag jdk8-b89 for changeset 9c1fe0b419b4 ! .hgtags Changeset: 625ddb0052e1 Author: amurillo Date: 2013-05-03 08:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/625ddb0052e1 8013800: new hotspot build - hs25-b32 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c456f4510385 Author: sla Date: 2013-05-03 12:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c456f4510385 8008453: JvmtiClassFileReconstituter does not recognize default methods Reviewed-by: acorn, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 0380df7c3cd0 Author: sla Date: 2013-05-03 12:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0380df7c3cd0 8013785: Respect EXTRA_CFLAGS on windows Reviewed-by: mgronlun, rbackman, kvn ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make Changeset: 31a4e55f8c9d Author: fparain Date: 2013-05-03 05:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31a4e55f8c9d 8004095: Add support for JMX interface to Diagnostic Framework and Commands Reviewed-by: acorn, sla ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/serviceThread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 39fba0d6d9ad Author: fparain Date: 2013-05-03 05:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39fba0d6d9ad Merge Changeset: bf089b838c9e Author: ccheung Date: 2013-05-02 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf089b838c9e 8012641: Perf_CreateLong creates perf counter of incorrect type Reviewed-by: mchung, hseigel, coleenp ! src/share/vm/prims/perf.cpp Changeset: a55b7b8c34af Author: zgu Date: 2013-05-03 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a55b7b8c34af Merge Changeset: 9c8e2f44228d Author: dcubed Date: 2013-05-03 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c8e2f44228d Merge Changeset: 800078be49d2 Author: hseigel Date: 2013-05-06 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/800078be49d2 8013648: Guarantee(VerifyBeforeGC || VerifyDuringGC || VerifyBeforeExit || VerifyAfterGC) failed: too expensive Summary: Fix code to call correct version of function find_class(). Reviewed-by: coleenp, rdurbin, dcubed ! src/share/vm/classfile/systemDictionary.cpp Changeset: c18152e0554e Author: zgu Date: 2013-05-06 11:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c18152e0554e 8013120: NMT: Kitchensink crashes with assert(next_region == NULL || !next_region->is_committed_region()) failed: Sanity check Summary: Fixed NMT to deal with releasing virtual memory region when there are still committed regions within it Reviewed-by: acorn, coleenp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/services/memSnapshot.cpp + test/runtime/NMT/ReleaseCommittedMemory.java Changeset: da4d87770781 Author: zgu Date: 2013-05-06 08:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da4d87770781 Merge Changeset: d9b08d62b95e Author: acorn Date: 2013-05-02 10:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9b08d62b95e 8010783: assert(s->refcount() != 0) failed: for create_overpasses Reviewed-by: kvn, dcubed ! src/share/vm/classfile/bytecodeAssembler.cpp Changeset: b7f3bf2ba33b Author: acorn Date: 2013-05-06 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7f3bf2ba33b Merge - agent/doc/c2replay.html Changeset: f916d5986c86 Author: acorn Date: 2013-05-06 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f916d5986c86 Merge Changeset: 187154b7a226 Author: sla Date: 2013-05-06 19:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/187154b7a226 8009615: JvmtiClassFileReconstituter does not create BootstrapMethod attributes Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: 3ecc6b9940de Author: sla Date: 2013-05-07 01:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3ecc6b9940de Merge Changeset: b5fef8013a95 Author: sla Date: 2013-05-07 14:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5fef8013a95 8014044: Spelling error in JDK-8009615: boostrapmethod Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: f6a055fcf47d Author: sla Date: 2013-05-07 14:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6a055fcf47d 8005038: remove crufty '_g' support from SA Reviewed-by: coleenp, mgronlun, rbackman ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java Changeset: 33bcd9ead1d5 Author: ctornqvi Date: 2013-05-07 21:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33bcd9ead1d5 8009577: Test test/closed/runtime/classunload broken Summary: Fixed tests to use new way of utilizing the WB API, fixed issue with where custom classloader got the classes from Reviewed-by: collins, mgerdin, zgu + test/runtime/ClassUnload/KeepAliveClass.java + test/runtime/ClassUnload/KeepAliveClassLoader.java + test/runtime/ClassUnload/KeepAliveObject.java + test/runtime/ClassUnload/KeepAliveSoftReference.java + test/runtime/ClassUnload/UnloadTest.java + test/runtime/ClassUnload/classes/test/Empty.java + test/runtime/testlibrary/ClassUnloadCommon.java Changeset: 58bb870a0cbd Author: emc Date: 2013-05-07 13:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58bb870a0cbd 8009729: Refix hotspot jni_.h JNIEXPORT and JNIIMPORT definitions to match jdk version Summary: Update JNIEXPORT and JNIIMPORT to work with other compilers that don't necessarily have the __attribute__ type qualifier Reviewed-by: dholmes, dcubed, coleenp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h Changeset: 7243490a6847 Author: coleenp Date: 2013-05-07 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7243490a6847 Merge Changeset: e60b3fce2b02 Author: jiangli Date: 2013-05-06 19:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e60b3fce2b02 8013067: Zero builds are broken after 8010862. Summary: Fixed broken Zero build. Reviewed-by: twisti, coleenp, kvn ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp Changeset: 27d2d456cd96 Author: jiangli Date: 2013-05-06 20:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27d2d456cd96 Merge Changeset: 6b388e7d4905 Author: bpittore Date: 2013-05-07 10:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b388e7d4905 8013633: Cleanup platform ifdefs in unsafe.cpp Summary: Replace ifdefs with SUPPORTS_NATIVE_CX8 set in platform include file Reviewed-by: dholmes, dlong ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/share/vm/prims/unsafe.cpp Changeset: a258a8351528 Author: vladidan Date: 2013-05-07 10:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a258a8351528 Merge - agent/doc/c2replay.html Changeset: d3c98423c146 Author: jiangli Date: 2013-05-09 16:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3c98423c146 Merge Changeset: 1d0fba8a2a6d Author: brutisso Date: 2013-05-02 22:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d0fba8a2a6d 8013574: PrintMalloc conflicts with the command line parsing Summary: Make sure that _num_jvm_args is not updated until the new entry to _jvm_args_array has been added Reviewed-by: johnc, tamao, tschatzl ! src/share/vm/runtime/arguments.cpp Changeset: f14063dcd52a Author: brutisso Date: 2013-05-06 09:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f14063dcd52a 8013791: G1: G1CollectorPolicy::initialize_flags() may set min_alignment > max_alignment Summary: Make sure max alignemnt is at least as large as min alignment Reviewed-by: johnc, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/g1/TestRegionAlignment.java Changeset: 30860066ae8f Author: jwilhelm Date: 2013-05-06 13:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30860066ae8f Merge ! src/share/vm/runtime/arguments.cpp Changeset: d17700c82d7d Author: tschatzl Date: 2013-05-06 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d17700c82d7d 8006088: Incompatible heap size flags accepted by VM Summary: Make processing of minimum, initial and maximum heap size more intiutive by removing previous limitations on allowed values, and make error reporting consistent. Further, fix errors in ergonomic heap sizing. Reviewed-by: johnc, jwilhelm, tamao ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b0d20fa374b4 Author: brutisso Date: 2013-05-06 21:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0d20fa374b4 8013872: G1: HeapRegionSeq::shrink_by() has invalid assert Summary: Refactored shrink_by() to only use region counts and not byte sizes Reviewed-by: johnc, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + test/gc/g1/TestShrinkToOneRegion.java Changeset: a9d568b7df60 Author: jmasa Date: 2013-05-08 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9d568b7df60 8013032: CMS: assert(used() == used_after_gc && used_after_gc <= capacity()) failed: used: 0 used_after_gc: 292080 capacity: 1431699456 Reviewed-by: tschatzl, mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/CheckAllocateAndSystemGC.java Changeset: 06ab37f08701 Author: jmasa Date: 2013-05-08 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06ab37f08701 8013184: CMS: Call reset_after_compaction() only if a compaction has been done Reviewed-by: mgerdin, johnc, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/concurrentMarkSweep/SystemGCOnForegroundCollector.java Changeset: 923ac8d1df95 Author: jwilhelm Date: 2013-05-09 12:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/923ac8d1df95 Merge Changeset: 194f52aa2f23 Author: johnc Date: 2013-05-09 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/194f52aa2f23 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap Summary: Refactor G1's hot card cache and card counts table into their own files. Simplify the card counts table, including removing the encoding of the card index in each entry. The card counts table now has a 1:1 correspondence with the cards spanned by heap. Space for the card counts table is reserved from virtual memory (rather than C heap) during JVM startup and is committed/expanded when the heap is expanded. Changes were also reviewed-by Vitaly Davidovich. Reviewed-by: tschatzl, jmasa ! make/excludeSrc.make ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp + src/share/vm/gc_implementation/g1/g1CardCounts.cpp + src/share/vm/gc_implementation/g1/g1CardCounts.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp + src/share/vm/gc_implementation/g1/g1HotCardCache.cpp + src/share/vm/gc_implementation/g1/g1HotCardCache.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 73652d89e7c4 Author: stefank Date: 2013-05-10 09:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73652d89e7c4 Merge Changeset: 69494caf5790 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69494caf5790 Merge Changeset: 1ae0472ff3a0 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ae0472ff3a0 Added tag hs25-b32 for changeset 69494caf5790 ! .hgtags Changeset: 1cdbd42c3e49 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cdbd42c3e49 Added tag jdk8-b90 for changeset 1ae0472ff3a0 ! .hgtags Changeset: 6114c49b31b5 Author: amurillo Date: 2013-05-10 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6114c49b31b5 8014279: new hotspot build - hs25-b33 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 712a1e9c91f3 Author: coleenp Date: 2013-05-07 09:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/712a1e9c91f3 8013063: nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free Summary: Clear out class_file_bytes so they aren't deallocated twice Reviewed-by: dcubed, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4674e409a9e6 Author: coleenp Date: 2013-05-07 18:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4674e409a9e6 8014024: NPG: keep compiled ic methods from being deallocated in redefine classes Summary: Walk the compiledIC relocation records to keep Method* from being deallocated. Reviewed-by: dlong, kvn ! src/share/vm/code/nmethod.cpp Changeset: a1cc1d1e7ce5 Author: coleenp Date: 2013-05-07 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1cc1d1e7ce5 Merge Changeset: 28ae1d38d296 Author: coleenp Date: 2013-05-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28ae1d38d296 Merge Changeset: 64340da5b68c Author: hseigel Date: 2013-05-08 08:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64340da5b68c 8007018: RFE: -XX:+UseLargePages does not work with CDS Summary: Remove command line restriction. It should just work. Reviewed-by: ctornqvi, coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: cbfe859bd244 Author: sla Date: 2013-05-08 15:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cbfe859bd244 8013591: compiler/ciReplay/TestSA.sh fails in nightly Reviewed-by: coleenp, rbackman, dholmes ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java Changeset: 0dc028fd5101 Author: sla Date: 2013-05-08 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0dc028fd5101 Merge Changeset: 39ead0411f07 Author: bharadwaj Date: 2013-05-08 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39ead0411f07 8013875: Incorrect vtable index being set during methodHandle creation for static Summary: Set vtable index as appropriate for static interface methods and for interface methods invoked via invokespecial. To be improved in a later enhancement to CallInfo. Reviewed-by: jrose, twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 711016f146fd Author: dholmes Date: 2013-05-08 19:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/711016f146fd 8006997: ContendedPaddingWidth should be range-checked Summary: Constrain between zero and 8K Reviewed-by: dholmes, rbackman Contributed-by: Aleksey Shipilev ! src/share/vm/runtime/arguments.cpp Changeset: 9b77ca4ce35e Author: dholmes Date: 2013-05-08 19:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b77ca4ce35e Merge ! src/share/vm/runtime/arguments.cpp Changeset: c272092594bd Author: dholmes Date: 2013-05-08 21:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c272092594bd Merge Changeset: 0b7f78069732 Author: rbackman Date: 2013-05-08 11:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b7f78069732 8008255: jvmtiExport.cpp::post_to_env() does not check malloc() return Reviewed-by: coleenp, dholmes, sla ! src/share/vm/prims/jvmtiExport.cpp Changeset: 735c995bf1a1 Author: rbackman Date: 2013-05-13 07:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/735c995bf1a1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 92ef81e2f571 Author: minqi Date: 2013-05-10 08:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/92ef81e2f571 8003557: NPG: Klass* const k should be const Klass* k. Summary: With NPG, const KlassOop klass which is in fact a definition converted to Klass* const, which is not the original intention. The right usage is converting them to const Klass*. Reviewed-by: coleenp, kvn Contributed-by: yumin.qi at oracle.com ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 1fcfc045b229 Author: minqi Date: 2013-05-10 19:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1fcfc045b229 Merge Changeset: 8b40495b9381 Author: minqi Date: 2013-05-13 18:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b40495b9381 Merge ! src/share/vm/oops/method.hpp Changeset: 43083e670adf Author: coleenp Date: 2013-05-13 15:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43083e670adf 8005056: NPG: Crash after redefining java.lang.Object Summary: Need to walk array class vtables replacing old methods too if j.l.o redefined Reviewed-by: sspitsyn, dcubed, ctornqvi ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp + test/runtime/RedefineObject/Agent.java + test/runtime/RedefineObject/TestRedefineObject.java ! test/testlibrary/ClassFileInstaller.java Changeset: a9270d9ecb13 Author: shade Date: 2013-05-14 11:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9270d9ecb13 8014448: Purge PrintCompactFieldsSavings Summary: Remove obsolete debugging code. Reviewed-by: dholmes, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: f944ba972151 Author: hseigel Date: 2013-05-14 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f944ba972151 8014138: Add VM option to facilitate the writing of CDS tests Summary: Added the -XX:SharedArchiveFile option. Reviewed-by: coleenp, ccheung, acorn, dcubed, zgu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp + test/runtime/SharedArchiveFile/SharedArchiveFile.java Changeset: f9be75d21404 Author: minqi Date: 2013-05-14 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9be75d21404 8012902: remove use of global operator new - take 2 Summary: The fix of 8010992, disable use of global operator new and new[] which caused failure on some tests. This takes two of the bugs also add ALLOW_OPERATOR_NEW_USAGE to prevent crash for third party code calling operator new of jvm on certain platforms. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/vm.make ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 513a5298c1dd Author: minqi Date: 2013-05-14 17:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513a5298c1dd Merge Changeset: d15464bfd4d0 Author: roland Date: 2013-05-03 09:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d15464bfd4d0 8012037: Test8009761.java "Failed: init recursive calls: 7224. After deopt 58824" Summary: test shouldn't be run with a modified CompileThreshold Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: e76dd894b984 Author: roland Date: 2013-04-24 14:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e76dd894b984 8012292: optimized build with GCC broken Summary: Some #ifndef PRODUCT should be #ifdef ASSERT Reviewed-by: kvn, twisti Contributed-by: gdub ! make/jprt.properties ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: d73c88e524ff Author: kvn Date: 2013-05-03 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d73c88e524ff Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: f0bc60565ba8 Author: twisti Date: 2013-05-06 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0bc60565ba8 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact Reviewed-by: jrose, kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: aabf54ccedb1 Author: twisti Date: 2013-05-06 19:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aabf54ccedb1 8008772: remove gamma launcher Reviewed-by: kvn, neliasso, ctornqvi ! make/Makefile ! make/bsd/makefiles/buildtree.make - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make + make/hotspot.script ! make/linux/makefiles/buildtree.make - make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make - make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make - make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/projectfiles/common/Makefile - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h Changeset: 6f3fd5150b67 Author: kvn Date: 2013-05-08 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f3fd5150b67 6934604: enable parts of EliminateAutoBox by default Summary: Resurrected autobox elimination code and enabled part of it by default. Reviewed-by: roland, twisti ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/6934604/TestByteBoxing.java + test/compiler/6934604/TestDoubleBoxing.java + test/compiler/6934604/TestFloatBoxing.java + test/compiler/6934604/TestIntBoxing.java + test/compiler/6934604/TestLongBoxing.java + test/compiler/6934604/TestShortBoxing.java Changeset: 70120f47d403 Author: kvn Date: 2013-05-09 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70120f47d403 8014189: JVM crash with SEGV in ConnectionGraph::record_for_escape_analysis() Summary: Add NULL checks and asserts for Type::make_ptr() returned value. Reviewed-by: twisti ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/subnode.cpp Changeset: 8bcfd9ce2c6b Author: twisti Date: 2013-05-13 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bcfd9ce2c6b Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 1da5d70655e9 Author: kvn Date: 2013-05-13 14:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1da5d70655e9 8014286: failed java/lang/Math/DivModTests.java after 6934604 changes Summary: Corrected escape state for the result of boxing method. Added force inlining executed boxing methods. Reviewed-by: twisti ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/escape.cpp Changeset: cd6f6fccd287 Author: iignatyev Date: 2013-05-15 22:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd6f6fccd287 8014068: TEST_BUG: compiler/ciReplay/TestSA.sh fails on Windows: core wasn't generated Reviewed-by: kvn ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/common.sh Changeset: e484fe2abebd Author: twisti Date: 2013-05-16 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e484fe2abebd Merge - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: 7a95933197d0 Author: tschatzl Date: 2013-05-13 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a95933197d0 8014058: Regression tests for 8006088 Summary: The patch for 8006088 misses regression tests after a merge error, this CR provides them. Reviewed-by: jwilhelm, tamao, jmasa ! src/share/vm/memory/collectorPolicy.cpp + test/gc/arguments/TestCMSHeapSizeFlags.java + test/gc/arguments/TestG1HeapSizeFlags.java + test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMinInitialErgonomics.java + test/gc/arguments/TestParallelHeapSizeFlags.java + test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 4868caa99ecf Author: brutisso Date: 2013-05-13 14:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4868caa99ecf 8014339: Improve assert and remove some dead code from parMarkBitMap.hpp/cpp Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 0a2986f36965 Author: tschatzl Date: 2013-05-14 17:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a2986f36965 8014489: tests/gc/arguments/Test(Serial|CMS|Parallel|G1)HeapSizeFlags jtreg tests invoke wrong class Summary: Some jtreg tests reference unknown classes in the @run and @build lines. This change fixes them. Reviewed-by: stefank, ehelin ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 12f651e29f6b Author: tschatzl Date: 2013-05-15 11:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12f651e29f6b 6843347: Boundary values in some public GC options cause crashes Summary: Setting some public integer options to specific values causes crashes or undefined GC behavior. This patchset adds the necessary argument checking for these options. Reviewed-by: jmasa, brutisso ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eba99d16dc6f Author: tamao Date: 2013-05-15 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba99d16dc6f 8007763: Refactoring: split up compute_generation_free_space() into two functions for class PSAdaptiveSizePolicy Summary: split up compute_generation_free_space() into two functions: compute_eden_space_size() + compute_old_gen_free_space(), each of which (if needed) can be reused without executing an overhead of the other. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: bed55d125e37 Author: johnc Date: 2013-05-15 22:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bed55d125e37 8014408: G1: crashes with assert assert(prev_committed_card_num == _committed_max_card_num) failed Summary: Mismatch in the card number calculation between next and previous committed sizes of the card counts table. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 05a17f270c7e Author: tschatzl Date: 2013-05-16 13:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05a17f270c7e 8014240: G1: Add remembered set size information to output of G1PrintRegionLivenessInfo Summary: Improve the output of G1PrintRegionLivenessInfo by adding a per-region remembered set size information column Reviewed-by: jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 48391ab0687e Author: johnc Date: 2013-05-16 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48391ab0687e 8010738: G1: Output for full GCs with +PrintGCDetails should contain perm gen size/meta data change info Summary: Include metaspace information (used, allocated, reserved) in the PrintGCDetails output for full GCs. Reviewed-by: poonam, jmasa, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + test/gc/g1/TestPrintGCDetails.java Changeset: acac2b03a07f Author: tschatzl Date: 2013-05-16 23:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acac2b03a07f 8014765: VM exits if MaxTenuringThreshold is set below the default InitialTenuringThreshold, and InitialTenuringThreshold is not set Summary: The VM exits when the condition in the subject line applies. The fix sets InitialTenuringThreshold to MaxTenuringThreshold if it is larger than MaxTenuringThreshold and InitialTenuringThreshold has not been set (is default). Reviewed-by: jwilhelm, jmasa, brutisso, johnc ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestInitialTenuringThreshold.java Changeset: 2958af1d8c5a Author: jwilhelm Date: 2013-05-17 06:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2958af1d8c5a Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2f9ac66165e6 Author: jwilhelm Date: 2013-05-17 08:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f9ac66165e6 Merge - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: b19517cecc2e Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b19517cecc2e Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: 7cbdf0e3725c Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7cbdf0e3725c Added tag hs25-b33 for changeset b19517cecc2e ! .hgtags From lana.steuck at oracle.com Wed May 22 12:12:58 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:12:58 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20130522191804.C371B48C4E@hg.openjdk.java.net> Changeset: b8e7d145abc2 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8e7d145abc2 Added tag jdk8-b89 for changeset 845025546e35 ! .hgtags Changeset: 1f1699686504 Author: katleman Date: 2013-05-09 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f1699686504 8014289: JDK8 b89 source with GPL header errors Reviewed-by: mchung, mduigou, tbell, dsamersoff ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/StringJoiner.java ! test/java/lang/CharSequence/DefaultTest.java ! test/java/util/StringJoiner/StringJoinerTest.java Changeset: c63eda8f6300 Author: katleman Date: 2013-05-14 12:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c63eda8f6300 Merge Changeset: 08c28cdacd7b Author: katleman Date: 2013-05-16 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08c28cdacd7b Added tag jdk8-b90 for changeset c63eda8f6300 ! .hgtags Changeset: 4dd6f7bb8bbd Author: simonis Date: 2013-05-06 12:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4dd6f7bb8bbd 7191872: Xrender: No text displayed using 64 bit JDK on solaris11-sparc Reviewed-by: prr, ceisserer ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/GlyphList.java ! src/solaris/classes/sun/font/XRGlyphCacheEntry.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 23f7ff502a89 Author: jgodinez Date: 2013-05-07 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23f7ff502a89 8011069: Printing: NullPointerException since jdk8 b82 showing native Page Setup Dialog. Reviewed-by: bae, prr ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 8a995d335d59 Author: lana Date: 2013-05-09 19:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a995d335d59 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 103f492d8ce7 Author: vadim Date: 2013-05-17 17:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/103f492d8ce7 4892259: GIF ImageReader does not call passComplete in IIOReadUpdateListener Reviewed-by: prr, bae ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java + test/javax/imageio/plugins/gif/GIFPassListenerTest.java Changeset: 4ee85e865a83 Author: vadim Date: 2013-05-17 14:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ee85e865a83 8000936: Enable Java2D D3D pipeline on newer Intel chipsets : Intel HD and later Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 51f5e544c88b Author: lana Date: 2013-05-17 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51f5e544c88b Merge Changeset: 90b67c9a7eb2 Author: serb Date: 2013-05-06 16:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90b67c9a7eb2 7161575: [macosx] On MacOSX port java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWToolkit.java Changeset: 7982299cd11c Author: serb Date: 2013-05-08 15:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7982299cd11c 8013841: [macosx] Animations not disabled for CALayers used via JAWT Reviewed-by: anthony, alexsch ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 5fe0a4da863d Author: lana Date: 2013-05-09 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe0a4da863d Merge - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: a466a4192fea Author: pchelko Date: 2013-05-14 16:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a466a4192fea 8002045: Auto failed and threw exception:java.lang.UnsatisfiedLinkError: Reviewed-by: serb, anthony ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mapfile-vers-linux ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux Changeset: b1a7cc79f13d Author: serb Date: 2013-05-14 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1a7cc79f13d 8014423: [macosx] The scrollbar's block increment performs incorrectly Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java Changeset: 722ee3129ce0 Author: ant Date: 2013-05-15 16:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/722ee3129ce0 8014227: JLightweightFrame needs another synchronization policy Reviewed-by: art ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 7a8a8e31a126 Author: pchelko Date: 2013-05-17 11:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8a8e31a126 7079254: Toolkit eventListener leaks memory Reviewed-by: serb, art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java + test/java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Changeset: e944b78812a8 Author: kshefov Date: 2013-05-17 14:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e944b78812a8 8014721: TEST_BUG: java/awt/TrayIcon/DragEventSource/DragEventSource.java fails with java.lang.UnsupportedOperationException Reviewed-by: anthony, serb ! test/java/awt/TrayIcon/DragEventSource/DragEventSource.java Changeset: 281add053efe Author: kshefov Date: 2013-05-17 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/281add053efe 8013426: TEST_BUG: java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java fails with "RuntimeException: The data should be available" on Linux Reviewed-by: anthony, serb ! test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java Changeset: 49871f1581b8 Author: lana Date: 2013-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49871f1581b8 Merge Changeset: 30101f69e66f Author: lana Date: 2013-05-17 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30101f69e66f Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Base64.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: bcfab7056195 Author: lana Date: 2013-05-22 09:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcfab7056195 Merge Changeset: 760d4187597a Author: lana Date: 2013-05-22 12:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/760d4187597a Merge From joe.darcy at oracle.com Wed May 22 13:34:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 22 May 2013 20:34:18 +0000 Subject: hg: jdk8/tl/langtools: 8010680: Clarify "present" and annotation ordering in javax.lang.model Message-ID: <20130522203421.0DEDA48C59@hg.openjdk.java.net> Changeset: 3bd22f99d408 Author: darcy Date: 2013-05-22 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3bd22f99d408 8010680: Clarify "present" and annotation ordering in javax.lang.model Reviewed-by: abuckley, jjg ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/util/Elements.java From naoto.sato at oracle.com Wed May 22 16:43:48 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2013 23:43:48 +0000 Subject: hg: jdk8/tl/jdk: 7056126: DateFormatSymbols documentation has incorrect description about DateFormat; ... Message-ID: <20130522234408.E489648C66@hg.openjdk.java.net> Changeset: 50fde3eeb48c Author: naoto Date: 2013-05-22 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50fde3eeb48c 7056126: DateFormatSymbols documentation has incorrect description about DateFormat 7083668: Sample code in ListResourceBundle is still not correct Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/util/ListResourceBundle.java From david.holmes at oracle.com Wed May 22 17:22:14 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 23 May 2013 00:22:14 +0000 Subject: hg: jdk8/tl/jdk: 8014814: (str) StringBuffer "null" is not appended Message-ID: <20130523002227.DFDD648C67@hg.openjdk.java.net> Changeset: a1a8e71e130a Author: dholmes Date: 2013-05-22 20:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1a8e71e130a 8014814: (str) StringBuffer "null" is not appended Reviewed-by: alanb ! src/share/classes/java/lang/StringBuffer.java ! test/java/lang/StringBuffer/ToStringCache.java From joe.darcy at oracle.com Wed May 22 20:04:11 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 23 May 2013 03:04:11 +0000 Subject: hg: jdk8/tl/jdk: 8014836: Have GenericDeclaration extend AnnotatedElement Message-ID: <20130523030435.BAA4248C7C@hg.openjdk.java.net> Changeset: e764bb01567e Author: darcy Date: 2013-05-22 20:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e764bb01567e 8014836: Have GenericDeclaration extend AnnotatedElement Reviewed-by: abuckley, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java From nils.loodin at oracle.com Thu May 23 06:54:01 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Thu, 23 May 2013 13:54:01 +0000 Subject: hg: jdk8/tl/jdk: 8014048: Online user guide of jconsole points incorrect link Message-ID: <20130523135413.A8A2B48CA9@hg.openjdk.java.net> Changeset: 0da6485cf656 Author: nloodin Date: 2013-05-23 15:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0da6485cf656 8014048: Online user guide of jconsole points incorrect link Reviewed-by: mchung, sla, jbachorik ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties From chris.hegarty at oracle.com Thu May 23 10:36:06 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 23 May 2013 17:36:06 +0000 Subject: hg: jdk8/tl/jdk: 8014076: Arrays parallel and serial sorting improvements Message-ID: <20130523173631.03B9748CB0@hg.openjdk.java.net> Changeset: 3b23e3529ab3 Author: dl Date: 2013-05-23 18:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b23e3529ab3 8014076: Arrays parallel and serial sorting improvements Reviewed-by: chegar, mduigou ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/ArraysParallelSortHelpers.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/DualPivotQuicksort.java ! src/share/classes/java/util/TimSort.java ! test/java/util/Arrays/ParallelSorting.java From weijun.wang at oracle.com Fri May 24 02:34:50 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 24 May 2013 09:34:50 +0000 Subject: hg: jdk8/tl/jdk: 8014196: ktab creates a file with zero kt_vno Message-ID: <20130524093523.B5AC848D07@hg.openjdk.java.net> Changeset: 6816afd70a68 Author: weijun Date: 2013-05-24 17:15 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6816afd70a68 8014196: ktab creates a file with zero kt_vno Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java + test/sun/security/krb5/tools/KtabZero.java + test/sun/security/krb5/tools/ktzero.sh From maurizio.cimadamore at oracle.com Fri May 24 07:29:32 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 24 May 2013 14:29:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130524142952.35A1E48D10@hg.openjdk.java.net> Changeset: 58329d9f6b68 Author: mcimadamore Date: 2013-05-24 15:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58329d9f6b68 8014643: Parser regression in JDK 8 when compiling super.x Summary: Fixed latent bug in JavacParser.analyzeParens() Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/8014643/T8014643.java Changeset: 97a9b4b3e63a Author: mcimadamore Date: 2013-05-24 15:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97a9b4b3e63a 8014649: Regression: bug in Resolve.resolveOperator Summary: Missing curly braces causes Resolve.findMethod to be called spuriously Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/PrimitiveBinopOverload.java Changeset: 6e5076af4660 Author: mcimadamore Date: 2013-05-24 15:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e5076af4660 8014494: javac crashes when varargs element of a method reference is inferred from the context Summary: varargs element is not refreshed after type-inference Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/TargetType73.java From joe.darcy at oracle.com Fri May 24 11:26:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 24 May 2013 18:26:28 +0000 Subject: hg: jdk8/tl/langtools: 8014836: Have GenericDeclaration extend AnnotatedElement Message-ID: <20130524182635.1F03048D20@hg.openjdk.java.net> Changeset: 0f8e9a0e5d9a Author: darcy Date: 2013-05-24 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f8e9a0e5d9a 8014836: Have GenericDeclaration extend AnnotatedElement Reviewed-by: jfranck ! src/share/sample/language/model/CoreReflectionFactory.java From kumar.x.srinivasan at oracle.com Fri May 24 18:54:53 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 25 May 2013 01:54:53 +0000 Subject: hg: jdk8/tl/jdk: 8007333: [launcher] removes multiple back slashes Message-ID: <20130525015529.0B9A248D30@hg.openjdk.java.net> Changeset: 5e769206f036 Author: ksrini Date: 2013-05-24 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e769206f036 8007333: [launcher] removes multiple back slashes Reviewed-by: alanb, akhil ! src/windows/bin/cmdtoargs.c ! test/tools/launcher/Arrrghs.java From david.holmes at oracle.com Mon May 27 04:34:19 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 27 May 2013 11:34:19 +0000 Subject: hg: jdk8/tl/jdk: 7038914: VM could throw uncaught OOME in ReferenceHandler thread Message-ID: <20130527113433.001D348D5A@hg.openjdk.java.net> Changeset: 0b8dab7fec54 Author: plevart Date: 2013-05-27 09:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b8dab7fec54 7038914: VM could throw uncaught OOME in ReferenceHandler thread Summary: Catch OutOfMemoryError in reference handler thread if caused by allocation of an InterruptedException Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ref/Reference.java + test/java/lang/ref/OOMEInReferenceHandler.java From vicente.romero at oracle.com Mon May 27 05:44:46 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 27 May 2013 12:44:46 +0000 Subject: hg: jdk8/tl/langtools: 7030476: Fix conflicting use of JCTree/JCExpression Message-ID: <20130527124449.5A3AB48D5F@hg.openjdk.java.net> Changeset: b391ecea538e Author: vromero Date: 2013-05-27 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b391ecea538e 7030476: Fix conflicting use of JCTree/JCExpression Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java From chris.hegarty at oracle.com Mon May 27 07:26:11 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 27 May 2013 14:26:11 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130527142657.20B0548D61@hg.openjdk.java.net> Changeset: a2dc42667df3 Author: chegar Date: 2013-05-27 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2dc42667df3 8015439: Minor/sync/cleanup of ConcurrentHashMap Reviewed-by: chegar Contributed-by: Doug Lea
, Chris Hegarty ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 9bbf2237071e Author: chegar Date: 2013-05-27 15:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bbf2237071e Merge From nils.loodin at oracle.com Mon May 27 08:18:33 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Mon, 27 May 2013 15:18:33 +0000 Subject: hg: jdk8/tl/jdk: 6470730: Disconnect button leads to wrong popup message Message-ID: <20130527151845.4F89448D64@hg.openjdk.java.net> Changeset: bbf6e6222726 Author: nloodin Date: 2013-05-27 17:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbf6e6222726 6470730: Disconnect button leads to wrong popup message Reviewed-by: dcubed, sla, egahlin ! src/share/classes/sun/tools/jconsole/VMPanel.java From vicente.romero at oracle.com Tue May 28 04:46:48 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 28 May 2013 11:46:48 +0000 Subject: hg: jdk8/tl/langtools: 6970173: Debug pointer at bad position Message-ID: <20130528114652.D07EF48D80@hg.openjdk.java.net> Changeset: c6df5b20f9eb Author: vromero Date: 2013-05-28 12:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c6df5b20f9eb 6970173: Debug pointer at bad position Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java From dmitry.samersoff at oracle.com Tue May 28 07:47:20 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Tue, 28 May 2013 14:47:20 +0000 Subject: hg: jdk8/tl/jdk: 8014420: Default JDP address does not match the one assigned by IANA Message-ID: <20130528144753.CA50E48D8D@hg.openjdk.java.net> Changeset: 7d7bfce34a79 Author: dsamersoff Date: 2013-05-28 18:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7bfce34a79 8014420: Default JDP address does not match the one assigned by IANA Summary: JDP protocol defaults changed to IANA assigned values Reviewed-by: dholmes, jbachorik, hirt Contributed-by: fweimer at redhat.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/jdp/package-info.java ! test/sun/management/jdp/JdpTest.sh From rob.mckenna at oracle.com Tue May 28 08:35:11 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 28 May 2013 15:35:11 +0000 Subject: hg: jdk8/tl/jdk: 7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys Message-ID: <20130528153537.D27B148D8F@hg.openjdk.java.net> Changeset: b16a8b4ae6b4 Author: robm Date: 2013-05-28 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16a8b4ae6b4 7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys Reviewed-by: alanb ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/IsHidden.java From vicente.romero at oracle.com Tue May 28 09:40:30 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 28 May 2013 16:40:30 +0000 Subject: hg: jdk8/tl/langtools: 8012333: javac, ClassFile should have a read(Path) method Message-ID: <20130528164037.CB39048D96@hg.openjdk.java.net> Changeset: d042cba65eab Author: vromero Date: 2013-05-28 17:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d042cba65eab 8012333: javac, ClassFile should have a read(Path) method Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java From xueming.shen at oracle.com Tue May 28 10:45:00 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 28 May 2013 17:45:00 +0000 Subject: hg: jdk8/tl/jdk: 8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method Message-ID: <20130528174551.2A37B48D9A@hg.openjdk.java.net> Changeset: 7fa2d1dcb8f6 Author: sherman Date: 2013-05-28 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa2d1dcb8f6 8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method Summary: to make defensive copy for set/get replacement byte array Reviewed-by: martin ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java From naoto.sato at oracle.com Tue May 28 14:03:16 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 28 May 2013 21:03:16 +0000 Subject: hg: jdk8/tl/jdk: 6251788: (rb) PropertyResourceBundle doesn't document exceptions Message-ID: <20130528210343.3E15D48DA6@hg.openjdk.java.net> Changeset: b99d56d1aa3f Author: naoto Date: 2013-05-28 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b99d56d1aa3f 6251788: (rb) PropertyResourceBundle doesn't document exceptions Reviewed-by: okutsu ! src/share/classes/java/util/PropertyResourceBundle.java From xuelei.fan at oracle.com Tue May 28 18:48:31 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 29 May 2013 01:48:31 +0000 Subject: hg: jdk8/tl/jdk: 8010815: some constructors issues in com.sun.jndi.toolkit Message-ID: <20130529014906.C8A5548DBA@hg.openjdk.java.net> Changeset: 1652a22cf6e7 Author: xuelei Date: 2013-05-28 18:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1652a22cf6e7 8010815: some constructors issues in com.sun.jndi.toolkit Reviewed-by: alanb ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java From dan.xu at oracle.com Tue May 28 22:25:24 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 29 May 2013 05:25:24 +0000 Subject: hg: jdk8/tl/jdk: 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently Message-ID: <20130529052537.1FE4848DBF@hg.openjdk.java.net> Changeset: e59d7f0f36f7 Author: ewang Date: 2013-05-28 22:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59d7f0f36f7 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently Reviewed-by: dxu, alanb Contributed-by: yiming.wang at oracle.com ! test/java/io/pathNames/General.java ! test/java/io/pathNames/GeneralWin32.java From staffan.larsen at oracle.com Wed May 29 00:43:11 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 29 May 2013 07:43:11 +0000 Subject: hg: jdk8/tl/jdk: 8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Message-ID: <20130529074332.6E97C48DC3@hg.openjdk.java.net> Changeset: bd6d3801347b Author: sla Date: 2013-05-29 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6d3801347b 8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Summary: Make sure serial gc compacts heap every time Reviewed-by: mchung, brutisso, nloodin ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java From alan.bateman at oracle.com Wed May 29 02:28:15 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 29 May 2013 09:28:15 +0000 Subject: hg: jdk8/tl/jdk: 8014928: (fs) Files.readAllBytes() copies content to new array when content completely read Message-ID: <20130529092901.8F87148DCF@hg.openjdk.java.net> Changeset: 2b3242a69a44 Author: alanb Date: 2013-05-29 10:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b3242a69a44 8014928: (fs) Files.readAllBytes() copies content to new array when content completely read Reviewed-by: martin ! src/share/classes/java/nio/file/Files.java From vicente.romero at oracle.com Wed May 29 02:58:03 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 29 May 2013 09:58:03 +0000 Subject: hg: jdk8/tl/langtools: 7053059: VerifyError with double Assignment using a Generic Member of a Superclass Message-ID: <20130529095809.94FF848DD1@hg.openjdk.java.net> Changeset: 92e420e9807d Author: vromero Date: 2013-05-29 10:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e420e9807d 7053059: VerifyError with double Assignment using a Generic Member of a Superclass Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/T7053059/VerifyErrorWithDoubleAssignmentTest.java From vincent.x.ryan at oracle.com Wed May 29 06:59:02 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 29 May 2013 13:59:02 +0000 Subject: hg: jdk8/tl/jdk: 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate Message-ID: <20130529135914.E179548DDF@hg.openjdk.java.net> Changeset: 00ad19610e75 Author: vinnie Date: 2013-05-29 14:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00ad19610e75 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java From jonathan.gibbons at oracle.com Wed May 29 15:42:33 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 29 May 2013 22:42:33 +0000 Subject: hg: jdk8/tl/langtools: 8015641: genstubs needs to cope with static interface methods Message-ID: <20130529224240.5958B48E07@hg.openjdk.java.net> Changeset: d685b12b62a4 Author: jjg Date: 2013-05-29 15:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d685b12b62a4 8015641: genstubs needs to cope with static interface methods Reviewed-by: ksrini ! make/tools/genstubs/GenStubs.java From xueming.shen at oracle.com Wed May 29 19:53:10 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 30 May 2013 02:53:10 +0000 Subject: hg: jdk8/tl/jdk: 4759491: method ZipEntry.setTime(long) works incorrectly; ... Message-ID: <20130530025333.AE19648E12@hg.openjdk.java.net> Changeset: 90df6756406f Author: sherman Date: 2013-05-29 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f 4759491: method ZipEntry.setTime(long) works incorrectly 6303183: Support NTFS and Unix-style timestamps for entries in Zip files 7012856: (zipfs) Newly created entry in zip file system should set all file times non-null values. 7012868: (zipfs) file times of entry in zipfs should always be the same regardless of TimeZone. Summary: to add suuport of Info-ZIP extended timestamp in extra data fields Reviewed-by: martin, alanb ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java + src/share/classes/java/util/zip/ZipUtils.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh ! test/java/util/jar/TestExtra.java ! test/java/util/zip/StoredCRC.java + test/java/util/zip/TestExtraTime.java ! test/java/util/zip/ZipFile/Assortment.java From chris.hegarty at oracle.com Thu May 30 04:21:39 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 30 May 2013 11:21:39 +0000 Subject: hg: jdk8/tl/jdk: 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Message-ID: <20130530112205.4794848E23@hg.openjdk.java.net> Changeset: 6df9b071b04d Author: jzavgren Date: 2013-05-30 12:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df9b071b04d 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Reviewed-by: martin, dholmes, chegar, ksrini ! src/solaris/bin/java_md_solinux.c From chris.hegarty at oracle.com Thu May 30 04:53:07 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 30 May 2013 12:53:07 +0100 Subject: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length Message-ID: <51A73DA3.8080905@oracle.com> The Unix native implementation that determines the network interface's broadcast address and network prefix/subnet mask, incorrectly ties the mask to the existence of a broadcast address. This should be changed so that the network prefix/subnet mask, if available, is exposed through the Java API, getNetworkPrefixLength, regardless of the broadcast address. http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ Creating a reliable automatic regression test for this be problematic. Also, there is already an existing test that verify that getNetworkPrefixLength returns values within specified bounds. This issue can be easily seen with the loopback interface: >: ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:722 errors:0 dropped:0 overruns:0 frame:0 TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) >: binaries/jdk1.7.0_07/bin/java Test lo <0:0:0:0:0:0:0:1%1> getBroadcast():null getNetworkPrefixLength():128 <127.0.0.1> getBroadcast():null getNetworkPrefixLength():0 -Chris. From Alan.Bateman at oracle.com Thu May 30 05:15:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 May 2013 13:15:09 +0100 Subject: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length In-Reply-To: <51A73DA3.8080905@oracle.com> References: <51A73DA3.8080905@oracle.com> Message-ID: <51A742CD.8000000@oracle.com> On 30/05/2013 12:53, Chris Hegarty wrote: > The Unix native implementation that determines the network interface's > broadcast address and network prefix/subnet mask, incorrectly ties the > mask to the existence of a broadcast address. This should be changed > so that the network prefix/subnet mask, if available, is exposed > through the Java API, getNetworkPrefixLength, regardless of the > broadcast address. > > http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ > > Creating a reliable automatic regression test for this be problematic. > Also, there is already an existing test that verify that > getNetworkPrefixLength returns values within specified bounds. > > This issue can be easily seen with the loopback interface: > > >: ifconfig lo > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:722 errors:0 dropped:0 overruns:0 frame:0 > TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) > > >: binaries/jdk1.7.0_07/bin/java Test lo > <0:0:0:0:0:0:0:1%1> > getBroadcast():null > getNetworkPrefixLength():128 > <127.0.0.1> > getBroadcast():null > getNetworkPrefixLength():0 > > -Chris. This looks fine to me. -Alan From michael.x.mcmahon at oracle.com Thu May 30 06:54:47 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 30 May 2013 14:54:47 +0100 Subject: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length In-Reply-To: <51A73DA3.8080905@oracle.com> References: <51A73DA3.8080905@oracle.com> Message-ID: <51A75A27.5050201@oracle.com> The change looks fine. Do you think it would be possible to make a test case by using the loopback interface, when it's available and when it doesn't have a broadcast address, which is probably a very common situation? Michael On 30/05/13 12:53, Chris Hegarty wrote: > The Unix native implementation that determines the network interface's > broadcast address and network prefix/subnet mask, incorrectly ties the > mask to the existence of a broadcast address. This should be changed > so that the network prefix/subnet mask, if available, is exposed > through the Java API, getNetworkPrefixLength, regardless of the > broadcast address. > > http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ > > Creating a reliable automatic regression test for this be problematic. > Also, there is already an existing test that verify that > getNetworkPrefixLength returns values within specified bounds. > > This issue can be easily seen with the loopback interface: > > >: ifconfig lo > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:722 errors:0 dropped:0 overruns:0 frame:0 > TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) > > >: binaries/jdk1.7.0_07/bin/java Test lo > <0:0:0:0:0:0:0:1%1> > getBroadcast():null > getNetworkPrefixLength():128 > <127.0.0.1> > getBroadcast():null > getNetworkPrefixLength():0 > > -Chris. From paul.sandoz at oracle.com Thu May 30 07:26:18 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 30 May 2013 14:26:18 +0000 Subject: hg: jdk8/tl/jdk: 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Message-ID: <20130530142644.D115248E2A@hg.openjdk.java.net> Changeset: 156ee44cd456 Author: psandoz Date: 2013-05-30 16:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ee44cd456 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Summary: Also fixes documentation on StreamBuilder.OfDouble Reviewed-by: alanb, chegar, mduigou ! src/share/classes/java/util/stream/StreamBuilder.java From paul.sandoz at oracle.com Thu May 30 07:34:17 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 30 May 2013 14:34:17 +0000 Subject: hg: jdk8/tl/jdk: 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Message-ID: <20130530143434.2119C48E2D@hg.openjdk.java.net> Changeset: b4742d038100 Author: psandoz Date: 2013-05-28 15:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4742d038100 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Reviewed-by: alanb, chegar ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java From chris.hegarty at oracle.com Thu May 30 08:33:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 30 May 2013 16:33:03 +0100 Subject: RFR 7107883: getNetworkPrefixLength() does not return correct prefix length In-Reply-To: <51A75A27.5050201@oracle.com> References: <51A73DA3.8080905@oracle.com> <51A75A27.5050201@oracle.com> Message-ID: <51A7712F.9000307@oracle.com> On 05/30/2013 02:54 PM, Michael McMahon wrote: > The change looks fine. Do you think it would be possible to make a > test case by using the loopback interface, when it's available and > when it doesn't have a broadcast address, which is probably a very common > situation? I think the IPv4 loopback address should always have a prefix of 8. So the test would look like : http://cr.openjdk.java.net/~chegar/7107883/webrev.01/webrev/test/java/net/InterfaceAddress/NetworkPrefixLength.java.udiff.html -Chris. > > Michael > > On 30/05/13 12:53, Chris Hegarty wrote: >> The Unix native implementation that determines the network interface's >> broadcast address and network prefix/subnet mask, incorrectly ties the >> mask to the existence of a broadcast address. This should be changed >> so that the network prefix/subnet mask, if available, is exposed >> through the Java API, getNetworkPrefixLength, regardless of the >> broadcast address. >> >> http://cr.openjdk.java.net/~chegar/7107883/webrev.00/webrev/ >> >> Creating a reliable automatic regression test for this be problematic. >> Also, there is already an existing test that verify that >> getNetworkPrefixLength returns values within specified bounds. >> >> This issue can be easily seen with the loopback interface: >> >> >: ifconfig lo >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 >> inet6 addr: ::1/128 Scope:Host >> UP LOOPBACK RUNNING MTU:16436 Metric:1 >> RX packets:722 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:722 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:102346 (102.3 KB) TX bytes:102346 (102.3 KB) >> >> >: binaries/jdk1.7.0_07/bin/java Test lo >> <0:0:0:0:0:0:0:1%1> >> getBroadcast():null >> getNetworkPrefixLength():128 >> <127.0.0.1> >> getBroadcast():null >> getNetworkPrefixLength():0 >> >> -Chris. > From michael.x.mcmahon at oracle.com Thu May 30 09:49:29 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 30 May 2013 17:49:29 +0100 Subject: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing Message-ID: <51A78319.1000508@oracle.com> http://cr.openjdk.java.net/~michaelm/8014723/webrev.1/ regression caused by the HttpURLPermission implemenation not using the raw URI accessor methods. Some other changes are coming to this class, but I just want to fix this problem separately. Thanks Michael From michael.x.mcmahon at oracle.com Thu May 30 10:04:56 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 30 May 2013 18:04:56 +0100 Subject: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing In-Reply-To: <51A78319.1000508@oracle.com> References: <51A78319.1000508@oracle.com> Message-ID: <51A786B8.5050003@oracle.com> This also fixes 8014720. So, I should have included the removal of the relevant test from ProblemList.txt diff -r b4742d038100 test/ProblemList.txt --- a/test/ProblemList.txt Tue May 28 15:22:30 2013 +0200 +++ b/test/ProblemList.txt Thu May 30 18:04:17 2013 +0100 @@ -199,12 +199,6 @@ # 7143960 java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all -# 8014720 -java/net/ResponseCache/B6181108.java generic-all - -# 8014723 -sun/misc/URLClassPath/ClassnameCharTest.java generic-all - # 8014719 sun/net/www/http/HttpClient/ProxyTest.java generic-all On 30/05/13 17:49, Michael McMahon wrote: > > http://cr.openjdk.java.net/~michaelm/8014723/webrev.1/ > > regression caused by the HttpURLPermission implemenation not using > the raw URI accessor methods. Some other changes are coming > to this class, but I just want to fix this problem separately. > > Thanks > Michael > > From xueming.shen at oracle.com Thu May 30 14:50:30 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 30 May 2013 21:50:30 +0000 Subject: hg: jdk8/tl/jdk: 8015271: Conversion table for EUC-KR is incorrect Message-ID: <20130530215045.E507448E36@hg.openjdk.java.net> Changeset: b588955b7e5b Author: sherman Date: 2013-05-30 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b588955b7e5b 8015271: Conversion table for EUC-KR is incorrect Summary: to add the requested postal code mark character u+327e Reviewed-by: alanb ! make/tools/CharsetMapping/EUC_KR.map From xuelei.fan at oracle.com Thu May 30 22:03:51 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:03:51 +0000 Subject: hg: jdk8/tl/jdk: 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Message-ID: <20130531050404.EA02048E4B@hg.openjdk.java.net> Changeset: 6407106f1b1c Author: xuelei Date: 2013-05-30 22:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6407106f1b1c 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/util/KeyUtil.java + test/com/sun/crypto/provider/TLS/TestLeadingZeroes.java + test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java From xuelei.fan at oracle.com Thu May 30 22:21:24 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:21:24 +0000 Subject: hg: jdk8/tl/jdk: 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Message-ID: <20130531052135.DD0F348E4D@hg.openjdk.java.net> Changeset: 8402ef8fabde Author: ascarpino Date: 2013-05-30 22:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8402ef8fabde 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Reviewed-by: mullan, xuelei ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/CipherOutputStream.java + test/javax/crypto/Cipher/CipherStreamClose.java From xuelei.fan at oracle.com Thu May 30 22:26:24 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:26:24 +0000 Subject: hg: jdk8/tl/jdk: 8013069: javax.crypto tests fail with new PBE algorithm names Message-ID: <20130531052636.127B448E4E@hg.openjdk.java.net> Changeset: 6cb09d3cd309 Author: valeriep Date: 2013-05-29 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cb09d3cd309 8013069: javax.crypto tests fail with new PBE algorithm names Summary: Shouldn't auto-generate default parameters for MAC objects. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/MacClone.java From xuelei.fan at oracle.com Thu May 30 22:36:11 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:36:11 +0000 Subject: hg: jdk8/tl/jdk: 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Message-ID: <20130531053622.DB15D48E4F@hg.openjdk.java.net> Changeset: 918d9ac17740 Author: ascarpino Date: 2013-05-30 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/918d9ac17740 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java From chris.hegarty at oracle.com Fri May 31 01:02:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 May 2013 09:02:59 +0100 Subject: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing In-Reply-To: <51A786B8.5050003@oracle.com> References: <51A78319.1000508@oracle.com> <51A786B8.5050003@oracle.com> Message-ID: <51A85933.3040201@oracle.com> Thanks for the additional update to the ProblemList Michael. The source change looks fine to me. I assume that all encoding, as with URL, needs to be done at the application level. Since you are effectively using the single arg URI constructor, then all accessors should use the raw form. -Chris. On 05/30/2013 06:04 PM, Michael McMahon wrote: > This also fixes 8014720. So, I should have included the removal > of the relevant test from ProblemList.txt > > diff -r b4742d038100 test/ProblemList.txt > --- a/test/ProblemList.txt Tue May 28 15:22:30 2013 +0200 > +++ b/test/ProblemList.txt Thu May 30 18:04:17 2013 +0100 > @@ -199,12 +199,6 @@ > # 7143960 > java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all > > -# 8014720 > -java/net/ResponseCache/B6181108.java generic-all > - > -# 8014723 > -sun/misc/URLClassPath/ClassnameCharTest.java generic-all > - > # 8014719 > sun/net/www/http/HttpClient/ProxyTest.java generic-all > > > > On 30/05/13 17:49, Michael McMahon wrote: >> >> http://cr.openjdk.java.net/~michaelm/8014723/webrev.1/ >> >> regression caused by the HttpURLPermission implemenation not using >> the raw URI accessor methods. Some other changes are coming >> to this class, but I just want to fix this problem separately. >> >> Thanks >> Michael >> >> > From paul.sandoz at oracle.com Fri May 31 01:03:03 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 31 May 2013 08:03:03 +0000 Subject: hg: jdk8/tl/jdk: 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Message-ID: <20130531080318.5C1D448E53@hg.openjdk.java.net> Changeset: b47044426bcd Author: psandoz Date: 2013-05-31 09:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b47044426bcd 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Summary: A minor documentation issue (not a spec issue). Reviewed-by: chegar, dl ! src/share/classes/java/util/Spliterator.java From chris.hegarty at oracle.com Fri May 31 01:32:00 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 31 May 2013 08:32:00 +0000 Subject: hg: jdk8/tl/jdk: 7107883: getNetworkPrefixLength() does not return correct prefix length Message-ID: <20130531083225.EF21548E58@hg.openjdk.java.net> Changeset: dcf42861b5b1 Author: chegar Date: 2013-05-31 09:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcf42861b5b1 7107883: getNetworkPrefixLength() does not return correct prefix length Reviewed-by: alanb, michaelm ! src/solaris/native/java/net/NetworkInterface.c ! test/java/net/InterfaceAddress/NetworkPrefixLength.java From vicente.romero at oracle.com Fri May 31 02:05:52 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 31 May 2013 09:05:52 +0000 Subject: hg: jdk8/tl/langtools: 7179353: try-with-resources fails to compile with generic exception parameters Message-ID: <20130531090604.168F148E79@hg.openjdk.java.net> Changeset: 9f11c7676cd5 Author: vromero Date: 2013-05-31 10:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f11c7676cd5 7179353: try-with-resources fails to compile with generic exception parameters Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T7179353/GenericsAndTWRCompileErrorTest.java From alan.bateman at oracle.com Fri May 31 04:22:33 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 31 May 2013 11:22:33 +0000 Subject: hg: jdk8/tl/jdk: 8014854: (bf) CharBuffer.chars too slow with default implementation Message-ID: <20130531112303.ED0E148E83@hg.openjdk.java.net> Changeset: 243cd682c47b Author: alanb Date: 2013-05-31 12:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/243cd682c47b 8014854: (bf) CharBuffer.chars too slow with default implementation Reviewed-by: erikj, briangoetz, henryjen, psandoz, mduigou ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcBuffer.gmk ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template + src/share/classes/java/nio/CharBufferSpliterator.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/Heap-X-Buffer.java.template ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template + test/java/nio/Buffer/Chars.java From Alan.Bateman at oracle.com Fri May 31 04:44:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 12:44:07 +0100 Subject: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing In-Reply-To: <51A78319.1000508@oracle.com> References: <51A78319.1000508@oracle.com> Message-ID: <51A88D07.6020100@oracle.com> On 30/05/2013 17:49, Michael McMahon wrote: > > http://cr.openjdk.java.net/~michaelm/8014723/webrev.1/ > > regression caused by the HttpURLPermission implemenation not using > the raw URI accessor methods. Some other changes are coming > to this class, but I just want to fix this problem separately. > > Thanks > Michael > I think looks fine. An alternative would be to just use the 5-arg constructor like this: u = new URI(scheme, u.getAuthority(), u.getPath(), null, null); but requires handling the checked URISyntaxExceptin so what you have is probably neater. -Alan. From john.zavgren at oracle.com Fri May 31 05:11:16 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Fri, 31 May 2013 08:11:16 -0400 Subject: RFR JDK7188517 In-Reply-To: <51937759.5070507@oracle.com> References: <51937759.5070507@oracle.com> Message-ID: <51A89364.30903@oracle.com> All: I'd like to give everyone another chance to weigh in on this change: http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ so that I can wrap up this fix ASAP. (It makes HTTP cookies that begin with a dollar sign "illegal".) Thanks! John On 05/15/2013 07:54 AM, John Zavgren wrote: > Greetings: > > Can I get a show of hands on this RFR > (http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)? > It's CCC request has been accepted and I'd like to wrap it up ASAP. > > Thanks! > John Zavgren > > On 05/09/2013 02:22 PM, John Zavgren wrote: >> Greetings: >> I made a mistake in my last RFR posting... the URL for the latest >> modifications is: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ >> instead of: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >> >> The most recent change is to reinstate the original test that tested >> for cookie names that lead with a dollar sign. >> >> I'm sorry about the confusion. >> >> Thanks! >> John >> >> >> On 05/09/2013 03:42 PM, John Zavgren wrote: >>> Chris, et alia: >>> I put the reinstated the old test. >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>> >>> John >>> >>> ----- Original Message ----- >>> From: chris.hegarty at oracle.com >>> To: john.zavgren at oracle.com >>> Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net >>> Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern >>> Subject: Re: RFR JDK7188517 >>> >>> John, >>> >>> I think you can simply reinstate >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java >>> >>> >>> -Chris. >>> >>> On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >>>> I would have thrown an exception if the IllegalArgumentException is >>>> not >>>> obtained, otherwise the test looses its >>>> purpose, and will pass silently if someone mistakenly removes the $ >>>> check in our code. >>>> >>>> - Kurchi >>>> >>>> On 5/8/2013 12:10 PM, John Zavgren wrote: >>>>> Greetings: >>>>> >>>>> I added a test for the leading dollar sign character in cookie names: >>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>>> >>>>> Thanks! >>>>> John >>>>> >>>>> >>>>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>>>> This looks okay to me. >>>>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>>>> for '$' >>>>>>>>> >>>>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>>>> change. We should get positive agreement from Michael before >>>>>>>>> pushing >>>>>>>>> this. >>>>>>>>> >>>>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>>>> with '$'. >>>>>>>> I agree we should add a negative test now for a similar cookie. >>>>>>>> >>>>>>>> Source changes look fine to me too. >>>>>>> Thanks Michael, >>>>>>> >>>>>>> In which case, I believe the check that a cookie the name >>>>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>>>> >>>>>> Right. I didn't realise the test was able to handle the IAE. I see >>>>>> now that it does and it should >>>>>> be possible to put the same test back. >>>>>> >>>>>> Michael >>>>>>> -Chris. >>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>>>> >>>>>>>>>> - Kurchi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>>>> All: >>>>>>>>>>> My original email was mangled by my email program >>>>>>>>>>> (stbeehive/zimbra) >>>>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>>>> >>>>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Basically there are two issues: >>>>>>>>>>> >>>>>>>>>>> 1.) the existing cookie constructor was allowing cookie >>>>>>>>>>> names to >>>>>>>>>>> have >>>>>>>>>>> a dollar sign as their leading character, >>>>>>>>>>> which is "illegal". The constructor code was modified to >>>>>>>>>>> disallow >>>>>>>>>>> these illegal names. >>>>>>>>>>> >>>>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>>>> ) >>>>>>>>>>> prohibited >>>>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>>>> use by >>>>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> John Zavgren >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>>>> Eastern >>>>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>>>> >>>>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>>>> constructor: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>> Basically there are two issues: 1.) the existing cookie >>>>>>>>>>> constructor >>>>>>>>>>> was allowing cookie names to have a dollar sign as their >>>>>>>>>>> leading >>>>>>>>>>> character, which is "illegal". The constructor code was >>>>>>>>>>> modified to >>>>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>>>> specdiff: >>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>>>> reserved >>>>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>>>> necessary. >>>>>>>>>>> Thanks! John Zavgren >>>>>>>>>> -- >>>>>>>>>> -Kurchi >>>>>>>>>> >>>>> > > -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From chris.hegarty at oracle.com Fri May 31 07:39:51 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 May 2013 15:39:51 +0100 Subject: RFR 8011719: Properties.loadFromXML fails with a chunked HTTP connection Message-ID: <51A8B637.20700@oracle.com> HttpURLConnection returns various input streams, depending on the response from the server. fixed content-length, chunked, error. Most, if not all, are wrapped in an implementation specific HttpInputStream, to correctly handle caching of responses. The issue reported by 8011719 is that the close method of HttpInputStream throws an IOException if called multiple times. The solution is to add a private boolean to HttpInputStream to indicate whether the stream has been closed, or not. This is very typical of these type of wrapper streams. Also worth noting, the stream cannot be marked closed until near the end of its close() method, since it needs to invoke read itself. Should not be a problem as these streams are not thread-safe. http://cr.openjdk.java.net/~chegar/8011719/webrev.00/webrev/ A test has been added to ensure correct behavior of the various combinations of returned input streams. -Chris. From chris.hegarty at oracle.com Fri May 31 07:42:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 May 2013 15:42:15 +0100 Subject: RFR JDK7188517 In-Reply-To: <51A89364.30903@oracle.com> References: <51937759.5070507@oracle.com> <51A89364.30903@oracle.com> Message-ID: <51A8B6C7.9090909@oracle.com> Looks fine to me John. -Chris. On 05/31/2013 01:11 PM, John Zavgren wrote: > All: > > I'd like to give everyone another chance to weigh in on this change: > http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ > so that I can wrap up this fix ASAP. > > (It makes HTTP cookies that begin with a dollar sign "illegal".) > > Thanks! > John > > On 05/15/2013 07:54 AM, John Zavgren wrote: >> Greetings: >> >> Can I get a show of hands on this RFR >> (http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)? >> It's CCC request has been accepted and I'd like to wrap it up ASAP. >> >> Thanks! >> John Zavgren >> >> On 05/09/2013 02:22 PM, John Zavgren wrote: >>> Greetings: >>> I made a mistake in my last RFR posting... the URL for the latest >>> modifications is: >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ >>> instead of: >>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>> >>> The most recent change is to reinstate the original test that tested >>> for cookie names that lead with a dollar sign. >>> >>> I'm sorry about the confusion. >>> >>> Thanks! >>> John >>> >>> >>> On 05/09/2013 03:42 PM, John Zavgren wrote: >>>> Chris, et alia: >>>> I put the reinstated the old test. >>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>> >>>> John >>>> >>>> ----- Original Message ----- >>>> From: chris.hegarty at oracle.com >>>> To: john.zavgren at oracle.com >>>> Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net >>>> Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern >>>> Subject: Re: RFR JDK7188517 >>>> >>>> John, >>>> >>>> I think you can simply reinstate >>>> >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java >>>> >>>> >>>> -Chris. >>>> >>>> On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >>>>> I would have thrown an exception if the IllegalArgumentException is >>>>> not >>>>> obtained, otherwise the test looses its >>>>> purpose, and will pass silently if someone mistakenly removes the $ >>>>> check in our code. >>>>> >>>>> - Kurchi >>>>> >>>>> On 5/8/2013 12:10 PM, John Zavgren wrote: >>>>>> Greetings: >>>>>> >>>>>> I added a test for the leading dollar sign character in cookie names: >>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>>>> >>>>>> Thanks! >>>>>> John >>>>>> >>>>>> >>>>>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>>>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>>>>> This looks okay to me. >>>>>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>>>>> for '$' >>>>>>>>>> >>>>>>>>>> In fact, Michael actually removed such a test [1] during another >>>>>>>>>> change. We should get positive agreement from Michael before >>>>>>>>>> pushing >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>>>>> with '$'. >>>>>>>>> I agree we should add a negative test now for a similar cookie. >>>>>>>>> >>>>>>>>> Source changes look fine to me too. >>>>>>>> Thanks Michael, >>>>>>>> >>>>>>>> In which case, I believe the check that a cookie the name >>>>>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>>>>> >>>>>>> Right. I didn't realise the test was able to handle the IAE. I see >>>>>>> now that it does and it should >>>>>>> be possible to put the same test back. >>>>>>> >>>>>>> Michael >>>>>>>> -Chris. >>>>>>>> >>>>>>>>> Michael >>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>>>>> >>>>>>>>>>> - Kurchi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>>>>> All: >>>>>>>>>>>> My original email was mangled by my email program >>>>>>>>>>>> (stbeehive/zimbra) >>>>>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>>>>> >>>>>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> --------------- >>>>>>>>>>>> >>>>>>>>>>>> Please consider the following change to the cookie constructor: >>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Basically there are two issues: >>>>>>>>>>>> >>>>>>>>>>>> 1.) the existing cookie constructor was allowing cookie >>>>>>>>>>>> names to >>>>>>>>>>>> have >>>>>>>>>>>> a dollar sign as their leading character, >>>>>>>>>>>> which is "illegal". The constructor code was modified to >>>>>>>>>>>> disallow >>>>>>>>>>>> these illegal names. >>>>>>>>>>>> >>>>>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>>>>> ) >>>>>>>>>>>> prohibited >>>>>>>>>>>> the use of cookie names that are one of the tokens reserved for >>>>>>>>>>>> use by >>>>>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> John Zavgren >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>>>>> Eastern >>>>>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>>>>> >>>>>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>>>>> constructor: >>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>>> Basically there are two issues: 1.) the existing cookie >>>>>>>>>>>> constructor >>>>>>>>>>>> was allowing cookie names to have a dollar sign as their >>>>>>>>>>>> leading >>>>>>>>>>>> character, which is "illegal". The constructor code was >>>>>>>>>>>> modified to >>>>>>>>>>>> disallow these illegal names. 2.) the API document (notice the >>>>>>>>>>>> specdiff: >>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>>>>> reserved >>>>>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>>>>> necessary. >>>>>>>>>>>> Thanks! John Zavgren >>>>>>>>>>> -- >>>>>>>>>>> -Kurchi >>>>>>>>>>> >>>>>> >> >> > > From john.zavgren at oracle.com Fri May 31 10:06:42 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Fri, 31 May 2013 13:06:42 -0400 Subject: RFR JDK-8008972 In-Reply-To: <5191498F.2070508@oracle.com> References: <5134E539.80007@oracle.com> <5191498F.2070508@oracle.com> Message-ID: <51A8D8A2.1060707@oracle.com> All: I have a revised webrev image that's ready for review: http://cr.openjdk.java.net/~jzavgren/8008972/webrev.04/ Thanks John On 05/13/2013 04:14 PM, John Zavgren wrote: > Greetings: > I posted a new webrev image: > http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/ > that fixes a memory leak. > > The leak in > src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c is > caused by an unfortunate interplay between two actions: > 1.) dynamically allocating a larger packet buffer when the length of > an incoming packet exceeds MAX_BUFFER_LEN. > 2.) truncating a received packet so that it's length equals > MAX_PACKET_LEN, when it exceeds this value. > > Action number two was embedded inside the code that implemented action > number one, and action number two can change the length of the packet. > Unfortunately, the original packet length was used as an indication > that the packet buffer needed to be freed, and because the length of > the packet may have changed after the allocation, the free() statement > wasn't being executed in some cases. > > I fixed the problem by moving action number two so that it always > precedes action number 1. This ensures that the packet length retains > the same value across the malloc() and the free() operations, and > therefore packet length can now be used as a reliable indication that > dynamically allocated memory must be freed. > > I also noticed that there is a procedure in > src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c that > also dynamically allocates memory in a similar way, but it doesn't > implement action number two. I added it. > > I also took advantage of this opportunity to fix spelling errors in > other files in the same directory as the two previously mentioned files. > > > On 03/04/2013 01:17 PM, Chris Hegarty wrote: >> On 03/04/2013 04:28 PM, John Zavgren wrote: >>> Greetings: >>> >>> I've posted a webrev image of a memory leak fix: >>> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/ >> >> Sorry John, I don't see what the problem is that you are trying to >> solve? Can you please explain why the original code has problems? >> >> Also, note that there are other places in the same function that do >> the very same check. >> >> -Chris. >> >>> >>> Thanks! >>> John >>> > > -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From chris.hegarty at oracle.com Fri May 31 10:43:01 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 May 2013 18:43:01 +0100 Subject: RFR JDK-8008972 In-Reply-To: <51A8D8A2.1060707@oracle.com> References: <5134E539.80007@oracle.com> <5191498F.2070508@oracle.com> <51A8D8A2.1060707@oracle.com> Message-ID: <3C4B0E48-1504-4017-95F7-F7EE9D956E0F@oracle.com> This looks fine to me John. Thanks for persisting with me to get thus done. -Chris On 31 May 2013, at 18:06, John Zavgren wrote: > All: > I have a revised webrev image that's ready for review: > http://cr.openjdk.java.net/~jzavgren/8008972/webrev.04/ > > Thanks > John > > On 05/13/2013 04:14 PM, John Zavgren wrote: >> Greetings: >> I posted a new webrev image: >> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/ >> that fixes a memory leak. >> >> The leak in src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c is caused by an unfortunate interplay between two actions: >> 1.) dynamically allocating a larger packet buffer when the length of an incoming packet exceeds MAX_BUFFER_LEN. >> 2.) truncating a received packet so that it's length equals MAX_PACKET_LEN, when it exceeds this value. >> >> Action number two was embedded inside the code that implemented action number one, and action number two can change the length of the packet. Unfortunately, the original packet length was used as an indication that the packet buffer needed to be freed, and because the length of the packet may have changed after the allocation, the free() statement wasn't being executed in some cases. >> >> I fixed the problem by moving action number two so that it always precedes action number 1. This ensures that the packet length retains the same value across the malloc() and the free() operations, and therefore packet length can now be used as a reliable indication that dynamically allocated memory must be freed. >> >> I also noticed that there is a procedure in src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c that also dynamically allocates memory in a similar way, but it doesn't implement action number two. I added it. >> >> I also took advantage of this opportunity to fix spelling errors in other files in the same directory as the two previously mentioned files. >> >> >> On 03/04/2013 01:17 PM, Chris Hegarty wrote: >>> On 03/04/2013 04:28 PM, John Zavgren wrote: >>>> Greetings: >>>> >>>> I've posted a webrev image of a memory leak fix: >>>> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/ >>> >>> Sorry John, I don't see what the problem is that you are trying to solve? Can you please explain why the original code has problems? >>> >>> Also, note that there are other places in the same function that do the very same check. >>> >>> -Chris. >>> >>>> >>>> Thanks! >>>> John > > -- > John Zavgren > john.zavgren at oracle.com > 603-821-0904 > US-Burlington-MA > From kurchi.subhra.hazra at oracle.com Fri May 31 11:15:04 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 31 May 2013 11:15:04 -0700 (PDT) Subject: RFR JDK7188517 In-Reply-To: <51A8B6C7.9090909@oracle.com> References: <51937759.5070507@oracle.com> <51A89364.30903@oracle.com> <51A8B6C7.9090909@oracle.com> Message-ID: <51A8E8A8.1080308@oracle.com> Looks good to me too! - Kurchi On 5/31/2013 7:42 AM, Chris Hegarty wrote: > Looks fine to me John. > > -Chris. > > On 05/31/2013 01:11 PM, John Zavgren wrote: >> All: >> >> I'd like to give everyone another chance to weigh in on this change: >> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ >> so that I can wrap up this fix ASAP. >> >> (It makes HTTP cookies that begin with a dollar sign "illegal".) >> >> Thanks! >> John >> >> On 05/15/2013 07:54 AM, John Zavgren wrote: >>> Greetings: >>> >>> Can I get a show of hands on this RFR >>> (http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)? >>> It's CCC request has been accepted and I'd like to wrap it up ASAP. >>> >>> Thanks! >>> John Zavgren >>> >>> On 05/09/2013 02:22 PM, John Zavgren wrote: >>>> Greetings: >>>> I made a mistake in my last RFR posting... the URL for the latest >>>> modifications is: >>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/ >>>> instead of: >>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>> >>>> The most recent change is to reinstate the original test that tested >>>> for cookie names that lead with a dollar sign. >>>> >>>> I'm sorry about the confusion. >>>> >>>> Thanks! >>>> John >>>> >>>> >>>> On 05/09/2013 03:42 PM, John Zavgren wrote: >>>>> Chris, et alia: >>>>> I put the reinstated the old test. >>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>>> >>>>> John >>>>> >>>>> ----- Original Message ----- >>>>> From: chris.hegarty at oracle.com >>>>> To: john.zavgren at oracle.com >>>>> Cc: kurchi.subhra.hazra at oracle.com, net-dev at openjdk.java.net >>>>> Sent: Thursday, May 9, 2013 4:39:29 AM GMT -05:00 US/Canada Eastern >>>>> Subject: Re: RFR JDK7188517 >>>>> >>>>> John, >>>>> >>>>> I think you can simply reinstate >>>>> >>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java >>>>> >>>>> >>>>> >>>>> -Chris. >>>>> >>>>> On 05/08/2013 09:02 PM, Kurchi Hazra wrote: >>>>>> I would have thrown an exception if the IllegalArgumentException is >>>>>> not >>>>>> obtained, otherwise the test looses its >>>>>> purpose, and will pass silently if someone mistakenly removes the $ >>>>>> check in our code. >>>>>> >>>>>> - Kurchi >>>>>> >>>>>> On 5/8/2013 12:10 PM, John Zavgren wrote: >>>>>>> Greetings: >>>>>>> >>>>>>> I added a test for the leading dollar sign character in cookie >>>>>>> names: >>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/ >>>>>>> >>>>>>> Thanks! >>>>>>> John >>>>>>> >>>>>>> >>>>>>> On 05/08/2013 08:33 AM, Michael McMahon wrote: >>>>>>>> On 08/05/13 09:50, Chris Hegarty wrote: >>>>>>>>> On 08/05/2013 10:35, Michael McMahon wrote: >>>>>>>>>> On 07/05/13 14:43, Chris Hegarty wrote: >>>>>>>>>>> On 05/06/2013 10:28 PM, Kurchi Hazra wrote: >>>>>>>>>>>> This looks okay to me. >>>>>>>>>>> Source changes look fine to me too. Probably best to add a test >>>>>>>>>>> for '$' >>>>>>>>>>> >>>>>>>>>>> In fact, Michael actually removed such a test [1] during >>>>>>>>>>> another >>>>>>>>>>> change. We should get positive agreement from Michael before >>>>>>>>>>> pushing >>>>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>> Yes, that was a positive test for for a cookie whose name began >>>>>>>>>> with '$'. >>>>>>>>>> I agree we should add a negative test now for a similar cookie. >>>>>>>>>> >>>>>>>>>> Source changes look fine to me too. >>>>>>>>> Thanks Michael, >>>>>>>>> >>>>>>>>> In which case, I believe the check that a cookie the name >>>>>>>>> '$Customer' throws IAE can be re-instated in TestHttpCookie.java >>>>>>>>> >>>>>>>> Right. I didn't realise the test was able to handle the IAE. I see >>>>>>>> now that it does and it should >>>>>>>> be possible to put the same test back. >>>>>>>> >>>>>>>> Michael >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7bd32bfc0539 >>>>>>>>>>> >>>>>>>>>>>> - Kurchi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 5/2/2013 10:09 AM, John Zavgren wrote: >>>>>>>>>>>>> All: >>>>>>>>>>>>> My original email was mangled by my email program >>>>>>>>>>>>> (stbeehive/zimbra) >>>>>>>>>>>>> ... so I'm sending a second correctly formatted copy. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm sorry for the inconvenience. >>>>>>>>>>>>> >>>>>>>>>>>>> John >>>>>>>>>>>>> --------------- >>>>>>>>>>>>> >>>>>>>>>>>>> Please consider the following change to the cookie >>>>>>>>>>>>> constructor: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Basically there are two issues: >>>>>>>>>>>>> >>>>>>>>>>>>> 1.) the existing cookie constructor was allowing cookie >>>>>>>>>>>>> names to >>>>>>>>>>>>> have >>>>>>>>>>>>> a dollar sign as their leading character, >>>>>>>>>>>>> which is "illegal". The constructor code was modified to >>>>>>>>>>>>> disallow >>>>>>>>>>>>> these illegal names. >>>>>>>>>>>>> >>>>>>>>>>>>> 2.) the API document (notice the specdiff: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ >>>>>>>>>>>>> ) >>>>>>>>>>>>> prohibited >>>>>>>>>>>>> the use of cookie names that are one of the tokens >>>>>>>>>>>>> reserved for >>>>>>>>>>>>> use by >>>>>>>>>>>>> the cookie protocol, and this restriction is not necessary. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> John Zavgren >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: john.zavgren at oracle.com >>>>>>>>>>>>> To: net-dev at openjdk.java.net >>>>>>>>>>>>> Sent: Thursday, May 2, 2013 10:36:38 AM GMT -05:00 US/Canada >>>>>>>>>>>>> Eastern >>>>>>>>>>>>> Subject: RFR JDK7188517 >>>>>>>>>>>>> >>>>>>>>>>>>> Greetings: Please consider the following change to the cookie >>>>>>>>>>>>> constructor: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.01/ >>>>>>>>>>>>> Basically there are two issues: 1.) the existing cookie >>>>>>>>>>>>> constructor >>>>>>>>>>>>> was allowing cookie names to have a dollar sign as their >>>>>>>>>>>>> leading >>>>>>>>>>>>> character, which is "illegal". The constructor code was >>>>>>>>>>>>> modified to >>>>>>>>>>>>> disallow these illegal names. 2.) the API document (notice >>>>>>>>>>>>> the >>>>>>>>>>>>> specdiff: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/) >>>>>>>>>>>>> prohibited the use of cookie names that are one of the tokens >>>>>>>>>>>>> reserved >>>>>>>>>>>>> for use by the cookie protocol, and this restriction is not >>>>>>>>>>>>> necessary. >>>>>>>>>>>>> Thanks! John Zavgren >>>>>>>>>>>> -- >>>>>>>>>>>> -Kurchi >>>>>>>>>>>> >>>>>>> >>> >>> >> >> -- -Kurchi From Alan.Bateman at oracle.com Fri May 31 11:18:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 19:18:28 +0100 Subject: RFR JDK-8008972 In-Reply-To: <51A8D8A2.1060707@oracle.com> References: <5134E539.80007@oracle.com> <5191498F.2070508@oracle.com> <51A8D8A2.1060707@oracle.com> Message-ID: <51A8E974.8060301@oracle.com> On 31/05/2013 18:06, John Zavgren wrote: > All: > I have a revised webrev image that's ready for review: > http://cr.openjdk.java.net/~jzavgren/8008972/webrev.04/ > There's something not quite right here, it looks to me that packetBufferLen will always be truncated to MAX_PACKET_LEN to therefore the malloc path will never be used. Do I have this right? -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130531/3aa6e151/attachment.html From naoto.sato at oracle.com Fri May 31 11:21:40 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 31 May 2013 18:21:40 +0000 Subject: hg: jdk8/tl/jdk: 7006052: awt_InputMethod.c cleanup is needed Message-ID: <20130531182153.1C22F48E95@hg.openjdk.java.net> Changeset: 933b1338b99c Author: naoto Date: 2013-05-31 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/933b1338b99c 7006052: awt_InputMethod.c cleanup is needed Reviewed-by: anthony ! src/solaris/native/sun/awt/awt_InputMethod.c From Alan.Bateman at oracle.com Fri May 31 12:05:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 20:05:16 +0100 Subject: RFR JDK-8008972 In-Reply-To: <51A8F1F7.6060806@oracle.com> References: <5134E539.80007@oracle.com> <5191498F.2070508@oracle.com> <51A8D8A2.1060707@oracle.com> <51A8E974.8060301@oracle.com> <51A8F1F7.6060806@oracle.com> Message-ID: <51A8F46C.6050905@oracle.com> On 31/05/2013 19:54, John Zavgren wrote: > Alan: > > There are two parameters involved here that have similar names: > MAX_PACKET_LEN and MAX_BUFFER_LEN. > > If the code receives a "jumbo" packet (larger than MAX_PACKET_LEN) > then the length is truncated to MAX_PACKET_LEN before the next step. > In that "if block" we look to see if the (possibly) truncated packet > exceeds the size of the packet buffer, if so, then the code allocates > a whole new larger buffer. > > Does this sound OK? > > John MAX_PACKET_LEN and MAX_BUFFER_LEN looked the same, sorry for the noise, the change is fine. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130531/1fd8cd3d/attachment.html From dmitry.samersoff at oracle.com Fri May 31 12:36:28 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 31 May 2013 23:36:28 +0400 Subject: RFR JDK-8008972 In-Reply-To: <51A8D8A2.1060707@oracle.com> References: <5134E539.80007@oracle.com> <5191498F.2070508@oracle.com> <51A8D8A2.1060707@oracle.com> Message-ID: <51A8FBBC.8030109@oracle.com> John, Looks good for me. -Dmitry On 2013-05-31 21:06, John Zavgren wrote: > All: > I have a revised webrev image that's ready for review: > http://cr.openjdk.java.net/~jzavgren/8008972/webrev.04/ > > Thanks > John > > On 05/13/2013 04:14 PM, John Zavgren wrote: >> Greetings: >> I posted a new webrev image: >> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/ >> that fixes a memory leak. >> >> The leak in >> src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c is >> caused by an unfortunate interplay between two actions: >> 1.) dynamically allocating a larger packet buffer when the length of >> an incoming packet exceeds MAX_BUFFER_LEN. >> 2.) truncating a received packet so that it's length equals >> MAX_PACKET_LEN, when it exceeds this value. >> >> Action number two was embedded inside the code that implemented action >> number one, and action number two can change the length of the packet. >> Unfortunately, the original packet length was used as an indication >> that the packet buffer needed to be freed, and because the length of >> the packet may have changed after the allocation, the free() statement >> wasn't being executed in some cases. >> >> I fixed the problem by moving action number two so that it always >> precedes action number 1. This ensures that the packet length retains >> the same value across the malloc() and the free() operations, and >> therefore packet length can now be used as a reliable indication that >> dynamically allocated memory must be freed. >> >> I also noticed that there is a procedure in >> src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c that >> also dynamically allocates memory in a similar way, but it doesn't >> implement action number two. I added it. >> >> I also took advantage of this opportunity to fix spelling errors in >> other files in the same directory as the two previously mentioned files. >> >> >> On 03/04/2013 01:17 PM, Chris Hegarty wrote: >>> On 03/04/2013 04:28 PM, John Zavgren wrote: >>>> Greetings: >>>> >>>> I've posted a webrev image of a memory leak fix: >>>> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/ >>> >>> Sorry John, I don't see what the problem is that you are trying to >>> solve? Can you please explain why the original code has problems? >>> >>> Also, note that there are other places in the same function that do >>> the very same check. >>> >>> -Chris. >>> >>>> >>>> Thanks! >>>> John >>>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dan.xu at oracle.com Fri May 31 13:35:00 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 31 May 2013 20:35:00 +0000 Subject: hg: jdk8/tl/jdk: 8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java Message-ID: <20130531203521.796F148E9A@hg.openjdk.java.net> Changeset: f522bbdf2859 Author: dxu Date: 2013-05-31 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f522bbdf2859 8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java Reviewed-by: alanb ! test/java/io/pathNames/General.java ! test/java/io/pathNames/GeneralWin32.java From kurchi.subhra.hazra at oracle.com Fri May 31 13:59:32 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 31 May 2013 20:59:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130531205955.2370E48E9D@hg.openjdk.java.net> Changeset: 11cdcf87ad5d Author: jzavgren Date: 2013-05-31 15:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cdcf87ad5d 8008972: Memory leak: Java_java_net_TwoStacksPlainDatagramSocketImpl_receive0 [parfait] Summary: Modified the code so that "jumbo frames" are truncated before buffer allocation is considered. This makes the buffer length a reliable indication that a buffer has been allocated, and it can then be used during clean up. Reviewed-by: chegar, khazra, alanb Contributed-by: john.zavgren at oracle.com ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: f6e6c27c19f3 Author: jzavgren Date: 2013-05-31 15:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6e6c27c19f3 7188517: Check on '$' character is missing in the HttpCookie class constructor Summary: Modified the constructor code so that the cookie names are examined for leading dollar signs and if they do, an illegal argument exception is thrown. Reviewed-by: chegar, khazra, michaelm Contributed-by: john.zavgren at oracle.com ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java From mike.duigou at oracle.com Fri May 31 17:32:07 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 01 Jun 2013 00:32:07 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130601003239.7507A48EA2@hg.openjdk.java.net> Changeset: fc0b3e86fdcf Author: mduigou Date: 2013-05-31 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0b3e86fdcf 8015686: {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException Reviewed-by: dholmes, alanb, psandoz ! src/share/classes/java/util/IntSummaryStatistics.java ! src/share/classes/java/util/LongSummaryStatistics.java Changeset: 198de8103df2 Author: mduigou Date: 2013-05-31 17:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/198de8103df2 Merge