hg: jdk8/tl/langtools: 8000666: javadoc should write directly to Writer instead of composing strings
Changeset: 8db45b13526e Author:jjg Date: 2012-10-15 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8db45b13526e 8000666: javadoc should write directly to Writer instead of composing strings Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
hg: jdk8/tl/jdk: 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout
Changeset: c0736b62160e Author:robm Date: 2012-10-15 22:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0736b62160e 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java + test/com/sun/jndi/ldap/LdapTimeoutTest.java - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java
Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?
Alan, Looks ok for me. -Dmitry On 2012-10-15 20:14, Alan Bateman wrote: > > java.net.URL guarantees that 5 protocol handlers are present: http, > https, ftp, file and jar. > > ftp a legacy protocol and I'm wondering whether it's time to consider > removing it from the list. I'm not suggesting we don't continue to > include it, rather just removing the guarantee that it is always > present. The motivation for bringing this up is modules and compact > profiles where it might be desirable to not include the ftp protocol > handler for footprint reasons. > > -Alan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?
Yes, this seems reasonable to me too. There seem to be fewer and fewer applications that use ftp... - Original Message - From: chris.hega...@oracle.com To: alan.bate...@oracle.com Cc: net-dev@openjdk.java.net Sent: Monday, October 15, 2012 2:48:05 PM GMT -05:00 US/Canada Eastern Subject: Re: URL guarantees that the ftp protocol handler is present, worth re-considering this? Seems reasonable. -Chris On 15 Oct 2012, at 17:14, Alan Bateman wrote: > > java.net.URL guarantees that 5 protocol handlers are present: http, https, > ftp, file and jar. > > ftp a legacy protocol and I'm wondering whether it's time to consider > removing it from the list. I'm not suggesting we don't continue to include > it, rather just removing the guarantee that it is always present. The > motivation for bringing this up is modules and compact profiles where it > might be desirable to not include the ftp protocol handler for footprint > reasons. > > -Alan
Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?
Seems reasonable. -Chris On 15 Oct 2012, at 17:14, Alan Bateman wrote: > > java.net.URL guarantees that 5 protocol handlers are present: http, https, > ftp, file and jar. > > ftp a legacy protocol and I'm wondering whether it's time to consider > removing it from the list. I'm not suggesting we don't continue to include > it, rather just removing the guarantee that it is always present. The > motivation for bringing this up is modules and compact profiles where it > might be desirable to not include the ftp protocol handler for footprint > reasons. > > -Alan
Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?
On 15/10/2012 18:20, Mike Duigou wrote: We should also nuke gopher and netdoc (in sun.net.www.protocol package) I am not sure if mailto should continue as there are better solutions. Mike I agree there isn't any reason to continue to include gopher or netdoc. I also agree with Guy's suggestion that we ship with a sftp handler. However, I should have been clearer is that I'm just talking about the spec at this time. URL lists the protocol handler that are guaranteed to be present and I'm just suggesting that it's time to remove ftp from that list. -Alan
Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?
We should also nuke gopher and netdoc (in sun.net.www.protocol package) I am not sure if mailto should continue as there are better solutions. Mike On Oct 15 2012, at 09:14 , Alan Bateman wrote: > > java.net.URL guarantees that 5 protocol handlers are present: http, https, > ftp, file and jar. > > ftp a legacy protocol and I'm wondering whether it's time to consider > removing it from the list. I'm not suggesting we don't continue to include > it, rather just removing the guarantee that it is always present. The > motivation for bringing this up is modules and compact profiles where it > might be desirable to not include the ftp protocol handler for footprint > reasons. > > -Alan
Re: URL guarantees that the ftp protocol handler is present, worth re-considering this?
What about including sftp? On Monday, October 15, 2012, Alan Bateman wrote: > > java.net.URL guarantees that 5 protocol handlers are present: http, https, > ftp, file and jar. > > ftp a legacy protocol and I'm wondering whether it's time to consider > removing it from the list. I'm not suggesting we don't continue to include > it, rather just removing the guarantee that it is always present. The > motivation for bringing this up is modules and compact profiles where it > might be desirable to not include the ftp protocol handler for footprint > reasons. > > -Alan > -- Regards, Guy Korland
URL guarantees that the ftp protocol handler is present, worth re-considering this?
java.net.URL guarantees that 5 protocol handlers are present: http, https, ftp, file and jar. ftp a legacy protocol and I'm wondering whether it's time to consider removing it from the list. I'm not suggesting we don't continue to include it, rather just removing the guarantee that it is always present. The motivation for bringing this up is modules and compact profiles where it might be desirable to not include the ftp protocol handler for footprint reasons. -Alan
