Re: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing

[Chris Hegarty]

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.txtTue May 28 15:22:30 2013 +0200
+++ b/test/ProblemList.txtThu 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

hg: jdk8/tl/jdk: 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown

[paul . sandoz]

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

hg: jdk8/tl/jdk: 7107883: getNetworkPrefixLength() does not return correct prefix length

[chris . hegarty]

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

hg: jdk8/tl/langtools: 7179353: try-with-resources fails to compile with generic exception parameters

[vicente . romero]

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

hg: jdk8/tl/jdk: 8014854: (bf) CharBuffer.chars too slow with default implementation

[alan . bateman]

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

Re: RFR: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing

[Alan Bateman]

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.

Re: RFR JDK7188517

[John Zavgren]

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.hega...@oracle.com
To: john.zavg...@oracle.com
Cc: kurchi.subhra.ha...@oracle.com, net-dev@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.zavg...@oracle.com
To: net-dev@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.zavg...@oracle.com
603-821-0904
US-Burlington-MA

RFR 8011719: Properties.loadFromXML fails with a chunked HTTP connection

[Chris Hegarty]

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.

Re: RFR JDK7188517

[Chris Hegarty]

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.hega...@oracle.com
To: john.zavg...@oracle.com
Cc: kurchi.subhra.ha...@oracle.com, net-dev@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.zavg...@oracle.com
To: net-dev@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

Re: RFR JDK-8008972

[John Zavgren]

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.zavg...@oracle.com
603-821-0904
US-Burlington-MA

Re: RFR JDK-8008972

[Chris Hegarty]

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.zavg...@oracle.com
> 603-821-0904
> US-Burlington-MA
> 

Re: RFR JDK7188517

[Kurchi Hazra]

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.hega...@oracle.com
To: john.zavg...@oracle.com
Cc: kurchi.subhra.ha...@oracle.com, net-dev@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.zavg...@oracle.com
To: net-dev@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

Re: RFR JDK-8008972

[Alan Bateman]

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.

Re: RFR JDK-8008972

[Alan Bateman]

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

Re: RFR JDK-8008972

[Dmitry Samersoff]

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.

hg: jdk8/tl/jdk: 8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java

[dan . xu]

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

hg: jdk8/tl/jdk: 2 new changesets

[kurchi . subhra . hazra]

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.zavg...@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.zavg...@oracle.com

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java

hg: jdk8/tl/jdk: 2 new changesets

[mike . duigou]

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