From Alan.Bateman at Sun.COM Fri Jun 1 00:20:31 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 01 Jun 2007 08:20:31 +0100 Subject: TTL ignored when sending Multicast UDP Datagram to IPv4 address via IPv6 socket In-Reply-To: <32870f240705312050pd0554e8k30782ba6ed5c431f@mail.gmail.com> References: <32870f240705312050pd0554e8k30782ba6ed5c431f@mail.gmail.com> Message-ID: <465FC8BF.4060808@sun.com> Don Coleman wrote: > 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? The bug tracking this one is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250763 At least in older kernels, it wasn't possible to set IPv4 multicast options on IPv6 sockets (the setsockopt would fail). Edward Wang has been testing with recent kernels and has results that suggest that setting the IPv4 options work now. I believe he has a fix/patch in the works to address this (Edward - can you comment?). If you need a workaround then run with -Djava.net.preferIPv4Stack=true so that all sockets are IPv4 (even if the machine has IPv6 enabled). -Alan. From richard at kennardconsulting.com Fri Jun 1 00:57:04 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Fri, 01 Jun 2007 17:57:04 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <465C30F0.4070407@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> <465BF918.3080404@kennardconsulting.com> <465C30F0.4070407@sun.com> Message-ID: <465FD150.9080702@kennardconsulting.com> Michael, Alan, Please find a new version of UrlEncodedQueryString up at: https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20206&forumID=1463 Changes include: 1. Renamed to UrlEncodedQueryString instead of URLEncodedQueryString 2. Removed use of java.net.URL 3. Renamed ParameterSeparator enum to Separator 4. Changed toString to never return null, only an empty String I hope this means we can get it through the CCC in time for its two year anniversary :) Regards, Richard. From robilad at kaffe.org Fri Jun 1 01:30:07 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 1 Jun 2007 08:30:07 +0000 (UTC) Subject: Request for comments: Bug 6306820 References: <4657740F.7050701@kennardconsulting.com> Message-ID: Richard Kennard writes: > > Dear All, > > Please find the latest version of URLEncodedQueryString at... > > > https://jdk-collaboration.dev.java.net/ [snip] > Thanks again for all your help, and I look forward to hearing from you, Hi Richard, a small meta-comment: URLs to the jdk-collaboration site will only be visible to members of that project, i.e. not to all OpenJDK developers. cheers, dalibor topic From dcoleman at chariotsolutions.com Fri Jun 1 09:15:13 2007 From: dcoleman at chariotsolutions.com (Don Coleman) Date: Fri, 1 Jun 2007 12:15:13 -0400 Subject: TTL ignored when sending Multicast UDP Datagram to IPv4 address via IPv6 socket In-Reply-To: <465FC8BF.4060808@sun.com> References: <32870f240705312050pd0554e8k30782ba6ed5c431f@mail.gmail.com> <465FC8BF.4060808@sun.com> Message-ID: <32870f240706010915t23342ee8k68a839c59f501737@mail.gmail.com> -Djava.net.preferIPv4Stack=true works fine for IPv4, but my application needs to send both IPv4 and IPv6. I'd be interested to see Edward Wang's patch for this issue. On 6/1/07, Alan Bateman wrote: > Don Coleman wrote: > > 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? > The bug tracking this one is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250763 > > At least in older kernels, it wasn't possible to set IPv4 multicast > options on IPv6 sockets (the setsockopt would fail). Edward Wang has > been testing with recent kernels and has results that suggest that > setting the IPv4 options work now. I believe he has a fix/patch in the > works to address this (Edward - can you comment?). > > If you need a workaround then run with -Djava.net.preferIPv4Stack=true > so that all sockets are IPv4 (even if the machine has IPv6 enabled). > > -Alan. > > > > > > > > > > > From richard at kennardconsulting.com Fri Jun 1 16:00:11 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Sat, 02 Jun 2007 09:00:11 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: References: <4657740F.7050701@kennardconsulting.com> Message-ID: <4660A4FB.4000706@kennardconsulting.com> Dalibor, Fair point. I am only following the original advice of the Peabody initiative to use http://jdk-collaboration, and the more recent advice of the OpenJDK project to use the net-dev mailing list. If there is a new preference I am happy to switch to that? Richard. Dalibor Topic wrote: > Richard Kennard writes: > > >> Dear All, >> >> Please find the latest version of URLEncodedQueryString at... >> >> >> >> > https://jdk-collaboration.dev.java.net/ > > [snip] > > >> Thanks again for all your help, and I look forward to hearing from you, >> > > Hi Richard, > > a small meta-comment: URLs to the jdk-collaboration site will only be visible to > members of that project, i.e. not to all OpenJDK developers. > > cheers, > dalibor topic > > > > From Yujiang.Wang at Sun.COM Sun Jun 3 19:42:55 2007 From: Yujiang.Wang at Sun.COM (Edward Wang) Date: Mon, 04 Jun 2007 10:42:55 +0800 Subject: TTL ignored when sending Multicast UDP Datagram to IPv4 address via IPv6 socket In-Reply-To: <32870f240706010915t23342ee8k68a839c59f501737@mail.gmail.com> References: <32870f240705312050pd0554e8k30782ba6ed5c431f@mail.gmail.com> <465FC8BF.4060808@sun.com> <32870f240706010915t23342ee8k68a839c59f501737@mail.gmail.com> Message-ID: <46637C2F.30109@sun.com> Hi Don, Yes, in recent kernels (2.6.*), both IPv4 and IPv6 socket options can be set for an IPv6 socket. And seems setting both of them is the only way to make things like TTL/HOP_LIMIT works properly as expected. Only that I still need to do more testing for different kernel versions. Hope I can integrate the patch soon. -Edward Don Coleman wrote: > -Djava.net.preferIPv4Stack=true works fine for IPv4, but my > application needs to send both IPv4 and IPv6. > > I'd be interested to see Edward Wang's patch for this issue. > > On 6/1/07, Alan Bateman wrote: >> Don Coleman wrote: >> > 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? >> The bug tracking this one is: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250763 >> >> At least in older kernels, it wasn't possible to set IPv4 multicast >> options on IPv6 sockets (the setsockopt would fail). Edward Wang has >> been testing with recent kernels and has results that suggest that >> setting the IPv4 options work now. I believe he has a fix/patch in the >> works to address this (Edward - can you comment?). >> >> If you need a workaround then run with -Djava.net.preferIPv4Stack=true >> so that all sockets are IPv4 (even if the machine has IPv6 enabled). >> >> -Alan. >> >> >> >> >> >> >> >> >> >> >> From robilad at kaffe.org Tue Jun 5 01:58:45 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 5 Jun 2007 08:58:45 +0000 (UTC) Subject: Request for comments: Bug 6306820 References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> Message-ID: Richard Kennard writes: > > Dalibor, > > Fair point. I am only following the original advice of the Peabody > initiative to use http://jdk-collaboration, and the more recent advice > of the OpenJDK project to use the net-dev mailing list. > > If there is a new preference I am happy to switch to that? No need to switch, if that works for you. But for the benefit of others who would be interested in following the discussion along with the code, I'd suggest posting the patches as unified diffs attached to your RFCs. cheers, dalibor topic From hansmann.d at debitel.net Wed Jun 13 06:46:23 2007 From: hansmann.d at debitel.net (David Hansmann) Date: Wed, 13 Jun 2007 15:46:23 +0200 Subject: JDK FTP support Message-ID: <466FF52F.8020200@debitel.net> Hi all, I recently looked at openjdk.java.net and found that there doesn't seem to be a fixed plan to integrate full FTP support (I'm referring to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4650689 ), so I wonder if you might be interested to use parts of my FTP API located on http://j-ftp.sourceforge.net . It is part of a file transfer client which supports FTP using an API which I wrote and which has been tested for quite some time now, SFTP (throug j2ssh or jsch), JCIFS (through JCIFS) and NFS (through Sun WebNFS) using a common interface. Although the code may not be state-of-the art (no generics yet) the core classes are very small, easy to refactor, not very complicated in general and there are various of the features you mentioned already present (like one control connection for multiple downloads, callbacks) and more. It should for example be possible to to use the other APIs as plugins once this would be implemented so those other protocols could be used by just placing the jars anywhere in the classpath. I'd of course help with the developement, code cleanup, testing and support if anybody wants to give it a try - it would be really exiting to contribute to the JDK especially because I started the project years ago because of the lack of a real (and OSS) java FTP API ;) Greetings and thanks for your time, David Hansmann P.S.: If you want to take a look at the code you probably want to look at net/FtpConnection, the BasicConnection interface and the example code in the doc/-directory. From Alan.Bateman at Sun.COM Wed Jun 13 07:16:39 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 13 Jun 2007 15:16:39 +0100 Subject: JDK FTP support In-Reply-To: <466FF52F.8020200@debitel.net> References: <466FF52F.8020200@debitel.net> Message-ID: <466FFC47.400@sun.com> David Hansmann wrote: > Hi all, > > I recently looked at openjdk.java.net and found that there doesn't > seem to be a fixed plan to integrate full FTP support > (I'm referring to > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4650689 ) You should probably talk to Jean-Christophe Collet as he has been thinking about this one aswell: http://blogs.sun.com/jcc/entry/spring_cleaning -Alan. From Jean-Christophe.Collet at Sun.COM Thu Jun 14 04:55:53 2007 From: Jean-Christophe.Collet at Sun.COM (Jean-Christophe Collet) Date: Thu, 14 Jun 2007 13:55:53 +0200 Subject: JDK FTP support In-Reply-To: <466FF52F.8020200@debitel.net> References: <466FF52F.8020200@debitel.net> Message-ID: <46712CC9.5000104@sun.com> Thank you for proposition, we certainly will take a look a all that. That being said, the FTP Client API project is in a unusual state. You see, as a pointed numerous times, we do have an API already, even if it's a rather incomplete and not flexible one. Which leads to 2 issues: 1) Any new FTP API has to be backward compatible with the existing one, and, to avoid bloat, should reuse most of the existing one. 2) So far it has been the blocking argument when trying to convince "the powers that be" that a new API is needed. I've been trying to get that project approved for a long time now (years to be exact). As of today it is still not approved for jdk7, even though I have good hopes that it will be. The corollary to that is that the API, and implementation, for a full FTP client has been in the works, internally, for a long time. Basically, it's done, just waiting in one of our internal workspaces for final approval. Now, assuming the project finally gets approved, I fully intend to publish what we've done before committing it to the workspace in order to get feedback, reviews, and, hopefully, contributions. At which point, I will take a look at your work and see what can be done to benefits all. In particular anything that could help with unit tests will be very, very needed. I hope this clarify a few things concerning FTP support in JDK 7. Don't hesitate to contact me on that subject, or any networking issue, if you have questions or issues. Thanks again, David Hansmann wrote: > Hi all, > > I recently looked at openjdk.java.net and found that there doesn't > seem to be a fixed plan to integrate full FTP support > (I'm referring to > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4650689 ), so I > wonder if you might be interested to use parts > of my FTP API located on http://j-ftp.sourceforge.net . > > It is part of a file transfer client which supports FTP using an API > which I wrote and which has been tested for quite some time now, > SFTP (throug j2ssh or jsch), JCIFS (through JCIFS) and NFS (through > Sun WebNFS) using > a common interface. Although the code may not be state-of-the art (no > generics yet) the core classes are very small, easy to refactor, not > very complicated in general and there are various of the features you > mentioned already present (like one control connection for multiple > downloads, > callbacks) and more. > > It should for example be possible to to use the other APIs as plugins > once this would be implemented so those other protocols could be used > by just placing the jars anywhere in the classpath. > > I'd of course help with the developement, code cleanup, testing and > support if anybody wants to give it a try - it would be really exiting to > contribute to the JDK especially because I started the project years > ago because of the lack of a real (and OSS) java FTP API ;) > > Greetings and thanks for your time, > > David Hansmann > > P.S.: If you want to take a look at the code you probably want to look > at net/FtpConnection, the BasicConnection interface and the example code > in the doc/-directory. From hansmann.d at debitel.net Mon Jun 18 01:50:44 2007 From: hansmann.d at debitel.net (David Hansmann) Date: Mon, 18 Jun 2007 10:50:44 +0200 Subject: JDK FTP support In-Reply-To: <46712CC9.5000104@sun.com> References: <466FF52F.8020200@debitel.net> <46712CC9.5000104@sun.com> Message-ID: <46764764.4090208@debitel.net> Hi, thanks for you response! I guess I'll wait for further developement then... Once your API is merged I might code some unit tests that test the same functionality on both your API and the JFtp one for example, so feel free to tell me what exactly you need then ;) Greetings, David Jean-Christophe Collet wrote: > Thank you for proposition, we certainly will take a look a all that. > That being said, the FTP Client API project is in a unusual state. > You see, as a pointed numerous times, we do have an API already, even > if it's a rather incomplete and not flexible one. Which leads to 2 > issues: > 1) Any new FTP API has to be backward compatible with the existing > one, and, to avoid bloat, should reuse most of the existing one. > 2) So far it has been the blocking argument when trying to convince > "the powers that be" that a new API is needed. I've been trying to get > that project approved for a long time now (years to be exact). As of > today it is still not approved for jdk7, even though I have good hopes > that it will be. > > The corollary to that is that the API, and implementation, for a full > FTP client has been in the works, internally, for a long time. > Basically, it's done, just waiting in one of our internal workspaces > for final approval. > > Now, assuming the project finally gets approved, I fully intend to > publish what we've done before committing it to the workspace in order > to get feedback, reviews, and, hopefully, contributions. > At which point, I will take a look at your work and see what can be > done to benefits all. In particular anything that could help with unit > tests will be very, very needed. > > I hope this clarify a few things concerning FTP support in JDK 7. > Don't hesitate to contact me on that subject, or any networking issue, > if you have questions or issues. > > Thanks again, > > David Hansmann wrote: >> Hi all, >> >> I recently looked at openjdk.java.net and found that there doesn't >> seem to be a fixed plan to integrate full FTP support >> (I'm referring to >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4650689 ), so I >> wonder if you might be interested to use parts >> of my FTP API located on http://j-ftp.sourceforge.net . >> >> It is part of a file transfer client which supports FTP using an API >> which I wrote and which has been tested for quite some time now, >> SFTP (throug j2ssh or jsch), JCIFS (through JCIFS) and NFS (through >> Sun WebNFS) using >> a common interface. Although the code may not be state-of-the art (no >> generics yet) the core classes are very small, easy to refactor, not >> very complicated in general and there are various of the features you >> mentioned already present (like one control connection for multiple >> downloads, >> callbacks) and more. >> >> It should for example be possible to to use the other APIs as plugins >> once this would be implemented so those other protocols could be used >> by just placing the jars anywhere in the classpath. >> >> I'd of course help with the developement, code cleanup, testing and >> support if anybody wants to give it a try - it would be really >> exiting to >> contribute to the JDK especially because I started the project years >> ago because of the lack of a real (and OSS) java FTP API ;) >> >> Greetings and thanks for your time, >> >> David Hansmann >> >> P.S.: If you want to take a look at the code you probably want to >> look at net/FtpConnection, the BasicConnection interface and the >> example code >> in the doc/-directory. > > > From Michael.McMahon at Sun.COM Thu Jun 21 03:17:51 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 21 Jun 2007 11:17:51 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <4660A4FB.4000706@kennardconsulting.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> Message-ID: <467A504F.1030406@sun.com> The CCC request has received initial approval, which simply means that the API change is accepted in principle. But, we need to finalize the specification and submit it to the CCC for final approval. Due to the (large) amount of discussion that has already taken place, I don't anticipate that this will take too long. The following is a comment from the final CCC reviewer. The comments are based on an older version of the API, but they are still applicable to the current version. - Michael A couple of quick comments: - The names of the elements of the URIQueryString.ParameterSeparator enum should be in UPPER_CASE, per convention. (Actually, defining an enum for this seems like overkill to me; I'd be tempted to accept a string argument and throw an IllegalArgumentException for anything except "&" and ";"). - Using string arrays in the URIQueryString API is just wrong; these should be List. (Mimicing the ServletRequest API is of marginal value at best, and so not an argument for using String[].) From richard at kennardconsulting.com Thu Jun 21 03:31:01 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Thu, 21 Jun 2007 20:31:01 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <467A504F.1030406@sun.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> <467A504F.1030406@sun.com> Message-ID: <467A5365.1010202@kennardconsulting.com> Michael, Given that I sort of disagree with both these comments, should I just take it that this is what the CCC wants and make the changes anyway? My disagreements would be: 1. Overkill or not, surely defining an enum is more explicit, more type-safe and a generally stricter way of doing things that defining the contract in the JavaDoc and throwing an IllegalArgumentException at runtime? 2. I think the whole 'a URL parameter can have multiple values' issue is unintuitive, and returning either a List or a String[] is going to be a surprise to people who just want a single String return value (witness the confusing nature of getParameter and getParameterValues in the Servlet API). Therefore, I'd rather follow ServletRequest which has beaten down this path for many years. But, as always, I'll defer to the CCC if that's what you'd prefer? Richard. Michael McMahon wrote: > The CCC request has received initial approval, > which simply means that the API change is accepted in principle. > But, we need to finalize the specification and submit it to the CCC > for final approval. > > Due to the (large) amount of discussion that has already > taken place, I don't anticipate that this will take too long. > > The following is a comment from the final CCC reviewer. The comments > are based on an older version of the API, but they are still > applicable to the current version. > > - Michael > > A couple of quick comments: > > - The names of the elements of the URIQueryString.ParameterSeparator > enum should be in UPPER_CASE, per convention. (Actually, defining > an enum for this seems like overkill to me; I'd be tempted to accept > a string argument and throw an IllegalArgumentException for anything > except "&" and ";"). > > - Using string arrays in the URIQueryString API is just wrong; these > should be List. (Mimicing the ServletRequest API is of > marginal value at best, and so not an argument for using String[].) > > > From Michael.McMahon at Sun.COM Thu Jun 21 03:55:42 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 21 Jun 2007 11:55:42 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <467A5365.1010202@kennardconsulting.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> <467A504F.1030406@sun.com> <467A5365.1010202@kennardconsulting.com> Message-ID: <467A592E.3000807@sun.com> Richard Kennard wrote: > Michael, > > Given that I sort of disagree with both these comments, should I just > take it that this is what the CCC wants and make the changes anyway? > > My disagreements would be: > > 1. Overkill or not, surely defining an enum is more explicit, more > type-safe and a generally stricter way of doing things that defining > the contract in the JavaDoc and throwing an IllegalArgumentException > at runtime? I think I agree since it does need to specified in the apply() method which separator you are talking about. Though I think we should stick with the uppercase convention. > 2. I think the whole 'a URL parameter can have multiple values' issue > is unintuitive, and returning either a List or a String[] is > going to be a surprise to people who just want a single String return > value (witness the confusing nature of getParameter and > getParameterValues in the Servlet API). Therefore, I'd rather follow > ServletRequest which has beaten down this path for many years. > What are you suggesting here? Michael. From richard at kennardconsulting.com Thu Jun 21 16:21:04 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Fri, 22 Jun 2007 09:21:04 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <467A592E.3000807@sun.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> <467A504F.1030406@sun.com> <467A5365.1010202@kennardconsulting.com> <467A592E.3000807@sun.com> Message-ID: <467B07E0.8010103@kennardconsulting.com> Michael, > Though I think we should stick with the uppercase convention. Agreed. > What are you suggesting here? Nothing different to what I have been saying before. HTML requires us to have the 'multi-valued return' feature, but I think if the API looks like... class UrlEncodedQueryString { void append( String name, String value ); void set( String name, String value ); String get( String name ); List getValues( String name ); } ...people are going to be 'Huh? What's the difference between get() and getValues()? When I put() or add() Strings in a List or a Map I don't need a get() and a getValues(), why do I need them here?'. Whereas, if the API looks like... class UrlEncodedQueryString { void appendParameter( String name, String value ); void setParameter( String name, String value ); String getParameter( String name ); String[] getParameterValues( String name ); } ...it feels a little more familiar. People can say 'hey this is weird, but it's the same kind of weird I'm used to from the Servlet API'. I keep going back to the Servlet API because it's the only Java SE/EE API, as far as I know, that directly addresses this same area. However, if I'm the only one that feels this way I'll go with the former? Richard. From Yujiang.Wang at Sun.COM Mon Jun 25 01:58:52 2007 From: Yujiang.Wang at Sun.COM (Edward Wang) Date: Mon, 25 Jun 2007 16:58:52 +0800 Subject: TTL ignored when sending Multicast UDP Datagram to IPv4 address via IPv6 socket In-Reply-To: <32870f240706010915t23342ee8k68a839c59f501737@mail.gmail.com> References: <32870f240705312050pd0554e8k30782ba6ed5c431f@mail.gmail.com> <465FC8BF.4060808@sun.com> <32870f240706010915t23342ee8k68a839c59f501737@mail.gmail.com> Message-ID: <467F83CC.50401@sun.com> Hi Don, The fix has been integrated. See attachment. It should be in next build of JDK 7. -Edward Don Coleman wrote: > -Djava.net.preferIPv4Stack=true works fine for IPv4, but my > application needs to send both IPv4 and IPv6. > > I'd be interested to see Edward Wang's patch for this issue. > > On 6/1/07, Alan Bateman wrote: >> Don Coleman wrote: >> > 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? >> The bug tracking this one is: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250763 >> >> At least in older kernels, it wasn't possible to set IPv4 multicast >> options on IPv6 sockets (the setsockopt would fail). Edward Wang has >> been testing with recent kernels and has results that suggest that >> setting the IPv4 options work now. I believe he has a fix/patch in the >> works to address this (Edward - can you comment?). >> >> If you need a workaround then run with -Djava.net.preferIPv4Stack=true >> so that all sockets are IPv4 (even if the machine has IPv6 enabled). >> >> -Alan. >> >> >> >> >> >> >> >> >> >> >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk7.patch Url: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20070625/cff09814/jdk7.patch From Michael.McMahon at Sun.COM Thu Jun 28 06:24:17 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 28 Jun 2007 14:24:17 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <467B07E0.8010103@kennardconsulting.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> <467A504F.1030406@sun.com> <467A5365.1010202@kennardconsulting.com> <467A592E.3000807@sun.com> <467B07E0.8010103@kennardconsulting.com> Message-ID: <4683B681.5020106@sun.com> Richard Kennard wrote: > Michael, > >> Though I think we should stick with the uppercase convention. > Agreed. >> What are you suggesting here? > Nothing different to what I have been saying before. HTML requires us > to have the 'multi-valued return' feature, but I think if the API > looks like... > > class UrlEncodedQueryString > { > void append( String name, String value ); > void set( String name, String value ); > String get( String name ); > List getValues( String name ); > } > > ...people are going to be 'Huh? What's the difference between get() > and getValues()? When I put() or add() Strings in a List or a Map I > don't need a get() and a getValues(), why do I need them here?'. > Whereas, if the API looks like... > > class UrlEncodedQueryString > { > void appendParameter( String name, String value ); > void setParameter( String name, String value ); > String getParameter( String name ); > String[] getParameterValues( String name ); > } > ...it feels a little more familiar. People can say 'hey this is > weird, but it's the same kind of weird I'm used to from the Servlet API'. I think I agree with respect to the names of the methods, but I think the comment (from Mark) was only to do with the return type of the multi-valued getXXX(). He is saying that it should be a List instead of a String[]. I think I agree with him. There may be a conflict here between the desire to fit in with the Java SE API conventions and the desire to remain "familiar" with existing Java EE APIs, but the CCC's policy will be to stick with the Java SE conventions. Thanks Michael. From Michael.McMahon at Sun.COM Thu Jun 28 08:30:06 2007 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 28 Jun 2007 16:30:06 +0100 Subject: Request for comments: Bug 6306820 In-Reply-To: <467B07E0.8010103@kennardconsulting.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> <467A504F.1030406@sun.com> <467A5365.1010202@kennardconsulting.com> <467A592E.3000807@sun.com> <467B07E0.8010103@kennardconsulting.com> Message-ID: <4683D3FE.4030900@sun.com> Some other minor comments on the last draft. - Michael. Class intro docs. 1. In the section entitled "Multivalued parameters" the list refers to getParameterValue() This should be getParameter() 2. The first reference to "(ampersand and semicolon)" should inlcude the actual symbols themselves for clarity eg. (ampersand "&" and semicolon ";") 3. I'd remove the section about URL. There is no need to mention it at all. 4. Section on Thread Safety. Change "not safe for use by multiple threads" to just "not synchronized". Other comments on the method definitions 5. If the use of [] arrays is being changed to List<>, then any of the methods that take these as parameters: create() , getParameterMap(). 6. Why does the parse() method say that calling it with an invalid string, is undefined? Would it not be better to throw an exception with an invalid string? Same comment applies to other methods with similar spec. 7. The notes in italics referring to servlet should be removed I think. 8. I think the docs for the 2nd setParameter() variant should say something different from the 1st one. Maybe an example showing how a literal or primitive integer type would be accepted as an argument. From richard at kennardconsulting.com Fri Jun 29 23:22:05 2007 From: richard at kennardconsulting.com (Richard Kennard) Date: Sat, 30 Jun 2007 16:22:05 +1000 Subject: Request for comments: Bug 6306820 In-Reply-To: <4683D3FE.4030900@sun.com> References: <4657740F.7050701@kennardconsulting.com> <4660A4FB.4000706@kennardconsulting.com> <467A504F.1030406@sun.com> <467A5365.1010202@kennardconsulting.com> <467A592E.3000807@sun.com> <467B07E0.8010103@kennardconsulting.com> <4683D3FE.4030900@sun.com> Message-ID: <4685F68D.3040705@kennardconsulting.com> Michael, Please find a new version of UrlEncodedQueryString at: https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20545&forumID=1463 Changes include: 1. JavaDoc changes 2. Changed String[] to List 3. Uppercased enums Basically, everything you asked for EXCEPT the thing about parse() returning 'undefined'. The problem here is I do not know if I can reliably error if I get an invalid query string, as most strings would be considered valid query strings and would probably parse to some degree. For example, if you passed an entire URL string (the most likely error to make, I'd say): http://java.sun.com?forum=3 I imagine this could validly be interpreted as a parameter called 'http://java.sun.com?forum' with a value of 3. Perhaps I should just say the results are 'unpredictable'? Richard.