From andreas.schaefer at madplanet.com Tue May 15 00:48:05 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Tue, 15 May 2007 00:48:05 -0700 Subject: URLConnection.disconnect() Tests Message-ID: <464965B5.1050603@madplanet.com> Hi Geeks I am just finishing the tests for the addition of URLConnection.disconnect() method. So far I tested the Jar, File and Ftp implementations but I cannot test MailToURLConnection. Is there, like in FtpURL class a local simulation available of a mail server? Thanks - Andy From Christopher.Hegarty at Sun.COM Tue May 15 03:46:36 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Tue, 15 May 2007 11:46:36 +0100 Subject: URLConnection.disconnect() Tests In-Reply-To: <464965B5.1050603@madplanet.com> References: <464965B5.1050603@madplanet.com> Message-ID: <46498F8C.3000503@sun.com> Hi Andy, Unfortunately we do not currently have a smtp test framework. Any mailto tests do not actually open a connection, they simply test the URL syntax. This maybe a useful addition to the test framework, but I suspect outside the scope of this 'Request for Enhancement'. I am assuming this query is in relation to CR 6313849 - "Provide API to close/disconnect an UrlConnection". In this situation, for the mailto handler, I think that we can test the changes manually against an independent smtp server, and not provide an automatic testcase. As far as ftp is concerned, our preference is to use the ftp framework in test/sun/net/www/ftptest. Thank you for your interest in working on this change and we look forward to receiving your code submission in the near future. Regards, -Chris. Andreas Schaefer wrote: > Hi Geeks > > I am just finishing the tests for the addition of > URLConnection.disconnect() method. So far I tested the Jar, File and Ftp > implementations but I cannot test MailToURLConnection. Is there, like in > FtpURL class a local simulation available of a mail server? > > Thanks - Andy From linuxhippy at gmail.com Tue May 15 15:06:28 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 16 May 2007 00:06:28 +0200 Subject: Howto volunteer? Message-ID: <194f62550705151506t517de733o689d020d97692c78@mail.gmail.com> Hello, 1.) I sent my contributors agreement to Sun about three weaks ago but have not heard and answer. Whats the next step to become an "official" contributor? 2.) I also would like to fix a problem in Webstart (is it opensource too?). Is there a special list dedicated to webstart? 3.) By the way are there still "I fixed the jdk" shirts left ;) ? Thank you in advance, lg Clemens From Michael.McMahon at Sun.COM Wed May 16 13:40:33 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Wed, 16 May 2007 21:40:33 +0100 Subject: [Fwd: How to test an Enhancement and Where] In-Reply-To: <464B49AD.5020206@sun.com> References: <464B49AD.5020206@sun.com> Message-ID: <464B6C41.7020506@sun.com> Andreas, This question was forwarded to us from the jtreg alias. > Hi Geeks > > I am new using jtreg to test changes in the JDK and so I would like to > ask two questions. > > 1) Name of the Test: > > I do an enhancements based on bug 4175918 and 6313849 (both are the > same) which asks for a URLConnection.disconnect() method. The > URLConnection will only contain an abstract disconnect class but all the > sub classes need to implement it. So I am wondering if the test should > be named after the bug number or if it should be named after the method > 'disconnect' because it is an enhancement. > There are no concrete rules, but in my opinion, for bug fixes, where the test is not likely to be more widely useful beyond the scope of the bug, then the test should be named after the bug id. If the test is a unit test for an RFE or other feature, then you could name it based on the functionality being tested. The idea would be that further tests could in the future be added to the same test case file. > 2) Place of the Test: > > Originally I though the test should go into java/net/URLConnection but > then I thought that the real tests must be done where it is implemented > meaning inside sun/net/www/protocol/AAA/AAAURLConnection. What is the > best place? > Again, we don't have concrete rules here. java/net/URLConnection might make sense because it is a common directory (assuming there is one test for all of the implementation classes) - Michael. From andreas.schaefe at madplanet.com Wed May 16 14:33:45 2007 From: andreas.schaefe at madplanet.com (Andreas Schaefer) Date: Wed, 16 May 2007 14:33:45 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 Message-ID: <464B78B9.7090600@madplanet.com> I added the disconnect() method to the java.net.URLConnection class and the implementation to its subclasses. I create the Disconnect.java test class which tests that the InputStreams are closed and the a reconnect is possible. The file disconnect.sh, Disconnect.java and foo2.jar should go into trunk/j2se/test/java/net/URLConnection. This is my first patch for the OpenJDK and so I would love to do it from start to finish. Please let me know if something does not work out or if I should change any of this. Thank you - Andy Schaefer -------------- next part -------------- A non-text attachment was scrubbed... Name: url.connection.disconnect.patch Type: text/x-patch Size: 4960 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070516/2dcc65cf/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: disconnect.sh Type: application/x-shellscript Size: 1721 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070516/2dcc65cf/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Disconnect.java Type: text/x-java Size: 23586 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070516/2dcc65cf/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: foo2.jar Type: application/x-jar Size: 464 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070516/2dcc65cf/attachment-0003.bin From Christopher.Hegarty at Sun.COM Thu May 17 02:03:55 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Thu, 17 May 2007 10:03:55 +0100 Subject: Howto volunteer? In-Reply-To: <194f62550705151506t517de733o689d020d97692c78@mail.gmail.com> References: <194f62550705151506t517de733o689d020d97692c78@mail.gmail.com> Message-ID: <464C1A7B.6010909@sun.com> Hi Clemens, I checked the Contributor Agreements at http://www.sunsource.net/CA_signatories, and you are listed there. Therefore you are eligible to contribute code to all products and projects owned or managed by Sun. I am not sure why you did not get an email confirming this. A query has been sent to the relevant department in Sun about this. Java Webstart has not been open sourced yet, but this is actively being worked on and hopefully will be available under GPL soon. For now you can still contribute to Webstart ( and other areas of the jdk ) through the JDK 7 Project on https://jdk7.dev.java.net/collaborate.html. Sorry, I believe all of the "I fixed the jdk" shirts are gone :-( Thank you for your interest in working on this technology and we look forward to your first contribution. Regards, -Chris. Clemens Eisserer wrote: > Hello, > > 1.) I sent my contributors agreement to Sun about three weaks ago but > have not heard and answer. Whats the next step to become an "official" > contributor? > > 2.) I also would like to fix a problem in Webstart (is it opensource > too?). Is there a special list dedicated to webstart? > > 3.) By the way are there still "I fixed the jdk" shirts left ;) ? > > Thank you in advance, lg Clemens From Michael.McMahon at Sun.COM Thu May 17 02:12:02 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 17 May 2007 10:12:02 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464B78B9.7090600@madplanet.com> References: <464B78B9.7090600@madplanet.com> Message-ID: <464C1C62.8080400@sun.com> Andreas Schaefer wrote: > I added the disconnect() method to the java.net.URLConnection class and > the implementation to its subclasses. I create the Disconnect.java test > class which tests that the InputStreams are closed and the a reconnect > is possible. > > The file disconnect.sh, Disconnect.java and foo2.jar should go into > trunk/j2se/test/java/net/URLConnection. > > This is my first patch for the OpenJDK and so I would love to do it from > start to finish. Please let me know if something does not work out or if > I should change any of this. > Hi Andreas, Since this is an RFE requesting an API change, then it (the API change) will need to be approved by the CCC. The process is that someone from Sun (me in this case) would liaise with the CCC, by submitting the request on your behalf, and then relaying any communications from them to this mailing list (and vice-versa). But, before we get to that stage, we need to discuss the change on this list, and thrash out all of the implications of it. We should be sure that this change will not have any unforeseen consequences down the line. Thanks, Michael. From Alan.Bateman at Sun.COM Thu May 17 02:13:58 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 17 May 2007 10:13:58 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464B78B9.7090600@madplanet.com> References: <464B78B9.7090600@madplanet.com> Message-ID: <464C1CD6.9020607@sun.com> Andreas Schaefer wrote: > I added the disconnect() method to the java.net.URLConnection class and > the implementation to its subclasses. I create the Disconnect.java test > class which tests that the InputStreams are closed and the a reconnect > is possible. > > I don't work in the networking APIs but one comment is that it's not clear if this disconnect method is meant to work as an asynchronous close. If there a thread blocked reading from a resource, for example, and another thread invokes the disconnect method then what is supposed to happen? Is the close allowed to block indefinitely or do you expect the other thread to throw an I/O exception? One concern is that the latter may not be feasible with some protocol handler implementations. The spec will probably also need to deal with the case where the disconnect method is invoked while another thread is disconnecting. There are currency issues with the implementation here but if the expectation is that on return from the disconnect method that all resources have been released, then you probably want disconnect to wait until the first invocation has completed. Another spec question is if we want to update HttpURLConnection's disconnect method. It doesn't define a checked exception (that should be okay) but more interesting, is that it doesn't have the same guarantee about releasing resources that you are looking to add to URLConnection. One final thing to think about is if we want a default implementation rather than adding an abstract method. -Alan. From Christopher.Hegarty at Sun.COM Thu May 17 03:46:56 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Thu, 17 May 2007 11:46:56 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C1CD6.9020607@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> Message-ID: <464C32A0.4030206@sun.com> Alan Bateman wrote: > One final thing to think about is if we want a default implementation > rather than adding an abstract method. I agree with Alan here. Adding disconnect as an abstract method will break both binary and source compatibility. From a binary point of view URLConnection subclasses compiled and runnable with Java SE 6 (or lower) will now throw a java.lang.AbstractMethodError if the disconnect method is called. From a source perspective URLConnection subclasses that previously compiled with Java SE 6 will no longer compile with the java compiler (javac) from Java SE 7 : ...Class is not abstract and does not override abstract method disconnect() in ... For these reasons I would suggest that having a default implementation would be better. -Chris. From andreas.schaefer at madplanet.com Thu May 17 08:04:31 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Thu, 17 May 2007 08:04:31 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C1C62.8080400@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1C62.8080400@sun.com> Message-ID: <464C6EFF.2010004@madplanet.com> Michael McMahon wrote: > Andreas Schaefer wrote: >> I added the disconnect() method to the java.net.URLConnection class and >> the implementation to its subclasses. I create the Disconnect.java test >> class which tests that the InputStreams are closed and the a reconnect >> is possible. >> >> The file disconnect.sh, Disconnect.java and foo2.jar should go into >> trunk/j2se/test/java/net/URLConnection. >> >> This is my first patch for the OpenJDK and so I would love to do it from >> start to finish. Please let me know if something does not work out or if >> I should change any of this. >> > Hi Andreas, > > Since this is an RFE requesting an API change, then it (the API > change) will need to be approved > by the CCC. The process is that someone from Sun (me in this case) > would liaise with the CCC, by > submitting the request on your behalf, and then relaying any > communications from them to this mailing > list (and vice-versa). But, before we get to that stage, we need to > discuss the change on this list, and thrash out all of the > implications of it. We should be sure that this change will not have > any unforeseen consequences down > the line. Well, I am a little bit disappointed that I had to put in all the work just so that this discussion starts. I announced my indention to work on this RFE over a year ago back in the Mustang area. -Andy From Michael.McMahon at Sun.COM Thu May 17 08:37:18 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 17 May 2007 16:37:18 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C6EFF.2010004@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1C62.8080400@sun.com> <464C6EFF.2010004@madplanet.com> Message-ID: <464C76AE.90406@sun.com> Andreas Schaefer wrote: > Michael McMahon wrote: > >> Andreas Schaefer wrote: >> >>> I added the disconnect() method to the java.net.URLConnection class and >>> the implementation to its subclasses. I create the Disconnect.java test >>> class which tests that the InputStreams are closed and the a reconnect >>> is possible. >>> >>> The file disconnect.sh, Disconnect.java and foo2.jar should go into >>> trunk/j2se/test/java/net/URLConnection. >>> >>> This is my first patch for the OpenJDK and so I would love to do it from >>> start to finish. Please let me know if something does not work out or if >>> I should change any of this. >>> >>> >> Hi Andreas, >> >> Since this is an RFE requesting an API change, then it (the API >> change) will need to be approved >> by the CCC. The process is that someone from Sun (me in this case) >> would liaise with the CCC, by >> submitting the request on your behalf, and then relaying any >> communications from them to this mailing >> list (and vice-versa). But, before we get to that stage, we need to >> discuss the change on this list, and thrash out all of the >> implications of it. We should be sure that this change will not have >> any unforeseen consequences down >> the line. >> > Well, I am a little bit disappointed that I had to put in all the work > just so that this discussion starts. I announced my indention to work on > this RFE over a year ago back in the Mustang area. > > The work that you have done is the starting point, now we can see what you are proposing exactly. API changes are more difficult that regular bug fixes. For instance, you have defined disconnect() as an abstract method. That causes problems for source and binary compatibility. It's not a big deal, but it's an example of the kind of issue we need to resolve before going to the CCC. - Michael. From andreas.schaefer at madplanet.com Thu May 17 09:54:21 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Thu, 17 May 2007 09:54:21 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C32A0.4030206@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> Message-ID: <464C88BD.9010400@madplanet.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > > Alan Bateman wrote: >> One final thing to think about is if we want a default implementation >> rather than adding an abstract method. > > I agree with Alan here. Adding disconnect as an abstract method will > break both binary and source compatibility. > > From a binary point of view URLConnection subclasses compiled and > runnable with Java SE 6 (or lower) will now throw a > java.lang.AbstractMethodError if the disconnect method is called. That can only happen if some code is 1.7 aware and some of the code is not like a library. AFAIK there were already changes in the JDK that caused that as well. I think that needs to be documented. On the other hand URLConnection is not a class that is extended quite a lot. > From a source perspective URLConnection subclasses that previously > compiled with Java SE 6 will no longer compile with the java compiler > (javac) from Java SE 7 : ...Class is not abstract and does not > override abstract method disconnect() in ... Well, the reason I did make it abstract is the fact that I did want to avoid someone getting away with an empty implementation. This is only causing a problem if someone is compiling its code for 1.7 and so he/she just needs to implement it. Compiling means that he/she has the code and so this is pretty easy fix. Providing an empty implementation is more costly that adding an implementation. -Andy From andreas.schaefer at madplanet.com Thu May 17 09:59:13 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Thu, 17 May 2007 09:59:13 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C1CD6.9020607@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> Message-ID: <464C89E1.7000904@madplanet.com> Alan Bateman wrote: > Andreas Schaefer wrote: >> I added the disconnect() method to the java.net.URLConnection class and >> the implementation to its subclasses. I create the Disconnect.java test >> class which tests that the InputStreams are closed and the a reconnect >> is possible. >> >> > I don't work in the networking APIs but one comment is that it's not > clear if this disconnect method is meant to work as an asynchronous > close. If there a thread blocked reading from a resource, for example, > and another thread invokes the disconnect method then what is supposed > to happen? Is the close allowed to block indefinitely or do you expect > the other thread to throw an I/O exception? One concern is that the > latter may not be feasible with some protocol handler implementations. > The spec will probably also need to deal with the case where the > disconnect method is invoked while another thread is disconnecting. > There are currency issues with the implementation here but if the > expectation is that on return from the disconnect method that all > resources have been released, then you probably want disconnect to > wait until the first invocation has completed. I don't think we need to deal with blocking etc because so far people had to obtain the underlying resource and close them which would have all the problems you mentioned. This new method is not any different except that its avoids the upcasts and the fishing for resources. -Andy From Alan.Bateman at Sun.COM Thu May 17 11:50:52 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 17 May 2007 19:50:52 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C89E1.7000904@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C89E1.7000904@madplanet.com> Message-ID: <464CA40C.4010908@sun.com> Andreas Schaefer wrote: > : > I don't think we need to deal with blocking etc because so far people > had to obtain the underlying resource and close them which would have > all the problems you mentioned. This new method is not any different > except that its avoids the upcasts and the fishing for resources. > The specification of the proposed disconnect method will need to set expectations. If you are saying that it depends on if the streams can be asynchronously closed then this should go into its spec. In that case, disconnect may block and you will also need to specify how disconnect behaves when invoked by several threads at around the same time. It may be best to say that it blocks until the first invocation completes as that will ensure that on completion, all resources will have been released. -Alan. From andreas.schaefer at madplanet.com Thu May 17 13:18:05 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Thu, 17 May 2007 13:18:05 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464CA40C.4010908@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C89E1.7000904@madplanet.com> <464CA40C.4010908@sun.com> Message-ID: <464CB87D.9030300@madplanet.com> Alan Bateman wrote: > Andreas Schaefer wrote: >> : >> I don't think we need to deal with blocking etc because so far people >> had to obtain the underlying resource and close them which would have >> all the problems you mentioned. This new method is not any different >> except that its avoids the upcasts and the fishing for resources. >> > The specification of the proposed disconnect method will need to set > expectations. If you are saying that it depends on if the streams can > be asynchronously closed then this should go into its spec. In that > case, disconnect may block and you will also need to specify how > disconnect behaves when invoked by several threads at around the same > time. It may be best to say that it blocks until the first invocation > completes as that will ensure that on completion, all resources will > have been released. > > -Alan. For the Jar- and FileURLConnection there is no such thing as an invocation. For the FTPURLConnection I am not quite sure if it would be a great thing to wait until an invocation is done especially when a huge file is transferred. Mostly we are dealing with Input / Output Stream and when they are closed the using thread gets an exception. On the other hand right now a user of any URLConnection has to make handle by themselves already so why we just let them handle it by themselves now. I suggest that we refer to the sub class' disconnect() method for protocol specific issues like concurrency and say by default the user has to take care of it by themselves. I also have a problem to come up with an use case of an asynchronous disconnect. How would another thread knows when to disconnect. The only use case I can come up with is than two threads could collide during connect / disconnect and we might want to prevent the URLConnection from doing so. This way we make sure that either a URLConnection is fully connected or disconnected. -Andy From richard at kennardconsulting.com Thu May 17 15:43:41 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Fri, 18 May 2007 08:43:41 +1000 Subject: Request for comments: Bug 6306820 Message-ID: <464CDA9D.3070307@kennardconsulting.com> Dear All, Following the advice of my OpenJDK sponsor, I am submitting my patch to this mailing list to ask for comments and suggestions. The patch targets the following RFE: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6306820 ...and the latest version of the code can be found here... https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=10348 In short, the RFE aims to provide tools to easily and safely manipulate 'www-form-urlencoded' query strings within Java SE. Regards, Richard. From Alan.Bateman at Sun.COM Fri May 18 03:07:07 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 18 May 2007 11:07:07 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <464CDA9D.3070307@kennardconsulting.com> References: <464CDA9D.3070307@kennardconsulting.com> Message-ID: <464D7ACB.1090507@sun.com> Richard Kennard wrote: > Dear All, > > Following the advice of my OpenJDK sponsor, I am submitting my patch > to this mailing list to ask for comments and suggestions. The patch > targets the following RFE: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6306820 > > ...and the latest version of the code can be found here... > > > https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=10348 > > > In short, the RFE aims to provide tools to easily and safely > manipulate 'www-form-urlencoded' query strings within Java SE. > > Regards, > > Richard. I know you've been talking with Michael about this one for a while but I'm curious to know if you've considered adding a simple utility class instead. That is, instead of introducing a mutual object to encapsulate a parameter map that you would instead just provide a few simply utility methods to parse and convert a map to a form encoded query string - maybe something like: public final class UrlQueryStrings { private UrlQueryStrings() { } public static Map> parse(String query) { .. } public static String toString(Map> params) { .. } } It's just a suggestion to think about but the benefit is that the collection APIs can be used to manipulate the parameter map. If this were fleshed out then you might have variants to allow the separator be specified and maybe a few utility methods to combine parameter maps. For the equivalent of your apply method then it may be worth thinking about adding a method to URI instead - it would be a variant of the resolve method that constructs a URI with the given query string - essentially a resolve method that deviates from the RFC in the way that the fragment component is preserved (which is what I think you are looking for here). -Alan. From Alan.Bateman at Sun.COM Fri May 18 03:34:33 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 18 May 2007 11:34:33 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464CB87D.9030300@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C89E1.7000904@madplanet.com> <464CA40C.4010908@sun.com> <464CB87D.9030300@madplanet.com> Message-ID: <464D8139.4080400@sun.com> Andreas Schaefer wrote: > : > For the Jar- and FileURLConnection there is no such thing as an > invocation. For the FTPURLConnection I am not quite sure if it would be > a great thing to wait until an invocation is done especially when a huge > file is transferred. Mostly we are dealing with Input / Output Stream > and when they are closed the using thread gets an exception. > On the other hand right now a user of any URLConnection has to make > handle by themselves already so why we just let them handle it by > themselves now. > > I suggest that we refer to the sub class' disconnect() method for > protocol specific issues like concurrency and say by default the user > has to take care of it by themselves. > > I also have a problem to come up with an use case of an asynchronous > disconnect. How would another thread knows when to disconnect. The only > use case I can come up with is than two threads could collide during > connect / disconnect and we might want to prevent the URLConnection from > doing so. This way we make sure that either a URLConnection is fully > connected or disconnected. > If you add a disconnect method (maybe it should be named "close" and have URLConnection implement Closeable), then it is likely that developers may attempt to use it for cancellation. In error situations or network file systems then access to JAR or file resources may block or take significant time. There is nothing in the spec that requires protocol handlers to support asynchronous close and it is highly likely there are protocol handlers where it doesn't work - invoking close on the intput or output stream may block or may not preempt threads blocked doing I/O on the streams for example. For the proposed disconnect method I'm just suggesting that these issues need to be considered. One suggestion is to specify that it can't make any guarantees, beyond a best effort attempt, to close the connection to the resource in a timely manner. It would not be unreasonable to specify that, on completion, the connection to the resource has been closed (which means that disconnect may block). One other thing - a common issue for new developers is to attempt re-use a URLConnection (it comes up with http a lot as developers don't know how the HTTP protocol handler works with persistent connections). In the disconnect method it may be useful to set expectations. Also, you may need to add wording to the connect method to specify the behavior after the connection has been closed. -Alan. From Christopher.Hegarty at Sun.COM Fri May 18 02:00:52 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 18 May 2007 10:00:52 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464CB87D.9030300@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C89E1.7000904@madplanet.com> <464CA40C.4010908@sun.com> <464CB87D.9030300@madplanet.com> Message-ID: <464D6B44.4000605@sun.com> Andreas Schaefer wrote: > I also have a problem to come up with an use case of an asynchronous > disconnect. How would another thread knows when to disconnect. The only > use case I can come up with is than two threads could collide during > connect / disconnect and we might want to prevent the URLConnection from > doing so. This way we make sure that either a URLConnection is fully > connected or disconnected. I have seen a few cases where HttpURLConnection.disconnect has been called asynchronously as a way of implemeting a connect/read timeout in user code. One such bug that comes to mind is CR 6358532. This bug was seen to be important enough that it was escalated by an external customer. -Chris. From Christopher.Hegarty at Sun.COM Fri May 18 01:51:39 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 18 May 2007 09:51:39 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464C88BD.9010400@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> Message-ID: <464D691B.3090409@sun.com> Andreas Schaefer wrote: > Well, the reason I did make it abstract is the fact that I did want to > avoid someone getting away with an empty implementation. This is only > causing a problem if someone is compiling its code for 1.7 and so he/she > just needs to implement it. Compiling means that he/she has the code and > so this is pretty easy fix. Providing an empty implementation is more > costly that adding an implementation. While breaking source compatibility in a major release ( and jdk 7 is a major release ) is acceptable, I think there should be a good reason to do so, and I do not believe that there is one in this case. Obviously even with disconnect being abstract implementers can still provide an empty implementation in the subclass. I do not see the advantage to forcing them to do this. Also, not all protocol handlers and URLConnection subclasses have specific public API's exposed, for example 'file'. Therefore it is even more important to try and clearly specify the methods of URLConnection. BTW, Shouldn't JarURLConnection.disconnect release the resources held by its containing URLConnection. -Chris. From andreas.schaefer at madplanet.com Fri May 18 08:55:18 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Fri, 18 May 2007 08:55:18 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464D691B.3090409@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> <464D691B.3090409@sun.com> Message-ID: <464DCC66.7000602@madplanet.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > > > Andreas Schaefer wrote: > > Well, the reason I did make it abstract is the fact that I did want to >> avoid someone getting away with an empty implementation. This is only >> causing a problem if someone is compiling its code for 1.7 and so he/she >> just needs to implement it. Compiling means that he/she has the code and >> so this is pretty easy fix. Providing an empty implementation is more >> costly that adding an implementation. > > While breaking source compatibility in a major release ( and jdk 7 is > a major release ) is acceptable, I think there should be a good reason > to do so, and I do not believe that there is one in this case. There are two independent bug reports asking for the disconnect() method and on 6313849 there are 9 votes. I am going to blog about this and see if I can get more feedback from the community. > Obviously even with disconnect being abstract implementers can still > provide an empty implementation in the subclass. I do not see the > advantage to forcing them to do this. Also, not all protocol handlers > and URLConnection subclasses have specific public API's exposed, for > example 'file'. Therefore it is even more important to try and clearly > specify the methods of URLConnection. Well, I can also create an URLConnection that has an empty connect() method, silly but true. If you really want an empty disconnect() method then be my guest but I still think that is worse than forcing the extended classes to create one so that it adheres to the "contract" otherwise I could also ask why is the connect() method abstract? > > BTW, Shouldn't JarURLConnection.disconnect release the resources held > by its containing URLConnection. Maybe you saw a bug in my implementation and if yes then tell me but otherwise you should do your homework and checkout my patch because that is what is in there. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: andreas.schaefer.vcf Type: text/x-vcard Size: 403 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/ac71f6aa/attachment.vcf From andreas.schaefer at madplanet.com Fri May 18 08:59:34 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Fri, 18 May 2007 08:59:34 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464D6B44.4000605@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C89E1.7000904@madplanet.com> <464CA40C.4010908@sun.com> <464CB87D.9030300@madplanet.com> <464D6B44.4000605@sun.com> Message-ID: <464DCD66.4050207@madplanet.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Andreas Schaefer wrote: > >> I also have a problem to come up with an use case of an asynchronous >> disconnect. How would another thread knows when to disconnect. The only >> use case I can come up with is than two threads could collide during >> connect / disconnect and we might want to prevent the URLConnection from >> doing so. This way we make sure that either a URLConnection is fully >> connected or disconnected. > > I have seen a few cases where HttpURLConnection.disconnect has been > called asynchronously as a way of implemeting a connect/read timeout > in user code. Did you know that HttpURLConnection.disconnect() method is already in and I did not do anything with it. So if it could be done for the HttpURLConnection why couldn't it be done for the base URLConnection? > One such bug that comes to mind is CR 6358532. This bug was seen to be > important enough that it was escalated by an external customer. Again that is a problem for the HttpURLConnection and does not apply to the others. BTW I could not find this bug. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: andreas.schaefer.vcf Type: text/x-vcard Size: 403 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/135811fe/attachment.vcf From Michael.McMahon at Sun.COM Fri May 18 09:05:41 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 18 May 2007 17:05:41 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464D691B.3090409@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> <464D691B.3090409@sun.com> Message-ID: <464DCED5.1050604@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > > > Andreas Schaefer wrote: > > Well, the reason I did make it abstract is the fact that I did want to >> avoid someone getting away with an empty implementation. This is only >> causing a problem if someone is compiling its code for 1.7 and so he/she >> just needs to implement it. Compiling means that he/she has the code and >> so this is pretty easy fix. Providing an empty implementation is more >> costly that adding an implementation. > > While breaking source compatibility in a major release ( and jdk 7 is > a major release ) is acceptable, I think there should be a good reason > to do so, and I do not believe that there is one in this case. > This case is probably in a grey area. Normally, the justification has to be very strong, but URLConnection and its sub-classes would mostly be considered as part of the platform rather than as part of applications. In other words, (as Andy said) there probably aren't that many implementations out there. So long as we maintain binary compatibility for existing applications using third party URLConnections (assuming there are some) then we should be ok. I think I prefer the method name close() to disconnect() since it seems to be closer to what the bug report is asking for. HttpURLConnection.disconnect() is slightly different in meaning. - Michael. From andreas.schaefer at madplanet.com Fri May 18 09:16:00 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Fri, 18 May 2007 09:16:00 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464D8139.4080400@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C89E1.7000904@madplanet.com> <464CA40C.4010908@sun.com> <464CB87D.9030300@madplanet.com> <464D8139.4080400@sun.com> Message-ID: <464DD140.9040007@madplanet.com> Alan Bateman wrote: > Andreas Schaefer wrote: >> : >> For the Jar- and FileURLConnection there is no such thing as an >> invocation. For the FTPURLConnection I am not quite sure if it would be >> a great thing to wait until an invocation is done especially when a huge >> file is transferred. Mostly we are dealing with Input / Output Stream >> and when they are closed the using thread gets an exception. >> On the other hand right now a user of any URLConnection has to make >> handle by themselves already so why we just let them handle it by >> themselves now. >> >> I suggest that we refer to the sub class' disconnect() method for >> protocol specific issues like concurrency and say by default the user >> has to take care of it by themselves. >> >> I also have a problem to come up with an use case of an asynchronous >> disconnect. How would another thread knows when to disconnect. The only >> use case I can come up with is than two threads could collide during >> connect / disconnect and we might want to prevent the URLConnection from >> doing so. This way we make sure that either a URLConnection is fully >> connected or disconnected. >> > If you add a disconnect method (maybe it should be named "close" and > have URLConnection implement Closeable), then it is likely that > developers may attempt to use it for cancellation. In error situations > or network file systems then access to JAR or file resources may block > or take significant time. There is nothing in the spec that requires > protocol handlers to support asynchronous close and it is highly > likely there are protocol handlers where it doesn't work - invoking > close on the intput or output stream may block or may not preempt > threads blocked doing I/O on the streams for example. For the proposed > disconnect method I'm just suggesting that these issues need to be > considered. One suggestion is to specify that it can't make any > guarantees, beyond a best effort attempt, to close the connection to > the resource in a timely manner. It would not be unreasonable to > specify that, on completion, the connection to the resource has been > closed (which means that disconnect may block). The underlying resource could be many things and so I would say that the disconnect closes the underlying resource as fast as possible maybe interrupting a work in progress by another thread and its the user's responsibility to handle this. > One other thing - a common issue for new developers is to attempt > re-use a URLConnection (it comes up with http a lot as developers > don't know how the HTTP protocol handler works with persistent > connections). In the disconnect method it may be useful to set > expectations. Also, you may need to add wording to the connect method > to specify the behavior after the connection has been closed. The basic idea is that a disconnect() must be closed in a way that a user can (re)connect again afterwards. This does require that the connect() and disconnect() do not interfere with each other. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: andreas.schaefer.vcf Type: text/x-vcard Size: 403 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/645a80b3/attachment.vcf From andreas.schaefer at madplanet.com Fri May 18 09:18:25 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Fri, 18 May 2007 09:18:25 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464DCED5.1050604@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> <464D691B.3090409@sun.com> <464DCED5.1050604@sun.com> Message-ID: <464DD1D1.50300@madplanet.com> Michael McMahon wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> >> >> Andreas Schaefer wrote: >> > Well, the reason I did make it abstract is the fact that I did >> want to >>> avoid someone getting away with an empty implementation. This is only >>> causing a problem if someone is compiling its code for 1.7 and so >>> he/she >>> just needs to implement it. Compiling means that he/she has the code >>> and >>> so this is pretty easy fix. Providing an empty implementation is more >>> costly that adding an implementation. >> >> While breaking source compatibility in a major release ( and jdk 7 is >> a major release ) is acceptable, I think there should be a good >> reason to do so, and I do not believe that there is one in this case. >> > This case is probably in a grey area. Normally, the justification has > to be very strong, but > URLConnection and its sub-classes would mostly be considered as part > of the platform rather > than as part of applications. In other words, (as Andy said) there > probably aren't that many > implementations out there. So long as we maintain binary compatibility > for existing applications > using third party URLConnections (assuming there are some) then we > should be ok. > > I think I prefer the method name close() to disconnect() since it > seems to be closer to > what the bug report is asking for. HttpURLConnection.disconnect() is > slightly different > in meaning. > > - Michael. My idea is that connect() / disconnect() are orthogonal methods meaning that after a disconnect() one can reopen the Connection by issuing another connect() call. Calling it close() would break that linguistically but with the proper documentation it should be fine. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: andreas.schaefer.vcf Type: text/x-vcard Size: 403 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070518/ed33cd9c/attachment.vcf From Michael.McMahon at Sun.COM Fri May 18 09:34:01 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 18 May 2007 17:34:01 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464DD1D1.50300@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> <464D691B.3090409@sun.com> <464DCED5.1050604@sun.com> <464DD1D1.50300@madplanet.com> Message-ID: <464DD579.3070904@sun.com> Andreas Schaefer wrote: > Michael McMahon wrote: >> Christopher Hegarty - Sun Microsystems Ireland wrote: >>> >>> >>> Andreas Schaefer wrote: >>> > Well, the reason I did make it abstract is the fact that I did >>> want to >>>> avoid someone getting away with an empty implementation. This is only >>>> causing a problem if someone is compiling its code for 1.7 and so >>>> he/she >>>> just needs to implement it. Compiling means that he/she has the >>>> code and >>>> so this is pretty easy fix. Providing an empty implementation is more >>>> costly that adding an implementation. >>> >>> While breaking source compatibility in a major release ( and jdk 7 >>> is a major release ) is acceptable, I think there should be a good >>> reason to do so, and I do not believe that there is one in this case. >>> >> This case is probably in a grey area. Normally, the justification has >> to be very strong, but >> URLConnection and its sub-classes would mostly be considered as part >> of the platform rather >> than as part of applications. In other words, (as Andy said) there >> probably aren't that many >> implementations out there. So long as we maintain binary >> compatibility for existing applications >> using third party URLConnections (assuming there are some) then we >> should be ok. >> >> I think I prefer the method name close() to disconnect() since it >> seems to be closer to >> what the bug report is asking for. HttpURLConnection.disconnect() is >> slightly different >> in meaning. >> >> - Michael. > My idea is that connect() / disconnect() are orthogonal methods > meaning that after a disconnect() one can reopen the Connection by > issuing another connect() call. Calling it close() would break that > linguistically but with the proper documentation it should be fine. > > -Andy One other thing, URLConnections can't be reused. I imagine it could lead to all kinds of security issues if we tried to support that. They are basically immutable in terms of the resource that is accessed. I don't think this RFE really needs that. What do you think? - Michael. From andreas.schaefer at madplanet.com Fri May 18 11:27:54 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Fri, 18 May 2007 11:27:54 -0700 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464DD579.3070904@sun.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> <464D691B.3090409@sun.com> <464DCED5.1050604@sun.com> <464DD1D1.50300@madplanet.com> <464DD579.3070904@sun.com> Message-ID: <464DF02A.2090303@madplanet.com> Michael McMahon wrote: > Andreas Schaefer wrote: >> Michael McMahon wrote: >>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>> >>>> >>>> Andreas Schaefer wrote: >>>> > Well, the reason I did make it abstract is the fact that I did >>>> want to >>>>> avoid someone getting away with an empty implementation. This is only >>>>> causing a problem if someone is compiling its code for 1.7 and so >>>>> he/she >>>>> just needs to implement it. Compiling means that he/she has the >>>>> code and >>>>> so this is pretty easy fix. Providing an empty implementation is more >>>>> costly that adding an implementation. >>>> >>>> While breaking source compatibility in a major release ( and jdk 7 >>>> is a major release ) is acceptable, I think there should be a good >>>> reason to do so, and I do not believe that there is one in this case. >>>> >>> This case is probably in a grey area. Normally, the justification >>> has to be very strong, but >>> URLConnection and its sub-classes would mostly be considered as part >>> of the platform rather >>> than as part of applications. In other words, (as Andy said) there >>> probably aren't that many >>> implementations out there. So long as we maintain binary >>> compatibility for existing applications >>> using third party URLConnections (assuming there are some) then we >>> should be ok. >>> >>> I think I prefer the method name close() to disconnect() since it >>> seems to be closer to >>> what the bug report is asking for. HttpURLConnection.disconnect() is >>> slightly different >>> in meaning. >>> >>> - Michael. >> My idea is that connect() / disconnect() are orthogonal methods >> meaning that after a disconnect() one can reopen the Connection by >> issuing another connect() call. Calling it close() would break that >> linguistically but with the proper documentation it should be fine. >> >> -Andy > One other thing, URLConnections can't be reused. I imagine it could > lead to all kinds > of security issues if we tried to support that. They are basically > immutable in terms > of the resource that is accessed. I don't think this RFE really needs > that. What do you think? > > - Michael. If that is necessary then it is OK with me. We just must make sure that nobody can (re)connect throwing an IOException in the connect() method. The problem is that every sub class that implements connect() must adhere to it and if they don't then one could still reconnect. I would suggest that a reconnect is possible except the URLConnection throws an exception. Glancing at the HttpURLConnection.disconnect() method I think they do allow reconnects. -Andy From richard at kennardconsulting.com Fri May 18 17:54:57 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Sat, 19 May 2007 10:54:57 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: References: Message-ID: <464E4AE1.4070808@kennardconsulting.com> Alan, Great to hear from you again! I am not at all opposed to making the changes you suggest. However, permit me to explain why it is the way it is first, and then you can counter my points :) If I understand you correctly, what you are suggesting is a more 'functional' (as opposed to OO) approach to the design. That is, have a bunch of static methods that operate on a Map>, and let the user worry about passing that Map around. I would have the following concerns to this approach: 1. The Map itself would be very unwieldy. To retrieve a parameter from a query string, you'd have to do... map.get( "param1" ).get( 0 ); ...as opposed to... query.getParameter( "param1" ); To set a parameter, you'd have to do... map.put( "param2", Arrays.asList( new String[]{ String.valueOf( 3 ) } )); ...as opposed to... query.setParameter( "param2", 3 ); To add a parameter, you'd have to do... List list = map.get( "param1" ); if ( list == null ) list = Arrays.asList( new String[]{ String.valueOf( 3 ) } )); else list.add( String.valueOf( 3 )); map.put( "param1", list ); ...as opposed to... query.appendParameter( "param1", 3 ); ...the former makes the concept of multi-valued parameters explicit and 'in your face', even though they are seldom used. This is a problem wrestled with by the Java EE team, which I believe first deprecated and then un-deprecated getParameterValue (as opposed to getParameterValues). 2. The existing class still allows the benefit of using the Collection APIs to manipulate the Map: you can call .getParameterMap() and go from there. However, I would expect this to be an advanced use-case. 3. To add a method to java.net.URI that accepts a Map and turns it into a 'www-form-urlencoded' query string would be to incorporate details from the HTML spec into the URI class. At present, the URI class is only concerned with the RFC 2396 URI spec - not anything HTML specific. I thought you'd prefer it to stay that way? Indeed, that was one of your objections to some of my earlier designs, many months ago. Look forward to hearing from you, Richard. From Alan.Bateman at Sun.COM Sat May 19 13:24:13 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 19 May 2007 21:24:13 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <464E4AE1.4070808@kennardconsulting.com> References: <464E4AE1.4070808@kennardconsulting.com> Message-ID: <464F5CED.7010500@sun.com> Richard Kennard wrote: > Alan, > > Great to hear from you again! > > I am not at all opposed to making the changes you suggest. However, > permit me to explain why it is the way it is first, and then you can > counter my points :) > > If I understand you correctly, what you are suggesting is a more > 'functional' (as opposed to OO) approach to the design. That is, have > a bunch of static methods that operate on a Map>, > and let the user worry about passing that Map around. I would have the > following concerns to this approach: It's good to see you are persevering with this one. I just mention the suggestion of a utility class as another approach to examine given that many of the operations are map-like. As it stands it looks like you are trying to support a dual API anyway in that you define the getParameterMap method. On that method, I see it returns a reference to the internal map - did you mean to do that? For several reasons this could be problematic and dangerous. A few other observations from my initial glance at the javadoc: - The methods that do not otherwise have a value to return could return the URLEncodedQueryString instead of void so as to allow for method chaining. If you make the method names relatively short (like "add" and "append") then it might be easier to chain several invocations on the same line. - I think I missed the point as to why it is necessary to make it Serializable. Could the serialized form is the query String or the URI? If you do make it Serializable then there are a issues in the implementation that will to be examined closely. - Should the spec say anything about character encoding? I believe you are using UTF-8 and maybe the spec should reference URLEncoder/URLDecoder. - Since the class is mutable you probably need something in the top-level spec to explain that it is not thread safe, etc. - Is the ParameterSeparator enum needed? I assume almost all cases are "&" and it should be rare for anything else (in that case perhaps have the user can specify the separator as a String - just a suggestion). - Do getQuery() and toString return the same string? > > > 3. To add a method to java.net.URI that accepts a Map and turns it > into a 'www-form-urlencoded' query string would be to incorporate > details from the HTML spec into the URI class. At present, the URI > class is only concerned with the RFC 2396 URI spec - not anything HTML > specific. I thought you'd prefer it to stay that way? Indeed, that was > one of your objections to some of my earlier designs, many months ago. I'm not suggesting adding any methods to URI that take the Map but rather that it may be useful to look into new static factory methods to construct URIs from other URIs and components. The piece-wise constructors and resolve methods don't cover the cases where you need to clone a URI and replace one or more components - this approach might be more broadly useful that the "apply" methods that you have suggested. -Alan. From richard at kennardconsulting.com Sat May 19 17:17:09 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Sun, 20 May 2007 10:17:09 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <464F5CED.7010500@sun.com> References: <464E4AE1.4070808@kennardconsulting.com> <464F5CED.7010500@sun.com> Message-ID: <464F9385.6030307@kennardconsulting.com> Alan, > It's good to see you are persevering with this one. Yes, though I confess after 18 months I would like to see it resolved, and I seem to receive more questions than answers! To that end, may I request you agree to each point, one at a time, before moving on to the next? Today's point: UTILITY CLASS v REGULAR CLASS You suggest a utility class because 'many of the operations are map-like'. As I tried to demonstrate, though, the map-like operations are very unwieldy because we are dealing with a Map>. I could also move 'addParameter( Map> map, String name, String value )', 'removeParameter', etc. into the utility class, and all the rest, but then that starts to look ugly? So, can we agree a regular class is better than a utility class? Regards, Richard. From Alan.Bateman at Sun.COM Sun May 20 04:32:57 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 20 May 2007 12:32:57 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <464F9385.6030307@kennardconsulting.com> References: <464E4AE1.4070808@kennardconsulting.com> <464F5CED.7010500@sun.com> <464F9385.6030307@kennardconsulting.com> Message-ID: <465031E9.8080504@sun.com> Richard Kennard wrote: > : > > So, can we agree a regular class is better than a utility class? That seems reasonable to me. I just suggested thinking about a utility class given that this is mostly about manipulating a map of parameters. Some aspects of the builder pattern are probably useful here but if I were creating it then I would keep it very simple and probably suggest something like this: public class UrlQueryString { private UrlQueryString() { } public static UrlQueryString create() public static UrlQueryString parse(CharSequence query) public String get(String name) public List getAll(String name) public UrlQueryString set(String name, String... value) public UrlQueryString set(String name, List values) public UrlQueryString add(String name, String... value) public UrlQueryString add(String name, List values) public UrlQueryString add(UrlQueryString other) public UrlQueryString add(CharSequence other) public UrlQueryString remove(String name) public String toString() public Map> toMap() } This isn't too different from what you have except that the object is created with static factory methods rather than public constructors, it allows for method chaining, and it doesn't do the URL/URI creation. For the latter I would suggest looking into adding static methods to java.net.URI to allow URIs be created from various URI and component combinations. Does that seem reasonable? -Alan. From richard at kennardconsulting.com Sun May 20 15:53:14 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Mon, 21 May 2007 08:53:14 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <465031E9.8080504@sun.com> References: <464E4AE1.4070808@kennardconsulting.com> <464F5CED.7010500@sun.com> <464F9385.6030307@kennardconsulting.com> <465031E9.8080504@sun.com> Message-ID: <4650D15A.3030201@kennardconsulting.com> Alan, Thanks for your prompt reply! I appreciate you keeping this moving. 1. I would like to postpone the issues of method chaining and URI/URL creation to another discussion, if that's okay. 2. So what we are debating between here is... public UrlQueryString { private UrlQueryString(); public static UrlQueryString create(); public static UrlQueryString parse(CharSequence query); ... } ...versus... public UrlQueryString { public UrlQueryString() public UrlQueryString(CharSequence query) ... } While both are roughly equivalent, I guess the latter seems more 'normal' to me, and more in keeping with the rest of the JDK? Just so you know where I'm coming from - I am no longer thinking this class should be any kind of builder or factory, rather I think it should simply model a 'www-form-urlencoded' query string. Regards, Richard. Alan Bateman wrote: > Richard Kennard wrote: >> : >> >> So, can we agree a regular class is better than a utility class? > That seems reasonable to me. I just suggested thinking about a utility > class given that this is mostly about manipulating a map of > parameters. Some aspects of the builder pattern are probably useful > here but if I were creating it then I would keep it very simple and > probably suggest something like this: > > public class UrlQueryString { > private UrlQueryString() { } > public static UrlQueryString create() > public static UrlQueryString parse(CharSequence query) > public String get(String name) > public List getAll(String name) > public UrlQueryString set(String name, String... value) > public UrlQueryString set(String name, List values) > public UrlQueryString add(String name, String... value) > public UrlQueryString add(String name, List values) > public UrlQueryString add(UrlQueryString other) > > public UrlQueryString add(CharSequence other) > public UrlQueryString remove(String name) > public String toString() > public Map> toMap() } > > This isn't too different from what you have except that the object is > created with static factory methods rather than public constructors, > it allows for method chaining, and it doesn't do the URL/URI creation. > For the latter I would suggest looking into adding static methods to > java.net.URI to allow URIs be created from various URI and component > combinations. Does that seem reasonable? > > -Alan. > > > From Alan.Bateman at Sun.COM Mon May 21 02:05:45 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 21 May 2007 10:05:45 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <4650D15A.3030201@kennardconsulting.com> References: <464E4AE1.4070808@kennardconsulting.com> <464F5CED.7010500@sun.com> <464F9385.6030307@kennardconsulting.com> <465031E9.8080504@sun.com> <4650D15A.3030201@kennardconsulting.com> Message-ID: <465160E9.3070902@sun.com> Richard Kennard wrote: > Alan, > > Thanks for your prompt reply! I appreciate you keeping this moving. > > 1. I would like to postpone the issues of method chaining and URI/URL > creation to another discussion, if that's okay. > 2. So what we are debating between here is... > > public UrlQueryString { > private UrlQueryString(); > public static UrlQueryString create(); > public static UrlQueryString parse(CharSequence query); > ... > } > > ...versus... > > public UrlQueryString { > public UrlQueryString() > public UrlQueryString(CharSequence query) > ... > } > > While both are roughly equivalent, I guess the latter seems more > 'normal' to me, and more in keeping with the rest of the JDK? > > Just so you know where I'm coming from - I am no longer thinking this > class should be any kind of builder or factory, rather I think it > should simply model a 'www-form-urlencoded' query string. Josh Bloch's Effective Java provides many good reasons to prefer static factory methods over public constructors. In this context the ability to name the creation methods and the possibility of returning a subtype are probably the important ones. As this class evolves then it is possible there will be new ways to create these objects (the ability the specify the encoding, separator, etc. come to mind). Many of these creation methods will specify the configuration as Strings so allowing the creation names be distinguished even though they have the same signatures will be useful. In the case of subtypes, it may be that you want to have other types of query string in the future (as web standard tend to evolve). -Alan. From Michael.McMahon at Sun.COM Mon May 21 08:55:32 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 21 May 2007 16:55:32 +0100 Subject: Patch for Enhancement Bug # 6313849 and 417591 In-Reply-To: <464DF02A.2090303@madplanet.com> References: <464B78B9.7090600@madplanet.com> <464C1CD6.9020607@sun.com> <464C32A0.4030206@sun.com> <464C88BD.9010400@madplanet.com> <464D691B.3090409@sun.com> <464DCED5.1050604@sun.com> <464DD1D1.50300@madplanet.com> <464DD579.3070904@sun.com> <464DF02A.2090303@madplanet.com> Message-ID: <4651C0F4.1050505@sun.com> Andreas Schaefer wrote: > Michael McMahon wrote: > >> Andreas Schaefer wrote: >> >>> Michael McMahon wrote: >>> >>>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>> >>>>> Andreas Schaefer wrote: >>>>> > Well, the reason I did make it abstract is the fact that I did >>>>> want to >>>>> >>>>>> avoid someone getting away with an empty implementation. This is only >>>>>> causing a problem if someone is compiling its code for 1.7 and so >>>>>> he/she >>>>>> just needs to implement it. Compiling means that he/she has the >>>>>> code and >>>>>> so this is pretty easy fix. Providing an empty implementation is more >>>>>> costly that adding an implementation. >>>>>> >>>>> While breaking source compatibility in a major release ( and jdk 7 >>>>> is a major release ) is acceptable, I think there should be a good >>>>> reason to do so, and I do not believe that there is one in this case. >>>>> >>>>> >>>> This case is probably in a grey area. Normally, the justification >>>> has to be very strong, but >>>> URLConnection and its sub-classes would mostly be considered as part >>>> of the platform rather >>>> than as part of applications. In other words, (as Andy said) there >>>> probably aren't that many >>>> implementations out there. So long as we maintain binary >>>> compatibility for existing applications >>>> using third party URLConnections (assuming there are some) then we >>>> should be ok. >>>> >>>> I think I prefer the method name close() to disconnect() since it >>>> seems to be closer to >>>> what the bug report is asking for. HttpURLConnection.disconnect() is >>>> slightly different >>>> in meaning. >>>> >>>> - Michael. >>>> >>> My idea is that connect() / disconnect() are orthogonal methods >>> meaning that after a disconnect() one can reopen the Connection by >>> issuing another connect() call. Calling it close() would break that >>> linguistically but with the proper documentation it should be fine. >>> >>> -Andy >>> >> One other thing, URLConnections can't be reused. I imagine it could >> lead to all kinds >> of security issues if we tried to support that. They are basically >> immutable in terms >> of the resource that is accessed. I don't think this RFE really needs >> that. What do you think? >> >> - Michael. >> > If that is necessary then it is OK with me. We just must make sure that > nobody can (re)connect throwing an IOException in the connect() method. > The problem is that every sub class that implements connect() must > adhere to it and if they don't then one could still reconnect. > I would suggest that a reconnect is possible except the URLConnection > throws an exception. Glancing at the HttpURLConnection.disconnect() > method I think they do allow reconnects. > > Yes, unfortunately it does, even though the docs for HttpURLConnection explicitly state: "Each HttpURLConnection instance is used to make a single request". There are likely all kind of problems with reusing HttpURLConnection objects because there is a lot of state that doesn't get reset when disconnect() is called. This is another reason why I think we should leave HttpURLConnection.disconnect() well alone, and put the new functionality into a close() method. I think Alan's question is valid, about specifying what happens when one thread calls close() while another thread could be blocked in a read (for example). One way of approaching this, would be to describe what will happen, with your proposed changes, for jar, file and http URLConnection types in that situation and then if the behavior is ok, we can document it that way. - Michael. > -Andy > From richard at kennardconsulting.com Mon May 21 19:48:05 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Tue, 22 May 2007 12:48:05 +1000 Subject: Request for comments: Bug 6306820 Message-ID: <465259E5.7090206@kennardconsulting.com> Alan, Thanks for your continued support. I find the 'static factory method' approach interesting, but I'm a little confused. You cite 'being able to return a subclass' as an advantage. However, you also recommend a private constructor and classes with private constructors can never be subclassed? Regards, Richard. From Alan.Bateman at Sun.COM Tue May 22 01:15:57 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 22 May 2007 09:15:57 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <465259E5.7090206@kennardconsulting.com> References: <465259E5.7090206@kennardconsulting.com> Message-ID: <4652A6BD.6090709@sun.com> Richard Kennard wrote: > Alan, > > Thanks for your continued support. > > I find the 'static factory method' approach interesting, but I'm a > little confused. You cite 'being able to return a subclass' as an > advantage. However, you also recommend a private constructor and > classes with private constructors can never be subclassed? Josh Bloch's Effective Java provides good coverage of this topic if you are interested. In this case the static factory methods that you define will create the UrlQueryString instances and they can return different subtypes if required. This might not be necessary now but in the future there may be differnt standards for encoding parameters and to support that you could add a new static factory method that returns a UrlQueryString that supports that mechanism. If it becomes necessary to return subtypes from other classes in the package then you could make the constructors package-private but for the current proposal it probably isn't necessary. -Alan. From Michael.McMahon at Sun.COM Tue May 22 07:33:40 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Tue, 22 May 2007 15:33:40 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <465259E5.7090206@kennardconsulting.com> References: <465259E5.7090206@kennardconsulting.com> Message-ID: <4652FF44.6020200@sun.com> Richard Kennard wrote: > Alan, > > Thanks for your continued support. > > I find the 'static factory method' approach interesting, but I'm a > little confused. You cite 'being able to return a subclass' as an > advantage. However, you also recommend a private constructor and > classes with private constructors can never be subclassed? > > Regards, > > Richard. > > > Hi Richard, I think one of the design goals for this class was to make sure it is easy to use in JSPs. Do you know if it makes much (or any) difference to JSP applications whether objects are created by constructor or by static factory method. Static factory methods are definitely useful if we think that it might be useful to have different implementation classes in the future, or where there may be important differences in the ways that these objects are created in the future. This can be addressed by using different createXXXX() method names. Also, I believe that there will be some work done in jdk7, which addresses the tagging of factory creation methods more clearly, so they stick out in the documentation a bit more. I also quite like the idea of method chaining, but again that is not a critical question at this point. We should discuss this point definitely, when it comes to finalising the API after the CCC approve the initial proposal. The main question I think is concerning the mutabilty of the object and whether to expose the implementation map. Clearly, the object has to be mutable, and it probably needs to be specified as being unsynchronized. I think I agree with Alan about the danger of exposing the internal map. Even if it does not cause a problem initially, it could seriously restrict how the class develops in the future. - Michael. From richard at kennardconsulting.com Tue May 22 18:07:47 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Wed, 23 May 2007 11:07:47 +1000 Subject: Request for comments: Bug 6306820 Message-ID: <465393E3.10208@kennardconsulting.com> Michael, >Do you know if it makes much (or any) difference to JSP applications >whether objects are created by constructor or by static factory method. Not really. A lot of the focus on JSPs has already gone from this class (since we moved it from URIBuilder to URIQueryString). It will now mainly be applicable 'behind the scenes' (eg. when implementing JSP tag libraries like c:url) > Static factory methods are definitely useful Agreed. Alan has clarified them a bit for me so I'll go ahead and make those changes. > I also quite like the idea of method chaining Me too, but my main concern is that it isn't in the 'spirit' of the rest of the JDK? Is method chaining used anywhere else? > The main question I think is ... whether to expose the implementation map. The reason I did this was because there were a number of useful scenarios from the original URIBuilder such as... 1. stripping out parameters with certain names, like jsession_id and j_username 2. stripping out parameters with certain values, like empty strings and zeros ...but we agreed these were overkill for many purposes. I was comfortable removing these scenerios only because, by exposing the internal Map via getParameterMap, advanced users could easily 'roll their own'. So, if we don't expose the internal Map we limit these scenerios. An alternative approach would be to expose a COPY of the internal Map, let the user modify it, and then introduce a setParameterMap method to re-set it. However, the problem there is that, internally, it is important the Map is a LinkedHashMap - so that it maintains the ordering of parameters. At the moment, however, getParameterMap simply returns a Map (eg. it doesn't worry the user with what sort of Map). However, setParameterMap would not have this luxury: it would have to be setParameterMap( LinkedHashMap ). So I guess it comes down to what seems less messy? Exposing the internal Map, or exposing the fact that it is a LinkedHashMap? Regards, Richard. From Alan.Bateman at Sun.COM Wed May 23 01:26:56 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 23 May 2007 09:26:56 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <465393E3.10208@kennardconsulting.com> References: <465393E3.10208@kennardconsulting.com> Message-ID: <4653FAD0.50203@sun.com> Richard Kennard wrote: > : > An alternative approach would be to expose a COPY of the internal Map, > let the user modify it, and then introduce a setParameterMap method to > re-set it. However, the problem there is that, internally, it is > important the Map is a LinkedHashMap - so that it maintains the > ordering of parameters. At the moment, however, getParameterMap simply > returns a Map (eg. it doesn't worry the user with what sort of Map). > > However, setParameterMap would not have this luxury: it would have to > be setParameterMap( LinkedHashMap ). > > So I guess it comes down to what seems less messy? Exposing the > internal Map, or exposing the fact that it is a LinkedHashMap? > Yes, a copy is important as you don't want to hand out a reference to the LinkedHashMap used in the representation (this would create too many problems and probably prevent you from changing the internal representation in the future). In the spec you can say that the iteration order of the returned map corresponds to the parameter ordering. For ease-of-use the returned map can be modifiable. To allow construction of a UrlQueryString then you can include a create method that takes a Map as a parameter. The parameter need not be a LinkedHashMap. In the spec for this method you can make it clear that the ordering of parameters depends on the map iteration order. If someone invokes toMap (or whatever you call it) and then creates a new UrlQueryString then it do what you expect as the iteration order of the exported map is predictable. -Alan. From betelgeuse at gentoo.org Thu May 24 11:28:24 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Thu, 24 May 2007 21:28:24 +0300 Subject: [Fwd: Re: Fixing compiler warnings] Message-ID: <4655D948.3000201@gentoo.org> Next stop: net-dev. -------- Alkuper?inen viesti / Orig.Msg. -------- Aihe: Re: Fixing compiler warnings P?iv?ys: Thu, 24 May 2007 18:55:39 +0100 L?hett?j?: Alan Bateman Vastaanottaja: Petteri R?ty CC: core-libs-dev at openjdk.java.net Viittaukset: <4655C7ED.9010807 at gentoo.org> Petteri R?ty wrote: > This silences some QA warnings given by GCC. I don't have access to > Solaris so it would probably be safest to test there before committing > although man gettimeofday is claiming that the function is quite standard: > > CONFORMING TO > SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not > settimeofday(). > > I haven't signed the SCA but this is hardly copyrightable. > > Regards, > Petteri > -- > Gentoo/Java project lead > Petteri - the networking libraries is the net-dev at openjdk.java.net mailing list so I would suggest posting the patch to that list. -Alan. -------------- next part -------------- A non-text attachment was scrubbed... Name: gettimeofday-declaration.patch Type: text/x-patch Size: 2001 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070524/a8091ef2/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070524/a8091ef2/attachment-0001.bin From richard at kennardconsulting.com Fri May 25 16:41:03 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Sat, 26 May 2007 09:41:03 +1000 Subject: Request for comments: Bug 6306820 Message-ID: <4657740F.7050701@kennardconsulting.com> Dear All, Please find the latest version of URLEncodedQueryString at... https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20098&forumID=1463 Changes include: 1. Static factory methods and a private constructor 2. getParameterMap returns a copy of the Map 3. Method chaining is used 4. Now mentions thread safety in the JavaDoc 5. Now mentions use of URLEncoder/URLDecoder in the JavaDoc 6. No longer Serializable Unit tests and coverage reports are included. Note I have not: 1. Changed the name of 'getParameterMap' to 'toMap', because I am trying to follow the javax.servlet.ServletRequest convention? 2. Shortened the names of 'setParameter' and 'appendParameter'. This is because the name 'getParameter' follows javax.servlet.ServletRequest? 3. Changed the use of an enum for 'ParameterSeparator'. This is because the enum reflects the list of recommended separators in the spec? 4. Moved 'apply' out into java.net.URI. This is because we would also need to update java.net.URL, and I'm not sure if that's what you wanted? Thanks again for all your help, and I look forward to hearing from you, Richard. From richard at kennardconsulting.com Sat May 26 15:24:41 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Sun, 27 May 2007 08:24:41 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <465861EB.3010903@sun.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> Message-ID: <4658B3A9.9050204@kennardconsulting.com> Alan, I read some distinct 'themes' into your last e-mail. Please permit me to respond to the 'themes', rather than your exact points: 1. java.net.URL You said: 'I would suggest ignoring java.net.URL completely... is parse(URL) needed? ... is apply(URL) needed? ... I believe naming conventions would suggest this be should Url* instead' I actually encounter java.net.URL quite often in my daily work - many APIs seem to use it, and don't seem to offer a java.net.URI alternative? I think it is still quite active and shouldn't be ignored? 2. Servlet API You said: 'it's not clear to me why any of the method names need the word "Parameter" in them... It's not clear to me that we have to be consistent with the Servlet API.' I think consistency with the Servlet API is important because it is the only example in the JDK (well, Java EE DK) of an API that deals specifically with www-form-urlencoded query strings: it is mature and very familiar to many developers? It also has some naming quirks around returning String versus String[] for getParameter and getParameterValues. Those quirks are the necessary because of the HTML spec, so I'd rather match the Servlet API's naming quirks than introduce a brand of quirks of our own? 3. Separators You said: 'Is this enum needed? ... maybe the create method can specify the separator? ... what if [the query string to be parsed] uses a different separator? ... Do you have examples in mind where a query would be parsed using one separator but then converted to use a different separator? I'm afraid I thought I'd explained this already? It's also in the JavaDoc: "ALL separators are recognised when parsing query strings. ONE separator may be passed to 'getQuery' and 'apply' when outputting query strings" I agree on your point around removing 'getQuery' and just having 'toString'. Regards, Richard. From Alan.Bateman at Sun.COM Sun May 27 03:27:49 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 27 May 2007 11:27:49 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <4658B3A9.9050204@kennardconsulting.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> Message-ID: <46595D25.4050902@sun.com> Richard Kennard wrote: > Alan, > > I read some distinct 'themes' into your last e-mail. Please permit me > to respond to the 'themes', rather than your exact points: > > 1. java.net.URL > > You said: > > 'I would suggest ignoring java.net.URL completely... is parse(URL) > needed? ... is apply(URL) needed? ... I believe naming conventions > would suggest this be should Url* instead' > > I actually encounter java.net.URL quite often in my daily work - many > APIs seem to use it, and don't seem to offer a java.net.URI > alternative? I think it is still quite active and shouldn't be ignored? You've pulled comments from different contexts here but no matter. The URL class has many problems and unfortunately they cannot be fixed for compatibility reasons. This is why the spec has a recommendation to use URI over URL. There are toURL and toURI methods to convert between the classes. We should encourage developers to use URI for new code (and I agree there is a large body of existing code that uses URL). For the static factory methods that construct the object by parsing an existing query string then you a number of choices. The proposed parse(CharSequence) looks good to me. If there is code using java.net.URL then it can be simply invoked using parse(url.getQuery()) and I don't see a problem with that. There is more argument for a parse(URI) method as developers can get confused as to if the query component, in string form, should be decoded or not. The "apply" methods could benefit from some discussion. As I mentioned, it may be worth seeing if we should have more general methods to construct URIs by combining an existing URI and other components. Michael may have views on this. As regards the name of the class, then Josh Bloch's Effective Java book has a good section on this. To follow those guidelines the class would be named UrlEncodedQueryString rather than URLEncodedQueryString. I just mention it as something to think about (and yes, we have lots of naming inconsistencies in the platform). > > 2. Servlet API > > You said: > > 'it's not clear to me why any of the method names need the word > "Parameter" in them... It's not clear to me that we have to be > consistent with the Servlet API.' > > I think consistency with the Servlet API is important because it is > the only example in the JDK (well, Java EE DK) of an API that deals > specifically with www-form-urlencoded query strings: it is mature and > very familiar to many developers? > > It also has some naming quirks around returning String versus String[] > for getParameter and getParameterValues. Those quirks are the > necessary because of the HTML spec, so I'd rather match the Servlet > API's naming quirks than introduce a brand of quirks of our own? My only concern with copying the method names from the Servlet spec is that it makes it awkward when constructing one of these objects by chaining a sequence of method invocations. If the method names are shorter then the syntax can be neater, eg: UrlQueryString qs = UrlQueryString().create().set(n1,v1).set(n2,v2); works well in my mind. Whether the map value is String[] or List isn't a major issue. I just suggested thinking about List as it may be more useful in the long term. > > 3. Separators > > You said: > > 'Is this enum needed? ... maybe the create method can specify the > separator? ... what if [the query string to be parsed] uses a > different separator? ... Do you have examples in mind where a query > would be parsed using one separator but then converted to use a > different separator? > > I'm afraid I thought I'd explained this already? It's also in the > JavaDoc: > > "ALL separators are recognised when parsing query strings. ONE > separator may be passed to 'getQuery' and 'apply' when outputting > query strings" Ah, those words are in the spec for the ParameterSeparator enum and so didn't appear in the javadoc that you appended. In that case, I would suggest making this clear in the spec for the parse spec. Should the parse spec also say anything about the non-default separators - if they can appear in values then I assume they must be escaped prior to parsing > > I agree on your point around removing 'getQuery' and just having > 'toString'. Did you decide on the method to construct a string with the non-default separator? Naming it toString(seperator) would be consistent. -Alan. From Yujiang.Wang at Sun.COM Mon May 28 01:56:40 2007 From: Yujiang.Wang at Sun.COM (Edward Wang) Date: Mon, 28 May 2007 16:56:40 +0800 Subject: [Fwd: Re: Fixing compiler warnings] In-Reply-To: <4655D948.3000201@gentoo.org> References: <4655D948.3000201@gentoo.org> Message-ID: <465A9948.9070907@sun.com> Hi Petteri, Yes, we'd better to fix this. It is a straightforward one. A new CR, 6562614, has been filed against this. You could check it in bugs.sun.com. And now I need to figure out how to go through internal process before I could finally put back the code on your behave. Will keep you posted. Best regards, Edward Petteri R?ty wrote: > Next stop: net-dev. > > -------- Alkuper?inen viesti / Orig.Msg. -------- > Aihe: Re: Fixing compiler warnings > P?iv?ys: Thu, 24 May 2007 18:55:39 +0100 > L?hett?j?: Alan Bateman > Vastaanottaja: Petteri R?ty > CC: core-libs-dev at openjdk.java.net > Viittaukset: <4655C7ED.9010807 at gentoo.org> > > Petteri R?ty wrote: >> This silences some QA warnings given by GCC. I don't have access to >> Solaris so it would probably be safest to test there before committing >> although man gettimeofday is claiming that the function is quite standard: >> >> CONFORMING TO >> SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not >> settimeofday(). >> >> I haven't signed the SCA but this is hardly copyrightable. >> >> Regards, >> Petteri >> -- >> Gentoo/Java project lead >> > Petteri - the networking libraries is the net-dev at openjdk.java.net > mailing list so I would suggest posting the patch to that list. > > -Alan. > > From richard at kennardconsulting.com Mon May 28 03:17:21 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Mon, 28 May 2007 20:17:21 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <46595D25.4050902@sun.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> <46595D25.4050902@sun.com> Message-ID: <465AAC31.4070308@kennardconsulting.com> Alan, Thanks for sticking with me - your comments and support have definitely improved my code, and I am grateful to you as a result. I have updated the version at... https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20129&forumID=1463 ...to include: a) toString(ParameterSeparator) b) Better JavaDoc around the 'parse' methods for ParameterSeparator What we have left appear to be some fairly small details. If I may summarise, you are saying... 1) java.net.URL is discouraged, therefore we shouldn't support it in our API nor follow its naming convention (even though we'll sit alongside it in the java.net package) 2) We should move the 'apply' method into java.net.URI 3) Keeping the method names familiar to javax.servlet.ServletRequest developers is less important than neatness of code during method chaining I'm happy either way on 1 and 2, though I disagree with you on 3, but none of these seem like they should be major obstacles to CCC approval? With your permission, then, I'd like to leave them to the larger consensus? Regards, Richard. From Michael.McMahon at Sun.COM Mon May 28 09:46:30 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 28 May 2007 17:46:30 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <465AAC31.4070308@kennardconsulting.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> <46595D25.4050902@sun.com> <465AAC31.4070308@kennardconsulting.com> Message-ID: <465B0766.5050205@sun.com> Richard Kennard wrote: > What we have left appear to be some fairly small details. If I may > summarise, you are saying... > Yes, I think that is true. > 1) java.net.URL is discouraged, therefore we shouldn't support it in > our API nor follow its naming convention (even though we'll sit > alongside it in the java.net package) I would agree with Alan on this. The problem with java.net.URL is that it contains a lot of legacy behavior which we cannot touch, much of which is contrary to the RFC specification for URIs. The more people are encouraged to use it, the more they will encounter these problems, and complain about them. URI on the other hand, was designed from the start to behave correctly with respect to the URI RFC, so the developers should be encouraged to use it, instead of URL. > 2) We should move the 'apply' method into java.net.URI In my view, apply() is fine where it is in this class. > 3) Keeping the method names familiar to javax.servlet.ServletRequest > developers is less important than neatness of code during method chaining > Again, and I suppose we are both coming from a Java SE perspective, but I would concur with Alan on this. I don't see a compelling reason to use excessively long method names, just to remain compatible with the servlet spec. This is a new API, and arguably there is no harm at all in looking a bit different from the servlet spec. We can defer the question though, if you feel particularly strongly about it. > I'm happy either way on 1 and 2, though I disagree with you on 3, but > none of these seem like they should be major obstacles to CCC > approval? With your permission, then, I'd like to leave them to the > larger consensus? > I just have a couple more questions to ask relating to encoding and interpretation of '&' and ';' What if a string to be parsed uses ';' as separator, but contains '&' chars embedded within it, which are not to be interpreted as separators? If this situation could arise, would we then need a variant of parse() which takes a Separator char and then only uses that char as the separator? I think the docs should explicitly state that UTF-8 is the default character set used, which leads to another question. Should we have the possibility to specify the character set, perhaps in the toString() method? In my experience, in some parts of the world, particularly Asia, other character sets are often used for web applications. > Regards, > > Richard. > From richard at kennardconsulting.com Mon May 28 15:51:24 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Tue, 29 May 2007 08:51:24 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <465B0766.5050205@sun.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> <46595D25.4050902@sun.com> <465AAC31.4070308@kennardconsulting.com> <465B0766.5050205@sun.com> Message-ID: <465B5CEC.2060307@kennardconsulting.com> Michael, >> 1) java.net.URL is discouraged... I would agree with Alan on this. Fair enough: I shall remove those methods. Can you confirm you want the naming convention changed to Url? It's just that everything else in the package uses uppercase URL (for legacy reasons, I'm sure). Note that the class is called URLEncodedQueryString because it models a 'www-form-urlencoded' query string, not because of the java.net.URL class. > What if a string to be parsed uses ';' as separator, but contains '&' chars embedded within it, > which are not to be interpreted as separators? When parsing, ALL separators are recognised. So if a string contains a mix of ';' and '&' both will be recognised. You do not specify the separator to use at parsing time - only at toString() time. > Should we have the possibility to specify the character set, perhaps > in the toString() method? In my experience, in some parts of the world, particularly Asia, > other character sets are often used for web applications. Earlier versions of URIBuilder did this, but either Alan or yourself thought it complicated matters too much. The HTML spec's recommendation is UTF-8... http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars ...note that this only applies to URIs - it is a quite separate issue than what character set is used on the HTML page. Regards, Richard. From Yujiang.Wang at Sun.COM Mon May 28 19:20:16 2007 From: Yujiang.Wang at Sun.COM (Edward Wang) Date: Tue, 29 May 2007 10:20:16 +0800 Subject: [Fwd: Re: Fixing compiler warnings] In-Reply-To: <465A9948.9070907@sun.com> References: <4655D948.3000201@gentoo.org> <465A9948.9070907@sun.com> Message-ID: <465B8DE0.5000004@sun.com> Hi Petteri, Two things. One is that seems 6562614 still doesn't show up in bugs.sun.com. I guess it's still on its way from our internal bug database to public one. You could check it later on. The other is that I encourage you to sign SCA. Then I can incorporate your code into OpenJDK code base. Here is how to do it: http://openjdk.java.net/contribute/ It should be simple enough. Thank you for your participation in improving Java technology and we look forward to hearing back from you. Best regards, Edward Edward Wang wrote: > Hi Petteri, > > Yes, we'd better to fix this. It is a straightforward one. A new CR, > 6562614, has been filed against this. You could check it in bugs.sun.com. > > And now I need to figure out how to go through internal process before I > could finally put back the code on your behave. Will keep you posted. > > Best regards, > Edward > > Petteri R?ty wrote: >> Next stop: net-dev. >> >> -------- Alkuper?inen viesti / Orig.Msg. -------- >> Aihe: Re: Fixing compiler warnings >> P?iv?ys: Thu, 24 May 2007 18:55:39 +0100 >> L?hett?j?: Alan Bateman >> Vastaanottaja: Petteri R?ty >> CC: core-libs-dev at openjdk.java.net >> Viittaukset: <4655C7ED.9010807 at gentoo.org> >> >> Petteri R?ty wrote: >>> This silences some QA warnings given by GCC. I don't have access to >>> Solaris so it would probably be safest to test there before committing >>> although man gettimeofday is claiming that the function is quite >>> standard: >>> >>> CONFORMING TO >>> SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not >>> settimeofday(). >>> >>> I haven't signed the SCA but this is hardly copyrightable. >>> >>> Regards, >>> Petteri >>> -- >>> Gentoo/Java project lead >>> >> Petteri - the networking libraries is the net-dev at openjdk.java.net >> mailing list so I would suggest posting the patch to that list. >> >> -Alan. >> >> > From betelgeuse at gentoo.org Tue May 29 00:26:54 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Tue, 29 May 2007 10:26:54 +0300 Subject: [Fwd: Re: Fixing compiler warnings] In-Reply-To: <465B8DE0.5000004@sun.com> References: <4655D948.3000201@gentoo.org> <465A9948.9070907@sun.com> <465B8DE0.5000004@sun.com> Message-ID: <465BD5BE.6080805@gentoo.org> Edward Wang kirjoitti: > The other is that I encourage you to sign SCA. Then I can incorporate > your code into OpenJDK code base. Here is how to do it: > http://openjdk.java.net/contribute/ > It should be simple enough. > I can look into if it's really want it but afaick it's the FSF policy that these kinds of things are not copyrightable and as such I have contributed many patches to their projects without signing any legal papers with them. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070529/2b6d72b0/attachment.bin From Michael.McMahon at Sun.COM Tue May 29 01:57:58 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Tue, 29 May 2007 09:57:58 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <465B5CEC.2060307@kennardconsulting.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> <46595D25.4050902@sun.com> <465AAC31.4070308@kennardconsulting.com> <465B0766.5050205@sun.com> <465B5CEC.2060307@kennardconsulting.com> Message-ID: <465BEB16.9040204@sun.com> Richard Kennard wrote: > Michael, > > >> 1) java.net.URL is discouraged... I would agree with Alan on this. > > Fair enough: I shall remove those methods. > > Can you confirm you want the naming convention changed to Url? It's > just that everything else in the package uses uppercase URL (for > legacy reasons, I'm sure). Note that the class is called > URLEncodedQueryString because it models a 'www-form-urlencoded' query > string, not because of the java.net.URL class. > Url does seem to fit the new conventions better. It is also more readable in my opinion. > > What if a string to be parsed uses ';' as separator, but contains > '&' chars embedded within it, > > which are not to be interpreted as separators? > > When parsing, ALL separators are recognised. So if a string contains a > mix of ';' and '&' both will be recognised. You do not specify the > separator to use at parsing time - only at toString() time. > So, this means that an '&' embedded in a parameter could not be recognised when parsing, but it would be recognised if added through one of the add parameter methods (in the latter case, it would get encoded into %xy). This sounds wrong to me. I'm not saying we shouldn't allow the parsing that you describe above, but just that it should be possible somehow to do a "roundtrip" of constructing a query piece by piece, outputting the string, and then parsing the string again later, back into the same query object. All that's needed is an additional parse() method which specifies the separator char. BTW, I meant to also suggest shortening the ParameterSeparator name to just Separator. > > Should we have the possibility to specify the character set, perhaps > > in the toString() method? In my experience, in some parts of the > world, particularly Asia, > > other character sets are often used for web applications. > > Earlier versions of URIBuilder did this, but either Alan or yourself > thought it complicated matters too much. The HTML spec's > recommendation is UTF-8... > > http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars > > ...note that this only applies to URIs - it is a quite separate issue > than what character set is used on the HTML page. > Yes, I suppose that is consistent with the URI spec as well. But the apidocs should state that UTF-8 is used in order to avoid any doubt. Thanks Michael From richard at kennardconsulting.com Tue May 29 02:57:44 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Tue, 29 May 2007 19:57:44 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <465BEB16.9040204@sun.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> <46595D25.4050902@sun.com> <465AAC31.4070308@kennardconsulting.com> <465B0766.5050205@sun.com> <465B5CEC.2060307@kennardconsulting.com> <465BEB16.9040204@sun.com> Message-ID: <465BF918.3080404@kennardconsulting.com> Michael, I just thought I'd tackle this point in detail... > So, this means that an '&' embedded in a parameter could not be > recognised when parsing I don't think you can have an 'embedded & in a parameter' in any meaningful sense. You'd have to encode it (as %26) or else it would be recognised as a separator by Web browsers and servers, regardless of whether you used semicolons for the rest of the URL. To me, the HTML spec doesn't imply 'if you use one separator then the other separator should be considered a normal character' - it just says 'ampersands and semicolons are separator characters'. > through one of the add parameter methods... it would get encoded into > %xy. This sounds wrong to me. I don't think it should sound wrong: the 'parse' methods parse an encoded String, the 'add' methods deal with unencoded Strings (and Numbers). > it should be possible somehow to do a "roundtrip" of constructing a > query piece by piece, outputting > the string, and then parsing the string again later, back into the > same query object. Here we agree! And with the current version of the code, this works... URLEncodedQueryString queryString = URLEncodedQueryString.create(); queryString.setParameter( "a", "x&y" ); queryString.setParameter( "b", "u;v" ); assertTrue( "a=x%26y&b=u%3Bv".equals( queryString.toString() )); queryString = URLEncodedQueryString.parse( queryString.toString() ); assertTrue( "x&y".equals( queryString.getParameter( "a" ))); assertTrue( "u;v".equals( queryString.getParameter( "b" ))); ...is that what you were suggesting? > All that's needed is an additional parse() method which specifies the > separator char. Again, the HTML spec doesn't say 'when one character is the separator char then the others are normal characters', so I don't see how you can specify a single separator char? If we can get this cleared up I'll post the new version of the class (renamed to use Url instead of URL). Regards, Richard. From Michael.McMahon at Sun.COM Tue May 29 06:56:00 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Tue, 29 May 2007 14:56:00 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <465BF918.3080404@kennardconsulting.com> References: <4656ABF0.3010908@kennardconsulting.com> <465861EB.3010903@sun.com> <4658B3A9.9050204@kennardconsulting.com> <46595D25.4050902@sun.com> <465AAC31.4070308@kennardconsulting.com> <465B0766.5050205@sun.com> <465B5CEC.2060307@kennardconsulting.com> <465BEB16.9040204@sun.com> <465BF918.3080404@kennardconsulting.com> Message-ID: <465C30F0.4070407@sun.com> Richard Kennard wrote: > Michael, > > I just thought I'd tackle this point in detail... > Here we agree! And with the current version of the code, this works... > > URLEncodedQueryString queryString = > URLEncodedQueryString.create(); > queryString.setParameter( "a", "x&y" ); > queryString.setParameter( "b", "u;v" ); > assertTrue( "a=x%26y&b=u%3Bv".equals( > queryString.toString() )); > queryString = URLEncodedQueryString.parse( > queryString.toString() ); > assertTrue( "x&y".equals( queryString.getParameter( "a" ))); > assertTrue( "u;v".equals( queryString.getParameter( "b" ))); > > ...is that what you were suggesting? > That's fine then. So long as the whole thing is fully consistent, I'm ok with it. >> All that's needed is an additional parse() method which specifies the >> separator char. > Again, the HTML spec doesn't say 'when one character is the separator > char then the others are normal characters', so I don't see how you > can specify a single separator char? > > If we can get this cleared up I'll post the new version of the class > (renamed to use Url instead of URL). > Good. Still haven't heard back from the CCC, but I will update the request with your next API version anyway. Thanks Michael From Yujiang.Wang at Sun.COM Wed May 30 02:36:17 2007 From: Yujiang.Wang at Sun.COM (Edward Wang) Date: Wed, 30 May 2007 17:36:17 +0800 Subject: [Fwd: Re: Fixing compiler warnings] In-Reply-To: <465BD5BE.6080805@gentoo.org> References: <4655D948.3000201@gentoo.org> <465A9948.9070907@sun.com> <465B8DE0.5000004@sun.com> <465BD5BE.6080805@gentoo.org> Message-ID: <465D4591.8050000@sun.com> Petteri R?ty wrote: > Edward Wang kirjoitti: >> The other is that I encourage you to sign SCA. Then I can incorporate >> your code into OpenJDK code base. Here is how to do it: >> http://openjdk.java.net/contribute/ >> It should be simple enough. >> > > I can look into if it's really want it but afaick it's the FSF policy > that these kinds of things are not copyrightable and as such I have > contributed many patches to their projects without signing any legal > papers with them. Hi Petteri, The information I got so far all say you need to sign an SCA. It may seem overkilled for a simple fix like this. Please look it this way - you just need to do it once and it will make your future contributions easier. Hope you can agree with me here ;-) About SCA, here is how to sign one: http://openjdk.java.net/contribute/ And you can check approved SCAs here: http://www.sunsource.net/CA_signatories Best regards, Edward From dcoleman at chariotsolutions.com Thu May 31 20:50:01 2007 From: dcoleman at chariotsolutions.com (Don Coleman) Date: Thu, 31 May 2007 23:50:01 -0400 Subject: TTL ignored when sending Multicast UDP Datagram to IPv4 address via IPv6 socket Message-ID: <32870f240705312050pd0554e8k30782ba6ed5c431f@mail.gmail.com> I'm have a problem setting TTL when sending Multicast packets to an IPv4 address over an IPv6 socket. Setting the TTL in Java has no effect when sending to an IPv4 address. It is always 1. This is only a problem on Linux, it works fine on OS X, Solaris and Windows. This problem exists with JDK5, but it looks like it's also in the JDK7 code. https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/j2se/src/solaris/native/java/net/PlainDatagramSocketImpl.c?annotate=237 on line 1873 IPV6_MULTICAST_HOPS is set for Linux I think we need also need to set IP_MULTICAST_TTL I've attached sample Java and C code that demonstrates the problem here https://bugs.launchpad.net/ubuntu/+bug/112257 Any thoughts if this is a Java problem or a Linux kernel bug?