RFR JDK8017079

2013-06-27 Thread John Zavgren
Greetings: Please consider the following socket constructor changes: http://cr.openjdk.java.net/~jzavgren/8017079/webrev.01/ <http://cr.openjdk.java.net/%7Ejzavgren/8017079/webrev.01/> Thanks! John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA

Re: RFR JDK8015799

2013-06-27 Thread John Zavgren
. - Kurchi [1] http://cr.openjdk.java.net/~arieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html <http://cr.openjdk.java.net/%7Earieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html> On 6/26/

RFR JDK8015799

2013-06-26 Thread John Zavgren
s John -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA

Re: RFR JDK8015799

2013-06-20 Thread John Zavgren
} } class TestCookieHandler extends CookieHandler { @Override public Map> get(URI uri, MapList> requestHeaders) { return new HashMap>(); } @Override public void put(URI uri, Map> responseHeaders) { } } - -Chris. On 06/19/2013 04:27 PM, John Zavgren wro

RFR JDK8014377

2013-06-19 Thread John Zavgren
; receptions. http://cr.openjdk.java.net/~jzavgren/8014377/webrev.03/ <http://cr.openjdk.java.net/%7Ejzavgren/8014377/webrev.03/> Thanks! -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA

RFR JDK8014499

2013-06-19 Thread John Zavgren
/cr.openjdk.java.net/~jzavgren/8014499/webrev.04/ <http://cr.openjdk.java.net/%7Ejzavgren/8014499/webrev.04/> Thanks! -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA

RFR JDK8015799

2013-06-19 Thread John Zavgren
/8015799/webrev.01/> -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA

PlainDatagramSocketImpl questions

2013-06-13 Thread John Zavgren
"SocketException", "Unable to set SO_BROADCAST"); return; <<< setsockopt() failed, we threw an exception. We didn't close the socket. } -- John Zavgren john.zavg...@oracle.com 603-821-0904 US-Burlington-MA

Re: RFR JDK-8008972

2013-05-31 Thread 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

Re: RFR JDK7188517

2013-05-31 Thread 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, Joh

Re: RFR JDK7188517

2013-05-15 Thread John Zavgren
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 R

Re: RFR JDK-8008972

2013-05-13 Thread John Zavgren
rrors 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/

Re: RFR JDK7188517

2013-05-09 Thread John Zavgren
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 > > - Ori

Re: RFR JDK7188517

2013-05-09 Thread John Zavgren
ion 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: >> >>

Re: RFR JDK7188517

2013-05-08 Thread John Zavgren
k8/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 fol

Re: suggestions for improvement in java.net APIs

2013-05-06 Thread John Zavgren
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 fe

Re: RFR JDK7188517

2013-05-02 Thread John Zavgren
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.za

RFR JDK7188517

2013-05-02 Thread John Zavgren
riction is not necessary. Thanks! John Zavgren

Re: RFR-JDK8012108

2013-04-25 Thread John Zavgren
Greetings: I've cleaned up some formatting nits and a leak that I created in my realloc() "repairs" and created a revised webrev image: http://cr.openjdk.java.net/~jzavgren/8012108/webrev.04 John On 04/24/2013 09:10 PM, John Zavgren wrote: All: I expanded the scope of th

Re: RFR-JDK8012108

2013-04-24 Thread John Zavgren
redundant. 438 - we will crash here if start is null Maybe it is good to have an additional check for start != null, but from what I see, start will not be null if *netaddrPP is not null. -Dmitry On 2013-04-20 01:33, John Zavgren wrote: Greetings: I fixed the bad realloc pattern. Please

Re: RFR-JDK8012108

2013-04-24 Thread John Zavgren
rote: On Apr 20, 2013, at 3:16 AM, Dmitry Samersoff wrote: John, 102, 145 else is redundant. 438 - we will crash here if start is null Maybe it is good to have an additional check for start != null, but from what I see, start will not be null if *netaddrPP is not null. -Dmitry O

Re: RFR-JDK8012108

2013-04-19 Thread John Zavgren
gt; e.g. > > 93 adapterInfo = (IP_ADAPTER_ADDRESSES *) realloc (adapterInfo, len); > > -Dmitry > > On 2013-04-19 00:56, John Zavgren wrote: >> Greetings: >> >> I fixed a case in the windows native code where calloc() was being used >> without checking it's retu

