Re: Does OpenJDK support bitmap image with JarURLConnection?
On 08/03/2011 09:13, Jing LV wrote: >.. > Hi Chris, > > Thanks for reply. So as we see no objection for this issue, would > someone help to raise a bug in the bug system? So that we can apply the > patch and fix this 12-year problem. I filed CR 7025938: "Add bitmap mime type to content-types.properties" for this. Please post your changes and I can work with you to get a patch integrated. -Chris.
Code Review 7024560: InetAddress.getLocalHost().getHostName() returns localhost for hostnames of length HOST_NAME_MAX
Alan, Michael, In Java_java_net_Inet(4|6)AddressImpl_getLocalHostName JVM_GetHostName, a.k.a gethostname, is returning ENAMETOOLONG. Then falling back to use "localhost", the assumption was that failure would only happen when something went wrong, maybe networking is not setup. It appears that on many Linux variations the given buffer length should include space for the null terminator. Our given buffers already account for this, just need to pass down the correct length to gethostname. http://cr.openjdk.java.net/~chegar/7024560/webrev.00/webrev/ -Chris.
Re: SocketPermission's implies() interesting behavior
On 1 March 2011 09:18, Chris Hegarty wrote: > Michael, > > Can you please take a look at this change, CR 7021280: "SocketPermission > trustProxy should accept wildcards". > > This patch came from Charles (cc'ed), and I agree with the changes. Can you > please take a look and give your feedback. > > http://cr.openjdk.java.net/~chegar/7021280/webrev.00/webrev/ > > -Chris. In the suggested fix, I see that the comparison becomes 'thatHost.endsWith(this.cname)' if 'this.wildcard' is 'true'. Prior to the change, the comparison was (always) 'thisHost.equalsIgnoreCase(thatHost)'. So, on the surface, it looks like a case-insensitive comparison - String.equalsIgnoreCase() - has been replaced (when 'this.wildcard' is 'true') with a case-sensitive comparison - String.endsWith(). Is there a reason why this change in case sensitivity is not a problem in this instance, or does the suggested fix need to be reworked to make the new comparison (also) case-insensitive ? - Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Code Review 7024560: InetAddress.getLocalHost().getHostName() returns localhost for hostnames of length HOST_NAME_MAX
Chris Hegarty wrote: Alan, Michael, In Java_java_net_Inet(4|6)AddressImpl_getLocalHostName JVM_GetHostName, a.k.a gethostname, is returning ENAMETOOLONG. Then falling back to use "localhost", the assumption was that failure would only happen when something went wrong, maybe networking is not setup. It appears that on many Linux variations the given buffer length should include space for the null terminator. Our given buffers already account for this, just need to pass down the correct length to gethostname. http://cr.openjdk.java.net/~chegar/7024560/webrev.00/webrev/ -Chris. Looks fine. I guess a regression test isn't practical in this case. - Michael
Re: Code Review 7024560: InetAddress.getLocalHost().getHostName() returns localhost for hostnames of length HOST_NAME_MAX
Chris Hegarty wrote: Alan, Michael, In Java_java_net_Inet(4|6)AddressImpl_getLocalHostName JVM_GetHostName, a.k.a gethostname, is returning ENAMETOOLONG. Then falling back to use "localhost", the assumption was that failure would only happen when something went wrong, maybe networking is not setup. It appears that on many Linux variations the given buffer length should include space for the null terminator. Our given buffers already account for this, just need to pass down the correct length to gethostname. http://cr.openjdk.java.net/~chegar/7024560/webrev.00/webrev/ -Chris. Are you sure that it is failing with ENAMETOOLONG? I just checked the man page and is reads "In case the null-terminated hostname does not fit, no error is returned, but the hostname is truncated. It is unspecified whether the truncated hostname will be null-terminated", which suggests to me that we should be careful to null terminate on the success path. -Alan.
Re: Code Review 7024560: InetAddress.getLocalHost().getHostName() returns localhost for hostnames of length HOST_NAME_MAX
On 09/03/2011 16:26, Alan Bateman wrote: Chris Hegarty wrote: Alan, Michael, In Java_java_net_Inet(4|6)AddressImpl_getLocalHostName JVM_GetHostName, a.k.a gethostname, is returning ENAMETOOLONG. Then falling back to use "localhost", the assumption was that failure would only happen when something went wrong, maybe networking is not setup. It appears that on many Linux variations the given buffer length should include space for the null terminator. Our given buffers already account for this, just need to pass down the correct length to gethostname. http://cr.openjdk.java.net/~chegar/7024560/webrev.00/webrev/ -Chris. Are you sure that it is failing with ENAMETOOLONG? I just checked the I tested on a few different Linux machines and instrumented the error handling code, it is definitely failing with ENAMETOOLONG. man page and is reads "In case the null-terminated hostname does not fit, no error is returned, but the hostname is truncated. It is unspecified whether the truncated hostname will be null-terminated", which suggests to me that we should be careful to null terminate on the success path. Yes, the man page does leave the door open for non null-terminated strings, but we've never seen this in the past so I didn't think it would be a problem in reality. -Chris. -Alan.
hg: jdk7/tl/langtools: 7025988: Test test/tools/javac/file/zip/T6836682.java takes too long to complete
Changeset: 4fd20d5b7295 Author:mcimadamore Date: 2011-03-09 16:47 + URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4fd20d5b7295 7025988: Test test/tools/javac/file/zip/T6836682.java takes too long to complete Summary: added @ignore tag to temporarily disable the test Reviewed-by: jjg ! test/tools/javac/file/zip/T6836682.java
Re: Code Review 7024560: InetAddress.getLocalHost().getHostName() returns localhost for hostnames of length HOST_NAME_MAX
Chris Hegarty wrote: : I tested on a few different Linux machines and instrumented the error handling code, it is definitely failing with ENAMETOOLONG. Okay, must be a glibc thing. The changes you have look okay to me but would be nice to ensure that the hostname is null-terminated (for platforms that don't fail with ENAMETOOLONG). -Alan.
hg: jdk7/tl/jdk: 7022370: Launcher ergonomics should provide simple default implementation
Changeset: 38626f41e458 Author:dholmes Date: 2011-03-09 19:52 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38626f41e458 7022370: Launcher ergonomics should provide simple default implementation Summary: Use a common, platform independent, implementation unless an architecture specific implementation exists Reviewed-by: ksrini, mchung, ohair, gbenson ! make/java/jli/Makefile ! src/solaris/bin/ergo.c - src/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c
Re: SocketPermission's implies() interesting behavior
On 03/10/2011 12:02 AM, Neil Richards wrote: On 1 March 2011 09:18, Chris Hegarty wrote: Michael, Can you please take a look at this change, CR 7021280: "SocketPermission trustProxy should accept wildcards". This patch came from Charles (cc'ed), and I agree with the changes. Can you please take a look and give your feedback. http://cr.openjdk.java.net/~chegar/7021280/webrev.00/webrev/ -Chris. In the suggested fix, I see that the comparison becomes 'thatHost.endsWith(this.cname)' if 'this.wildcard' is 'true'. Prior to the change, the comparison was (always) 'thisHost.equalsIgnoreCase(thatHost)'. So, on the surface, it looks like a case-insensitive comparison - String.equalsIgnoreCase() - has been replaced (when 'this.wildcard' is 'true') with a case-sensitive comparison - String.endsWith(). Is there a reason why this change in case sensitivity is not a problem in this instance, or does the suggested fix need to be reworked to make the new comparison (also) case-insensitive ? - Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Hi Neil, With a quick search in the SocketPermission using "cname =" as search word, cname always seems to be lower cases. But hostname does not. It may need some rework on the patch. And more, every place where cname compare with another cname should use normal equalsTo (equalsIgnoreCase is not needed). Every place where getName and hostname is involved should use case-insensitive comparison. Any opinion, Neil and Chris?
hg: jdk7/tl/jdk: 3 new changesets
Changeset: cfc05963734e Author:ramap Date: 2011-03-09 15:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cfc05963734e 7020513: Add com.sun.xml.internal to the "package.access" property in $JAVA_HOME/lib/security/java.security Reviewed-by: ohair, alanb ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: 5da9973cdba2 Author:ramap Date: 2011-03-09 15:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5da9973cdba2 6635776: Regression in jaxb tests with JDk6 U4 6741058: Move org/relaxng/datatype sources from jdk to jaxws workspace Reviewed-by: ohair, alanb ! make/com/sun/Makefile - make/com/sun/xml/Makefile ! make/common/internal/Defs-jaxws.gmk - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.java Changeset: ea897f472e81 Author:ohair Date: 2011-03-09 18:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea897f472e81 Merge - make/com/sun/xml/Makefile - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.java
hg: jdk7/tl/jdk: 6960211: JavaScript engine allows creation of interface although methods not available
Changeset: 090c52eebf6a Author:sundar Date: 2011-03-10 12:52 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/090c52eebf6a 6960211: JavaScript engine allows creation of interface although methods not available Reviewed-by: jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/com/sun/script/util/InterfaceImplementor.java + test/javax/script/GetInterfaceTest.java
