From jonathan.gibbons at oracle.com Tue Feb 16 03:37:31 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 15 Feb 2016 19:37:31 -0800 Subject: RFR: 8149886: 16 windows tests broke with recent putback Message-ID: <56C2997B.6090401@oracle.com> Please review the following quick fix for a latent bug in javadoc, uncovered by recent change to use the nio.file API. The root cause is that you typically cannot create a Path from a string containing a URL; you may get an exception -- and will get one on Windows trying to create a Path for a string beginning http:.... The fix is to reverse two tests to ensure the string is not a URL JBS: https://bugs.openjdk.java.net/browse/JDK-8149886 Webrev: http://cr.openjdk.java.net/~jjg/8149886/webrev.00 -- Jon From sundararajan.athijegannathan at oracle.com Tue Feb 16 03:50:45 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 16 Feb 2016 09:20:45 +0530 Subject: RFR: 8149886: 16 windows tests broke with recent putback In-Reply-To: <56C2997B.6090401@oracle.com> References: <56C2997B.6090401@oracle.com> Message-ID: <56C29C95.7000502@oracle.com> Looks good. -Sundar On 2/16/2016 9:07 AM, Jonathan Gibbons wrote: > Please review the following quick fix for a latent bug in javadoc, > uncovered by recent change to use the nio.file API. > > The root cause is that you typically cannot create a Path from a > string containing a URL; you may get an exception -- and will get one > on Windows trying to create a Path for a string beginning http:.... > > The fix is to reverse two tests to ensure the string is not a URL > > JBS: https://bugs.openjdk.java.net/browse/JDK-8149886 > Webrev: http://cr.openjdk.java.net/~jjg/8149886/webrev.00 > > -- Jon From jvanek at redhat.com Thu Feb 25 11:24:21 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 25 Feb 2016 12:24:21 +0100 Subject: Provide zipped javadoc archive from make Message-ID: <56CEE465.40107@redhat.com> Hello! Firs, sorry for spamming three lists but imho it is really touching all of them - it will be change in makefile, and it is new feature for old docs.... Currently, when you run make all, javadoc is generated as directory. I do not wont to touch this. However, I would like to add target, which will pack generated javadoc... Lets say correctly to zip archive. Having javadoc as directory have its advantages, but having javadoc as archive have another set of advantages. (eg main user of javadoc are IDEs. and all IDEs I know support archived javadocs. All library javadocs distributed over web are distributed as zips, and they are not expected to be unpacked. Many tools crate archved javadocs by default and so on...) I'm packaging openjdk for fedora, and next to java-1.X.0-openjdk-javadoc, and I wonted to provide java-1.X.0-openjdk-javadoc-zip so users have an choice to select zipped/unzipped javadoc depending on theirs usage. You may argue that size do not meter, but having four (6,7,8,9) jdks on machine, and so having 4 javadocs - it metres if it is 4x250mb or 4x50mb. Also, when I was preparing this simple patch to my packages, I realised - am I compressing all? Am I compressing it correctly and in best way? Is delivering of *JDK's* javadoc as archive even safe? So I would say that having this supported in upstream is much better then just pack zip it in distribution packages. What do you think? If you are interested, I will elaborate patch for jdk9 with wish for jdk8. Change should be simple, and the benefits worthy. Thanx! J. From jonathan.gibbons at oracle.com Thu Feb 25 15:35:06 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Feb 2016 07:35:06 -0800 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CEE465.40107@redhat.com> References: <56CEE465.40107@redhat.com> Message-ID: <56CF1F2A.1090108@oracle.com> javadoc folk, This discussion is continuing on build-dev. -- Jon On 02/25/2016 03:24 AM, Jiri Vanek wrote: > Hello! > > Firs, sorry for spamming three lists but imho it is really touching > all of them - it will be change in makefile, and it is new feature for > old docs.... > > > Currently, when you run make all, javadoc is generated as directory. I > do not wont to touch this. However, I would like to add target, which > will pack generated javadoc... Lets say correctly to zip archive. > > Having javadoc as directory have its advantages, but having javadoc as > archive have another set of advantages. (eg main user of javadoc are > IDEs. and all IDEs I know support archived javadocs. All library > javadocs distributed over web are distributed as zips, and they are > not expected to be unpacked. Many tools crate archved javadocs by > default and so on...) > > I'm packaging openjdk for fedora, and next to > java-1.X.0-openjdk-javadoc, and I wonted to provide > java-1.X.0-openjdk-javadoc-zip so users have an choice to select > zipped/unzipped javadoc depending on theirs usage. You may argue that > size do not meter, but having four (6,7,8,9) jdks on machine, and so > having 4 javadocs - it metres if it is 4x250mb or 4x50mb. > > Also, when I was preparing this simple patch to my packages, I > realised - am I compressing all? Am I compressing it correctly and in > best way? Is delivering of *JDK's* javadoc as archive even safe? > > So I would say that having this supported in upstream is much better > then just pack zip it in distribution packages. > > What do you think? > > If you are interested, I will elaborate patch for jdk9 with wish for > jdk8. Change should be simple, and the benefits worthy. > > Thanx! > J.