RFR-JDK8012108

2013-04-18 Thread John Zavgren
Greetings: I fixed a case in the windows native code where calloc() was being used without checking it's returned value. http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/ Thanks! John Zavgren

RFR-8012108

2013-04-17 Thread John Zavgren
Greetings: Please review the following webrev image. I fixed a memory leak that can occur when calloc() fails. http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/ Thanks! John Zavgren john.zavg...@oracle.com

RFR-JDK8010505

2013-04-16 Thread John Zavgren
://www.ietf.org/rfc/rfc2617.txt) section 3.2.2 and follow its references back to section 3.2.1 http://cr.openjdk.java.net/~jzavgren/8010505/webrev.01/ Thanks! John Zavgren

Re: RFR JDK-8008804

2013-03-04 Thread John Zavgren
PM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8008804 On 04/03/2013 19:37, John Zavgren wrote: > Thanks for catching that Dmitry. I just posted a new webrev image for a > change that uses the correct procedure: > http://cr.openjdk.java.net/~jzavgren/8008804/webrev.02/ > > J

Re: RFR JDK-8008804

2013-03-04 Thread John Zavgren
Sent: Monday, March 4, 2013 12:59:16 PM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8008804 John, closesocket call should be here. -Dmitry On 2013-03-04 20:12, John Zavgren wrote: > Greetings: > > I posted a webrev image for a modification that eliminates a file descriptor > lea

Re: RFR JDK-8008972

2013-03-04 Thread John Zavgren
hn.zavg...@oracle.com Sent: Monday, March 4, 2013 1:17:31 PM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8008972 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/

RFR JDK-8008972

2013-03-04 Thread John Zavgren
Greetings: I've posted a webrev image of a memory leak fix: http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/ Thanks! John

RFR JDK-8008804

2013-03-04 Thread John Zavgren
Greetings: I posted a webrev image for a modification that eliminates a file descriptor leak. http://cr.openjdk.java.net/~jzavgren/8008804/webrev.01/ Thanks! John

Re: RFR: JDK-8007606

2013-02-08 Thread John Zavgren
Greetings: I fixed numerous errors that were identified by Mr. Davidovich. I've posed a new webrev image at: http://cr.openjdk.java.net/~jzavgren/8007606/webrev.02/ <http://cr.openjdk.java.net/%7Ejzavgren/8007606/webrev.02/> Thanks! John Zavgren On 02/05/2013 07:33 PM, Vitaly

RFR: JDK-8007606

2013-02-05 Thread John Zavgren
Greetings: I modified the use of malloc() and realloc() so that return values are checked and potential memory leaks and data corruption problems are prevented. http://cr.openjdk.java.net/~jzavgren/8007606/webrev.01/ Thanks! John Zavgren

Re: RFR JDK-4880778

2013-02-04 Thread John Zavgren
fields. --- > * Only classes derived from URLStreamHandler are able to use this > * method to set the values of the URL fields. It is still not great, but I think the best we can do with an old API. -Chris. On 04/02/2013 14:00, John Zavgren wrote: > I posted a new webrev image: > htt

Re: RFR JDK-4880778

2013-02-04 Thread John Zavgren
I posted a new webrev image: http://cr.openjdk.java.net/~jzavgren/4880778/webrev.02/ I made two changes: 1.) modified the indentation that's used for the argument list of the URL class set() methods. 2.) changed the documentation for the set method in the URLStreamHandler class. - Original

RFR JDK-4880778

2013-02-02 Thread John Zavgren
Greetings: Please consider the following modification of our classes for handling URLs. http://cr.openjdk.java.net/~jzavgren/4880778/webrev.01/ background See http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html. The URL class is declared final yet has two protected methods: prot

Re: RFR JDK-8005120

2013-01-17 Thread John Zavgren
.openjdk.java.net/~jzavgren/8005120/webrev.07/ <http://cr.openjdk.java.net/%7Ejzavgren/8005120/webrev.07/> Thank you! John Zavgren john.zavg...@oracle.com On 12/20/2012 05:47 PM, John Zavgren wrote: Greetings: I modified my changes so that windows knows the definition of the POSIX data

Re: RFR JDK-8005120

