From Christopher.Hegarty at Sun.COM Mon Mar 1 06:29:15 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Mon, 01 Mar 2010 14:29:15 +0000 Subject: 6370908: Add support for HTTP_CONNECT proxy in Socket class In-Reply-To: <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> References: <9e89675b1002210509n4e705eb7y8846b93eeccc3c12@mail.gmail.com> <4B829C73.7090905@Sun.COM> <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> Message-ID: <4B8BCF3B.7020105@Sun.COM> Hi Damjan, Sorry for the delayed response, I'm juggling too many things! I'm not sure how important Authentication is here. I initially pointed it out, but hadn't done sufficient scoping so didn't encounter these issues. Let me take another look at it, but I'm wondering if we should just proceed with it as is for now. Authentication is the reason that this RFE never made it back yet and has been sitting for a few years now. -Chris. On 24/02/2010 17:28, Damjan Jovanovic wrote: > On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun > Microsystems Ireland wrote: >> Hi Damjan, >> >> Actually, I did some work on this back in 2006 (!), but never finished it. I >> brought the changes into a mercurial repository and created a webrev: >> >> http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/ >> >> Basically, this change provides the basic functionality, without any frills, >> authentication, etc. I think for tunneling sockets through a HTTP proxy it >> should be sufficient. Do you require authentication in your environment? >> >> To have authentication supported we would need to restructure the HTTP >> protocol handler in sun.net.www.protocol.http.HttpURLConnection, so that we >> can take advantage of the authentication schemes it already supports. Not a >> big deal, just needs to be done. > > The major problem with authentication is that there is no guarantee > the HTTP connection will be persistent. Authentication generally > requires making additional requests to the proxy, so we may need to > connect to the proxy more than once. Each socket can only connect > once, and the HttpConnectSocketImpl is a single immutable socket, so > it cannot directly be used for authentication. > > A workaround may be to connect with a different socket for the initial > request, and then connect through the HttpConnectSocketImpl's own > socket for the final request. But then the problem becomes that if the > proxy doesn't require authentication, the initial socket will succeed > in connecting to the target host, and it will be too late to stop it > and use HttpConnectSocketImpl's own socket... > > So we have the following options: > 1. Only support proxies for which the entire request chain can be made > over a single persistent connection. > 2. Connect to each target host up to twice, once when we believe the > proxy needs authentication but doesn't, and then again later with the > real socket. This will probably kill protocols that use one shot > connections, like FTP. > 3. Find some way to change socket identities, then use as many sockets > as it takes and somehow adopt the final socket into > HttpConnectSocketImpl's own. > > Any suggestions? > >> -Chris. > > Damjan > >> On 21/02/2010 13:09, Damjan Jovanovic wrote: >>> >>> Hi >>> >>>> From http://bugs.sun.com/view_bug.do?bug_id=6370908 >>> >>> This RFE is basically about getting a TCP socket to tunnel through an >>> HTTP proxy using the HTTP CONNECT request. >>> >>> I've found a hack to get this feature to work, using sun.net.* >>> packages and lots of reflection. Would it be acceptable to use this >>> solution (with some way to change socket identity) in a patch that >>> adds a java.net.HttpSocketImpl class similar to the >>> java.net.SocksSocketImpl class that's already used to tunnel through >>> SOCKS proxies? If not, in what other way should such a patch be done? >>> >>> Thank you >>> Damjan Jovanovic >>> >>> import java.net.*; >>> import java.io.*; >>> import java.lang.reflect.*; >>> >>> public class TunnelProxy { >>> private static Socket connectThroughHTTPProxy(String proxyHost, int >>> proxyPort, String destinationHost, int destinationPort) throws >>> Exception >>> { >>> URL destinationURL = new URL("http://" + destinationHost + >>> ":" + >>> destinationPort); >>> sun.net.www.protocol.http.HttpURLConnection conn = >>> new sun.net.www.protocol.http.HttpURLConnection( >>> destinationURL, new >>> java.net.Proxy(java.net.Proxy.Type.HTTP, new >>> InetSocketAddress(proxyHost, proxyPort))); >>> conn.setDoInput(true); >>> conn.setDoOutput(true); >>> conn.connect(); >>> conn.doTunneling(); >>> Field httpField = conn.getClass().getDeclaredField("http"); >>> httpField.setAccessible(true); >>> sun.net.www.http.HttpClient httpClient = >>> (sun.net.www.http.HttpClient) httpField.get(conn); >>> Field serverSocketField = >>> sun.net.NetworkClient.class.getDeclaredField("serverSocket"); >>> serverSocketField.setAccessible(true); >>> Socket socket = (Socket) serverSocketField.get(httpClient); >>> return socket; >>> } >>> >>> public static void main(String[] args) throws Exception { >>> System.setProperty("java.net.useSystemProxies", "true"); >>> InputStream in = connectThroughHTTPProxy(args[0], >>> Integer.parseInt(args[1]), args[2], >>> Integer.parseInt(args[3])).getInputStream(); >>> byte[] bytes = new byte[1024]; >>> int bytesRead; >>> while ((bytesRead = in.read(bytes)) != -1) { >>> System.out.print(new String(bytes)); >>> } >>> } >>> } >> From vincent.ryan at sun.com Mon Mar 1 10:00:23 2010 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Mon, 01 Mar 2010 18:00:23 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100301180103.D0ACF41DBD@hg.openjdk.java.net> Changeset: 78d91c4223cb Author: vinnie Date: 2010-03-01 17:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78d91c4223cb 6921001: api/java_security/IdentityScope/IdentityScopeTests.html#getSystemScope fails starting from b78 JDK7 Reviewed-by: mullan ! src/share/classes/java/security/IdentityScope.java ! src/share/lib/security/java.security + test/java/security/IdentityScope/NoDefaultSystemScope.java Changeset: 893034df4ec2 Author: vinnie Date: 2010-03-01 18:00 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/893034df4ec2 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java From damjan.jov at gmail.com Mon Mar 1 10:03:47 2010 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Mon, 1 Mar 2010 20:03:47 +0200 Subject: 6370908: Add support for HTTP_CONNECT proxy in Socket class In-Reply-To: <4B8BCF3B.7020105@Sun.COM> References: <9e89675b1002210509n4e705eb7y8846b93eeccc3c12@mail.gmail.com> <4B829C73.7090905@Sun.COM> <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> <4B8BCF3B.7020105@Sun.COM> Message-ID: <9e89675b1003011003t28c3d70eod7f7c08068b2afb@mail.gmail.com> Hi Chris I think that without authentication, you'll just get another RFE asking for authentication. Many corporate proxies require authentication, especially for a liberal request like CONNECT. java.net.Socket seems to delegate its impl field's methods. If we have another, internal socket in HttpConnectSocketImpl, and we override getInputStream() and getOutputStream() in HttpConnectSocketImpl to return this inner socket's streams, we can open as many sockets as we like during authentication, and then just store the last one that connected as this internal socket? This seems like a way to "change socket identities" like I suggested. Thank you Damjan On Mon, Mar 1, 2010 at 4:29 PM, Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Damjan, > > Sorry for the delayed response, I'm juggling too many things! > > I'm not sure how important Authentication is here. I initially pointed it > out, but hadn't done sufficient scoping so didn't encounter these issues. > Let me take another look at it, but I'm wondering if we should just proceed > with it as is for now. Authentication is the reason that this RFE never made > it back yet and has been sitting for a few years now. > -Chris. > > On 24/02/2010 17:28, Damjan Jovanovic wrote: >> >> On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun >> Microsystems Ireland ?wrote: >>> >>> Hi Damjan, >>> >>> Actually, I did some work on this back in 2006 (!), but never finished >>> it. I >>> brought the changes into a mercurial repository and created a webrev: >>> >>> ?http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/ >>> >>> Basically, this change provides the basic functionality, without any >>> frills, >>> authentication, etc. I think for tunneling sockets through a HTTP proxy >>> it >>> should be sufficient. Do you require authentication in your environment? >>> >>> To have authentication supported we would need to restructure the HTTP >>> protocol handler in sun.net.www.protocol.http.HttpURLConnection, so that >>> we >>> can take advantage of the authentication schemes it already supports. Not >>> a >>> big deal, just needs to be done. >> >> The major problem with authentication is that there is no guarantee >> the HTTP connection will be persistent. Authentication generally >> requires making additional requests to the proxy, so we may need to >> connect to the proxy more than once. Each socket can only connect >> once, and the HttpConnectSocketImpl is a single immutable socket, so >> it cannot directly be used for authentication. >> >> A workaround may be to connect with a different socket for the initial >> request, and then connect through the HttpConnectSocketImpl's own >> socket for the final request. But then the problem becomes that if the >> proxy doesn't require authentication, the initial socket will succeed >> in connecting to the target host, and it will be too late to stop it >> and use HttpConnectSocketImpl's own socket... >> >> So we have the following options: >> 1. Only support proxies for which the entire request chain can be made >> over a single persistent connection. >> 2. Connect to each target host up to twice, once when we believe the >> proxy needs authentication but doesn't, and then again later with the >> real socket. This will probably kill protocols that use one shot >> connections, like FTP. >> 3. Find some way to change socket identities, then use as many sockets >> as it takes and somehow adopt the final socket into >> HttpConnectSocketImpl's own. >> >> Any suggestions? >> >>> -Chris. >> >> Damjan >> >>> On 21/02/2010 13:09, Damjan Jovanovic wrote: >>>> >>>> Hi >>>> >>>>> ?From http://bugs.sun.com/view_bug.do?bug_id=6370908 >>>> >>>> This RFE is basically about getting a TCP socket to tunnel through an >>>> HTTP proxy using the HTTP CONNECT request. >>>> >>>> I've found a hack to get this feature to work, using sun.net.* >>>> packages and lots of reflection. Would it be acceptable to use this >>>> solution (with some way to change socket identity) in a patch that >>>> adds a java.net.HttpSocketImpl class similar to the >>>> java.net.SocksSocketImpl class that's already used to tunnel through >>>> SOCKS proxies? If not, in what other way should such a patch be done? >>>> >>>> Thank you >>>> Damjan Jovanovic >>>> >>>> import java.net.*; >>>> import java.io.*; >>>> import java.lang.reflect.*; >>>> >>>> public class TunnelProxy { >>>> ? ? ? ?private static Socket connectThroughHTTPProxy(String proxyHost, >>>> int >>>> proxyPort, String destinationHost, int destinationPort) throws >>>> Exception >>>> ? ? ? ?{ >>>> ? ? ? ? ? ? ? ?URL destinationURL = new URL("http://" + destinationHost >>>> + >>>> ":" + >>>> destinationPort); >>>> ? ? ? ? ? ? ? ?sun.net.www.protocol.http.HttpURLConnection conn = >>>> ? ? ? ? ? ? ? ? ? ? ? ?new sun.net.www.protocol.http.HttpURLConnection( >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?destinationURL, new >>>> java.net.Proxy(java.net.Proxy.Type.HTTP, new >>>> InetSocketAddress(proxyHost, proxyPort))); >>>> ? ? ? ? ? ? ? ?conn.setDoInput(true); >>>> ? ? ? ? ? ? ? ?conn.setDoOutput(true); >>>> ? ? ? ? ? ? ? ?conn.connect(); >>>> ? ? ? ? ? ? ? ?conn.doTunneling(); >>>> ? ? ? ? ? ? ? ?Field httpField = >>>> conn.getClass().getDeclaredField("http"); >>>> ? ? ? ? ? ? ? ?httpField.setAccessible(true); >>>> ? ? ? ? ? ? ? ?sun.net.www.http.HttpClient httpClient = >>>> (sun.net.www.http.HttpClient) httpField.get(conn); >>>> ? ? ? ? ? ? ? ?Field serverSocketField = >>>> sun.net.NetworkClient.class.getDeclaredField("serverSocket"); >>>> ? ? ? ? ? ? ? ?serverSocketField.setAccessible(true); >>>> ? ? ? ? ? ? ? ?Socket socket = (Socket) >>>> serverSocketField.get(httpClient); >>>> ? ? ? ? ? ? ? ?return socket; >>>> ? ? ? ?} >>>> >>>> ? ? ? ?public static void main(String[] args) throws Exception { >>>> ? ? ? ? ? ? ? ?System.setProperty("java.net.useSystemProxies", "true"); >>>> ? ? ? ? ? ? ? ?InputStream in = connectThroughHTTPProxy(args[0], >>>> Integer.parseInt(args[1]), args[2], >>>> Integer.parseInt(args[3])).getInputStream(); >>>> ? ? ? ? ? ? ? ?byte[] bytes = new byte[1024]; >>>> ? ? ? ? ? ? ? ?int bytesRead; >>>> ? ? ? ? ? ? ? ?while ((bytesRead = in.read(bytes)) != -1) { >>>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.print(new String(bytes)); >>>> ? ? ? ? ? ? ? ?} >>>> ? ? ? ?} >>>> } >>> > From joe.darcy at sun.com Tue Mar 2 13:57:06 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 02 Mar 2010 21:57:06 +0000 Subject: hg: jdk7/tl/langtools: 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Message-ID: <20100302215709.B65C341F86@hg.openjdk.java.net> Changeset: 7c23bbbe0dbd Author: darcy Date: 2010-03-02 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c23bbbe0dbd 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java From jonathan.gibbons at sun.com Tue Mar 2 16:41:43 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 03 Mar 2010 00:41:43 +0000 Subject: hg: jdk7/tl/langtools: 6931482: minor findbugs fixes Message-ID: <20100303004146.B692D41FB5@hg.openjdk.java.net> Changeset: 6e1e2738c530 Author: jjg Date: 2010-03-02 16:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e1e2738c530 6931482: minor findbugs fixes Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java From jonathan.gibbons at sun.com Tue Mar 2 16:44:42 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 03 Mar 2010 00:44:42 +0000 Subject: hg: jdk7/tl/langtools: 6931127: strange test class files Message-ID: <20100303004445.7B6E041FB6@hg.openjdk.java.net> Changeset: 235135d61974 Author: jjg Date: 2010-03-02 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/235135d61974 6931127: strange test class files Reviewed-by: darcy ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java From Christopher.Hegarty at Sun.COM Wed Mar 3 05:07:22 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Wed, 03 Mar 2010 13:07:22 +0000 Subject: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy Message-ID: <4B8E5F0A.2000104@sun.com> Hi All, This patch fixes a problem where the socks proxy implementation does not honor the timeout specified in Socket.connect(SocketAddress, timeout). In fact, it uses the read timeout set with setSoTimeout since the socks implementation opens a connection to the socks server to perform the socks protocol. This also violates the spec since a timeout of 0 means block indefinitely. It is worth noting that the proposed fix changes the current behavior as specified above; SO_TIMEOUT no longer impacts on the timeout when using a socks proxy. 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy OpenJDK Bugzilla ID: https://bugs.openjdk.java.net/show_bug.cgi?id=100130 Webrev: http://cr.openjdk.java.net/~chegar/6223635/webrev.00/webrev/ Contribution-by: damjan.jov at gmail.com Thanks, -Chris. From Christopher.Hegarty at Sun.COM Wed Mar 3 05:55:53 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Wed, 03 Mar 2010 13:55:53 +0000 Subject: 6370908: Add support for HTTP_CONNECT proxy in Socket class In-Reply-To: <9e89675b1003011003t28c3d70eod7f7c08068b2afb@mail.gmail.com> References: <9e89675b1002210509n4e705eb7y8846b93eeccc3c12@mail.gmail.com> <4B829C73.7090905@Sun.COM> <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> <4B8BCF3B.7020105@Sun.COM> <9e89675b1003011003t28c3d70eod7f7c08068b2afb@mail.gmail.com> Message-ID: <4B8E6A69.9070003@sun.com> Hi Damjan, After spending more time looking at this, I still haven't found an elegant solution for supporting authentication. You've correctly identified an issue with the fact we have no guaranteed of a persistent connection with the proxy. Changing the socket identity is not as simple as overriding getIn/OutputStream since other methods like setting/getting options, close, shutdown, etc use the impls fd field. This field needs to refer to the correct file descriptor object. There is quite a lot of logic in the http protocol handler to support authentication and looking at it again it is closely tied to the handler implementation itself. I would prefer to reuse this code if possible. Have you made any progress on this? If we want authentication it may be more straight forward to revert back to your original proposal of using HttpURLConnection directly and having its socket exposed. Though, I'm still not convinced of this solution either. -Chris Damjan Jovanovic wrote: > Hi Chris > > I think that without authentication, you'll just get another RFE > asking for authentication. Many corporate proxies require > authentication, especially for a liberal request like CONNECT. > > java.net.Socket seems to delegate its impl field's methods. If we have > another, internal socket in HttpConnectSocketImpl, and we override > getInputStream() and getOutputStream() in HttpConnectSocketImpl to > return this inner socket's streams, we can open as many sockets as we > like during authentication, and then just store the last one that > connected as this internal socket? This seems like a way to "change > socket identities" like I suggested. > > Thank you > Damjan > > On Mon, Mar 1, 2010 at 4:29 PM, Christopher Hegarty - Sun Microsystems > Ireland wrote: >> Hi Damjan, >> >> Sorry for the delayed response, I'm juggling too many things! >> >> I'm not sure how important Authentication is here. I initially pointed it >> out, but hadn't done sufficient scoping so didn't encounter these issues. >> Let me take another look at it, but I'm wondering if we should just proceed >> with it as is for now. Authentication is the reason that this RFE never made >> it back yet and has been sitting for a few years now. > > >> -Chris. >> >> On 24/02/2010 17:28, Damjan Jovanovic wrote: >>> On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun >>> Microsystems Ireland wrote: >>>> Hi Damjan, >>>> >>>> Actually, I did some work on this back in 2006 (!), but never finished >>>> it. I >>>> brought the changes into a mercurial repository and created a webrev: >>>> >>>> http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/ >>>> >>>> Basically, this change provides the basic functionality, without any >>>> frills, >>>> authentication, etc. I think for tunneling sockets through a HTTP proxy >>>> it >>>> should be sufficient. Do you require authentication in your environment? >>>> >>>> To have authentication supported we would need to restructure the HTTP >>>> protocol handler in sun.net.www.protocol.http.HttpURLConnection, so that >>>> we >>>> can take advantage of the authentication schemes it already supports. Not >>>> a >>>> big deal, just needs to be done. >>> The major problem with authentication is that there is no guarantee >>> the HTTP connection will be persistent. Authentication generally >>> requires making additional requests to the proxy, so we may need to >>> connect to the proxy more than once. Each socket can only connect >>> once, and the HttpConnectSocketImpl is a single immutable socket, so >>> it cannot directly be used for authentication. >>> >>> A workaround may be to connect with a different socket for the initial >>> request, and then connect through the HttpConnectSocketImpl's own >>> socket for the final request. But then the problem becomes that if the >>> proxy doesn't require authentication, the initial socket will succeed >>> in connecting to the target host, and it will be too late to stop it >>> and use HttpConnectSocketImpl's own socket... >>> >>> So we have the following options: >>> 1. Only support proxies for which the entire request chain can be made >>> over a single persistent connection. >>> 2. Connect to each target host up to twice, once when we believe the >>> proxy needs authentication but doesn't, and then again later with the >>> real socket. This will probably kill protocols that use one shot >>> connections, like FTP. >>> 3. Find some way to change socket identities, then use as many sockets >>> as it takes and somehow adopt the final socket into >>> HttpConnectSocketImpl's own. >>> >>> Any suggestions? >>> >>>> -Chris. >>> Damjan >>> >>>> On 21/02/2010 13:09, Damjan Jovanovic wrote: >>>>> Hi >>>>> >>>>>> From http://bugs.sun.com/view_bug.do?bug_id=6370908 >>>>> This RFE is basically about getting a TCP socket to tunnel through an >>>>> HTTP proxy using the HTTP CONNECT request. >>>>> >>>>> I've found a hack to get this feature to work, using sun.net.* >>>>> packages and lots of reflection. Would it be acceptable to use this >>>>> solution (with some way to change socket identity) in a patch that >>>>> adds a java.net.HttpSocketImpl class similar to the >>>>> java.net.SocksSocketImpl class that's already used to tunnel through >>>>> SOCKS proxies? If not, in what other way should such a patch be done? >>>>> >>>>> Thank you >>>>> Damjan Jovanovic >>>>> >>>>> import java.net.*; >>>>> import java.io.*; >>>>> import java.lang.reflect.*; >>>>> >>>>> public class TunnelProxy { >>>>> private static Socket connectThroughHTTPProxy(String proxyHost, >>>>> int >>>>> proxyPort, String destinationHost, int destinationPort) throws >>>>> Exception >>>>> { >>>>> URL destinationURL = new URL("http://" + destinationHost >>>>> + >>>>> ":" + >>>>> destinationPort); >>>>> sun.net.www.protocol.http.HttpURLConnection conn = >>>>> new sun.net.www.protocol.http.HttpURLConnection( >>>>> destinationURL, new >>>>> java.net.Proxy(java.net.Proxy.Type.HTTP, new >>>>> InetSocketAddress(proxyHost, proxyPort))); >>>>> conn.setDoInput(true); >>>>> conn.setDoOutput(true); >>>>> conn.connect(); >>>>> conn.doTunneling(); >>>>> Field httpField = >>>>> conn.getClass().getDeclaredField("http"); >>>>> httpField.setAccessible(true); >>>>> sun.net.www.http.HttpClient httpClient = >>>>> (sun.net.www.http.HttpClient) httpField.get(conn); >>>>> Field serverSocketField = >>>>> sun.net.NetworkClient.class.getDeclaredField("serverSocket"); >>>>> serverSocketField.setAccessible(true); >>>>> Socket socket = (Socket) >>>>> serverSocketField.get(httpClient); >>>>> return socket; >>>>> } >>>>> >>>>> public static void main(String[] args) throws Exception { >>>>> System.setProperty("java.net.useSystemProxies", "true"); >>>>> InputStream in = connectThroughHTTPProxy(args[0], >>>>> Integer.parseInt(args[1]), args[2], >>>>> Integer.parseInt(args[3])).getInputStream(); >>>>> byte[] bytes = new byte[1024]; >>>>> int bytesRead; >>>>> while ((bytesRead = in.read(bytes)) != -1) { >>>>> System.out.print(new String(bytes)); >>>>> } >>>>> } >>>>> } From alan.bateman at sun.com Wed Mar 3 08:10:11 2010 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Wed, 03 Mar 2010 16:10:11 +0000 Subject: hg: jdk7/tl/jdk: 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Message-ID: <20100303161050.CC14143C39@hg.openjdk.java.net> Changeset: cddb43b12d28 Author: alanb Date: 2010-03-03 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cddb43b12d28 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Reviewed-by: chegar ! test/java/nio/file/WatchService/LotsOfEvents.java From kelly.ohair at sun.com Wed Mar 3 11:30:18 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 03 Mar 2010 19:30:18 +0000 Subject: hg: jdk7/tl/jdk: 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Message-ID: <20100303193038.0881343C6C@hg.openjdk.java.net> Changeset: 507159d8d143 Author: ohair Date: 2010-03-03 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/507159d8d143 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Reviewed-by: jjg ! make/common/shared/Sanity.gmk From joe.darcy at sun.com Wed Mar 3 16:05:47 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 04 Mar 2010 00:05:47 +0000 Subject: hg: jdk7/tl/langtools: 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Message-ID: <20100304000550.9A71443CAE@hg.openjdk.java.net> Changeset: fc7132746501 Author: darcy Date: 2010-03-03 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc7132746501 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/element/TestAnonClassNames.java + test/tools/javac/processing/model/element/TestAnonSourceNames.java From jonathan.gibbons at sun.com Wed Mar 3 17:23:54 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 04 Mar 2010 01:23:54 +0000 Subject: hg: jdk7/tl/langtools: 6931927: position issues with synthesized anonymous class Message-ID: <20100304012357.898BF43CC4@hg.openjdk.java.net> Changeset: 7f5db2e8b423 Author: jjg Date: 2010-03-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7f5db2e8b423 6931927: position issues with synthesized anonymous class Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/TestAnnotatedAnonClass.java + test/tools/javac/tree/TreePosTest.java - test/tools/javac/treepostests/TreePosTest.java From weijun.wang at sun.com Wed Mar 3 18:40:26 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 04 Mar 2010 02:40:26 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100304024122.AFDFC43CD7@hg.openjdk.java.net> Changeset: 61c298558549 Author: weijun Date: 2010-03-04 10:37 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61c298558549 6844909: support allow_weak_crypto in krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java + test/sun/security/krb5/etype/WeakCrypto.java + test/sun/security/krb5/etype/weakcrypto.conf Changeset: 0f383673ce31 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f383673ce31 6923681: Jarsigner crashes during timestamping Reviewed-by: vinnie ! src/share/classes/sun/security/tools/TimestampedSigner.java Changeset: 5e15b70e6d27 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e15b70e6d27 6880321: sun.security.provider.JavaKeyStore abuse of OOM Exception handling Reviewed-by: xuelei ! src/share/classes/sun/security/provider/JavaKeyStore.java From jonathan.gibbons at sun.com Wed Mar 3 19:35:50 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 04 Mar 2010 03:35:50 +0000 Subject: hg: jdk7/tl/langtools: 6931126: jtreg tests not Windows friendly Message-ID: <20100304033552.E838743CE5@hg.openjdk.java.net> Changeset: 117c95448ab9 Author: jjg Date: 2010-03-03 19:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/117c95448ab9 6931126: jtreg tests not Windows friendly Reviewed-by: darcy ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/generics/NameOrder.java From damjan.jov at gmail.com Thu Mar 4 03:29:32 2010 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Thu, 4 Mar 2010 13:29:32 +0200 Subject: 6370908: Add support for HTTP_CONNECT proxy in Socket class In-Reply-To: <4B8E6A69.9070003@sun.com> References: <9e89675b1002210509n4e705eb7y8846b93eeccc3c12@mail.gmail.com> <4B829C73.7090905@Sun.COM> <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> <4B8BCF3B.7020105@Sun.COM> <9e89675b1003011003t28c3d70eod7f7c08068b2afb@mail.gmail.com> <4B8E6A69.9070003@sun.com> Message-ID: <9e89675b1003040329t65467149w247734c889e7c467@mail.gmail.com> Hi Chris Proxies are on the application layer, TCP is a transport layer protocol below. Using the application layer to establish in-band transport layer connections is dodgy by its very nature. The multiple sockets to get through an HTTP proxy issue is not unique to Java. Here's a quick look at how several open source applications have dealt with the problem: * prtunnel (http://joshbeam.com/software/prtunnel.php), a C application for tunneling through several proxy types, only supports no authentication and BASIC HTTP authentication. proxychains does the same. XChat does the same. * ntlmaps.sourceforge.net and similar apps work by acting as another proxy themselves. They can use as many sockets as necessary on the outgoing end to the second proxy. * pidgin (www.pidgin.im), an instant messaging app, has very good proxy support including NTLM authentication for HTTP proxies. It only uses a single socket and requires the proxy to use a persistent connection. proxytunnel (proxytunnel.sourceforge.net) does the same. I like pidgin's solution the best, and since it even works with NTLM, the other authentication types should be easy. Most HTTP 1.1 proxies should support persistent connections - after all, that feature benefits proxies the most. So we should be able to get away with one socket in most cases, maybe even for all commonly used HTTP proxies. I'll try to do some tests this weekend. Also, nothing stops a Socket from changing its impl. We would need a very clever impl that somehow remembers options that have been set and reapplies them to the new impl, but there's no theoretical reason why connect() cannot create as many impls as are necessary to get through the proxy. On the other hand, all Java's solutions for connecting through proxies are poor: SOCKS 4 is broken (http://mail.openjdk.java.net/pipermail/net-dev/2010-February/001580.html), server sockets are unsupported, datagram sockets are unsupported, and all java.nio channels are unsupported. But then proxies aren't so common any more: ADSL routers typically use NAT instead, and we don't provide any NAT traversal support for server sockets and datagram sockets using UPnP's IGD or Bonjour's NAT-PMP protocols. Maybe we should? Damjan On Wed, Mar 3, 2010 at 3:55 PM, Christopher Hegarty -Sun Microsystems Ireland wrote: > Hi Damjan, > > After spending more time looking at this, I still haven't found an elegant > solution for supporting authentication. > > You've correctly identified an issue with the fact we have no guaranteed of > a persistent connection with the proxy. Changing the socket identity is not > as simple as overriding getIn/OutputStream since other methods like > setting/getting options, close, shutdown, etc use the impls fd field. This > field needs to refer to the correct file descriptor object. > > There is quite a lot of logic in the http protocol handler to support > authentication and looking at it again it is closely tied to the handler > implementation itself. I would prefer to reuse this code if possible. > > Have you made any progress on this? If we want authentication it may be more > straight forward to revert back to your original proposal of using > HttpURLConnection directly and having its socket exposed. Though, I'm still > not convinced of this solution either. > > -Chris > > Damjan Jovanovic wrote: >> >> Hi Chris >> >> I think that without authentication, you'll just get another RFE >> asking for authentication. Many corporate proxies require >> authentication, especially for a liberal request like CONNECT. >> >> java.net.Socket seems to delegate its impl field's methods. If we have >> another, internal socket in HttpConnectSocketImpl, and we override >> getInputStream() and getOutputStream() in HttpConnectSocketImpl to >> return this inner socket's streams, we can open as many sockets as we >> like during authentication, and then just store the last one that >> connected as this internal socket? This seems like a way to "change >> socket identities" like I suggested. >> >> Thank you >> Damjan >> >> On Mon, Mar 1, 2010 at 4:29 PM, Christopher Hegarty - Sun Microsystems >> Ireland wrote: >>> >>> Hi Damjan, >>> >>> Sorry for the delayed response, I'm juggling too many things! >>> >>> I'm not sure how important Authentication is here. I initially pointed it >>> out, but hadn't done sufficient scoping so didn't encounter these issues. >>> Let me take another look at it, but I'm wondering if we should just >>> proceed >>> with it as is for now. Authentication is the reason that this RFE never >>> made >>> it back yet and has been sitting for a few years now. >> >> >>> -Chris. >>> >>> On 24/02/2010 17:28, Damjan Jovanovic wrote: >>>> >>>> On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun >>>> Microsystems Ireland ?wrote: >>>>> >>>>> Hi Damjan, >>>>> >>>>> Actually, I did some work on this back in 2006 (!), but never finished >>>>> it. I >>>>> brought the changes into a mercurial repository and created a webrev: >>>>> >>>>> ?http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/ >>>>> >>>>> Basically, this change provides the basic functionality, without any >>>>> frills, >>>>> authentication, etc. I think for tunneling sockets through a HTTP proxy >>>>> it >>>>> should be sufficient. Do you require authentication in your >>>>> environment? >>>>> >>>>> To have authentication supported we would need to restructure the HTTP >>>>> protocol handler in sun.net.www.protocol.http.HttpURLConnection, so >>>>> that >>>>> we >>>>> can take advantage of the authentication schemes it already supports. >>>>> Not >>>>> a >>>>> big deal, just needs to be done. >>>> >>>> The major problem with authentication is that there is no guarantee >>>> the HTTP connection will be persistent. Authentication generally >>>> requires making additional requests to the proxy, so we may need to >>>> connect to the proxy more than once. Each socket can only connect >>>> once, and the HttpConnectSocketImpl is a single immutable socket, so >>>> it cannot directly be used for authentication. >>>> >>>> A workaround may be to connect with a different socket for the initial >>>> request, and then connect through the HttpConnectSocketImpl's own >>>> socket for the final request. But then the problem becomes that if the >>>> proxy doesn't require authentication, the initial socket will succeed >>>> in connecting to the target host, and it will be too late to stop it >>>> and use HttpConnectSocketImpl's own socket... >>>> >>>> So we have the following options: >>>> 1. Only support proxies for which the entire request chain can be made >>>> over a single persistent connection. >>>> 2. Connect to each target host up to twice, once when we believe the >>>> proxy needs authentication but doesn't, and then again later with the >>>> real socket. This will probably kill protocols that use one shot >>>> connections, like FTP. >>>> 3. Find some way to change socket identities, then use as many sockets >>>> as it takes and somehow adopt the final socket into >>>> HttpConnectSocketImpl's own. >>>> >>>> Any suggestions? >>>> >>>>> -Chris. >>>> >>>> Damjan >>>> >>>>> On 21/02/2010 13:09, Damjan Jovanovic wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>>> ?From http://bugs.sun.com/view_bug.do?bug_id=6370908 >>>>>> >>>>>> This RFE is basically about getting a TCP socket to tunnel through an >>>>>> HTTP proxy using the HTTP CONNECT request. >>>>>> >>>>>> I've found a hack to get this feature to work, using sun.net.* >>>>>> packages and lots of reflection. Would it be acceptable to use this >>>>>> solution (with some way to change socket identity) in a patch that >>>>>> adds a java.net.HttpSocketImpl class similar to the >>>>>> java.net.SocksSocketImpl class that's already used to tunnel through >>>>>> SOCKS proxies? If not, in what other way should such a patch be done? >>>>>> >>>>>> Thank you >>>>>> Damjan Jovanovic >>>>>> >>>>>> import java.net.*; >>>>>> import java.io.*; >>>>>> import java.lang.reflect.*; >>>>>> >>>>>> public class TunnelProxy { >>>>>> ? ? ? private static Socket connectThroughHTTPProxy(String proxyHost, >>>>>> int >>>>>> proxyPort, String destinationHost, int destinationPort) throws >>>>>> Exception >>>>>> ? ? ? { >>>>>> ? ? ? ? ? ? ? URL destinationURL = new URL("http://" + destinationHost >>>>>> + >>>>>> ":" + >>>>>> destinationPort); >>>>>> ? ? ? ? ? ? ? sun.net.www.protocol.http.HttpURLConnection conn = >>>>>> ? ? ? ? ? ? ? ? ? ? ? new sun.net.www.protocol.http.HttpURLConnection( >>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? destinationURL, new >>>>>> java.net.Proxy(java.net.Proxy.Type.HTTP, new >>>>>> InetSocketAddress(proxyHost, proxyPort))); >>>>>> ? ? ? ? ? ? ? conn.setDoInput(true); >>>>>> ? ? ? ? ? ? ? conn.setDoOutput(true); >>>>>> ? ? ? ? ? ? ? conn.connect(); >>>>>> ? ? ? ? ? ? ? conn.doTunneling(); >>>>>> ? ? ? ? ? ? ? Field httpField = >>>>>> conn.getClass().getDeclaredField("http"); >>>>>> ? ? ? ? ? ? ? httpField.setAccessible(true); >>>>>> ? ? ? ? ? ? ? sun.net.www.http.HttpClient httpClient = >>>>>> (sun.net.www.http.HttpClient) httpField.get(conn); >>>>>> ? ? ? ? ? ? ? Field serverSocketField = >>>>>> sun.net.NetworkClient.class.getDeclaredField("serverSocket"); >>>>>> ? ? ? ? ? ? ? serverSocketField.setAccessible(true); >>>>>> ? ? ? ? ? ? ? Socket socket = (Socket) >>>>>> serverSocketField.get(httpClient); >>>>>> ? ? ? ? ? ? ? return socket; >>>>>> ? ? ? } >>>>>> >>>>>> ? ? ? public static void main(String[] args) throws Exception { >>>>>> ? ? ? ? ? ? ? System.setProperty("java.net.useSystemProxies", "true"); >>>>>> ? ? ? ? ? ? ? InputStream in = connectThroughHTTPProxy(args[0], >>>>>> Integer.parseInt(args[1]), args[2], >>>>>> Integer.parseInt(args[3])).getInputStream(); >>>>>> ? ? ? ? ? ? ? byte[] bytes = new byte[1024]; >>>>>> ? ? ? ? ? ? ? int bytesRead; >>>>>> ? ? ? ? ? ? ? while ((bytesRead = in.read(bytes)) != -1) { >>>>>> ? ? ? ? ? ? ? ? ? ? ? System.out.print(new String(bytes)); >>>>>> ? ? ? ? ? ? ? } >>>>>> ? ? ? } >>>>>> } > From Weijun.Wang at Sun.COM Thu Mar 4 04:06:12 2010 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Thu, 04 Mar 2010 20:06:12 +0800 Subject: 6370908: Add support for HTTP_CONNECT proxy in Socket class In-Reply-To: <9e89675b1003040329t65467149w247734c889e7c467@mail.gmail.com> References: <9e89675b1002210509n4e705eb7y8846b93eeccc3c12@mail.gmail.com> <4B829C73.7090905@Sun.COM> <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> <4B8BCF3B.7020105@Sun.COM> <9e89675b1003011003t28c3d70eod7f7c08068b2afb@mail.gmail.com> <4B8E6A69.9070003@sun.com> <9e89675b1003040329t65467149w247734c889e7c467@mail.gmail.com> Message-ID: <117A0DB5-AC9A-457D-A174-2E5D37739399@sun.com> Haven't read the full thread, just 2 cents on this specific paragraph. On Mar 4, 2010, at 7:29 PM, Damjan Jovanovic wrote: > Hi Chris > > ... > * pidgin (www.pidgin.im), an instant messaging app, has very good > proxy support including NTLM authentication for HTTP proxies. It only > uses a single socket and requires the proxy to use a persistent > connection. proxytunnel (proxytunnel.sourceforge.net) does the same. > > I like pidgin's solution the best, and since it even works with NTLM, > the other authentication types should be easy. Most HTTP 1.1 proxies > should support persistent connections - after all, that feature > benefits proxies the most. So we should be able to get away with one > socket in most cases, maybe even for all commonly used HTTP proxies. > I'll try to do some tests this weekend. I remember somewhere in the HTTP RFC says that the client must close the connection when the initial 401/407 response is received. Hence, my understanding of web auth inside proxy auth should look like this: . Connect proxy, see 407 . Disconnect/reconnect to proxy, authenticate to proxy, succeed . Proxy connect to web server, see 401 . Tell proxy to disconnect/reconnect web server, authenticate to web server, see 200 This way an NTLM/web inside NTLM/proxy can be implemented, even if MS has explicitly said this is not supported. --Max From lana.steuck at sun.com Thu Mar 4 22:46:13 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:46:13 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b84 for changeset 2f3ea057d1ad Message-ID: <20100305064613.4D93E43E6F@hg.openjdk.java.net> Changeset: cf26288a114b Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cf26288a114b Added tag jdk7-b84 for changeset 2f3ea057d1ad ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:46:19 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:46:19 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b84 for changeset 68c8961a82e4 Message-ID: <20100305064620.B3DA043E70@hg.openjdk.java.net> Changeset: c67a9df7bc0c Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c67a9df7bc0c Added tag jdk7-b84 for changeset 68c8961a82e4 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:48:40 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:48:40 +0000 Subject: hg: jdk7/tl/hotspot: 27 new changesets Message-ID: <20100305065004.1989143E71@hg.openjdk.java.net> Changeset: 125eb6a9fccf Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/125eb6a9fccf Added tag jdk7-b84 for changeset ffc8d176b84b ! .hgtags Changeset: 745c853ee57f Author: johnc Date: 2010-01-29 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/745c853ee57f 6885297: java -XX:RefDiscoveryPolicy=2 or -XX:TLABWasteTargetPercent=0 cause VM crash Summary: Interval checking is now being performed on the values passed in for these two flags. The current acceptable range for RefDiscoveryPolicy is [0..1], and for TLABWasteTargetPercent it is [1..100]. Reviewed-by: apetrusenko, ysr ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 6484c4ee11cb Author: ysr Date: 2010-02-01 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6484c4ee11cb 6904516: More object array barrier fixes, following up on 6906727 Summary: Fixed missing pre-barrier calls for G1, modified C1 to call pre- and correct post-barrier interfaces, deleted obsolete interface, (temporarily) disabled redundant deferred barrier in BacktraceBuilder. Reviewed-by: coleenp, jmasa, kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/runtime/stubRoutines.cpp Changeset: deada8912c54 Author: johnc Date: 2010-02-02 18:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/deada8912c54 6914402: G1: assert(!is_young_card(cached_ptr),"shouldn't get a card in young region") Summary: Invalid assert. Filter cards evicted from the card count cache instead. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 230fac611b50 Author: johnc Date: 2010-02-08 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/230fac611b50 Merge ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_core Changeset: 455df1b81409 Author: kamg Date: 2010-02-08 13:49 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/455df1b81409 6587322: dtrace probe object__alloc doesn't fire in some situations on amd64 Summary: Fix misplaced probe point Reviewed-by: rasbold, phh Contributed-by: neojia at gmail.com ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 95d21201c29a Author: apangin Date: 2010-02-11 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/95d21201c29a Merge Changeset: 3f5b7efb9642 Author: never Date: 2010-02-05 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f5b7efb9642 6920293: OptimizeStringConcat causing core dumps Reviewed-by: kvn, twisti ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 576e77447e3c Author: kvn Date: 2010-02-07 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/576e77447e3c 6923002: assert(false,"this call site should not be polymorphic") Summary: Clear the total count when a receiver information is cleared. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f516d5d7a019 Author: kvn Date: 2010-02-08 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f516d5d7a019 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Summary: Set the reexecute bit for runtime calls _new_array_Java when they used for _multianewarray bytecode. Reviewed-by: never ! src/share/vm/code/pcDesc.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/6910605/Test.java Changeset: f70b0d9ab095 Author: kvn Date: 2010-02-09 01:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f70b0d9ab095 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Summary: Mark in PcDesc call sites which return oop and save the result oop across objects reallocation during deoptimization. Reviewed-by: never ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/includeDB_core ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/deoptimization.cpp + test/compiler/6910618/Test.java Changeset: 4ee1c645110e Author: kvn Date: 2010-02-09 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4ee1c645110e 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Summary: Use PhiNode::make_blank(r, n) method to construct the phi. Reviewed-by: never ! src/share/vm/opto/loopopts.cpp Changeset: e3a4305c6bc3 Author: kvn Date: 2010-02-12 08:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e3a4305c6bc3 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Summary: Fix assert since top deoptimized frame has last_sp == interpreter_frame_monitor_begin if there are no expressions. Reviewed-by: twisti ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: c09ee209b65c Author: kvn Date: 2010-02-12 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c09ee209b65c 6926048: Improve Zero performance Summary: Make Zero figure out result types in a similar way to C++ interpreter implementation. Reviewed-by: kvn Contributed-by: gbenson at redhat.com ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp Changeset: 7b4415a18c8a Author: kvn Date: 2010-02-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7b4415a18c8a Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 38836cf1d8d2 Author: tonyp Date: 2010-02-05 11:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38836cf1d8d2 6920977: G1: guarantee(k == probe->klass(),"klass should be in dictionary") fails Summary: the guarantee is too strict and the test will fail (incorrectly) if the class is not in the system dictionary but in the placeholders. Reviewed-by: acorn, phh ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/includeDB_core Changeset: 9eee977dd1a9 Author: tonyp Date: 2010-02-08 14:23 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eee977dd1a9 6802453: G1: hr()->is_in_reserved(from),"Precondition." Summary: The operations of re-using a RSet component and expanding the same RSet component were not mutually exlusive, and this could lead to RSets getting corrupted and entries being dropped. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 8859772195c6 Author: johnc Date: 2010-02-09 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8859772195c6 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate. Summary: Update and display the timers associated with these flags for all safepoints. Reviewed-by: ysr, jcoomes ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/runtimeService.cpp Changeset: 0414c1049f15 Author: iveresov Date: 2010-02-11 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0414c1049f15 6923991: G1: improve scalability of RSet scanning Summary: Implemented block-based work stealing. Moved copying during the rset scanning phase to the main copying phase. Made the size of rset table depend on the region size. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 58add740c4ee Author: johnc Date: 2010-02-16 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/58add740c4ee Merge ! src/share/vm/includeDB_core Changeset: e7b1cc79bd25 Author: kvn Date: 2010-02-16 16:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7b1cc79bd25 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Summary: Define AdapterHandlerTableIterator class as non product instead of debug. Reviewed-by: never ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 106f41e88c85 Author: never Date: 2010-02-16 20:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/106f41e88c85 6877221: Endless deoptimizations in OSR nmethod Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: b4b440360f1e Author: twisti Date: 2010-02-18 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b4b440360f1e 6926782: CodeBuffer size too small after 6921352 Summary: After 6921352 the CodeBuffer size was too small. Reviewed-by: kvn, never ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: 3b687c53c266 Author: twisti Date: 2010-02-18 06:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3b687c53c266 6927165: Zero S/390 fixes Summary: Fixes two failures on 31-bit S/390. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp Changeset: 72f1840531a4 Author: twisti Date: 2010-02-18 10:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72f1840531a4 Merge Changeset: 1f341bb67b5b Author: trims Date: 2010-02-18 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f341bb67b5b Merge Changeset: 6c9796468b91 Author: trims Date: 2010-02-18 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c9796468b91 6927886: Bump the HS17 build number to 10 Summary: Update the HS17 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version From lana.steuck at sun.com Thu Mar 4 22:53:59 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:53:59 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b84 for changeset 32c0cf01d555 Message-ID: <20100305065359.9313F43E73@hg.openjdk.java.net> Changeset: 6c0ccabb430d Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/6c0ccabb430d Added tag jdk7-b84 for changeset 32c0cf01d555 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:54:06 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:54:06 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b84 for changeset 8bc02839eee4 Message-ID: <20100305065406.7BDCD43E74@hg.openjdk.java.net> Changeset: 8424512588ff Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8424512588ff Added tag jdk7-b84 for changeset 8bc02839eee4 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:54:39 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:54:39 +0000 Subject: hg: jdk7/tl/jdk: 5 new changesets Message-ID: <20100305065612.5781943E77@hg.openjdk.java.net> Changeset: a9b4fde406d4 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a9b4fde406d4 Added tag jdk7-b84 for changeset 7cb9388bb1a1 ! .hgtags Changeset: 2ba381560071 Author: dcherepanov Date: 2010-02-12 19:58 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ba381560071 6705345: Enable multiple file selection in AWT FileDialog Reviewed-by: art, anthony, alexp ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h + test/java/awt/FileDialog/MultipleMode/MultipleMode.html + test/java/awt/FileDialog/MultipleMode/MultipleMode.java Changeset: d6d2de6ee2d1 Author: lana Date: 2010-02-19 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6d2de6ee2d1 Merge Changeset: b396584a3e64 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b396584a3e64 Merge - make/java/text/FILES_java.gmk Changeset: c2d29e5695c2 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2d29e5695c2 Merge From lana.steuck at sun.com Thu Mar 4 23:03:30 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 07:03:30 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100305070338.B02E543E79@hg.openjdk.java.net> Changeset: 75d5bd12eb86 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/75d5bd12eb86 Added tag jdk7-b84 for changeset d9cd5b8286e4 ! .hgtags Changeset: 136bfc679462 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/136bfc679462 Merge Changeset: c55733ceed61 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c55733ceed61 Merge From jonathan.gibbons at sun.com Fri Mar 5 16:14:47 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Sat, 06 Mar 2010 00:14:47 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100306001501.DFE7143F6E@hg.openjdk.java.net> Changeset: a23282f17d0b Author: jjg Date: 2010-03-05 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a23282f17d0b 6930108: IllegalArgumentException in AbstractDiagnosticFormatter for tools/javac/api/TestJavacTaskScanner.jav Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/api/TestResolveError.java Changeset: a4f3b97c8028 Author: jjg Date: 2010-03-05 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a4f3b97c8028 Merge From kelly.ohair at sun.com Sat Mar 6 15:00:11 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Mar 2010 23:00:11 +0000 Subject: hg: jdk7/tl/jdk: 6915983: testing problems, adjusting list of tests, needs some investigation Message-ID: <20100306230106.5B8CA440AE@hg.openjdk.java.net> Changeset: 58b44ac0b10d Author: ohair Date: 2010-03-06 14:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58b44ac0b10d 6915983: testing problems, adjusting list of tests, needs some investigation Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt From kelly.ohair at sun.com Sat Mar 6 15:01:34 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Mar 2010 23:01:34 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20100306230134.7DB32440AF@hg.openjdk.java.net> Changeset: 4d7419e4b759 Author: ohair Date: 2010-03-06 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4d7419e4b759 6928700: Configure top repo for JPRT testing Reviewed-by: alanb, jjg ! make/jprt.properties + test/Makefile Changeset: f3664d6879ab Author: ohair Date: 2010-03-06 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f3664d6879ab Merge From jack.bates at gmail.com Tue Mar 9 08:49:43 2010 From: jack.bates at gmail.com (Jack Bates) Date: Tue, 09 Mar 2010 08:49:43 -0800 Subject: new URI("http://example.com/foo#bar").resolve("") In-Reply-To: <4B5EDD28.8050706@sun.com> References: <1264270499.31527.21.camel@tad> <4B5D7E89.2000203@sun.com> <1264463496.23253.49.camel@tad> <4B5EDD28.8050706@sun.com> Message-ID: <1268153383.32027.0.camel@selene> Thanks again Michael, is there a URL for this bug? Can I check its status? On Tue, 2010-01-26 at 12:16 +0000, Michael McMahon wrote: > Jack, > > 6920138 is the reference for this bug. > > Thanks, > Michael. > > Jack Bates wrote: > > Hi Michael, > > > > On Mon, 2010-01-25 at 11:20 +0000, Michael McMahon wrote: > > > >> I don't think this is a bug. Everything to the > >> right of the final "/" in the original URI is discarded when resolving > >> against any relative URI. > >> > > > > I think you're referring to step 6a) in RFC2396 section 5.2, > > > > a) All but the last segment of the base URI's path component is > > copied to the buffer. In other words, any characters after the > > last (right-most) slash character, if any, are excluded. > > > > - however step 2) is, > > > > 2) If the path component is empty and the scheme, authority, and > > query components are undefined, then it is a reference to the > > current document and we are done. Otherwise, the reference URI's > > query and fragment components are defined as found (or not found) > > within the URI reference and not inherited from the base URI. > > > > In my example the path component is empty and the scheme, authority, and > > query components are undefined, which is why I expect it to return, > > "http://example.com/foo" > > > > There's also an example in appendix C.2, > > > > An empty reference refers to the start of the current document. > > > > <> = (current document) > > > > RFC3986 section 5.4.1 gives some more examples, > > > > Within a representation with a well defined base URI of > > > > http://a/b/c/d;p?q > > > > a relative reference is transformed to its target URI as follows. > > > > [...] > > > > "" = "http://a/b/c/d;p?q" > > > > - however when I run, > > > > import java.net.URI; > > > > public class Test > > { > > public static void main(String[] args) throws Exception > > { > > System.out.println(new URI("http://a/b/c/d;p?q").resolve("")); > > } > > } > > > > - instead of "http://a/b/c/d;p?q", it outputs, > > > > $ java Test > > http://a/b/c/ > > $ > > > > RFC3986 section 5.2.2 also includes, > > > > if (R.path == "") then > > T.path = Base.path; > > > > > >> So, "foo#bar" is correctly discarded, leaving the new URI > >> > >> http://example.com/ > >> > >> That would be my reading of RFC2396 anyway. > >> > >> - Michael. > >> > >> Jack Bates wrote: > >> > >>> new URI("http://example.com/foo#bar").resolve("") > >>> > >>> ^ I expect this to return "http://example.com/foo", but when I run, > >>> > >>> import java.net.URI; > >>> > >>> public class Test > >>> { > >>> public static void main(String[] args) throws Exception > >>> { > >>> System.out.println(new URI("http://example.com/foo#bar").resolve("")); > >>> } > >>> } > >>> > >>> - it outputs, > >>> > >>> $ java Test > >>> http://example.com/ > >>> $ > >>> > >>> Do you think this is a bug? > >>> > >>> I'm running OpenJDK 6, but I can find only cosmetic differences between > >>> URI.java in the version I'm running and URI.java in, > >>> http://www.java.net/download/openjdk/jdk7/promoted/b80/openjdk-7-ea-src-b80-21_jan_2010.zip > >>> > >>> - so I assume the issue (if it is an issue) still exists? > >>> > >>> > >> > > > > > > From Christopher.Hegarty at Sun.COM Tue Mar 9 09:41:16 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Tue, 09 Mar 2010 17:41:16 +0000 Subject: new URI("http://example.com/foo#bar").resolve("") In-Reply-To: <1268153383.32027.0.camel@selene> References: <1264270499.31527.21.camel@tad> <4B5D7E89.2000203@sun.com> <1264463496.23253.49.camel@tad> <4B5EDD28.8050706@sun.com> <1268153383.32027.0.camel@selene> Message-ID: <4B96883C.9050808@sun.com> http://bugs.sun.com/view_bug.do?bug_id=6920138 -Chris. Jack Bates wrote: > Thanks again Michael, is there a URL for this bug? Can I check its > status? > > On Tue, 2010-01-26 at 12:16 +0000, Michael McMahon wrote: >> Jack, >> >> 6920138 is the reference for this bug. >> >> Thanks, >> Michael. >> >> Jack Bates wrote: >>> Hi Michael, >>> >>> On Mon, 2010-01-25 at 11:20 +0000, Michael McMahon wrote: >>> >>>> I don't think this is a bug. Everything to the >>>> right of the final "/" in the original URI is discarded when resolving >>>> against any relative URI. >>>> >>> I think you're referring to step 6a) in RFC2396 section 5.2, >>> >>> a) All but the last segment of the base URI's path component is >>> copied to the buffer. In other words, any characters after the >>> last (right-most) slash character, if any, are excluded. >>> >>> - however step 2) is, >>> >>> 2) If the path component is empty and the scheme, authority, and >>> query components are undefined, then it is a reference to the >>> current document and we are done. Otherwise, the reference URI's >>> query and fragment components are defined as found (or not found) >>> within the URI reference and not inherited from the base URI. >>> >>> In my example the path component is empty and the scheme, authority, and >>> query components are undefined, which is why I expect it to return, >>> "http://example.com/foo" >>> >>> There's also an example in appendix C.2, >>> >>> An empty reference refers to the start of the current document. >>> >>> <> = (current document) >>> >>> RFC3986 section 5.4.1 gives some more examples, >>> >>> Within a representation with a well defined base URI of >>> >>> http://a/b/c/d;p?q >>> >>> a relative reference is transformed to its target URI as follows. >>> >>> [...] >>> >>> "" = "http://a/b/c/d;p?q" >>> >>> - however when I run, >>> >>> import java.net.URI; >>> >>> public class Test >>> { >>> public static void main(String[] args) throws Exception >>> { >>> System.out.println(new URI("http://a/b/c/d;p?q").resolve("")); >>> } >>> } >>> >>> - instead of "http://a/b/c/d;p?q", it outputs, >>> >>> $ java Test >>> http://a/b/c/ >>> $ >>> >>> RFC3986 section 5.2.2 also includes, >>> >>> if (R.path == "") then >>> T.path = Base.path; >>> >>> >>>> So, "foo#bar" is correctly discarded, leaving the new URI >>>> >>>> http://example.com/ >>>> >>>> That would be my reading of RFC2396 anyway. >>>> >>>> - Michael. >>>> >>>> Jack Bates wrote: >>>> >>>>> new URI("http://example.com/foo#bar").resolve("") >>>>> >>>>> ^ I expect this to return "http://example.com/foo", but when I run, >>>>> >>>>> import java.net.URI; >>>>> >>>>> public class Test >>>>> { >>>>> public static void main(String[] args) throws Exception >>>>> { >>>>> System.out.println(new URI("http://example.com/foo#bar").resolve("")); >>>>> } >>>>> } >>>>> >>>>> - it outputs, >>>>> >>>>> $ java Test >>>>> http://example.com/ >>>>> $ >>>>> >>>>> Do you think this is a bug? >>>>> >>>>> I'm running OpenJDK 6, but I can find only cosmetic differences between >>>>> URI.java in the version I'm running and URI.java in, >>>>> http://www.java.net/download/openjdk/jdk7/promoted/b80/openjdk-7-ea-src-b80-21_jan_2010.zip >>>>> >>>>> - so I assume the issue (if it is an issue) still exists? >>>>> >>>>> >>>> >>> >> > > From jack.bates at gmail.com Tue Mar 9 10:02:13 2010 From: jack.bates at gmail.com (Jack Bates) Date: Tue, 09 Mar 2010 10:02:13 -0800 Subject: new URI("http://example.com/foo#bar").resolve("") In-Reply-To: <4B96883C.9050808@sun.com> References: <1264270499.31527.21.camel@tad> <4B5D7E89.2000203@sun.com> <1264463496.23253.49.camel@tad> <4B5EDD28.8050706@sun.com> <1268153383.32027.0.camel@selene> <4B96883C.9050808@sun.com> Message-ID: <1268157733.32027.1.camel@selene> Thanks Chris On Tue, 2010-03-09 at 17:41 +0000, Christopher Hegarty -Sun Microsystems Ireland wrote: > http://bugs.sun.com/view_bug.do?bug_id=6920138 > > -Chris. > > Jack Bates wrote: > > Thanks again Michael, is there a URL for this bug? Can I check its > > status? > > > > On Tue, 2010-01-26 at 12:16 +0000, Michael McMahon wrote: > >> Jack, > >> > >> 6920138 is the reference for this bug. > >> > >> Thanks, > >> Michael. > >> > >> Jack Bates wrote: > >>> Hi Michael, > >>> > >>> On Mon, 2010-01-25 at 11:20 +0000, Michael McMahon wrote: > >>> > >>>> I don't think this is a bug. Everything to the > >>>> right of the final "/" in the original URI is discarded when resolving > >>>> against any relative URI. > >>>> > >>> I think you're referring to step 6a) in RFC2396 section 5.2, > >>> > >>> a) All but the last segment of the base URI's path component is > >>> copied to the buffer. In other words, any characters after the > >>> last (right-most) slash character, if any, are excluded. > >>> > >>> - however step 2) is, > >>> > >>> 2) If the path component is empty and the scheme, authority, and > >>> query components are undefined, then it is a reference to the > >>> current document and we are done. Otherwise, the reference URI's > >>> query and fragment components are defined as found (or not found) > >>> within the URI reference and not inherited from the base URI. > >>> > >>> In my example the path component is empty and the scheme, authority, and > >>> query components are undefined, which is why I expect it to return, > >>> "http://example.com/foo" > >>> > >>> There's also an example in appendix C.2, > >>> > >>> An empty reference refers to the start of the current document. > >>> > >>> <> = (current document) > >>> > >>> RFC3986 section 5.4.1 gives some more examples, > >>> > >>> Within a representation with a well defined base URI of > >>> > >>> http://a/b/c/d;p?q > >>> > >>> a relative reference is transformed to its target URI as follows. > >>> > >>> [...] > >>> > >>> "" = "http://a/b/c/d;p?q" > >>> > >>> - however when I run, > >>> > >>> import java.net.URI; > >>> > >>> public class Test > >>> { > >>> public static void main(String[] args) throws Exception > >>> { > >>> System.out.println(new URI("http://a/b/c/d;p?q").resolve("")); > >>> } > >>> } > >>> > >>> - instead of "http://a/b/c/d;p?q", it outputs, > >>> > >>> $ java Test > >>> http://a/b/c/ > >>> $ > >>> > >>> RFC3986 section 5.2.2 also includes, > >>> > >>> if (R.path == "") then > >>> T.path = Base.path; > >>> > >>> > >>>> So, "foo#bar" is correctly discarded, leaving the new URI > >>>> > >>>> http://example.com/ > >>>> > >>>> That would be my reading of RFC2396 anyway. > >>>> > >>>> - Michael. > >>>> > >>>> Jack Bates wrote: > >>>> > >>>>> new URI("http://example.com/foo#bar").resolve("") > >>>>> > >>>>> ^ I expect this to return "http://example.com/foo", but when I run, > >>>>> > >>>>> import java.net.URI; > >>>>> > >>>>> public class Test > >>>>> { > >>>>> public static void main(String[] args) throws Exception > >>>>> { > >>>>> System.out.println(new URI("http://example.com/foo#bar").resolve("")); > >>>>> } > >>>>> } > >>>>> > >>>>> - it outputs, > >>>>> > >>>>> $ java Test > >>>>> http://example.com/ > >>>>> $ > >>>>> > >>>>> Do you think this is a bug? > >>>>> > >>>>> I'm running OpenJDK 6, but I can find only cosmetic differences between > >>>>> URI.java in the version I'm running and URI.java in, > >>>>> http://www.java.net/download/openjdk/jdk7/promoted/b80/openjdk-7-ea-src-b80-21_jan_2010.zip > >>>>> > >>>>> - so I assume the issue (if it is an issue) still exists? > >>>>> > >>>>> > >>>> > >>> > >> > > > > > > From Christopher.Hegarty at Sun.COM Wed Mar 10 02:53:52 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 10 Mar 2010 10:53:52 +0000 Subject: Code Review 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Message-ID: <4B977A40.4030801@Sun.COM> Hi Alan, Michael, Trivial change. 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun If java/net/MulticastSocket/NoLoopbackPackets.java is run in a batch which contains all the MulticastSocket tests then it will fail on reruns with java.lang.NoSuchMethodError: Sender.. The reason it fails is that there is another test, java/net/MulticastSocket/SetOutgoingIf.java, that has a class named Sender. This test is typically run after NoLoopbackPackets so its Sender class gets left over in the classes directory and is used in subsequest runs of NoLoopbackPackets. The Sender class in NoLoopbackPackets is not compatible with the Sender class in SetOutgoingIf. NoLoopbackPackets should define Sender as an internal class avoiding this name conflict. Also remove hardcoded port number. Webrev: http://cr.openjdk.java.net/~chegar/6933618/webrev.00/ Thanks, -Chris. From Alan.Bateman at Sun.COM Wed Mar 10 04:32:43 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 10 Mar 2010 12:32:43 +0000 Subject: Code Review 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun In-Reply-To: <4B977A40.4030801@Sun.COM> References: <4B977A40.4030801@Sun.COM> Message-ID: <4B97916B.2000506@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Alan, Michael, > > Trivial change. > > 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun > > If java/net/MulticastSocket/NoLoopbackPackets.java is run in a batch > which contains all the MulticastSocket tests then it will fail on > reruns with java.lang.NoSuchMethodError: Sender.. > > The reason it fails is that there is another test, > java/net/MulticastSocket/SetOutgoingIf.java, that has a class named > Sender. This test is typically run after NoLoopbackPackets so its > Sender class gets left over in the classes directory and is used in > subsequest runs of NoLoopbackPackets. The Sender class in > NoLoopbackPackets is not compatible with the Sender class in > SetOutgoingIf. > > NoLoopbackPackets should define Sender as an internal class avoiding > this name conflict. Also remove hardcoded port number. > > Webrev: > http://cr.openjdk.java.net/~chegar/6933618/webrev.00/ > > Thanks, > -Chris. Looks okay to me - one small suggestion is to close msock in a finally block so that the file descriptor usage doesn't creep up during these samevm runs. -Alan. From Christopher.Hegarty at Sun.COM Wed Mar 10 06:42:16 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 10 Mar 2010 14:42:16 +0000 Subject: Code Review 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun In-Reply-To: <4B97916B.2000506@sun.com> References: <4B977A40.4030801@Sun.COM> <4B97916B.2000506@sun.com> Message-ID: <4B97AFC8.8090409@Sun.COM> On 10/03/2010 12:32, Alan Bateman wrote: > ...... > Looks okay to me - one small suggestion is to close msock in a finally > block so that the file descriptor usage doesn't creep up during these > samevm runs. Ah, good catch! Webrev updated. Thanks, -Chris. > > -Alan. From christopher.hegarty at sun.com Wed Mar 10 06:47:32 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 10 Mar 2010 14:47:32 +0000 Subject: hg: jdk7/tl/jdk: 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Message-ID: <20100310144817.62C2D445BC@hg.openjdk.java.net> Changeset: 47958f76babc Author: chegar Date: 2010-03-10 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47958f76babc 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Reviewed-by: alanb ! test/java/net/MulticastSocket/NoLoopbackPackets.java From Christopher.Hegarty at Sun.COM Wed Mar 10 09:31:34 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 10 Mar 2010 17:31:34 +0000 Subject: Code Review 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Message-ID: <4B97D776.70901@Sun.COM> Hi Alan, Michael, Summary: Make test run in othervm. java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode with a NullPointer Exception cause by CookieHandlerTest$MyCookieHandler.put(CookieHandlerTest.java:131) The CookieHandlerTest$MyCookieHandler the HTTP protocol handler is using is installed during the run of another test, java/net/CookieHandler/CookieHandlerTest.java. This is clearly not supposed to be installed during the HttpResponseCode test. In fact, it may also have a negative effect on other HTTP releated tests. CookieHandlerTest should be run in othervm mode so that the default cookie handler installed does not effect subsequent tests. Webrev: http://cr.openjdk.java.net/~chegar/6933629/webrev.00/webrev/ Thanks, -Chris. From Alan.Bateman at Sun.COM Wed Mar 10 09:34:35 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 10 Mar 2010 17:34:35 +0000 Subject: Code Review 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode In-Reply-To: <4B97D776.70901@Sun.COM> References: <4B97D776.70901@Sun.COM> Message-ID: <4B97D82B.1070800@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Alan, Michael, > > Summary: Make test run in othervm. > > java/net/HttpURLConnection/HttpResponseCode.java fails if run in > samevm mode with a NullPointer Exception cause by > CookieHandlerTest$MyCookieHandler.put(CookieHandlerTest.java:131) > > The CookieHandlerTest$MyCookieHandler the HTTP protocol handler is > using is installed during the run of another test, > java/net/CookieHandler/CookieHandlerTest.java. This is clearly not > supposed to be installed during the HttpResponseCode test. In fact, it > may also have a negative effect on other HTTP releated tests. > CookieHandlerTest should be run in othervm mode so that the default > cookie handler installed does not effect subsequent tests. > > Webrev: > http://cr.openjdk.java.net/~chegar/6933629/webrev.00/webrev/ > > Thanks, > -Chris. Looks OK to me. Don't forget to remove it from test/ProblemList.txt. -Alan. From Christopher.Hegarty at Sun.COM Wed Mar 10 09:37:26 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 10 Mar 2010 17:37:26 +0000 Subject: Code Review 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode In-Reply-To: <4B97D82B.1070800@sun.com> References: <4B97D776.70901@Sun.COM> <4B97D82B.1070800@sun.com> Message-ID: <4B97D8D6.5080307@Sun.COM> On 10/03/2010 17:34, Alan Bateman wrote: > ... > Looks OK to me. Don't forget to remove it from test/ProblemList.txt. Ah yes, good call. I'll remove it and do a few jprt runs before pushing. Thanks, -Chris. > > -Alan. From martinrb at google.com Wed Mar 10 15:14:43 2010 From: martinrb at google.com (martinrb at google.com) Date: Wed, 10 Mar 2010 23:14:43 +0000 Subject: hg: jdk7/tl/jdk: 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Message-ID: <20100310231507.8C5B944633@hg.openjdk.java.net> Changeset: 467484e025d6 Author: martin Date: 2010-03-10 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/467484e025d6 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Summary: uc >> 16 == 0 is superior to (int) (char) uc == uc Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/sun/nio/cs/Surrogate.java From jonathan.gibbons at sun.com Wed Mar 10 16:24:36 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 11 Mar 2010 00:24:36 +0000 Subject: hg: jdk7/tl/langtools: 6933914: fix missing newlines Message-ID: <20100311002440.1FD1244644@hg.openjdk.java.net> Changeset: 9871ce4fd56f Author: jjg Date: 2010-03-10 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9871ce4fd56f 6933914: fix missing newlines Reviewed-by: ohair ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/api/6731573/Erroneous.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/varargs/T6746184.java - test/tools/javap/T6305779.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java From Christopher.Hegarty at Sun.COM Thu Mar 11 06:25:37 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 11 Mar 2010 14:25:37 +0000 Subject: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm Message-ID: <4B98FD61.6090106@sun.com> Hi Alan, Michael, Another small test change! This test requires interruptible I/O to verify that the accept implementation does not impact on fd0. UseVMInterruptibleIO needs to be explicitly enabled since it is now disabled by default, see 6554406. Without interruptible I/O the thread executing the accept gets blocked and the test harness cannot perform the necessary cleanup required by samevm. Note: This test is only applicable to Solaris, since it is the only platform to support interruptible I/O, but should still pass on all platforms. Webrev: http://cr.openjdk.java.net/~chegar/6934054/webrev.00/webrev/ Thanks, -Chris. From Alan.Bateman at Sun.COM Thu Mar 11 07:42:25 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 11 Mar 2010 15:42:25 +0000 Subject: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm In-Reply-To: <4B98FD61.6090106@sun.com> References: <4B98FD61.6090106@sun.com> Message-ID: <4B990F61.9070401@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Hi Alan, Michael, > > Another small test change! > > This test requires interruptible I/O to verify that the accept > implementation does not impact on fd0. UseVMInterruptibleIO needs to > be explicitly enabled since it is now disabled by default, see > 6554406. Without interruptible I/O the thread executing the accept > gets blocked and the test harness cannot perform the necessary cleanup > required by samevm. > > Note: This test is only applicable to Solaris, since it is the only > platform to support interruptible I/O, but should still pass on all > platforms. > > Webrev: > http://cr.openjdk.java.net/~chegar/6934054/webrev.00/webrev/ > > Thanks, > -Chris. I'm tempted to suggest that the best thing is to just hg rm the test as it's not very useful. If you want to keep it then the changes looks OK to me. One suggestion is to have AReader implement Closeable and have the close implement just do sock.close(). -Alan. From Christopher.Hegarty at Sun.COM Thu Mar 11 07:50:16 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 11 Mar 2010 15:50:16 +0000 Subject: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm In-Reply-To: <4B990F61.9070401@sun.com> References: <4B98FD61.6090106@sun.com> <4B990F61.9070401@sun.com> Message-ID: <4B991138.1000304@sun.com> Alan Bateman wrote: > ..... > I'm tempted to suggest that the best thing is to just hg rm the test as > it's not very useful. If you want to keep it then the changes looks OK This had crossed my mind. If you agree then I think I will just remove it. -Chris. > to me. One suggestion is to have AReader implement Closeable and have > the close implement just do sock.close(). > > -Alan. From Alan.Bateman at Sun.COM Thu Mar 11 07:59:27 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 11 Mar 2010 15:59:27 +0000 Subject: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm In-Reply-To: <4B991138.1000304@sun.com> References: <4B98FD61.6090106@sun.com> <4B990F61.9070401@sun.com> <4B991138.1000304@sun.com> Message-ID: <4B99135F.9050603@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > > > Alan Bateman wrote: >> ..... >> I'm tempted to suggest that the best thing is to just hg rm the test >> as it's not very useful. If you want to keep it then the changes >> looks OK > > This had crossed my mind. If you agree then I think I will just remove > it. The bazooka would be a fine choice. From christopher.hegarty at sun.com Thu Mar 11 08:20:14 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 16:20:14 +0000 Subject: hg: jdk7/tl/jdk: 6934054: java/net/Socket/FDClose.java return error in samevm Message-ID: <20100311162054.0273244735@hg.openjdk.java.net> Changeset: 07e1c5a90c6a Author: chegar Date: 2010-03-11 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07e1c5a90c6a 6934054: java/net/Socket/FDClose.java return error in samevm Summary: test is no longer useful Reviewed-by: alanb ! test/ProblemList.txt - test/java/net/Socket/FDClose.java From Michael.McMahon at Sun.COM Thu Mar 11 08:37:57 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 11 Mar 2010 16:37:57 +0000 Subject: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy In-Reply-To: <4B8E5F0A.2000104@sun.com> References: <4B8E5F0A.2000104@sun.com> Message-ID: <4B991C65.6010907@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Hi All, > > This patch fixes a problem where the socks proxy implementation does > not honor the timeout specified in Socket.connect(SocketAddress, > timeout). In fact, it uses the read timeout set with setSoTimeout > since the socks implementation opens a connection to the socks server > to perform the socks protocol. This also violates the spec since a > timeout of 0 means block indefinitely. > > It is worth noting that the proposed fix changes the current behavior > as specified above; SO_TIMEOUT no longer impacts on the timeout when > using a socks proxy. > Do you mean there that SO_TIMEOUT does not affect the connect behavior, but it still works when reading off the socket after it is connected? Thanks Michael From Christopher.Hegarty at Sun.COM Thu Mar 11 09:14:23 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 11 Mar 2010 17:14:23 +0000 Subject: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy In-Reply-To: <4B991C65.6010907@sun.com> References: <4B8E5F0A.2000104@sun.com> <4B991C65.6010907@sun.com> Message-ID: <4B9924EF.9070100@sun.com> Michael McMahon wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> Hi All, >> >> This patch fixes a problem where the socks proxy implementation does >> not honor the timeout specified in Socket.connect(SocketAddress, >> timeout). In fact, it uses the read timeout set with setSoTimeout >> since the socks implementation opens a connection to the socks server >> to perform the socks protocol. This also violates the spec since a >> timeout of 0 means block indefinitely. >> >> It is worth noting that the proposed fix changes the current behavior >> as specified above; SO_TIMEOUT no longer impacts on the timeout when >> using a socks proxy. >> > Do you mean there that SO_TIMEOUT does not affect the connect behavior, > but it still works > when reading off the socket after it is connected? Yes, this is correct. Since we need to read off the socket during the connection process to implement the socks protocol, the SO_TIMEOUT (before this fix) had an impact on the connection timeout. After this change SO_TIMEOUT will only impact on SocketInputStream reads, connection timeout can be implemented through the Socket.connect API. -Chris. > > Thanks > Michael From Michael.McMahon at Sun.COM Thu Mar 11 09:34:54 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Thu, 11 Mar 2010 17:34:54 +0000 Subject: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy In-Reply-To: <4B9924EF.9070100@sun.com> References: <4B8E5F0A.2000104@sun.com> <4B991C65.6010907@sun.com> <4B9924EF.9070100@sun.com> Message-ID: <4B9929BE.8050902@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Michael McMahon wrote: >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> Hi All, >>> >>> This patch fixes a problem where the socks proxy implementation does >>> not honor the timeout specified in Socket.connect(SocketAddress, >>> timeout). In fact, it uses the read timeout set with setSoTimeout >>> since the socks implementation opens a connection to the socks >>> server to perform the socks protocol. This also violates the spec >>> since a timeout of 0 means block indefinitely. >>> >>> It is worth noting that the proposed fix changes the current >>> behavior as specified above; SO_TIMEOUT no longer impacts on the >>> timeout when using a socks proxy. >>> >> Do you mean there that SO_TIMEOUT does not affect the connect >> behavior, but it still works >> when reading off the socket after it is connected? > > Yes, this is correct. Since we need to read off the socket during the > connection process to implement the socks protocol, the SO_TIMEOUT > (before this fix) had an impact on the connection timeout. After this > change SO_TIMEOUT will only impact on SocketInputStream reads, > connection timeout can be implemented through the Socket.connect API. > Ok, just checking that. The fix looks fine to me then. - Michael From christopher.hegarty at sun.com Thu Mar 11 09:39:36 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 17:39:36 +0000 Subject: hg: jdk7/tl/jdk: 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Message-ID: <20100311173955.C60B444747@hg.openjdk.java.net> Changeset: c342735a3e58 Author: chegar Date: 2010-03-11 17:37 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c342735a3e58 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieHandlerTest.java From christopher.hegarty at sun.com Thu Mar 11 09:51:09 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 17:51:09 +0000 Subject: hg: jdk7/tl/jdk: 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Message-ID: <20100311175127.DA7B84474C@hg.openjdk.java.net> Changeset: c6f8c58ed51a Author: chegar Date: 2010-03-11 17:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f8c58ed51a 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Reviewed-by: michaelm, chegar Contributed-by: damjan.jov at gmail.com ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java + test/java/net/Socket/SocksConnectTimeout.java From xueming.shen at sun.com Thu Mar 11 14:13:54 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 11 Mar 2010 22:13:54 +0000 Subject: hg: jdk7/tl/jdk: 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Message-ID: <20100311221413.1ACC14478B@hg.openjdk.java.net> Changeset: ee385b4e2ffb Author: sherman Date: 2010-03-11 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee385b4e2ffb 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Summary: system property sun.zip.disableMemoryMapping to disable mmap use Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h From Christopher.Hegarty at Sun.COM Fri Mar 12 06:18:25 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 12 Mar 2010 14:18:25 +0000 Subject: 6370908: Add support for HTTP_CONNECT proxy in Socket class In-Reply-To: <9e89675b1003040329t65467149w247734c889e7c467@mail.gmail.com> References: <9e89675b1002210509n4e705eb7y8846b93eeccc3c12@mail.gmail.com> <4B829C73.7090905@Sun.COM> <9e89675b1002240928t36885dafhe60b26cdde9126e1@mail.gmail.com> <4B8BCF3B.7020105@Sun.COM> <9e89675b1003011003t28c3d70eod7f7c08068b2afb@mail.gmail.com> <4B8E6A69.9070003@sun.com> <9e89675b1003040329t65467149w247734c889e7c467@mail.gmail.com> Message-ID: <4B9A4D31.5090005@Sun.COM> Hi Damjan, I've come full circle on this and created a new webrev based on your original proposal. Using the current HTTP protocol handler that already implements the tunneling and authentication. See the updated webrev: http://cr.openjdk.java.net/~chegar/6370908/webrev.01/ I've used "more" reflection to avoid creating static dependencies on the internal http implementation. The addition of a test will ensure that any changes to the implementation will be picked up very quickly, i.e. the test will break. -Chris. On 04/03/2010 11:29, Damjan Jovanovic wrote: > Hi Chris > > Proxies are on the application layer, TCP is a transport layer > protocol below. Using the application layer to establish in-band > transport layer connections is dodgy by its very nature. The multiple > sockets to get through an HTTP proxy issue is not unique to Java. > Here's a quick look at how several open source applications have dealt > with the problem: > > * prtunnel (http://joshbeam.com/software/prtunnel.php), a C > application for tunneling through several proxy types, only supports > no authentication and BASIC HTTP authentication. proxychains does the > same. XChat does the same. > * ntlmaps.sourceforge.net and similar apps work by acting as another > proxy themselves. They can use as many sockets as necessary on the > outgoing end to the second proxy. > * pidgin (www.pidgin.im), an instant messaging app, has very good > proxy support including NTLM authentication for HTTP proxies. It only > uses a single socket and requires the proxy to use a persistent > connection. proxytunnel (proxytunnel.sourceforge.net) does the same. > > I like pidgin's solution the best, and since it even works with NTLM, > the other authentication types should be easy. Most HTTP 1.1 proxies > should support persistent connections - after all, that feature > benefits proxies the most. So we should be able to get away with one > socket in most cases, maybe even for all commonly used HTTP proxies. > I'll try to do some tests this weekend. > > Also, nothing stops a Socket from changing its impl. We would need a > very clever impl that somehow remembers options that have been set and > reapplies them to the new impl, but there's no theoretical reason why > connect() cannot create as many impls as are necessary to get through > the proxy. > > On the other hand, all Java's solutions for connecting through proxies > are poor: SOCKS 4 is broken > (http://mail.openjdk.java.net/pipermail/net-dev/2010-February/001580.html), > server sockets are unsupported, datagram sockets are unsupported, and > all java.nio channels are unsupported. But then proxies aren't so > common any more: ADSL routers typically use NAT instead, and we don't > provide any NAT traversal support for server sockets and datagram > sockets using UPnP's IGD or Bonjour's NAT-PMP protocols. Maybe we > should? > > Damjan > > On Wed, Mar 3, 2010 at 3:55 PM, Christopher Hegarty -Sun Microsystems > Ireland wrote: >> Hi Damjan, >> >> After spending more time looking at this, I still haven't found an elegant >> solution for supporting authentication. >> >> You've correctly identified an issue with the fact we have no guaranteed of >> a persistent connection with the proxy. Changing the socket identity is not >> as simple as overriding getIn/OutputStream since other methods like >> setting/getting options, close, shutdown, etc use the impls fd field. This >> field needs to refer to the correct file descriptor object. >> >> There is quite a lot of logic in the http protocol handler to support >> authentication and looking at it again it is closely tied to the handler >> implementation itself. I would prefer to reuse this code if possible. >> >> Have you made any progress on this? If we want authentication it may be more >> straight forward to revert back to your original proposal of using >> HttpURLConnection directly and having its socket exposed. Though, I'm still >> not convinced of this solution either. >> >> -Chris >> >> Damjan Jovanovic wrote: >>> >>> Hi Chris >>> >>> I think that without authentication, you'll just get another RFE >>> asking for authentication. Many corporate proxies require >>> authentication, especially for a liberal request like CONNECT. >>> >>> java.net.Socket seems to delegate its impl field's methods. If we have >>> another, internal socket in HttpConnectSocketImpl, and we override >>> getInputStream() and getOutputStream() in HttpConnectSocketImpl to >>> return this inner socket's streams, we can open as many sockets as we >>> like during authentication, and then just store the last one that >>> connected as this internal socket? This seems like a way to "change >>> socket identities" like I suggested. >>> >>> Thank you >>> Damjan >>> >>> On Mon, Mar 1, 2010 at 4:29 PM, Christopher Hegarty - Sun Microsystems >>> Ireland wrote: >>>> >>>> Hi Damjan, >>>> >>>> Sorry for the delayed response, I'm juggling too many things! >>>> >>>> I'm not sure how important Authentication is here. I initially pointed it >>>> out, but hadn't done sufficient scoping so didn't encounter these issues. >>>> Let me take another look at it, but I'm wondering if we should just >>>> proceed >>>> with it as is for now. Authentication is the reason that this RFE never >>>> made >>>> it back yet and has been sitting for a few years now. >>> >>> >>>> -Chris. >>>> >>>> On 24/02/2010 17:28, Damjan Jovanovic wrote: >>>>> >>>>> On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun >>>>> Microsystems Ireland wrote: >>>>>> >>>>>> Hi Damjan, >>>>>> >>>>>> Actually, I did some work on this back in 2006 (!), but never finished >>>>>> it. I >>>>>> brought the changes into a mercurial repository and created a webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/ >>>>>> >>>>>> Basically, this change provides the basic functionality, without any >>>>>> frills, >>>>>> authentication, etc. I think for tunneling sockets through a HTTP proxy >>>>>> it >>>>>> should be sufficient. Do you require authentication in your >>>>>> environment? >>>>>> >>>>>> To have authentication supported we would need to restructure the HTTP >>>>>> protocol handler in sun.net.www.protocol.http.HttpURLConnection, so >>>>>> that >>>>>> we >>>>>> can take advantage of the authentication schemes it already supports. >>>>>> Not >>>>>> a >>>>>> big deal, just needs to be done. >>>>> >>>>> The major problem with authentication is that there is no guarantee >>>>> the HTTP connection will be persistent. Authentication generally >>>>> requires making additional requests to the proxy, so we may need to >>>>> connect to the proxy more than once. Each socket can only connect >>>>> once, and the HttpConnectSocketImpl is a single immutable socket, so >>>>> it cannot directly be used for authentication. >>>>> >>>>> A workaround may be to connect with a different socket for the initial >>>>> request, and then connect through the HttpConnectSocketImpl's own >>>>> socket for the final request. But then the problem becomes that if the >>>>> proxy doesn't require authentication, the initial socket will succeed >>>>> in connecting to the target host, and it will be too late to stop it >>>>> and use HttpConnectSocketImpl's own socket... >>>>> >>>>> So we have the following options: >>>>> 1. Only support proxies for which the entire request chain can be made >>>>> over a single persistent connection. >>>>> 2. Connect to each target host up to twice, once when we believe the >>>>> proxy needs authentication but doesn't, and then again later with the >>>>> real socket. This will probably kill protocols that use one shot >>>>> connections, like FTP. >>>>> 3. Find some way to change socket identities, then use as many sockets >>>>> as it takes and somehow adopt the final socket into >>>>> HttpConnectSocketImpl's own. >>>>> >>>>> Any suggestions? >>>>> >>>>>> -Chris. >>>>> >>>>> Damjan >>>>> >>>>>> On 21/02/2010 13:09, Damjan Jovanovic wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>>> From http://bugs.sun.com/view_bug.do?bug_id=6370908 >>>>>>> >>>>>>> This RFE is basically about getting a TCP socket to tunnel through an >>>>>>> HTTP proxy using the HTTP CONNECT request. >>>>>>> >>>>>>> I've found a hack to get this feature to work, using sun.net.* >>>>>>> packages and lots of reflection. Would it be acceptable to use this >>>>>>> solution (with some way to change socket identity) in a patch that >>>>>>> adds a java.net.HttpSocketImpl class similar to the >>>>>>> java.net.SocksSocketImpl class that's already used to tunnel through >>>>>>> SOCKS proxies? If not, in what other way should such a patch be done? >>>>>>> >>>>>>> Thank you >>>>>>> Damjan Jovanovic >>>>>>> >>>>>>> import java.net.*; >>>>>>> import java.io.*; >>>>>>> import java.lang.reflect.*; >>>>>>> >>>>>>> public class TunnelProxy { >>>>>>> private static Socket connectThroughHTTPProxy(String proxyHost, >>>>>>> int >>>>>>> proxyPort, String destinationHost, int destinationPort) throws >>>>>>> Exception >>>>>>> { >>>>>>> URL destinationURL = new URL("http://" + destinationHost >>>>>>> + >>>>>>> ":" + >>>>>>> destinationPort); >>>>>>> sun.net.www.protocol.http.HttpURLConnection conn = >>>>>>> new sun.net.www.protocol.http.HttpURLConnection( >>>>>>> destinationURL, new >>>>>>> java.net.Proxy(java.net.Proxy.Type.HTTP, new >>>>>>> InetSocketAddress(proxyHost, proxyPort))); >>>>>>> conn.setDoInput(true); >>>>>>> conn.setDoOutput(true); >>>>>>> conn.connect(); >>>>>>> conn.doTunneling(); >>>>>>> Field httpField = >>>>>>> conn.getClass().getDeclaredField("http"); >>>>>>> httpField.setAccessible(true); >>>>>>> sun.net.www.http.HttpClient httpClient = >>>>>>> (sun.net.www.http.HttpClient) httpField.get(conn); >>>>>>> Field serverSocketField = >>>>>>> sun.net.NetworkClient.class.getDeclaredField("serverSocket"); >>>>>>> serverSocketField.setAccessible(true); >>>>>>> Socket socket = (Socket) >>>>>>> serverSocketField.get(httpClient); >>>>>>> return socket; >>>>>>> } >>>>>>> >>>>>>> public static void main(String[] args) throws Exception { >>>>>>> System.setProperty("java.net.useSystemProxies", "true"); >>>>>>> InputStream in = connectThroughHTTPProxy(args[0], >>>>>>> Integer.parseInt(args[1]), args[2], >>>>>>> Integer.parseInt(args[3])).getInputStream(); >>>>>>> byte[] bytes = new byte[1024]; >>>>>>> int bytesRead; >>>>>>> while ((bytesRead = in.read(bytes)) != -1) { >>>>>>> System.out.print(new String(bytes)); >>>>>>> } >>>>>>> } >>>>>>> } >> From jonathan.gibbons at sun.com Fri Mar 12 12:01:35 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 12 Mar 2010 20:01:35 +0000 Subject: hg: jdk7/tl/langtools: 6934224: update langtools/test/Makefile Message-ID: <20100312200137.D4E54448C3@hg.openjdk.java.net> Changeset: f856c0942c06 Author: jjg Date: 2010-03-12 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f856c0942c06 6934224: update langtools/test/Makefile Reviewed-by: ohair ! make/jprt.properties ! test/Makefile From kelly.ohair at sun.com Fri Mar 12 12:15:43 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 12 Mar 2010 20:15:43 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100312201621.2443B448C8@hg.openjdk.java.net> Changeset: bf6eb240e718 Author: ohair Date: 2010-03-12 09:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf6eb240e718 6933294: Fix some test/Makefile issues around Linux ARCH settings, better defaults Reviewed-by: jjg ! test/Makefile ! test/ProblemList.txt Changeset: cda90ceb7176 Author: ohair Date: 2010-03-12 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cda90ceb7176 Merge ! test/ProblemList.txt From jonathan.gibbons at sun.com Fri Mar 12 15:25:00 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 12 Mar 2010 23:25:00 +0000 Subject: hg: jdk7/tl: 6934712: run langtools jtreg tests from top level test/Makefile Message-ID: <20100312232500.DB883448F5@hg.openjdk.java.net> Changeset: bbd817429100 Author: jjg Date: 2010-03-12 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/bbd817429100 6934712: run langtools jtreg tests from top level test/Makefile Reviewed-by: ohair ! test/Makefile From kelly.ohair at sun.com Fri Mar 12 17:47:22 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 13 Mar 2010 01:47:22 +0000 Subject: hg: jdk7/tl: 6934759: Add langtools testing to jprt control builds Message-ID: <20100313014722.B3FF544918@hg.openjdk.java.net> Changeset: c60ed0f6d91a Author: ohair Date: 2010-03-12 17:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/c60ed0f6d91a 6934759: Add langtools testing to jprt control builds Reviewed-by: jjg ! make/jprt.properties From Christopher.Hegarty at Sun.COM Mon Mar 15 06:41:03 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Mon, 15 Mar 2010 13:41:03 +0000 Subject: Code Review 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Message-ID: <4B9E38EF.3030900@Sun.COM> Hi Alan, Michael, The test has a connected TCP socket and performs individual writes of only 2 bytes on one end. It does not read off the data on the other end. After 8 writes, on the 9th, the write blocks. Clearly the send buffer has not been exhausted, but after some experimenting it can be shown that you can only write more data if some is read off. This only occurs when both ends of the socket are on the same host. This is a result of the Solaris TCP Fusion feature. See the bug description for more details. The solution is to amend the test to have the producer and consumer on separate threads. Also, cleaned up a few NPE I noticed when running the test on various systems. Webrev: http://cr.openjdk.java.net/~chegar/6934923/webrev.00/webrev/ -Chris. From Alan.Bateman at Sun.COM Mon Mar 15 12:17:58 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 15 Mar 2010 19:17:58 +0000 Subject: Code Review 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 In-Reply-To: <4B9E38EF.3030900@Sun.COM> References: <4B9E38EF.3030900@Sun.COM> Message-ID: <4B9E87E6.1060405@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Alan, Michael, > > The test has a connected TCP socket and performs individual writes of > only 2 bytes on one end. It does not read off the data on the other > end. After 8 writes, on the 9th, the write blocks. Clearly the send > buffer has not been exhausted, but after some experimenting it can be > shown that you can only write more data if some is read off. > > This only occurs when both ends of the socket are on the same host. > This is a result of the Solaris TCP Fusion feature. See the bug > description for more details. > > The solution is to amend the test to have the producer and consumer on > separate threads. Also, cleaned up a few NPE I noticed when running > the test on various systems. > > Webrev: > http://cr.openjdk.java.net/~chegar/6934923/webrev.00/webrev/ > > -Chris. Looks okay to me. -Alan From christopher.hegarty at sun.com Tue Mar 16 03:06:44 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 16 Mar 2010 10:06:44 +0000 Subject: hg: jdk7/tl/jdk: 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Message-ID: <20100316100704.71B7644D83@hg.openjdk.java.net> Changeset: f88f6f8ddd21 Author: chegar Date: 2010-03-16 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f88f6f8ddd21 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Reviewed-by: alanb ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java From Christopher.Hegarty at Sun.COM Tue Mar 16 03:28:04 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Tue, 16 Mar 2010 10:28:04 +0000 Subject: Code Review 6935199: java/net regression tests failing with Assertions Message-ID: <4B9F5D34.7070903@sun.com> Hi Michael, The following tests have incorrect assertion failures if run with assertions enabled: test/java/net/CookieHandler/TestHttpCookie.java test/java/net/URLClassLoader/closetest/CloseTest.java Webrev: http://cr.openjdk.java.net/~chegar/6935199/webrev.00/webrev/ -Chris. From Michael.McMahon at Sun.COM Tue Mar 16 03:36:35 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Tue, 16 Mar 2010 10:36:35 +0000 Subject: Code Review 6935199: java/net regression tests failing with Assertions In-Reply-To: <4B9F5D34.7070903@sun.com> References: <4B9F5D34.7070903@sun.com> Message-ID: <4B9F5F33.2070201@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Hi Michael, > > The following tests have incorrect assertion failures if run with > assertions enabled: > test/java/net/CookieHandler/TestHttpCookie.java Would it be better to just remove the assertion in the first one as well? > test/java/net/URLClassLoader/closetest/CloseTest.java > > Webrev: > http://cr.openjdk.java.net/~chegar/6935199/webrev.00/webrev/ > > -Chris. From Christopher.Hegarty at Sun.COM Tue Mar 16 03:45:28 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Tue, 16 Mar 2010 10:45:28 +0000 Subject: Code Review 6935199: java/net regression tests failing with Assertions In-Reply-To: <4B9F5F33.2070201@sun.com> References: <4B9F5D34.7070903@sun.com> <4B9F5F33.2070201@sun.com> Message-ID: <4B9F6148.5030502@sun.com> Michael McMahon wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> Hi Michael, >> >> The following tests have incorrect assertion failures if run with >> assertions enabled: >> test/java/net/CookieHandler/TestHttpCookie.java > Would it be better to just remove the assertion in the first one as well? I don't think it really matters. The assertion just verifies that the that the construction is not called with null, which seems reasonable. It is just this one specific test that doesn't conform since it verifies that NPE is actually thrown. If you feel strongly I can remove it. -Chris. > >> test/java/net/URLClassLoader/closetest/CloseTest.java >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/6935199/webrev.00/webrev/ >> >> -Chris. > From Michael.McMahon at Sun.COM Tue Mar 16 06:54:06 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Tue, 16 Mar 2010 13:54:06 +0000 Subject: Code Review 6935199: java/net regression tests failing with Assertions In-Reply-To: <4B9F6148.5030502@sun.com> References: <4B9F5D34.7070903@sun.com> <4B9F5F33.2070201@sun.com> <4B9F6148.5030502@sun.com> Message-ID: <4B9F8D7E.4030408@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > > > Michael McMahon wrote: >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> Hi Michael, >>> >>> The following tests have incorrect assertion failures if run with >>> assertions enabled: >>> test/java/net/CookieHandler/TestHttpCookie.java >> Would it be better to just remove the assertion in the first one as >> well? > > I don't think it really matters. The assertion just verifies that the > that the construction is not called with null, which seems reasonable. > It is just this one specific test that doesn't conform since it > verifies that NPE is actually thrown. If you feel strongly I can > remove it. > Personally, I think it would be better. It doesn't seem right to have code that works around an assertion. - Michael From Christopher.Hegarty at Sun.COM Tue Mar 16 07:14:25 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Tue, 16 Mar 2010 14:14:25 +0000 Subject: Code Review 6935199: java/net regression tests failing with Assertions In-Reply-To: <4B9F8D7E.4030408@sun.com> References: <4B9F5D34.7070903@sun.com> <4B9F5F33.2070201@sun.com> <4B9F6148.5030502@sun.com> <4B9F8D7E.4030408@sun.com> Message-ID: <4B9F9241.5070504@sun.com> Michael McMahon wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> >> >> Michael McMahon wrote: >>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>> Hi Michael, >>>> >>>> The following tests have incorrect assertion failures if run with >>>> assertions enabled: >>>> test/java/net/CookieHandler/TestHttpCookie.java >>> Would it be better to just remove the assertion in the first one as >>> well? >> >> I don't think it really matters. The assertion just verifies that the >> that the construction is not called with null, which seems reasonable. >> It is just this one specific test that doesn't conform since it >> verifies that NPE is actually thrown. If you feel strongly I can >> remove it. >> > Personally, I think it would be better. It doesn't seem right to have > code that works > around an assertion. OK, I'll just remove it. -Chris. > > - Michael From christopher.hegarty at sun.com Tue Mar 16 07:34:19 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 16 Mar 2010 14:34:19 +0000 Subject: hg: jdk7/tl/jdk: 6935199: java/net regression tests failing with Assertions Message-ID: <20100316143439.1BD6244DC5@hg.openjdk.java.net> Changeset: 895a1211b2e1 Author: chegar Date: 2010-03-16 14:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/895a1211b2e1 6935199: java/net regression tests failing with Assertions Reviewed-by: michaelm ! test/ProblemList.txt ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/URLClassLoader/closetest/CloseTest.java From Christopher.Hegarty at Sun.COM Tue Mar 16 10:22:43 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Tue, 16 Mar 2010 17:22:43 +0000 Subject: Code Review 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Message-ID: <4B9FBE63.80806@sun.com> Alan, Michael, java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build because number of open file descriptors exceeds 20. Instead of a hardcoded number, the test should check the number of file descriptors does not increase much before and after its work. Also, run in othervm so that the file descriptors in the particular process will be consistent. Webrev: http://cr.openjdk.java.net/~chegar/6935233/webrev.00/webrev/ -Chris. From weijun.wang at sun.com Tue Mar 16 18:55:37 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Wed, 17 Mar 2010 01:55:37 +0000 Subject: hg: jdk7/tl/jdk: 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Message-ID: <20100317015556.BC14844E6E@hg.openjdk.java.net> Changeset: 0500f7306cbe Author: weijun Date: 2010-03-17 09:55 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0500f7306cbe 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Reviewed-by: wetmore ! test/sun/security/tools/jarsigner/oldsig.sh From weijun.wang at sun.com Thu Mar 18 03:27:35 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 18 Mar 2010 10:27:35 +0000 Subject: hg: jdk7/tl/jdk: 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Message-ID: <20100318102854.BFEB644088@hg.openjdk.java.net> Changeset: 2796f839e337 Author: weijun Date: 2010-03-18 18:26 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2796f839e337 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java From Alan.Bateman at Sun.COM Thu Mar 18 04:23:20 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 18 Mar 2010 11:23:20 +0000 Subject: Code Review 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build In-Reply-To: <4B9FBE63.80806@sun.com> References: <4B9FBE63.80806@sun.com> Message-ID: <4BA20D28.4010005@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Alan, Michael, > > java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with > modules build because number of open file descriptors exceeds 20. > Instead of a hardcoded number, the test should check the number of > file descriptors does not increase much before and after its work. > > Also, run in othervm so that the file descriptors in the particular > process will be consistent. > > Webrev: > http://cr.openjdk.java.net/~chegar/6935233/webrev.00/webrev/ > > -Chris. It still seems very fragile and doesn't take into account that the number of file descriptors might legitimately increase. How about changing the test to use ulimit on Solaris/Linux to set the hard limit to a smallish limit (say 1024) and then run and accept >1024 connections. If the original leak were to come back then it should fail reliably. -Alan. From Christopher.Hegarty at Sun.COM Thu Mar 18 06:16:39 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 13:16:39 +0000 Subject: Code Review 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build In-Reply-To: <4BA20D28.4010005@sun.com> References: <4B9FBE63.80806@sun.com> <4BA20D28.4010005@sun.com> Message-ID: <4BA227B7.6010900@sun.com> Alan Bateman wrote: > .... > It still seems very fragile and doesn't take into account that the > number of file descriptors might legitimately increase. How about > changing the test to use ulimit on Solaris/Linux to set the hard limit > to a smallish limit (say 1024) and then run and accept >1024 > connections. If the original leak were to come back then it should fail > reliably. I've updated the webrev as per your suggestion. http://cr.openjdk.java.net/~chegar/6935233/webrev.00/webrev/ -Chris. > > -Alan. From Alan.Bateman at Sun.COM Thu Mar 18 06:36:02 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 18 Mar 2010 13:36:02 +0000 Subject: Code Review 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build In-Reply-To: <4BA227B7.6010900@sun.com> References: <4B9FBE63.80806@sun.com> <4BA20D28.4010005@sun.com> <4BA227B7.6010900@sun.com> Message-ID: <4BA22C42.6020409@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Alan Bateman wrote: >> .... >> It still seems very fragile and doesn't take into account that the >> number of file descriptors might legitimately increase. How about >> changing the test to use ulimit on Solaris/Linux to set the hard >> limit to a smallish limit (say 1024) and then run and accept >1024 >> connections. If the original leak were to come back then it should >> fail reliably. > > I've updated the webrev as per your suggestion. > http://cr.openjdk.java.net/~chegar/6935233/webrev.00/webrev/ This looks much better - thanks for doing this. -Alan. From ptisnovs at redhat.com Thu Mar 18 07:38:17 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Thu, 18 Mar 2010 15:38:17 +0100 Subject: Please review new regression test for java.net.* API Message-ID: <4BA23AD9.4060906@redhat.com> Hi, please review new regression test for java.net.* API. This test check if the cacerts keytool database is configured properly and SSL is really working. The test should not fail if SSL is working (in other case it simply throws IOException). Webrev si available at http://cr.openjdk.java.net/~ptisnovs/TestHttps/ Thanks in advance Pavel Tisnovsky From Alan.Bateman at Sun.COM Thu Mar 18 06:56:43 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 18 Mar 2010 13:56:43 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA23AD9.4060906@redhat.com> References: <4BA23AD9.4060906@redhat.com> Message-ID: <4BA2311B.1090300@sun.com> Pavel Tisnovsky wrote: > Hi, > > please review new regression test for java.net.* API. This test check > if the cacerts keytool database is configured properly and SSL is > really working. The test should not fail if SSL is working (in other > case it simply throws IOException). Webrev si available at > http://cr.openjdk.java.net/~ptisnovs/TestHttps/ > > Thanks in advance > Pavel Tisnovsky I suspect the dependency on verisign.com will be problematic. Isn't SSL already covered by the javax.net and https tests? -Alan. From ahughes at redhat.com Thu Mar 18 07:24:42 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 14:24:42 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA2311B.1090300@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> Message-ID: <17c6771e1003180724k398dcd6em9df569277b27e11e@mail.gmail.com> On 18 March 2010 13:56, Alan Bateman wrote: > Pavel Tisnovsky wrote: >> >> Hi, >> >> please review new regression test for java.net.* API. This test check if >> the cacerts keytool database is configured properly and SSL is really >> working. The test should not fail if SSL is working (in other case it simply >> throws IOException). Webrev si available at >> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >> >> Thanks in advance >> Pavel Tisnovsky > > I suspect the dependency on verisign.com will be problematic. ?Isn't SSL > already covered by the javax.net and https tests? > > -Alan. > None of them actually test a HTTPS server with a certificate AFAICS. Pavel's run on the JTreg tests on a build and it didn't pick up an empty cacerts file, whereas this test does. A different https server could be used; the URL of the JAXP tarballs would work. Pavel, + * Copyright 2001-2003 Sun Microsystems, Inc. All Rights Reserved. is wrong. It should be Copyright 2010 Red Hat, Inc. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 07:28:26 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 14:28:26 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA2311B.1090300@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> Message-ID: <4BA2388A.9020502@sun.com> Alan Bateman wrote: > Pavel Tisnovsky wrote: >> Hi, >> >> please review new regression test for java.net.* API. This test check >> if the cacerts keytool database is configured properly and SSL is >> really working. The test should not fail if SSL is working (in other >> case it simply throws IOException). Webrev si available at >> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >> >> Thanks in advance >> Pavel Tisnovsky > I suspect the dependency on verisign.com will be problematic. Isn't SSL > already covered by the javax.net and https tests? I'm not sure what the prime motivation of the test is. Pavel, can you please elaborate? Reading between the lines I guess the test is verifying that the correct root Certification Authority is installed in cacerts, i.e. the cert from www.verisign.com can be validated. Alan is correct there are already tests for SSL/Https in javax.net, but I believe these use self signed certs, no dependency on cacerts. -Chris. > > -Alan. From ahughes at redhat.com Thu Mar 18 07:39:51 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 14:39:51 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA2388A.9020502@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> Message-ID: <17c6771e1003180739v1a40dd52nabb67a46b8fdecbb@mail.gmail.com> On 18 March 2010 14:28, Christopher Hegarty -Sun Microsystems Ireland wrote: > Alan Bateman wrote: >> >> Pavel Tisnovsky wrote: >>> >>> Hi, >>> >>> please review new regression test for java.net.* API. This test check if >>> the cacerts keytool database is configured properly and SSL is really >>> working. The test should not fail if SSL is working (in other case it simply >>> throws IOException). Webrev si available at >>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>> >>> Thanks in advance >>> Pavel Tisnovsky >> >> I suspect the dependency on verisign.com will be problematic. ?Isn't SSL >> already covered by the javax.net and https tests? > > I'm not sure what the prime motivation of the test is. Pavel, can you please > elaborate? > > Reading between the lines I guess the test is verifying that the correct > ?root Certification Authority is installed in cacerts, i.e. the cert from > www.verisign.com can be validated. > > Alan is correct there are already tests for SSL/Https in javax.net, but I > believe these use self signed certs, no dependency on cacerts. > Sounds like you have things spot on to me, Chris. > -Chris. > >> >> -Alan. > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Alan.Bateman at Sun.COM Thu Mar 18 07:48:44 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 18 Mar 2010 14:48:44 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA2388A.9020502@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> Message-ID: <4BA23D4C.3020500@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > : > > Alan is correct there are already tests for SSL/Https in javax.net, > but I believe these use self signed certs, no dependency on cacerts. OK, in that case adding a new test make sense. The test/java/net tree is probably not the best place though - maybe test/javax/net/ssl? I'm sure there will be suggestions on security-dev on the best way to exercise/test it. -Alan. From ptisnovs at redhat.com Thu Mar 18 08:50:05 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Thu, 18 Mar 2010 16:50:05 +0100 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA2388A.9020502@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> Message-ID: <4BA24BAD.9020206@redhat.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Alan Bateman wrote: >> Pavel Tisnovsky wrote: >>> Hi, >>> >>> please review new regression test for java.net.* API. This test check >>> if the cacerts keytool database is configured properly and SSL is >>> really working. The test should not fail if SSL is working (in other >>> case it simply throws IOException). Webrev si available at >>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>> >>> Thanks in advance >>> Pavel Tisnovsky >> I suspect the dependency on verisign.com will be problematic. Isn't >> SSL already covered by the javax.net and https tests? > > I'm not sure what the prime motivation of the test is. Pavel, can you > please elaborate? > > Reading between the lines I guess the test is verifying that the correct > root Certification Authority is installed in cacerts, i.e. the cert > from www.verisign.com can be validated. Hi Chris, you guessed correctly :-) And we can use other URL if verisign.com is problematic. > > Alan is correct there are already tests for SSL/Https in javax.net, but > I believe these use self signed certs, no dependency on cacerts. > > -Chris. > >> >> -Alan. From Christopher.Hegarty at Sun.COM Thu Mar 18 07:57:07 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 14:57:07 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA24BAD.9020206@redhat.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> Message-ID: <4BA23F43.70203@sun.com> Pavel Tisnovsky wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> Alan Bateman wrote: >>> Pavel Tisnovsky wrote: >>>> Hi, >>>> >>>> please review new regression test for java.net.* API. This test >>>> check if the cacerts keytool database is configured properly and SSL >>>> is really working. The test should not fail if SSL is working (in >>>> other case it simply throws IOException). Webrev si available at >>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>> >>>> Thanks in advance >>>> Pavel Tisnovsky >>> I suspect the dependency on verisign.com will be problematic. Isn't >>> SSL already covered by the javax.net and https tests? >> >> I'm not sure what the prime motivation of the test is. Pavel, can you >> please elaborate? >> >> Reading between the lines I guess the test is verifying that the >> correct root Certification Authority is installed in cacerts, i.e. >> the cert from www.verisign.com can be validated. > > Hi Chris, you guessed correctly :-) And we can use other URL if > verisign.com is problematic. OK, so the test is trying to validate cacerts. Does it make sense to validate this certificate store in a general purpose regression test? The test will of course pass with Sun's priority build and probably RedHats too, since they contain the root certificate for verisign, but an OpenJDK build will not contain it, right? So the test will fail. Security folk: Do we currently have any tests with a dependency on cacerts? -Chris. > >> >> Alan is correct there are already tests for SSL/Https in javax.net, >> but I believe these use self signed certs, no dependency on cacerts. >> >> -Chris. >> >>> >>> -Alan. > From ahughes at redhat.com Thu Mar 18 08:04:40 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 15:04:40 +0000 Subject: Please review new regression test for java.net.* API In-Reply-To: <4BA23F43.70203@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> Message-ID: <17c6771e1003180804q532d147djd19839f03f616d0c@mail.gmail.com> On 18 March 2010 14:57, Christopher Hegarty -Sun Microsystems Ireland wrote: > Pavel Tisnovsky wrote: >> >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> >>> Alan Bateman wrote: >>>> >>>> Pavel Tisnovsky wrote: >>>>> >>>>> Hi, >>>>> >>>>> please review new regression test for java.net.* API. This test check >>>>> if the cacerts keytool database is configured properly and SSL is really >>>>> working. The test should not fail if SSL is working (in other case it simply >>>>> throws IOException). Webrev si available at >>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>> >>>>> Thanks in advance >>>>> Pavel Tisnovsky >>>> >>>> I suspect the dependency on verisign.com will be problematic. ?Isn't SSL >>>> already covered by the javax.net and https tests? >>> >>> I'm not sure what the prime motivation of the test is. Pavel, can you >>> please elaborate? >>> >>> Reading between the lines I guess the test is verifying that the correct >>> ?root Certification Authority is installed in cacerts, i.e. the cert from >>> www.verisign.com can be validated. >> >> Hi Chris, you guessed correctly :-) And we can use other URL if >> verisign.com is problematic. > > OK, so the test is trying to validate cacerts. > > Does it make sense to validate this certificate store in a general purpose > regression test? The test will of course pass with Sun's priority build and > probably RedHats too, since they contain the root certificate for verisign, > but an OpenJDK build will not contain it, right? So the test will fail. > > Security folk: > ?Do we currently have any tests with a dependency on cacerts? > > -Chris. > > >> >>> >>> Alan is correct there are already tests for SSL/Https in javax.net, but I >>> believe these use self signed certs, no dependency on cacerts. >>> >>> -Chris. >>> >>>> >>>> -Alan. >> > Yes, it will fail. >From an OpenJDK build: $ /mnt/builder/jdk7/j2sdk-image/bin/java TestHttps Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty This has been posted about before; OpenJDK currently can't bootstrap itself because it doesn't have a working cacerts store (the JAXP URL uses https). I don't know how to solve this; we can certainly have the cacerts file populated on GNU/Linux systems, but I don't have a clue how you'd do it on Solaris or Windows. How do Sun populate it? Can that be shared? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 08:07:25 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 15:07:25 +0000 Subject: [security-dev 01701]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA24027.2050700@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <4BA24027.2050700@sun.com> Message-ID: <4BA241AD.7020709@sun.com> Sean Mullan wrote: > .... >> >> Security folk: >> Do we currently have any tests with a dependency on cacerts? > > yes, but they would be in the closed tests. So we have your own non public tests for this. Maybe RedHat should take a similar approach then. -Chris. > > --Sean From ahughes at redhat.com Thu Mar 18 08:15:12 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 15:15:12 +0000 Subject: [security-dev 01703]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA241AD.7020709@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <4BA24027.2050700@sun.com> <4BA241AD.7020709@sun.com> Message-ID: <17c6771e1003180815y3ff466e6ncc10fbdf8812c005@mail.gmail.com> On 18 March 2010 15:07, Christopher Hegarty -Sun Microsystems Ireland wrote: > > > Sean Mullan wrote: >> >> .... >>> >>> Security folk: >>> ?Do we currently have any tests with a dependency on cacerts? >> >> yes, but they would be in the closed tests. > > So we have your own non public tests for this. Maybe RedHat should take a > similar approach then. > > -Chris. > >> >> --Sean > We don't really do 'non public' at Red Hat. The patch will be in IcedTea which is publicly available, but it would be better for upstream to remain as in sync with us as possible. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Mar 18 08:16:16 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 15:16:16 +0000 Subject: [security-dev 01702]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA2430D.5020803@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <17c6771e1003180804q532d147djd19839f03f616d0c@mail.gmail.com> <4BA2430D.5020803@sun.com> Message-ID: <17c6771e1003180816lb18e3c0n4055051ee83caaf5@mail.gmail.com> On 18 March 2010 15:13, Sean Mullan wrote: > Andrew John Hughes wrote: > >> This has been posted about before; OpenJDK currently can't bootstrap >> itself because it doesn't have a working cacerts store (the JAXP URL >> uses https). >> >> I don't know how to solve this; we can certainly have the cacerts file >> populated on GNU/Linux systems, but I don't have a clue how you'd do >> it on Solaris or Windows. ?How do Sun populate it? Can that be shared? > > No. The agreements we have with CAs to include root CA certificates are for > our product releases only, we can't (at least not right now) include them in > OpenJDK. > So they don't just use system-installed ones? Ok. > I haven't been following this thread in great detail, but don't existing > JSSE tests cover this? > No, if they did we wouldn't need another test. > --Sean > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Bradford.Wetmore at Sun.COM Thu Mar 18 11:40:05 2010 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Thu, 18 Mar 2010 11:40:05 -0700 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA24BAD.9020206@redhat.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> Message-ID: <4BA27385.9060200@sun.com> I have a couple important tasks to finish ASAP, so if there is more discussion, I'll have to jump in sometime next week, but wanted to add one thing before anything was done: Pavel wrote: > And we can use other URL if verisign.com is problematic. We've tried to limit the reliance on servers outside our control for the open tests and to be as self-contained as possible, tho I'm sure there are still some tests that do this anyway. IMHO, it's not exactly neighborly of OpenJDK to include tests that just bang on someone's server(s) for "testing", even if the volume isn't terribly high. I think we should check with the server's admin before we included such a test in the general repository. In the past we've also had transient network errors (servers or network down), so that was another reason to limit our external dependencies. But they still had to be investigated and took time. Brad On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> Alan Bateman wrote: >>> Pavel Tisnovsky wrote: >>>> Hi, >>>> >>>> please review new regression test for java.net.* API. This test >>>> check if the cacerts keytool database is configured properly and SSL >>>> is really working. The test should not fail if SSL is working (in >>>> other case it simply throws IOException). Webrev si available at >>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>> >>>> Thanks in advance >>>> Pavel Tisnovsky >>> I suspect the dependency on verisign.com will be problematic. Isn't >>> SSL already covered by the javax.net and https tests? >> >> I'm not sure what the prime motivation of the test is. Pavel, can you >> please elaborate? >> >> Reading between the lines I guess the test is verifying that the >> correct root Certification Authority is installed in cacerts, i.e. >> the cert from www.verisign.com can be validated. > > Hi Chris, you guessed correctly :-) And we can use other URL if > verisign.com is problematic. > >> >> Alan is correct there are already tests for SSL/Https in javax.net, >> but I believe these use self signed certs, no dependency on cacerts. >> >> -Chris. >> >>> >>> -Alan. > From ahughes at redhat.com Thu Mar 18 11:45:45 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 18:45:45 +0000 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA27385.9060200@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> Message-ID: <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> On 18 March 2010 18:40, Brad Wetmore wrote: > > I have a couple important tasks to finish ASAP, so if there is more > discussion, I'll have to jump in sometime next week, but wanted to add > one thing before anything was done: > > Pavel wrote: >> And we can use other URL if verisign.com is problematic. > > We've tried to limit the reliance on servers outside our control for the > open tests and to be as self-contained as possible, tho I'm sure there > are still some tests that do this anyway. ?IMHO, it's not exactly > neighborly of OpenJDK to include tests that just bang on someone's > server(s) for "testing", even if the volume isn't terribly high. ?I > think we should check with the server's admin before we included such a > test in the general repository. > > In the past we've also had transient network errors (servers or network > down), so that was another reason to limit our external dependencies. > But they still had to be investigated and took time. > https://jaxp.dev.java.net/files/documents/913/147490 seems an appropriate URL to hit. It's the very URL that causes the OpenJDK build to fail to bootstrap itself and I assume Oracle do control dev.java.net to some degree. > Brad > > > > > > > On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> Alan Bateman wrote: >>>> Pavel Tisnovsky wrote: >>>>> Hi, >>>>> >>>>> please review new regression test for java.net.* API. This test >>>>> check if the cacerts keytool database is configured properly and SSL >>>>> is really working. The test should not fail if SSL is working (in >>>>> other case it simply throws IOException). Webrev si available at >>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>> >>>>> Thanks in advance >>>>> Pavel Tisnovsky >>>> I suspect the dependency on verisign.com will be problematic. ?Isn't >>>> SSL already covered by the javax.net and https tests? >>> >>> I'm not sure what the prime motivation of the test is. Pavel, can you >>> please elaborate? >>> >>> Reading between the lines I guess the test is verifying that the >>> correct ?root Certification Authority is installed in cacerts, i.e. >>> the cert from www.verisign.com can be validated. >> >> Hi Chris, you guessed correctly :-) And we can use other URL if >> verisign.com is problematic. >> >>> >>> Alan is correct there are already tests for SSL/Https in javax.net, >>> but I believe these use self signed certs, no dependency on cacerts. >>> >>> -Chris. >>> >>>> >>>> -Alan. >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 13:56:37 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 20:56:37 +0000 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> Message-ID: <4BA29385.7020600@sun.com> Brad, Pavel, Andrew, I'm also not comfortable with this test, but what bothers me more than the reliance on an external server is the reliance on cacerts. While cacerts (or equivalent) is not part of OpenJDK I don't think it makes sense adding a test to OpenJDK that has a reliance on it. For now I think is makes more sense to add a test like this to wherever in the build process cacerts (or equivalent) is added. -Chris Andrew John Hughes wrote: > On 18 March 2010 18:40, Brad Wetmore wrote: >> I have a couple important tasks to finish ASAP, so if there is more >> discussion, I'll have to jump in sometime next week, but wanted to add >> one thing before anything was done: >> >> Pavel wrote: >>> And we can use other URL if verisign.com is problematic. >> We've tried to limit the reliance on servers outside our control for the >> open tests and to be as self-contained as possible, tho I'm sure there >> are still some tests that do this anyway. IMHO, it's not exactly >> neighborly of OpenJDK to include tests that just bang on someone's >> server(s) for "testing", even if the volume isn't terribly high. I >> think we should check with the server's admin before we included such a >> test in the general repository. >> >> In the past we've also had transient network errors (servers or network >> down), so that was another reason to limit our external dependencies. >> But they still had to be investigated and took time. >> > > https://jaxp.dev.java.net/files/documents/913/147490 seems an > appropriate URL to hit. It's the very URL that causes the OpenJDK > build to fail to bootstrap itself and I assume Oracle do control > dev.java.net to some degree. > >> Brad >> >> >> >> >> >> >> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>> Alan Bateman wrote: >>>>> Pavel Tisnovsky wrote: >>>>>> Hi, >>>>>> >>>>>> please review new regression test for java.net.* API. This test >>>>>> check if the cacerts keytool database is configured properly and SSL >>>>>> is really working. The test should not fail if SSL is working (in >>>>>> other case it simply throws IOException). Webrev si available at >>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>> >>>>>> Thanks in advance >>>>>> Pavel Tisnovsky >>>>> I suspect the dependency on verisign.com will be problematic. Isn't >>>>> SSL already covered by the javax.net and https tests? >>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>> please elaborate? >>>> >>>> Reading between the lines I guess the test is verifying that the >>>> correct root Certification Authority is installed in cacerts, i.e. >>>> the cert from www.verisign.com can be validated. >>> Hi Chris, you guessed correctly :-) And we can use other URL if >>> verisign.com is problematic. >>> >>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>> but I believe these use self signed certs, no dependency on cacerts. >>>> >>>> -Chris. >>>> >>>>> -Alan. > > > From ahughes at redhat.com Thu Mar 18 14:08:56 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 21:08:56 +0000 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA29385.7020600@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> Message-ID: <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland wrote: > Brad, Pavel, Andrew, > > I'm also not comfortable with this test, but what bothers me more than the > reliance on an external server is the reliance on cacerts. While cacerts (or > equivalent) is not part of OpenJDK I don't think it makes sense adding a > test to OpenJDK that has a reliance on it. > > For now I think is makes more sense to add a test like this to wherever in > the build process cacerts (or equivalent) is added. > The problem is nothing does in the OpenJDK build process. So SSL is always broken for OpenJDK builds. Is this something we really want? > -Chris > > Andrew John Hughes wrote: >> >> On 18 March 2010 18:40, Brad Wetmore wrote: >>> >>> I have a couple important tasks to finish ASAP, so if there is more >>> discussion, I'll have to jump in sometime next week, but wanted to add >>> one thing before anything was done: >>> >>> Pavel wrote: >>>> >>>> And we can use other URL if verisign.com is problematic. >>> >>> We've tried to limit the reliance on servers outside our control for the >>> open tests and to be as self-contained as possible, tho I'm sure there >>> are still some tests that do this anyway. ?IMHO, it's not exactly >>> neighborly of OpenJDK to include tests that just bang on someone's >>> server(s) for "testing", even if the volume isn't terribly high. ?I >>> think we should check with the server's admin before we included such a >>> test in the general repository. >>> >>> In the past we've also had transient network errors (servers or network >>> down), so that was another reason to limit our external dependencies. >>> But they still had to be investigated and took time. >>> >> >> https://jaxp.dev.java.net/files/documents/913/147490 seems an >> appropriate URL to hit. ?It's the very URL that causes the OpenJDK >> build to fail to bootstrap itself and I assume Oracle do control >> dev.java.net to some degree. >> >>> Brad >>> >>> >>> >>> >>> >>> >>> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>>> >>>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>>> >>>>> Alan Bateman wrote: >>>>>> >>>>>> Pavel Tisnovsky wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review new regression test for java.net.* API. This test >>>>>>> check if the cacerts keytool database is configured properly and SSL >>>>>>> is really working. The test should not fail if SSL is working (in >>>>>>> other case it simply throws IOException). Webrev si available at >>>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>>> >>>>>>> Thanks in advance >>>>>>> Pavel Tisnovsky >>>>>> >>>>>> I suspect the dependency on verisign.com will be problematic. ?Isn't >>>>>> SSL already covered by the javax.net and https tests? >>>>> >>>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>>> please elaborate? >>>>> >>>>> Reading between the lines I guess the test is verifying that the >>>>> correct ?root Certification Authority is installed in cacerts, i.e. >>>>> the cert from www.verisign.com can be validated. >>>> >>>> Hi Chris, you guessed correctly :-) And we can use other URL if >>>> verisign.com is problematic. >>>> >>>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>>> but I believe these use self signed certs, no dependency on cacerts. >>>>> >>>>> -Chris. >>>>> >>>>>> -Alan. >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 14:12:49 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 21:12:49 +0000 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> Message-ID: <4BA29751.2020104@sun.com> Andrew John Hughes wrote: > On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland > wrote: >> Brad, Pavel, Andrew, >> >> I'm also not comfortable with this test, but what bothers me more than the >> reliance on an external server is the reliance on cacerts. While cacerts (or >> equivalent) is not part of OpenJDK I don't think it makes sense adding a >> test to OpenJDK that has a reliance on it. >> >> For now I think is makes more sense to add a test like this to wherever in >> the build process cacerts (or equivalent) is added. >> > > The problem is nothing does in the OpenJDK build process. So SSL is > always broken for OpenJDK builds. Is this something we really want? This is certainly not ideal, but is a separate issue to the test, right? It seems Sean or someone in the security team should comment on the possibility of adding root CA's to OpenJDK, until then I don't see any requirement for a test. -Chris. > >> -Chris >> >> Andrew John Hughes wrote: >>> On 18 March 2010 18:40, Brad Wetmore wrote: >>>> I have a couple important tasks to finish ASAP, so if there is more >>>> discussion, I'll have to jump in sometime next week, but wanted to add >>>> one thing before anything was done: >>>> >>>> Pavel wrote: >>>>> And we can use other URL if verisign.com is problematic. >>>> We've tried to limit the reliance on servers outside our control for the >>>> open tests and to be as self-contained as possible, tho I'm sure there >>>> are still some tests that do this anyway. IMHO, it's not exactly >>>> neighborly of OpenJDK to include tests that just bang on someone's >>>> server(s) for "testing", even if the volume isn't terribly high. I >>>> think we should check with the server's admin before we included such a >>>> test in the general repository. >>>> >>>> In the past we've also had transient network errors (servers or network >>>> down), so that was another reason to limit our external dependencies. >>>> But they still had to be investigated and took time. >>>> >>> https://jaxp.dev.java.net/files/documents/913/147490 seems an >>> appropriate URL to hit. It's the very URL that causes the OpenJDK >>> build to fail to bootstrap itself and I assume Oracle do control >>> dev.java.net to some degree. >>> >>>> Brad >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>>>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>>>> Alan Bateman wrote: >>>>>>> Pavel Tisnovsky wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review new regression test for java.net.* API. This test >>>>>>>> check if the cacerts keytool database is configured properly and SSL >>>>>>>> is really working. The test should not fail if SSL is working (in >>>>>>>> other case it simply throws IOException). Webrev si available at >>>>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>>>> >>>>>>>> Thanks in advance >>>>>>>> Pavel Tisnovsky >>>>>>> I suspect the dependency on verisign.com will be problematic. Isn't >>>>>>> SSL already covered by the javax.net and https tests? >>>>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>>>> please elaborate? >>>>>> >>>>>> Reading between the lines I guess the test is verifying that the >>>>>> correct root Certification Authority is installed in cacerts, i.e. >>>>>> the cert from www.verisign.com can be validated. >>>>> Hi Chris, you guessed correctly :-) And we can use other URL if >>>>> verisign.com is problematic. >>>>> >>>>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>>>> but I believe these use self signed certs, no dependency on cacerts. >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> -Alan. >>> >>> > > > From ahughes at redhat.com Thu Mar 18 14:23:05 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 21:23:05 +0000 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA29751.2020104@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> <4BA29751.2020104@sun.com> Message-ID: <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> On 18 March 2010 21:12, Christopher Hegarty -Sun Microsystems Ireland wrote: > Andrew John Hughes wrote: >> >> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland >> wrote: >>> >>> Brad, Pavel, Andrew, >>> >>> I'm also not comfortable with this test, but what bothers me more than >>> the >>> reliance on an external server is the reliance on cacerts. While cacerts >>> (or >>> equivalent) is not part of OpenJDK I don't think it makes sense adding a >>> test to OpenJDK that has a reliance on it. >>> >>> For now I think is makes more sense to add a test like this to wherever >>> in >>> the build process cacerts (or equivalent) is added. >>> >> >> The problem is nothing does in the OpenJDK build process. ?So SSL is >> always broken for OpenJDK builds. ?Is this something we really want? > > This is certainly not ideal, but is a separate issue to the test, right? It > seems Sean or someone in the security team should comment on the possibility > of adding root CA's to OpenJDK, until then I don't see any requirement for a > test. > My thoughts too. We have a solution for GNU/Linux where cacerts is populated from the crt files found on the system (installed by Mozilla and the like). I don't know what the equivalent would be for Windows and Solaris though. A quick look on my OpenSolaris box didn't find any crt files but I only looked in installed packages. I presume firefox may bring some in if it's available. > -Chris. > >> >>> -Chris >>> >>> Andrew John Hughes wrote: >>>> >>>> On 18 March 2010 18:40, Brad Wetmore wrote: >>>>> >>>>> I have a couple important tasks to finish ASAP, so if there is more >>>>> discussion, I'll have to jump in sometime next week, but wanted to add >>>>> one thing before anything was done: >>>>> >>>>> Pavel wrote: >>>>>> >>>>>> And we can use other URL if verisign.com is problematic. >>>>> >>>>> We've tried to limit the reliance on servers outside our control for >>>>> the >>>>> open tests and to be as self-contained as possible, tho I'm sure there >>>>> are still some tests that do this anyway. ?IMHO, it's not exactly >>>>> neighborly of OpenJDK to include tests that just bang on someone's >>>>> server(s) for "testing", even if the volume isn't terribly high. ?I >>>>> think we should check with the server's admin before we included such a >>>>> test in the general repository. >>>>> >>>>> In the past we've also had transient network errors (servers or network >>>>> down), so that was another reason to limit our external dependencies. >>>>> But they still had to be investigated and took time. >>>>> >>>> https://jaxp.dev.java.net/files/documents/913/147490 seems an >>>> appropriate URL to hit. ?It's the very URL that causes the OpenJDK >>>> build to fail to bootstrap itself and I assume Oracle do control >>>> dev.java.net to some degree. >>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>>>>> >>>>>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>>>>> >>>>>>> Alan Bateman wrote: >>>>>>>> >>>>>>>> Pavel Tisnovsky wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review new regression test for java.net.* API. This test >>>>>>>>> check if the cacerts keytool database is configured properly and >>>>>>>>> SSL >>>>>>>>> is really working. The test should not fail if SSL is working (in >>>>>>>>> other case it simply throws IOException). Webrev si available at >>>>>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>>>>> >>>>>>>>> Thanks in advance >>>>>>>>> Pavel Tisnovsky >>>>>>>> >>>>>>>> I suspect the dependency on verisign.com will be problematic. ?Isn't >>>>>>>> SSL already covered by the javax.net and https tests? >>>>>>> >>>>>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>>>>> please elaborate? >>>>>>> >>>>>>> Reading between the lines I guess the test is verifying that the >>>>>>> correct ?root Certification Authority is installed in cacerts, i.e. >>>>>>> the cert from www.verisign.com can be validated. >>>>>> >>>>>> Hi Chris, you guessed correctly :-) And we can use other URL if >>>>>> verisign.com is problematic. >>>>>> >>>>>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>>>>> but I believe these use self signed certs, no dependency on cacerts. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>>> -Alan. >>>> >>>> >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From yu-ching.peng at sun.com Thu Mar 18 18:08:20 2010 From: yu-ching.peng at sun.com (yu-ching.peng at sun.com) Date: Fri, 19 Mar 2010 01:08:20 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100319010953.BA4894417C@hg.openjdk.java.net> Changeset: c52f292a8f86 Author: valeriep Date: 2010-03-18 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c52f292a8f86 6695485: SignedObject constructor throws ProviderException if it's called using provider "SunPKCS11-Solaris" Summary: Added checking for RSA key lengths in initSign and initVerify Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Signature.java + test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: df5714cbe76d Author: valeriep Date: 2010-03-18 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df5714cbe76d 6591117: Poor preformance of PKCS#11 security provider compared to Sun default provider Summary: Added internal buffering to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java Changeset: dc42c9d9ca16 Author: valeriep Date: 2010-03-18 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc42c9d9ca16 6837847: PKCS#11 A SecureRandom and a serialization error following installation of 1.5.0_18 Summary: Added a custom readObject method to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java + test/sun/security/pkcs11/SecureRandom/TestDeserialization.java From lana.steuck at sun.com Thu Mar 18 22:17:04 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:17:04 +0000 Subject: hg: jdk7/tl: 3 new changesets Message-ID: <20100319051704.78292441C6@hg.openjdk.java.net> Changeset: 3ddf90b39176 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3ddf90b39176 Added tag jdk7-b85 for changeset cf26288a114b ! .hgtags Changeset: 433a60a9c0bf Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/433a60a9c0bf Merge Changeset: 98505d97a822 Author: lana Date: 2010-03-18 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/98505d97a822 Merge From lana.steuck at sun.com Thu Mar 18 22:17:11 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:17:11 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b85 for changeset c67a9df7bc0c Message-ID: <20100319051713.B7AF2441C7@hg.openjdk.java.net> Changeset: 6253e28826d1 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6253e28826d1 Added tag jdk7-b85 for changeset c67a9df7bc0c ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:19:23 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:19:23 +0000 Subject: hg: jdk7/tl/hotspot: 2 new changesets Message-ID: <20100319051931.87330441C8@hg.openjdk.java.net> Changeset: 418bc80ce139 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/418bc80ce139 Added tag jdk7-b85 for changeset 6c9796468b91 ! .hgtags Changeset: bf823ef06b4f Author: trims Date: 2010-03-08 15:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bf823ef06b4f Added tag hs17-b10 for changeset 418bc80ce139 ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:23:25 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:23:25 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b85 for changeset 6c0ccabb430d Message-ID: <20100319052325.DADBE441CA@hg.openjdk.java.net> Changeset: 81c0f115bbe5 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/81c0f115bbe5 Added tag jdk7-b85 for changeset 6c0ccabb430d ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:23:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:23:32 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b85 for changeset 8424512588ff Message-ID: <20100319052332.21C08441CB@hg.openjdk.java.net> Changeset: 512b0e924a5a Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/512b0e924a5a Added tag jdk7-b85 for changeset 8424512588ff ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:24:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:24:32 +0000 Subject: hg: jdk7/tl/jdk: 22 new changesets Message-ID: <20100319053136.DA606441CE@hg.openjdk.java.net> Changeset: 03cd9e62961f Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03cd9e62961f Added tag jdk7-b85 for changeset b396584a3e64 ! .hgtags Changeset: 840601ac5ab7 Author: rkennke Date: 2010-03-03 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/840601ac5ab7 6892485: Deadlock in SunGraphicsEnvironment / FontManager Summary: Synchronize on correct monitor in SunFontManager. Reviewed-by: igor, prr ! src/share/classes/sun/font/SunFontManager.java Changeset: 1d7db2d5c4c5 Author: minqi Date: 2010-03-08 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1d7db2d5c4c5 6918065: Crash in Java2D blit loop (IntArgbToIntArgbPreSrcOverMaskBlit) in 64bit mode Reviewed-by: igor, bae ! src/share/classes/java/awt/AlphaComposite.java + test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java Changeset: 494f5e4f24da Author: lana Date: 2010-03-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/494f5e4f24da Merge Changeset: e64331144648 Author: rupashka Date: 2010-02-10 15:15 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e64331144648 6848475: JSlider does not display the correct value of its BoundedRangeModel Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6848475/bug6848475.java Changeset: f81c8041ccf4 Author: peytoia Date: 2010-02-11 15:58 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f81c8041ccf4 6909002: Remove indicim.jar and thaiim.jar from JRE and move to samples if needed Reviewed-by: okutsu ! make/com/sun/Makefile Changeset: e2b58a45a426 Author: peytoia Date: 2010-02-12 14:38 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2b58a45a426 6921289: (tz) Support tzdata2010b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e8340332745e Author: malenkov Date: 2010-02-18 17:46 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8340332745e 4498236: RFE: Provide a toString method for PropertyChangeEvent and other classes Reviewed-by: peterz ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyChangeEvent.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test4498236.java Changeset: 5c03237838e1 Author: rupashka Date: 2010-02-27 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c03237838e1 6913758: Specification for SynthViewportUI.paintBorder(...) should mention that this method is never called Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 96205ed1b196 Author: rupashka Date: 2010-02-27 14:47 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/96205ed1b196 6918447: SynthToolBarUI.setBorderToXXXX() methods don't correspond inherited spec. They do nothing. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java Changeset: 621e921a14cd Author: rupashka Date: 2010-02-27 15:09 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/621e921a14cd 6918861: SynthSliderUI.uninstallDefaults() is not called when UI is uninstalled Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6918861/bug6918861.java Changeset: 28741de0bb4a Author: rupashka Date: 2010-02-27 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28741de0bb4a 6923305: SynthSliderUI paints the slider track when the slider's "paintTrack" property is set to false Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6923305/bug6923305.java Changeset: 2bf137beb9bd Author: rupashka Date: 2010-02-27 16:14 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2bf137beb9bd 6929298: The SynthSliderUI#calculateTickRect method should be removed Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java Changeset: d6b3a07c8752 Author: rupashka Date: 2010-03-03 17:57 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6b3a07c8752 6924059: SynthScrollBarUI.configureScrollBarColors() should have spec different from the overridden method Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/6924059/bug6924059.java Changeset: 30c520bd148f Author: rupashka Date: 2010-03-03 20:08 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/30c520bd148f 6913768: With default SynthLookAndFeel instance installed new JTable creation leads to throwing NPE Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java + test/javax/swing/JTable/6913768/bug6913768.java Changeset: f13fc955be62 Author: rupashka Date: 2010-03-03 20:53 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f13fc955be62 6917744: JScrollPane Page Up/Down keys do not handle correctly html tables with different cells contents Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/text/DefaultEditorKit.java + test/javax/swing/JEditorPane/6917744/bug6917744.java + test/javax/swing/JEditorPane/6917744/test.html Changeset: 0622086d82ac Author: malenkov Date: 2010-03-04 21:17 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0622086d82ac 6921644: XMLEncoder generates invalid XML Reviewed-by: peterz ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test5023550.java + test/java/beans/XMLEncoder/Test5023557.java + test/java/beans/XMLEncoder/Test6921644.java Changeset: 79a509ac8f35 Author: lana Date: 2010-03-01 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79a509ac8f35 Merge ! make/com/sun/Makefile - make/java/text/FILES_java.gmk Changeset: 90248595ec35 Author: lana Date: 2010-03-04 13:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90248595ec35 Merge Changeset: 2fe4e72288ce Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fe4e72288ce Merge Changeset: eae6e9ab2606 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eae6e9ab2606 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: dff4f51b73d4 Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dff4f51b73d4 Merge From lana.steuck at sun.com Thu Mar 18 22:37:45 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:37:45 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100319053756.31267441D1@hg.openjdk.java.net> Changeset: b816baf594e3 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b816baf594e3 Added tag jdk7-b85 for changeset 136bfc679462 ! .hgtags Changeset: ef07347428f2 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ef07347428f2 Merge - test/tools/javac/treepostests/TreePosTest.java Changeset: 6fad35d25b1e Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6fad35d25b1e Merge From christopher.hegarty at sun.com Fri Mar 19 06:27:27 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Fri, 19 Mar 2010 13:27:27 +0000 Subject: hg: jdk7/tl/jdk: 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Message-ID: <20100319132803.016AC44258@hg.openjdk.java.net> Changeset: 3bb93c410f41 Author: chegar Date: 2010-03-19 13:07 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3bb93c410f41 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java + test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh From Christopher.Hegarty at Sun.COM Fri Mar 19 07:21:42 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 19 Mar 2010 14:21:42 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String Message-ID: <4BA38876.7010506@Sun.COM> Hi Michael, This is a forward port of a fix that you did in JDK6u11 to JDK7. The source changes are trivial and the very same as what went in 6. The change is for strict conformance of getDisplayName, should return null instead of an empty string. Webrev: http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ -Chris. From Christopher.Hegarty at Sun.COM Fri Mar 19 07:36:20 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 19 Mar 2010 14:36:20 +0000 Subject: Code Review 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Message-ID: <4BA38BE4.7020400@Sun.COM> Hi Michael, This is a forward port of a fix from JDK6u6 to JDK7. The source changes are small and the very same as what went in 6. The HttpClient was changed to use getHostString (does not perform reverse lookup), but the HttpsClient was overlooked at the time. This fix changes the HttpsClient to delegate to the already fixed HttpClient. Webrev: http://cr.openjdk.java.net/~chegar/6632169/webrev.00/webrev/ -Chris. From Alan.Bateman at Sun.COM Fri Mar 19 07:42:52 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 19 Mar 2010 14:42:52 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA38876.7010506@Sun.COM> References: <4BA38876.7010506@Sun.COM> Message-ID: <4BA38D6C.8020308@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Michael, > > This is a forward port of a fix that you did in JDK6u11 to JDK7. The > source changes are trivial and the very same as what went in 6. > > The change is for strict conformance of getDisplayName, should return > null instead of an empty string. > > Webrev: > http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ > > -Chris. Is this really a bug? The spec doesn't prohibit the display name from being the empty string. If the empty string is not allowed then the javadoc should probably be clarified. -Alan. From Christopher.Hegarty at Sun.COM Fri Mar 19 07:51:10 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 19 Mar 2010 14:51:10 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA38D6C.8020308@sun.com> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> Message-ID: <4BA38F5E.1010707@Sun.COM> On 19/03/2010 14:42, Alan Bateman wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> Hi Michael, >> >> This is a forward port of a fix that you did in JDK6u11 to JDK7. The >> source changes are trivial and the very same as what went in 6. >> >> The change is for strict conformance of getDisplayName, should return >> null instead of an empty string. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ >> >> -Chris. > Is this really a bug? The spec doesn't prohibit the display name from > being the empty string. If the empty string is not allowed then the > javadoc should probably be clarified. I vaguely remember the history of this issue (Michael will know better), but the expectation from the API is that while empty string is not disallowed if the display name cannot be retrieved then null should be returned. I think such a clarification is unnecessary in the API, it is such a corner case, and may be confusing. -Chris. > > -Alan. From Michael.McMahon at Sun.COM Fri Mar 19 08:04:13 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 19 Mar 2010 15:04:13 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA38F5E.1010707@Sun.COM> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> Message-ID: <4BA3926D.5030602@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > On 19/03/2010 14:42, Alan Bateman wrote: >> Christopher Hegarty - Sun Microsystems Ireland wrote: >>> Hi Michael, >>> >>> This is a forward port of a fix that you did in JDK6u11 to JDK7. The >>> source changes are trivial and the very same as what went in 6. >>> >>> The change is for strict conformance of getDisplayName, should return >>> null instead of an empty string. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ >>> >>> -Chris. >> Is this really a bug? The spec doesn't prohibit the display name from >> being the empty string. If the empty string is not allowed then the >> javadoc should probably be clarified. > > I vaguely remember the history of this issue (Michael will know > better), but the expectation from the API is that while empty string > is not disallowed if the display name cannot be retrieved then null > should be returned. > > I think such a clarification is unnecessary in the API, it is such a > corner case, and may be confusing. > The javadoc specifies it should be null. So, I don't think we've much choice - Michael > -Chris. > >> >> -Alan. From Christopher.Hegarty at Sun.COM Fri Mar 19 08:07:25 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 19 Mar 2010 15:07:25 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA3926D.5030602@sun.com> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA3926D.5030602@sun.com> Message-ID: <4BA3932D.4080406@Sun.COM> On 19/03/2010 15:04, Michael McMahon wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> On 19/03/2010 14:42, Alan Bateman wrote: >>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>> Hi Michael, >>>> >>>> This is a forward port of a fix that you did in JDK6u11 to JDK7. The >>>> source changes are trivial and the very same as what went in 6. >>>> >>>> The change is for strict conformance of getDisplayName, should return >>>> null instead of an empty string. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ >>>> >>>> -Chris. >>> Is this really a bug? The spec doesn't prohibit the display name from >>> being the empty string. If the empty string is not allowed then the >>> javadoc should probably be clarified. >> >> I vaguely remember the history of this issue (Michael will know >> better), but the expectation from the API is that while empty string >> is not disallowed if the display name cannot be retrieved then null >> should be returned. >> >> I think such a clarification is unnecessary in the API, it is such a >> corner case, and may be confusing. >> > The javadoc specifies it should be null. So, I don't think we've much > choice Will I take this as a positive review ;-) -Chris. > > - Michael > >> -Chris. >> >>> >>> -Alan. > From Alan.Bateman at Sun.COM Fri Mar 19 08:12:51 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 19 Mar 2010 15:12:51 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA38F5E.1010707@Sun.COM> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> Message-ID: <4BA39473.7080506@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > : > I vaguely remember the history of this issue (Michael will know > better), but the expectation from the API is that while empty string > is not disallowed if the display name cannot be retrieved then null > should be returned. > > I think such a clarification is unnecessary in the API, it is such a > corner case, and may be confusing. If the empty string is not allowed then changing the @return to make this clear would be good. -Alan. From Michael.McMahon at Sun.COM Fri Mar 19 08:31:00 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 19 Mar 2010 15:31:00 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA3932D.4080406@Sun.COM> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA3926D.5030602@sun.com> <4BA3932D.4080406@Sun.COM> Message-ID: <4BA398B4.6070505@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > On 19/03/2010 15:04, Michael McMahon wrote: >> Christopher Hegarty - Sun Microsystems Ireland wrote: >>> On 19/03/2010 14:42, Alan Bateman wrote: >>>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>>> Hi Michael, >>>>> >>>>> This is a forward port of a fix that you did in JDK6u11 to JDK7. The >>>>> source changes are trivial and the very same as what went in 6. >>>>> >>>>> The change is for strict conformance of getDisplayName, should return >>>>> null instead of an empty string. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ >>>>> >>>>> -Chris. >>>> Is this really a bug? The spec doesn't prohibit the display name from >>>> being the empty string. If the empty string is not allowed then the >>>> javadoc should probably be clarified. >>> >>> I vaguely remember the history of this issue (Michael will know >>> better), but the expectation from the API is that while empty string >>> is not disallowed if the display name cannot be retrieved then null >>> should be returned. >>> >>> I think such a clarification is unnecessary in the API, it is such a >>> corner case, and may be confusing. >>> >> The javadoc specifies it should be null. So, I don't think we've much >> choice > > Will I take this as a positive review ;-) > Yes. An empty string would have been better than null. But we couldn't change the spec for 6, so it's better to make 7 the same as 6 now I would think. - Michael > -Chris. > >> >> - Michael >> >>> -Chris. >>> >>>> >>>> -Alan. >> From ahughes at redhat.com Fri Mar 19 08:33:22 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 19 Mar 2010 15:33:22 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA39473.7080506@sun.com> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA39473.7080506@sun.com> Message-ID: <17c6771e1003190833w7b1b7aa7rf3950abcbfecefe0@mail.gmail.com> On 19 March 2010 15:12, Alan Bateman wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> >> : >> I vaguely remember the history of this issue (Michael will know better), >> ?but the expectation from the API is that while empty string is not >> disallowed if the display name cannot be retrieved then null should be >> returned. >> >> I think such a clarification is unnecessary in the API, it is such a >> corner case, and may be confusing. > > If the empty string is not allowed then changing the @return to make this > clear would be good. > > -Alan. > The @return currently says 'the display name of this network interface, or null if no display name is available.' 'null if the display name is either null or the empty string' may be clearer. It's these kind of corner cases that are a major pain for users of the API. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Fri Mar 19 09:06:20 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 19 Mar 2010 16:06:20 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <17c6771e1003190833w7b1b7aa7rf3950abcbfecefe0@mail.gmail.com> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA39473.7080506@sun.com> <17c6771e1003190833w7b1b7aa7rf3950abcbfecefe0@mail.gmail.com> Message-ID: <4BA3A0FC.9060902@Sun.COM> How about (thanks to Alan for the wording): * A display name is a human readable String describing the network * device. * - * @return the display name of this network interface, - * or null if no display name is available. + * @return a non-empty string representing the display name of this network + * interface, or null if no display name is available. */ public String getDisplayName() { - return displayName; + /* strict TCK conformance */ + return "".equals(displayName) ? null : displayName; } * A display name is a human readable String describing the network * device. * - * @return the display name of this network interface, - * or null if no display name is available. + * @return a non-empty string representing the display name of this network + * interface, or null if no display name is available. */ public String getDisplayName() { - return displayName; + /* strict TCK conformance */ + return "".equals(displayName) ? null : displayName; } Updated Webrev: http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ -Chris. On 19/03/2010 15:33, Andrew John Hughes wrote: > On 19 March 2010 15:12, Alan Bateman wrote: >> Christopher Hegarty - Sun Microsystems Ireland wrote: >>> >>> : >>> I vaguely remember the history of this issue (Michael will know better), >>> but the expectation from the API is that while empty string is not >>> disallowed if the display name cannot be retrieved then null should be >>> returned. >>> >>> I think such a clarification is unnecessary in the API, it is such a >>> corner case, and may be confusing. >> >> If the empty string is not allowed then changing the @return to make this >> clear would be good. >> >> -Alan. >> > > The @return currently says 'the display name of this network > interface, or null if no display name is available.' > > 'null if the display name is either null or the empty string' may be > clearer. It's these kind of corner cases that are a major pain for > users of the API. From Michael.McMahon at Sun.COM Fri Mar 19 09:08:52 2010 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Fri, 19 Mar 2010 16:08:52 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA3A0FC.9060902@Sun.COM> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA39473.7080506@sun.com> <17c6771e1003190833w7b1b7aa7rf3950abcbfecefe0@mail.gmail.com> <4BA3A0FC.9060902@Sun.COM> Message-ID: <4BA3A194.2070502@sun.com> Looks good to me. - Michael. Christopher Hegarty - Sun Microsystems Ireland wrote: > How about (thanks to Alan for the wording): > > * A display name is a human readable String describing the network > * device. > * > - * @return the display name of this network interface, > - * or null if no display name is available. > + * @return a non-empty string representing the display name of > this network > + * interface, or null if no display name is available. > */ > public String getDisplayName() { > - return displayName; > + /* strict TCK conformance */ > + return "".equals(displayName) ? null : displayName; > } > * A display name is a human readable String describing the network > * device. > * > - * @return the display name of this network interface, > - * or null if no display name is available. > + * @return a non-empty string representing the display name of > this network > + * interface, or null if no display name is available. > */ > public String getDisplayName() { > - return displayName; > + /* strict TCK conformance */ > + return "".equals(displayName) ? null : displayName; > } > > Updated Webrev: > http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ > > -Chris. > > On 19/03/2010 15:33, Andrew John Hughes wrote: >> On 19 March 2010 15:12, Alan Bateman wrote: >>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>> >>>> : >>>> I vaguely remember the history of this issue (Michael will know >>>> better), >>>> but the expectation from the API is that while empty string is not >>>> disallowed if the display name cannot be retrieved then null should be >>>> returned. >>>> >>>> I think such a clarification is unnecessary in the API, it is such a >>>> corner case, and may be confusing. >>> >>> If the empty string is not allowed then changing the @return to make >>> this >>> clear would be good. >>> >>> -Alan. >>> >> >> The @return currently says 'the display name of this network >> interface, or null if no display name is available.' >> >> 'null if the display name is either null or the empty string' may be >> clearer. It's these kind of corner cases that are a major pain for >> users of the API. From ahughes at redhat.com Fri Mar 19 09:11:10 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 19 Mar 2010 16:11:10 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA3A194.2070502@sun.com> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA39473.7080506@sun.com> <17c6771e1003190833w7b1b7aa7rf3950abcbfecefe0@mail.gmail.com> <4BA3A0FC.9060902@Sun.COM> <4BA3A194.2070502@sun.com> Message-ID: <17c6771e1003190911l7db4b2cej2735f90c63de8927@mail.gmail.com> On 19 March 2010 16:08, Michael McMahon wrote: > Looks good to me. > > - Michael. > > Christopher Hegarty - Sun Microsystems Ireland wrote: >> >> How about (thanks to Alan for the wording): >> >> ? ? ?* A display name is a human readable String describing the network >> ? ? ?* device. >> ? ? ?* >> - ? ? * @return the display name of this network interface, >> - ? ? * ? ? ? ? or null if no display name is available. >> + ? ? * @return a non-empty string representing the display name of this >> network >> + ? ? * ? ? ? ? interface, or null if no display name is available. >> ? ? ?*/ >> ? ? public String getDisplayName() { >> - ? ? ? ?return displayName; >> + ? ? ? ?/* strict TCK conformance */ >> + ? ? ? ?return "".equals(displayName) ? null : displayName; >> ? ? } >> ? ? ?* A display name is a human readable String describing the network >> ? ? ?* device. >> ? ? ?* >> - ? ? * @return the display name of this network interface, >> - ? ? * ? ? ? ? or null if no display name is available. >> + ? ? * @return a non-empty string representing the display name of this >> network >> + ? ? * ? ? ? ? interface, or null if no display name is available. >> ? ? ?*/ >> ? ? public String getDisplayName() { >> - ? ? ? ?return displayName; >> + ? ? ? ?/* strict TCK conformance */ >> + ? ? ? ?return "".equals(displayName) ? null : displayName; >> ? ? } >> >> Updated Webrev: >> ?http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ >> >> -Chris. >> >> On 19/03/2010 15:33, Andrew John Hughes wrote: >>> >>> On 19 March 2010 15:12, Alan Bateman ?wrote: >>>> >>>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>>> >>>>> : >>>>> I vaguely remember the history of this issue (Michael will know >>>>> better), >>>>> ?but the expectation from the API is that while empty string is not >>>>> disallowed if the display name cannot be retrieved then null should be >>>>> returned. >>>>> >>>>> I think such a clarification is unnecessary in the API, it is such a >>>>> corner case, and may be confusing. >>>> >>>> If the empty string is not allowed then changing the @return to make >>>> this >>>> clear would be good. >>>> >>>> -Alan. >>>> >>> >>> The @return currently says 'the display name of this network >>> interface, or null if no display name is available.' >>> >>> 'null if the display name is either null or the empty string' may be >>> clearer. ?It's these kind of corner cases that are a major pain for >>> users of the API. > > +1; seen that language on other Javadocs. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Fri Mar 19 10:47:10 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 19 Mar 2010 17:47:10 +0000 Subject: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String In-Reply-To: <4BA398B4.6070505@sun.com> References: <4BA38876.7010506@Sun.COM> <4BA38D6C.8020308@sun.com> <4BA38F5E.1010707@Sun.COM> <4BA3926D.5030602@sun.com> <4BA3932D.4080406@Sun.COM> <4BA398B4.6070505@sun.com> Message-ID: <17c6771e1003191047y6ceb6b29sd32123a3dee51699@mail.gmail.com> On 19 March 2010 15:31, Michael McMahon wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> >> On 19/03/2010 15:04, Michael McMahon wrote: >>> >>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>> >>>> On 19/03/2010 14:42, Alan Bateman wrote: >>>>> >>>>> Christopher Hegarty - Sun Microsystems Ireland wrote: >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> This is a forward port of a fix that you did in JDK6u11 to JDK7. The >>>>>> source changes are trivial and the very same as what went in 6. >>>>>> >>>>>> The change is for strict conformance of getDisplayName, should return >>>>>> null instead of an empty string. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~chegar/6706251/webrev.00/webrev/ >>>>>> >>>>>> -Chris. >>>>> >>>>> Is this really a bug? The spec doesn't prohibit the display name from >>>>> being the empty string. If the empty string is not allowed then the >>>>> javadoc should probably be clarified. >>>> >>>> I vaguely remember the history of this issue (Michael will know >>>> better), but the expectation from the API is that while empty string >>>> is not disallowed if the display name cannot be retrieved then null >>>> should be returned. >>>> >>>> I think such a clarification is unnecessary in the API, it is such a >>>> corner case, and may be confusing. >>>> >>> The javadoc specifies it should be null. So, I don't think we've much >>> choice >> >> Will I take this as a positive review ;-) >> > Yes. An empty string would have been better than null. But we couldn't > change the spec for 6, so it's better to make 7 the same as 6 now I would > think. > We also need this change for OpenJDK6 by the sound of it. > - Michael >> >> -Chris. >> >>> >>> - Michael >>> >>>> -Chris. >>>> >>>>> >>>>> -Alan. >>> > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From kelly.ohair at sun.com Fri Mar 19 18:18:24 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 20 Mar 2010 01:18:24 +0000 Subject: hg: jdk7/tl: 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Message-ID: <20100320011825.0F4AE44311@hg.openjdk.java.net> Changeset: 35d272ef7598 Author: ohair Date: 2010-03-19 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/35d272ef7598 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Reviewed-by: jjg ! test/Makefile From christopher.hegarty at sun.com Mon Mar 22 05:00:30 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 22 Mar 2010 12:00:30 +0000 Subject: hg: jdk7/tl/jdk: 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Message-ID: <20100322120310.8BCBE4465E@hg.openjdk.java.net> Changeset: c40572afb29e Author: chegar Date: 2010-03-22 11:55 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c40572afb29e 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java From Christopher.Hegarty at Sun.COM Mon Mar 22 09:01:31 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Mon, 22 Mar 2010 16:01:31 +0000 Subject: Code Review: 6614957, 6771432, 6766775 Message-ID: <4BA7945B.6070904@Sun.COM> Hi Andrew, Michael, This review is to forward port the following three bugs from 6uXX to JDK7: 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 The source changes are identical to what we have in JDK6uXX. The tests come from 6uXX verbatim with minimal changes (license header, com.sun.net.ssl.internal.ssl.SSLSocketImpl -> sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs together since they directly impact on each other. Please let me know if you require more information to be able to review. -Chris. From ahughes at redhat.com Mon Mar 22 09:01:38 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 22 Mar 2010 16:01:38 +0000 Subject: [security-dev 01725]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA78F93.4080507@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> <4BA29751.2020104@sun.com> <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> <4BA78F93.4080507@sun.com> Message-ID: <17c6771e1003220901q59b8a4a3pffb328a46615d8d6@mail.gmail.com> On 22 March 2010 15:41, Sean Mullan wrote: > Andrew John Hughes wrote: >> >> On 18 March 2010 21:12, Christopher Hegarty -Sun Microsystems Ireland >> wrote: >>> >>> Andrew John Hughes wrote: >>>> >>>> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland >>>> wrote: >>>>> >>>>> Brad, Pavel, Andrew, >>>>> >>>>> I'm also not comfortable with this test, but what bothers me more than >>>>> the >>>>> reliance on an external server is the reliance on cacerts. While >>>>> cacerts >>>>> (or >>>>> equivalent) is not part of OpenJDK I don't think it makes sense adding >>>>> a >>>>> test to OpenJDK that has a reliance on it. >>>>> >>>>> For now I think is makes more sense to add a test like this to wherever >>>>> in >>>>> the build process cacerts (or equivalent) is added. >>>>> >>>> The problem is nothing does in the OpenJDK build process. ?So SSL is >>>> always broken for OpenJDK builds. ?Is this something we really want? >>> >>> This is certainly not ideal, but is a separate issue to the test, right? >>> It >>> seems Sean or someone in the security team should comment on the >>> possibility >>> of adding root CA's to OpenJDK, until then I don't see any requirement >>> for a >>> test. > > I don't have an answer right now - this will take some more investigation > first. > >> My thoughts too. ?We have a solution for GNU/Linux where cacerts is >> populated from the crt files found on the system (installed by Mozilla >> and the like). ?I don't know what the equivalent would be for Windows >> and Solaris though. ?A quick look on my OpenSolaris box didn't find >> any crt files but I only looked in installed packages. ?I presume >> firefox may bring some in if it's available. > > On Windows you can use the "Windows-ROOT" KeyStore type, ex: > > keytool -list -keystore NONE -storetype Windows-ROOT > Ok, so that presumably makes some Windows system call, right? > I haven't tried it, but you could probably use the keytool -importkeystore > option to import all of these certs into the cacerts file. > > On Solaris, you could use the /usr/java/jre/lib/security/cacerts file. > Isn't that exactly what's being installed? Though maybe there's a general solution there of importing from the bootstrap JDK. > > --Sean > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Mon Mar 22 09:45:53 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Mon, 22 Mar 2010 16:45:53 +0000 Subject: [security-dev 01726]: Code Review: 6614957, 6771432, 6766775 In-Reply-To: <4BA7945B.6070904@Sun.COM> References: <4BA7945B.6070904@Sun.COM> Message-ID: <4BA79EC1.7090701@Sun.COM> Dooh! Webrev: http://cr.openjdk.java.net/~chegar/6614957/webrev.00/webrev/ -Chris. On 22/03/2010 16:01, Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Andrew, Michael, > > This review is to forward port the following three bugs from 6uXX to JDK7: > 6614957: HttpsURLConnection not using the set SSLSocketFactory for > creating all its Sockets > 6771432: createSocket() - smpatch fails using 1.6.0_10 because of > "Unconnected sockets not implemented" > 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 > > The source changes are identical to what we have in JDK6uXX. > The tests come from 6uXX verbatim with minimal changes (license header, > com.sun.net.ssl.internal.ssl.SSLSocketImpl -> > sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs together > since they directly impact on each other. > > Please let me know if you require more information to be able to review. > > -Chris. > > From Xuelei.Fan at Sun.COM Mon Mar 22 17:53:51 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Tue, 23 Mar 2010 08:53:51 +0800 Subject: Code Review: 6614957, 6771432, 6766775 In-Reply-To: <4BA7945B.6070904@Sun.COM> References: <4BA7945B.6070904@Sun.COM> Message-ID: <4BA8111F.9050501@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Andrew, Michael, > > This review is to forward port the following three bugs from 6uXX to > JDK7: > 6614957: HttpsURLConnection not using the set SSLSocketFactory for > creating all its Sockets > 6771432: createSocket() - smpatch fails using 1.6.0_10 because of > "Unconnected sockets not implemented" > 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 > > The source changes are identical to what we have in JDK6uXX. > The tests come from 6uXX verbatim with minimal changes (license > header, com.sun.net.ssl.internal.ssl.SSLSocketImpl -> > sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs > together since they directly impact on each other. Sounds good to me. Andrew > > Please let me know if you require more information to be able to review. > > -Chris. > > From Xuelei.Fan at Sun.COM Mon Mar 22 19:40:58 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Tue, 23 Mar 2010 10:40:58 +0800 Subject: [security-dev 01726]: Code Review: 6614957, 6771432, 6766775 In-Reply-To: <4BA79EC1.7090701@Sun.COM> References: <4BA7945B.6070904@Sun.COM> <4BA79EC1.7090701@Sun.COM> Message-ID: <4BA82A3A.4040003@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Dooh! Webrev: > > http://cr.openjdk.java.net/~chegar/6614957/webrev.00/webrev/ > Looks fine to me. Andrew > -Chris. > > On 22/03/2010 16:01, Christopher Hegarty - Sun Microsystems Ireland > wrote: >> Hi Andrew, Michael, >> >> This review is to forward port the following three bugs from 6uXX to >> JDK7: >> 6614957: HttpsURLConnection not using the set SSLSocketFactory for >> creating all its Sockets >> 6771432: createSocket() - smpatch fails using 1.6.0_10 because of >> "Unconnected sockets not implemented" >> 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 >> >> The source changes are identical to what we have in JDK6uXX. >> The tests come from 6uXX verbatim with minimal changes (license header, >> com.sun.net.ssl.internal.ssl.SSLSocketImpl -> >> sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs together >> since they directly impact on each other. >> >> Please let me know if you require more information to be able to review. >> >> -Chris. >> >> From weijun.wang at sun.com Mon Mar 22 19:42:26 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 23 Mar 2010 02:42:26 +0000 Subject: hg: jdk7/tl/jdk: 6586707: NTLM authentication with proxy fails Message-ID: <20100323024302.3CD6A4472E@hg.openjdk.java.net> Changeset: 31dcf23042f9 Author: weijun Date: 2010-03-23 10:41 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31dcf23042f9 6586707: NTLM authentication with proxy fails Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java From christopher.hegarty at sun.com Tue Mar 23 06:57:59 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 23 Mar 2010 13:57:59 +0000 Subject: hg: jdk7/tl/jdk: 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets; ... Message-ID: <20100323135911.52071447CD@hg.openjdk.java.net> Changeset: 8a9ebdc27045 Author: chegar Date: 2010-03-23 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a9ebdc27045 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 Summary: All three bugs are interdependent Reviewed-by: xuelei ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java From jonathan.gibbons at sun.com Tue Mar 23 18:07:03 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 24 Mar 2010 01:07:03 +0000 Subject: hg: jdk7/tl/langtools: 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Message-ID: <20100324010711.722334408A@hg.openjdk.java.net> Changeset: dd30de080cb9 Author: jjg Date: 2010-03-23 18:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd30de080cb9 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/6937244/T6937244.java + test/tools/javap/6937244/T6937244A.java From daniel.daugherty at sun.com Tue Mar 23 20:20:33 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 24 Mar 2010 03:20:33 +0000 Subject: hg: jdk7/tl/jdk: 6915365: 3/4 assert(false, "Unsupported VMGlobal Type") at management.cpp:1540 Message-ID: <20100324032046.21DBD440B1@hg.openjdk.java.net> Changeset: f8c9a5e3f5db Author: dcubed Date: 2010-03-23 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8c9a5e3f5db 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove exception throw to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/native/sun/management/Flag.c From Christopher.Hegarty at Sun.COM Wed Mar 24 03:22:30 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 24 Mar 2010 10:22:30 +0000 Subject: Code Review 6937703: java/net regression test issues with samevm Message-ID: <4BA9E7E6.80707@Sun.COM> Hi Michael, Alan, Some more test updates for samevm mode. Webrev: http://cr.openjdk.java.net/~chegar/6937703/webrev.00/webrev/ -Chris. From Alan.Bateman at Sun.COM Wed Mar 24 04:06:21 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 24 Mar 2010 11:06:21 +0000 Subject: Code Review 6937703: java/net regression test issues with samevm In-Reply-To: <4BA9E7E6.80707@Sun.COM> References: <4BA9E7E6.80707@Sun.COM> Message-ID: <4BA9F22D.5060106@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Michael, Alan, > > Some more test updates for samevm mode. > > Webrev: > http://cr.openjdk.java.net/~chegar/6937703/webrev.00/webrev/ > > -Chris. In HttpTest.java I see exceptions are silently consumed - while you are there it would be good to at least print the stack trace to may any future failures easier to debug. Good catch with the wrong header in B5052093.java. An alternative for this one is to put the try/finally after you assign server. That would avoid needing to catch if it null or not. Otherwise looks good to me and thanks for fixing up these issues. -Alan. From Christopher.Hegarty at Sun.COM Wed Mar 24 04:32:06 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 24 Mar 2010 11:32:06 +0000 Subject: Code Review 6937703: java/net regression test issues with samevm In-Reply-To: <4BA9F22D.5060106@sun.com> References: <4BA9E7E6.80707@Sun.COM> <4BA9F22D.5060106@sun.com> Message-ID: <4BA9F836.7070005@Sun.COM> On 24/03/2010 11:06, Alan Bateman wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> Hi Michael, Alan, >> >> Some more test updates for samevm mode. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/6937703/webrev.00/webrev/ >> >> -Chris. > In HttpTest.java I see exceptions are silently consumed - while you are > there it would be good to at least print the stack trace to may any > future failures easier to debug. > > Good catch with the wrong header in B5052093.java. An alternative for > this one is to put the try/finally after you assign server. That would > avoid needing to catch if it null or not. Thanks Alan, I've made the changes you suggested and updated the webrev. -Chris. > > Otherwise looks good to me and thanks for fixing up these issues. > > -Alan. From Alan.Bateman at Sun.COM Wed Mar 24 04:46:19 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 24 Mar 2010 11:46:19 +0000 Subject: Code Review 6937703: java/net regression test issues with samevm In-Reply-To: <4BA9F836.7070005@Sun.COM> References: <4BA9E7E6.80707@Sun.COM> <4BA9F22D.5060106@sun.com> <4BA9F836.7070005@Sun.COM> Message-ID: <4BA9FB8B.3080708@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > : > Thanks Alan, > > I've made the changes you suggested and updated the webrev. Good okay to me. In passing I see HttpTest.run also silently consumes any exceptions so you might want to do this while you are there (not wishing to extend the scope of getting these tests to run in samevm of course). -Alan. From Christopher.Hegarty at Sun.COM Wed Mar 24 04:55:31 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Wed, 24 Mar 2010 11:55:31 +0000 Subject: Code Review 6937703: java/net regression test issues with samevm In-Reply-To: <4BA9FB8B.3080708@sun.com> References: <4BA9E7E6.80707@Sun.COM> <4BA9F22D.5060106@sun.com> <4BA9F836.7070005@Sun.COM> <4BA9FB8B.3080708@sun.com> Message-ID: <4BA9FDB3.20906@Sun.COM> On 24/03/2010 11:46, Alan Bateman wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> : >> Thanks Alan, >> >> I've made the changes you suggested and updated the webrev. > Good okay to me. In passing I see HttpTest.run also silently consumes > any exceptions so you might want to do this while you are there (not Yes, I looked at this but decided not to because it will alway throw an exception since the socket is close from anther thread. I could do a if not "Socket closed" then it is an unexpected exception. -Chris. > wishing to extend the scope of getting these tests to run in samevm of > course). > > -Alan. From jonathan.gibbons at sun.com Wed Mar 24 12:19:58 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 24 Mar 2010 19:19:58 +0000 Subject: hg: jdk7/tl/langtools: 6937318: jdk7 b86: javah and javah -help is no output for these commands Message-ID: <20100324192003.81CA4441A5@hg.openjdk.java.net> Changeset: 3058880c0b8d Author: jjg Date: 2010-03-24 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3058880c0b8d 6937318: jdk7 b86: javah and javah -help is no output for these commands Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java ! test/tools/javah/T6893943.java From joe.darcy at sun.com Wed Mar 24 17:03:57 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 25 Mar 2010 00:03:57 +0000 Subject: hg: jdk7/tl/langtools: 6937417: javac -Xprint returns IndexOutOfBoundsException Message-ID: <20100325000401.C8A36441EB@hg.openjdk.java.net> Changeset: 65e422bbb984 Author: darcy Date: 2010-03-24 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/65e422bbb984 6937417: javac -Xprint returns IndexOutOfBoundsException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + test/tools/javac/processing/model/util/elements/VacuousEnum.java From weijun.wang at sun.com Wed Mar 24 21:09:04 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 25 Mar 2010 04:09:04 +0000 Subject: hg: jdk7/tl/jdk: 6813340: X509Factory should not depend on is.available()==0 Message-ID: <20100325040917.7E9654422E@hg.openjdk.java.net> Changeset: 26477628f2d5 Author: weijun Date: 2010-03-25 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26477628f2d5 6813340: X509Factory should not depend on is.available()==0 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/KeyTool.java + test/java/security/cert/CertificateFactory/ReturnStream.java + test/java/security/cert/CertificateFactory/SlowStream.java + test/java/security/cert/CertificateFactory/slowstream.sh From christopher.hegarty at sun.com Thu Mar 25 02:40:31 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 25 Mar 2010 09:40:31 +0000 Subject: hg: jdk7/tl/jdk: 6937703: java/net regression test issues with samevm Message-ID: <20100325094056.833F744286@hg.openjdk.java.net> Changeset: 6109b166bf68 Author: chegar Date: 2010-03-25 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6109b166bf68 6937703: java/net regression test issues with samevm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java From Christopher.Hegarty at Sun.COM Thu Mar 25 04:36:38 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 25 Mar 2010 11:36:38 +0000 Subject: Code Review 6648001: Cancelling HTTP authentication causes subsequent deadlocks Message-ID: <4BAB4AC6.3010704@sun.com> Hi Michael, This is a forward port of a fix that you put in 6uXX. By exposing the key used in the authentication cache outside of AuthenticationInfo, this allows all requests to be terminated correctly, including ones, that have no username/password returned. Webrev: http://cr.openjdk.java.net/~chegar/6648001/webrev.00/webrev/ -Chris. From Christopher.Hegarty at Sun.COM Fri Mar 26 02:58:00 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 26 Mar 2010 09:58:00 +0000 Subject: Code Review 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption Message-ID: <4BAC8528.8060200@Sun.COM> Hi Michael, Alan, This is a very small change to fix a problem in native code where, if multiple threads are executing the native method, an unset value of a static variable may be used. When setting static variables in a block we can only be sure they are all set when the last one is. This is a common pattern in the socket impl native code. I plan to clean up this area of native code and remove unnecessary duplicate static state, but for now I just want to resolve this specific bug. Webrev: http://cr.openjdk.java.net/~chegar/6921111/webrev.00/webrev/ Thanks, -Chris. From Alan.Bateman at Sun.COM Fri Mar 26 06:45:05 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 26 Mar 2010 13:45:05 +0000 Subject: Code Review 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption In-Reply-To: <4BAC8528.8060200@Sun.COM> References: <4BAC8528.8060200@Sun.COM> Message-ID: <4BACBA61.8010108@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Michael, Alan, > > This is a very small change to fix a problem in native code where, if > multiple threads are executing the native method, an unset value of a > static variable may be used. When setting static variables in a block > we can only be sure they are all set when the last one is. This is a > common pattern in the socket impl native code. > > I plan to clean up this area of native code and remove unnecessary > duplicate static state, but for now I just want to resolve this > specific bug. > > Webrev: > http://cr.openjdk.java.net/~chegar/6921111/webrev.00/webrev/ > > Thanks, > -Chris. The proposed change will help but I assume it is not bullet proof. A slightly better fix might to be do the initialization if nis_addrsID or ia_addressID is NULL. I know I've mentioned this to you before, but I think it would be a lot better to just replace this code with a cleaner implementation in java. -Alan. From Christopher.Hegarty at Sun.COM Fri Mar 26 08:16:03 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 26 Mar 2010 15:16:03 +0000 Subject: Code Review 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption In-Reply-To: <4BACBA61.8010108@sun.com> References: <4BAC8528.8060200@Sun.COM> <4BACBA61.8010108@sun.com> Message-ID: <4BACCFB3.1040602@Sun.COM> On 03/26/10 13:45, Alan Bateman wrote: > Christopher Hegarty - Sun Microsystems Ireland wrote: >> Hi Michael, Alan, >> >> This is a very small change to fix a problem in native code where, if >> multiple threads are executing the native method, an unset value of a >> static variable may be used. When setting static variables in a block >> we can only be sure they are all set when the last one is. This is a >> common pattern in the socket impl native code. >> >> I plan to clean up this area of native code and remove unnecessary >> duplicate static state, but for now I just want to resolve this >> specific bug. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/6921111/webrev.00/webrev/ >> >> Thanks, >> -Chris. > The proposed change will help but I assume it is not bullet proof. A > slightly better fix might to be do the initialization if nis_addrsID or > ia_addressID is NULL. I know I've mentioned this to you before, but I > think it would be a lot better to just replace this code with a cleaner > implementation in java. Thanks Alan, you are of course correct I implemented your suggestion. For now I'll go ahead with what we have and create a new bug to rewrite this. -Chris. > > -Alan. From kelly.ohair at sun.com Fri Mar 26 22:44:16 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 27 Mar 2010 05:44:16 +0000 Subject: hg: jdk7/tl/langtools: 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Message-ID: <20100327054418.366324454D@hg.openjdk.java.net> Changeset: de6375751eb7 Author: ohair Date: 2010-03-26 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/de6375751eb7 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Reviewed-by: jjg ! make/Makefile From xuelei.fan at sun.com Sun Mar 28 22:51:14 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Mon, 29 Mar 2010 05:51:14 +0000 Subject: hg: jdk7/tl/jdk: 6693917: regression tests need to update for supporting ECC on solaris 11 Message-ID: <20100329055200.65A9D44814@hg.openjdk.java.net> Changeset: 31517a0345d1 Author: xuelei Date: 2010-03-29 13:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31517a0345d1 6693917: regression tests need to update for supporting ECC on solaris 11 Reviewed-by: weijun ! test/sun/security/ssl/etc/keystore ! test/sun/security/ssl/etc/truststore ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java From xueming.shen at sun.com Tue Mar 30 19:15:11 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Wed, 31 Mar 2010 02:15:11 +0000 Subject: hg: jdk7/tl/jdk: 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7; ... Message-ID: <20100331021524.C3C5044ABB@hg.openjdk.java.net> Changeset: 3771ac2a8b3b Author: sherman Date: 2010-03-30 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3771ac2a8b3b 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7 6911753: NSN wants to add Big5 HKSCS-2004 support Summary: support HKSCS2008 in Big5_HKSCS and MS950_HKSCS Reviewed-by: okutsu ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile + make/tools/CharsetMapping/Big5.c2b + make/tools/CharsetMapping/Big5.map + make/tools/CharsetMapping/Big5.nr + make/tools/CharsetMapping/HKSCS2001.c2b + make/tools/CharsetMapping/HKSCS2001.map + make/tools/CharsetMapping/HKSCS2008.c2b + make/tools/CharsetMapping/HKSCS2008.map + make/tools/CharsetMapping/HKSCS_XP.c2b + make/tools/CharsetMapping/HKSCS_XP.map ! make/tools/CharsetMapping/dbcs - make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/DBCS.java + make/tools/src/build/tools/charsetmapping/EUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java + make/tools/src/build/tools/charsetmapping/HKSCS.java + make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java + make/tools/src/build/tools/charsetmapping/SBCS.java + make/tools/src/build/tools/charsetmapping/Utils.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5.java ! src/share/classes/sun/io/ByteToCharBig5_HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5.java ! src/share/classes/sun/io/CharToByteBig5_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/nio/cs/ext/Big5.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS.java + src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java + src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/native/java/lang/java_props_md.c ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/native/java/lang/java_props_md.c ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/Charset/RegisteredCharsets.java