2013-01-08 Thread John Zavgren
On 12/28/2012 10:49 AM, John Zavgren wrote: Please consider the following webrev for JDK-8005120. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.06/ (I apologize for overlooking an error in the windows code that I created in my previous release. ) Thanks! John Zavgren

Re: RFR JDK-8005120

2012-12-28 Thread John Zavgren
Greetings: I modified windows source code files so they pass size_t for buffer sizes and socklen_t for address structures. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.03/ Please let me know what you think. Thanks! On 12/26/2012 02:56 PM, John Zavgren wrote

Re: RFR JDK-8005120

2012-12-26 Thread John Zavgren
Greetings: I modified the windows code so that it uses socklen_t to specify the lengths of data structures, parameter lengths, etc. instead of ints (which can be negative.) http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.02/ Thanks! John Zavgren On 12/20/2012 05:47 PM

Re: RFR JDK-8005120

2012-12-20 Thread John Zavgren
1/ Thanks! John Zavgren On 20/12/2012 13:49, John Zavgren wrote: > Greetings: > > I agree that the "correct" way to fix this problem is to use POSIX data > types, e.g., socklen_t. However, when I switch to the doctrinaire data type, > the build fails on windows machin

Re: RFR JDK-8005120

2012-12-20 Thread John Zavgren
r-sign] >> ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected >> 'uint32_t *' but argument is of type 'int *' >> >> Do you see these in your build? >> >> -Chris. >> >> On 12/19/2012 03:42 PM, Alan Bateman wrote: >

Re: RFR JDK-8005120

2012-12-19 Thread John Zavgren
GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 John, On 2012-12-19 22:25, John Zavgren wrote: > Yes... I did consider that, but I didn't see any POSIX data types near the > code I was changing, so I decided to use a "brute force" data type instead. connect, recvfr

Re: RFR JDK-8005120

2012-12-19 Thread John Zavgren
com Cc: net-dev@openjdk.java.net Sent: Wednesday, December 19, 2012 1:06:52 PM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 John, Did you consider using socklen_t instead of uint32_t and unsigned int (for namelen etc) ? -Dmitry On 2012-12-19 19:36, John Zavgren wrote: > Greetings: >

RFR JDK-8005120

2012-12-19 Thread John Zavgren
correctly. They were declared as integers, but they must be "unsigned" integers because they are used to define buffer lengths. Were one to supply a negative value as an argument, it would be cast into an unsigned "Martian" value and there'd be (hopefully) a system call err

Re: RFR8003991 (take two)

2012-11-27 Thread John Zavgren
hat.) > > http://cr.openjdk.java.net/~mullan/webrevs/8003991/webrev.00/ > > Thanks! > John Zavgren > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer

RFR8003991 (take two)

2012-11-26 Thread John Zavgren
/webrev.00/ Thanks! John Zavgren

Re: RFR JDK-80003991

2012-11-26 Thread John Zavgren
2012 2:49:46 PM GMT -05:00 US/Canada Eastern Subject: RFR JDK-80003991 Greetings: The procedure initLoopbackRoutes() has a file descriptor leak. http://cr.openjdk.java.net/~mullan/webrevs/8003991/ Thanks! John Zavgren

RFR JDK-80003991

2012-11-26 Thread John Zavgren
Greetings: The procedure initLoopbackRoutes() has a file descriptor leak. http://cr.openjdk.java.net/~mullan/webrevs/8003991/ Thanks! John Zavgren

Re: getportbyname in Java?

2012-11-14 Thread John Zavgren
I see after reading the correspondence that DNS would be used to bind the names to the numbers, as in RFC 2728 :http://www.dns-sd.org/ServiceTypes.html. (There is a convenient description here: http://en.wikipedia.org/wiki/SRV_record.) I wasn't aware of this effort. It's very cool and useful, e

Re: getportbyname in Java?

2012-11-13 Thread John Zavgren
Max: I've never seen a procedure that binds a protocol to a port number. (The http protocol you mention usually uses TCP port number 80, but the port choice for this protocol is up to the discretion of the programmer. The file /etc/services binds names to numbers so that tools like tcpdump and n

Re: RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c ... AND a potential realloc()-related memory leak.

2012-10-24 Thread John Zavgren
urchi On 24.10.2012 06:27, Chris Hegarty wrote: > Looks good to me. Thanks for going the extra mile here. > > -Chris. > > On 24/10/2012 14:16, John Zavgren wrote: >> >> Greetings: >> >> I'm requesting a review of a software change that fixes a file >&g

RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c ... AND a potential realloc()-related memory leak.

2012-10-24 Thread John Zavgren
Greetings: I'm requesting a review of a software change that fixes a file descriptor leak AND a potential memory leak that involves memory reallocation (realloc()). The webrev image is in the following location: http://cr.openjdk.java.net/~chegar/8000203/webrev.01/ Thanks! John Za

RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c

2012-10-23 Thread John Zavgren
Greetings: I'm requesting a review of a proposed change that fixes a file descriptor leak. The webrev image is in the following location: http://cr.openjdk.java.net/~chegar/8000203/webrev.00/ Thanks! John Zavgren john.zavg...@oracle.com

Change to: ./src/solaris/native/java/net/PlainDatagramSocketImpl.c

2012-10-18 Thread John Zavgren
esn't change any of the externally-visible behavior in the procedure. I look forward to your comments and suggestions. Thanks! John Zavgren john.zavg...@oracle.com

Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?

2012-10-15 Thread John Zavgren
Yes, this seems reasonable to me too. There seem to be fewer and fewer applications that use ftp... - Original Message - From: chris.hega...@oracle.com To: alan.bate...@oracle.com Cc: net-dev@openjdk.java.net Sent: Monday, October 15, 2012 2:48:05 PM GMT -05:00 US/Canada Eastern Subject: R

Two Review requests

2012-09-28 Thread John Zavgren
a bug. I assume it's better to put minor harmless tweaks in our code than to add state information to parfait, that would cause it to ignore certain "situations". That option seems complicated and dangerous. Thanks! John Zavgren john.zavg...@oracle.com

Re: Proposed changes for Bug 7193520

2012-09-14 Thread John Zavgren
field name to be set is "imr_address", whereas when other OSes are used, the field name is: imr_interface. Am I understanding your suggestion correctly? Thanks! John -Dmitry On 2012-09-14 22:22, John Zavgren wrote: > Greetings: > > > This bug (7193520) was filed beca

Re: Proposed changes for Bug 7193520

2012-09-14 Thread John Zavgren
. PlainDatagramSocketImpl.c 318 brackets is not necessary anymore 1644 whole #ifdef could be removed struct ip_mreqn mreqn; is not necessary anymore, 2283 the same 2294 #ifdef is not necessary anymore -Dmitry On 2012-09-14 22:22, John Zavgren wrote: > Greetings: > >

Proposed changes for Bug 7193520

2012-09-14 Thread John Zavgren
the run time checks are eliminated. Thanks! and RSVP John Zavgren john.zavg...@oracle.com

Indenting code?

2012-09-13 Thread John Zavgren
equently whenever I make something, the very first step is to format the code, and I know that when I do a check in later on... I never have to think about whether or not the code conforms to a style guide... because the options I gave to "indent" implemented this guide. (You can do similar

Re: Review request for bug number: 6354758, aka "rename old test HttpServer classes"

2012-09-05 Thread John Zavgren
Kurchi: That is a mistake. I'll change the HTTPS name right now... and create a new webrev image. Thanks! John Zavgren - Original Message - From: kurchi.subhra.ha...@oracle.com To: john.zavg...@oracle.com Cc: net-dev@openjdk.java.net Sent: Wednesday, September 5, 2012 11:54:01 A

Re: Review request for bug number: 6354758, aka "rename old test HttpServer classes"

2012-09-05 Thread John Zavgren
rver should be named TestHttpsServer to be similar to the Http equivalent. Otherwise, it looks fine to me. And I think we'll look into migrating these tests to use the com.sun.net.httpserver API instead of that old implementation in the test tree. Thanks Michael On 05/09/12 15:39, John Z

Review request for bug number: 6354758, aka "rename old test HttpServer classes"

2012-09-05 Thread John Zavgren
ision". The server in the test code (which is intended to be used ONLY for testing) has the same name as the server that's used as an actual Http Server: ./jdk/src/share/classes/com/sun/net/httpserver/HttpServer.java Thanks, John Zavgren