From jviswana at linux.vnet.ibm.com Wed Oct 3 02:25:43 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Wed, 03 Oct 2012 14:55:43 +0530 Subject: docencoding not available to stylesheet In-Reply-To: <5057414A.6090403@oracle.com> References: <50408900.8020206@linux.vnet.ibm.com> <50521723.4070208@oracle.com> <5056C943.2030808@linux.vnet.ibm.com> <5057414A.6090403@oracle.com> Message-ID: <506C0497.3050805@linux.vnet.ibm.com> Hi Jon , Got a chance to look at the webrev ? Thanks ! Regards, Jayashree V On 17-09-2012 8:57 PM, Jonathan Gibbons wrote: > OK, I will take a look at your latest webrev. > > -- Jon > > On 09/16/2012 11:54 PM, jayashree viswanathan wrote: >> Hi Jon , >> >> Thanks a lot for looking in and passing your review comments . >> >> I have made the changes Please find the webrev at >> http://cr.openjdk.java.net/~luchsh/7006270_3/ >> >> Regards, >> Jayashree Viswanathan >> >> On 13-09-2012 10:55 PM, Jonathan Gibbons wrote: >>> The basic fix looks OK, I'd recommend a couple of white-space >>> tweaks, such as a space between ")" and "{" on line 370, and after >>> "," on line 373. >>> >>> In the tests, I suggest blank lines before/after the IBM copyright >>> on both files, and remove the space before the comment on line 23 in >>> the Test.java file. >>> >>> Are you claiming the copyright on all three files is 2011, not 2012? >>> >>> -- Jon >>> >>> On 08/31/2012 02:50 AM, jayashree viswanathan wrote: >>>> *Problem statement : *Stylesheet.css is not getting encoded like >>>> the other generated html files while using -docencoding >>>> >>>> *Recreation step : * >>>> javadoc -docencoding "use non-ascii encoding" HelloWorld.java >>>> say , >>>> jdk1.8.0\bin\javadoc.exe -docencoding Cp930 -d docencoding3 >>>> HelloWorld.java >>>> >>>> *Explanation :* >>>> The stylesheet.css is not getting generated in the proper encoding >>>> as in the code the configuration.docencoding is not getting passed >>>> to the output stream . >>>> while this scenario works in JDK 6 [as confirmed in Java 6u14] , >>>> below changeset seems to have regressed this when adding new >>>> copyFile method. >>>> >>>> Changeset: >>>> 792 (ffbf2b2a8611) 7006270: Several javadoc regression tests are >>>> failing on windows >>>> >>>> Please find the webrev patch with changes and jtreg test . >>>> >>>> http://cr.openjdk.java.net/~luchsh/ojdk-660/ >>>> >>>> Thanks and Regards, >>>> Jayashree V >>> >> > From jonathan.gibbons at oracle.com Wed Oct 3 12:10:03 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 Oct 2012 12:10:03 -0700 Subject: docencoding not available to stylesheet In-Reply-To: <506C0497.3050805@linux.vnet.ibm.com> References: <50408900.8020206@linux.vnet.ibm.com> <50521723.4070208@oracle.com> <5056C943.2030808@linux.vnet.ibm.com> <5057414A.6090403@oracle.com> <506C0497.3050805@linux.vnet.ibm.com> Message-ID: <506C8D8B.10008@oracle.com> Note that you open the writer twice, once unmodified on like 369, then again in the lines you added. I suggest you either change line 369 to an uninitialized declaration, or merge 369-374 into a declaration whose initialization involved a conditional expression. But, note that there may be big changes in this area coming soon, with work to support JEP 106 [1].which will involve rewriting all code that currently uses File, FileInputStream etc, to use JavaFileObject. -- Jon [1] http://openjdk.java.net/jeps/106 On 10/03/2012 02:25 AM, jayashree viswanathan wrote: > Hi Jon , > > Got a chance to look at the webrev ? > > Thanks ! > > Regards, > Jayashree V > > On 17-09-2012 8:57 PM, Jonathan Gibbons wrote: >> OK, I will take a look at your latest webrev. >> >> -- Jon >> >> On 09/16/2012 11:54 PM, jayashree viswanathan wrote: >>> Hi Jon , >>> >>> Thanks a lot for looking in and passing your review comments . >>> >>> I have made the changes Please find the webrev at >>> http://cr.openjdk.java.net/~luchsh/7006270_3/ >>> >>> Regards, >>> Jayashree Viswanathan >>> >>> On 13-09-2012 10:55 PM, Jonathan Gibbons wrote: >>>> The basic fix looks OK, I'd recommend a couple of white-space >>>> tweaks, such as a space between ")" and "{" on line 370, and after >>>> "," on line 373. >>>> >>>> In the tests, I suggest blank lines before/after the IBM copyright >>>> on both files, and remove the space before the comment on line 23 >>>> in the Test.java file. >>>> >>>> Are you claiming the copyright on all three files is 2011, not 2012? >>>> >>>> -- Jon >>>> >>>> On 08/31/2012 02:50 AM, jayashree viswanathan wrote: >>>>> *Problem statement : *Stylesheet.css is not getting encoded like >>>>> the other generated html files while using -docencoding >>>>> >>>>> *Recreation step : * >>>>> javadoc -docencoding "use non-ascii encoding" HelloWorld.java >>>>> say , >>>>> jdk1.8.0\bin\javadoc.exe -docencoding Cp930 -d docencoding3 >>>>> HelloWorld.java >>>>> >>>>> *Explanation :* >>>>> The stylesheet.css is not getting generated in the proper encoding >>>>> as in the code the configuration.docencoding is not getting passed >>>>> to the output stream . >>>>> while this scenario works in JDK 6 [as confirmed in Java 6u14] , >>>>> below changeset seems to have regressed this when adding new >>>>> copyFile method. >>>>> >>>>> Changeset: >>>>> 792 (ffbf2b2a8611) 7006270: Several javadoc regression tests are >>>>> failing on windows >>>>> >>>>> Please find the webrev patch with changes and jtreg test . >>>>> >>>>> http://cr.openjdk.java.net/~luchsh/ojdk-660/ >>>>> >>>>> Thanks and Regards, >>>>> Jayashree V >>>> >>> >> > From jviswana at linux.vnet.ibm.com Sat Oct 6 19:49:24 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Sun, 07 Oct 2012 08:19:24 +0530 Subject: docencoding not available to stylesheet In-Reply-To: <506C0497.3050805@linux.vnet.ibm.com> References: <50408900.8020206@linux.vnet.ibm.com> <50521723.4070208@oracle.com> <5056C943.2030808@linux.vnet.ibm.com> <5057414A.6090403@oracle.com> <506C0497.3050805@linux.vnet.ibm.com> Message-ID: <5070EDB4.4010702@linux.vnet.ibm.com> Hi Jon , The changed webrev is available here . http://cr.openjdk.java.net/~jviswana/7006270_02/ Thanks for all your inputs and information on the JEPs which looks interesting . I believe adding the regression test to the bucket might help to catch this issue ,also help stop the regression in Java 7 . Thanks and Regards, Jayashree Viswanathan > Message: 1 > Date: Wed, 03 Oct 2012 12:10:03 -0700 > From: Jonathan Gibbons > Subject: Re: docencoding not available to stylesheet > To: jayashree viswanathan > Cc: javadoc-dev > Message-ID:<506C8D8B.10008 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Note that you open the writer twice, once unmodified on like 369, > then again in the lines you added. I suggest you either change > line 369 to an uninitialized declaration, or merge 369-374 into a > declaration whose initialization involved a conditional expression. > > But, note that there may be big changes in this area coming soon, > with work to support JEP 106 [1].which will involve rewriting all code > that currently uses File, FileInputStream etc, to use JavaFileObject. > > -- Jon > Hi Jon , > > Got a chance to look at the webrev ? > > Thanks ! > > Regards, > Jayashree V > > On 17-09-2012 8:57 PM, Jonathan Gibbons wrote: >> OK, I will take a look at your latest webrev. >> >> -- Jon >> >> On 09/16/2012 11:54 PM, jayashree viswanathan wrote: >>> Hi Jon , >>> >>> Thanks a lot for looking in and passing your review comments . >>> >>> I have made the changes Please find the webrev at >>> http://cr.openjdk.java.net/~luchsh/7006270_3/ >>> >>> Regards, >>> Jayashree Viswanathan >>> >>> On 13-09-2012 10:55 PM, Jonathan Gibbons wrote: >>>> The basic fix looks OK, I'd recommend a couple of white-space >>>> tweaks, such as a space between ")" and "{" on line 370, and after >>>> "," on line 373. >>>> >>>> In the tests, I suggest blank lines before/after the IBM copyright >>>> on both files, and remove the space before the comment on line 23 >>>> in the Test.java file. >>>> >>>> Are you claiming the copyright on all three files is 2011, not 2012? >>>> >>>> -- Jon >>>> >>>> On 08/31/2012 02:50 AM, jayashree viswanathan wrote: >>>>> *Problem statement : *Stylesheet.css is not getting encoded like >>>>> the other generated html files while using -docencoding >>>>> >>>>> *Recreation step : * >>>>> javadoc -docencoding "use non-ascii encoding" HelloWorld.java >>>>> say , >>>>> jdk1.8.0\bin\javadoc.exe -docencoding Cp930 -d docencoding3 >>>>> HelloWorld.java >>>>> >>>>> *Explanation :* >>>>> The stylesheet.css is not getting generated in the proper encoding >>>>> as in the code the configuration.docencoding is not getting passed >>>>> to the output stream . >>>>> while this scenario works in JDK 6 [as confirmed in Java 6u14] , >>>>> below changeset seems to have regressed this when adding new >>>>> copyFile method. >>>>> >>>>> Changeset: >>>>> 792 (ffbf2b2a8611) 7006270: Several javadoc regression tests are >>>>> failing on windows >>>>> >>>>> Please find the webrev patch with changes and jtreg test . >>>>> >>>>> http://cr.openjdk.java.net/~luchsh/ojdk-660/ >>>>> >>>>> Thanks and Regards, >>>>> Jayashree V >>>> >>> >> > From jonathan.gibbons at oracle.com Wed Oct 10 08:35:42 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Oct 2012 08:35:42 -0700 Subject: docencoding not available to stylesheet In-Reply-To: <5070EDB4.4010702@linux.vnet.ibm.com> References: <50408900.8020206@linux.vnet.ibm.com> <50521723.4070208@oracle.com> <5056C943.2030808@linux.vnet.ibm.com> <5057414A.6090403@oracle.com> <506C0497.3050805@linux.vnet.ibm.com> <5070EDB4.4010702@linux.vnet.ibm.com> Message-ID: <507595CE.30404@oracle.com> Jayashree, The work to change/update Util is well underway, but I'll push your changeset before that, so that your test is included. As a general comment, the test is very fragile. There is no positive test case, just a negative test case. So if we were to change the default stylesheet so the background color was something other than white, or if we just changed the constant from #ffffff to #FFFFFF, the test would continue passing even if the docencoding code was broken again. How hard would it be for you to generate the positive test case automatically, by using Java API to translate the string into a series of bytes for the expected encoding? A somewhat better solution would be to improve JavadocTester itself, so that we can optionally specify the encoding to use when reading files. Then, you would have just one test, your negated test, but you would create two different testers in main, one for the default encoding, one for the expected encoding. For the default encoding, your test would be a negative test case, and for the expected encoding, your test would be a positive test case. -- Jon On 10/06/2012 07:49 PM, jayashree viswanathan wrote: > Hi Jon , > > The changed webrev is available here . > > http://cr.openjdk.java.net/~jviswana/7006270_02/ > > Thanks for all your inputs and information on the JEPs which looks > interesting . > I believe adding the regression test to the bucket might help to catch > this issue ,also help stop the regression in Java 7 . > > Thanks and Regards, > Jayashree Viswanathan >> Message: 1 >> Date: Wed, 03 Oct 2012 12:10:03 -0700 >> From: Jonathan Gibbons >> Subject: Re: docencoding not available to stylesheet >> To: jayashree viswanathan >> Cc: javadoc-dev >> Message-ID:<506C8D8B.10008 at oracle.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Note that you open the writer twice, once unmodified on like 369, >> then again in the lines you added. I suggest you either change >> line 369 to an uninitialized declaration, or merge 369-374 into a >> declaration whose initialization involved a conditional expression. >> >> But, note that there may be big changes in this area coming soon, >> with work to support JEP 106 [1].which will involve rewriting all code >> that currently uses File, FileInputStream etc, to use JavaFileObject. >> >> -- Jon > >> Hi Jon , >> >> Got a chance to look at the webrev ? >> >> Thanks ! >> >> Regards, >> Jayashree V >> >> On 17-09-2012 8:57 PM, Jonathan Gibbons wrote: >>> OK, I will take a look at your latest webrev. >>> >>> -- Jon >>> >>> On 09/16/2012 11:54 PM, jayashree viswanathan wrote: >>>> Hi Jon , >>>> >>>> Thanks a lot for looking in and passing your review comments . >>>> >>>> I have made the changes Please find the webrev at >>>> http://cr.openjdk.java.net/~luchsh/7006270_3/ >>>> >>>> Regards, >>>> Jayashree Viswanathan >>>> >>>> On 13-09-2012 10:55 PM, Jonathan Gibbons wrote: >>>>> The basic fix looks OK, I'd recommend a couple of white-space >>>>> tweaks, such as a space between ")" and "{" on line 370, and after >>>>> "," on line 373. >>>>> >>>>> In the tests, I suggest blank lines before/after the IBM copyright >>>>> on both files, and remove the space before the comment on line 23 >>>>> in the Test.java file. >>>>> >>>>> Are you claiming the copyright on all three files is 2011, not 2012? >>>>> >>>>> -- Jon >>>>> >>>>> On 08/31/2012 02:50 AM, jayashree viswanathan wrote: >>>>>> *Problem statement : *Stylesheet.css is not getting encoded like >>>>>> the other generated html files while using -docencoding >>>>>> >>>>>> *Recreation step : * >>>>>> javadoc -docencoding "use non-ascii encoding" HelloWorld.java >>>>>> say , >>>>>> jdk1.8.0\bin\javadoc.exe -docencoding Cp930 -d docencoding3 >>>>>> HelloWorld.java >>>>>> >>>>>> *Explanation :* >>>>>> The stylesheet.css is not getting generated in the proper >>>>>> encoding as in the code the configuration.docencoding is not >>>>>> getting passed to the output stream . >>>>>> while this scenario works in JDK 6 [as confirmed in Java 6u14] , >>>>>> below changeset seems to have regressed this when adding new >>>>>> copyFile method. >>>>>> >>>>>> Changeset: >>>>>> 792 (ffbf2b2a8611) 7006270: Several javadoc regression tests are >>>>>> failing on windows >>>>>> >>>>>> Please find the webrev patch with changes and jtreg test . >>>>>> >>>>>> http://cr.openjdk.java.net/~luchsh/ojdk-660/ >>>>>> >>>>>> Thanks and Regards, >>>>>> Jayashree V >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Wed Oct 10 18:14:37 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Oct 2012 18:14:37 -0700 Subject: docencoding not available to stylesheet In-Reply-To: <507595CE.30404@oracle.com> References: <50408900.8020206@linux.vnet.ibm.com> <50521723.4070208@oracle.com> <5056C943.2030808@linux.vnet.ibm.com> <5057414A.6090403@oracle.com> <506C0497.3050805@linux.vnet.ibm.com> <5070EDB4.4010702@linux.vnet.ibm.com> <507595CE.30404@oracle.com> Message-ID: <50761D7D.2000808@oracle.com> Jayashree, I have pushed your changeset. Note that the test should contain the issue number that covers the work contained in the changeset, not the issue number for the changeset that you believe caused the problem. In this case, I filed a new issue on your behalf, which was allocated number 8000743, so you will see that number in your test and in the changeset messages. -- Jon On 10/10/2012 08:35 AM, Jonathan Gibbons wrote: > Jayashree, > > The work to change/update Util is well underway, but I'll push your > changeset before that, so that your test is included. > > As a general comment, the test is very fragile. There is no positive > test case, just a negative test case. So if we were to change the > default stylesheet so the background color was something other than > white, or if we just changed the constant from #ffffff to #FFFFFF, the > test would continue passing even if the docencoding code was broken > again. > > How hard would it be for you to generate the positive test case > automatically, by using Java API to translate the string into a series > of bytes for the expected encoding? > > A somewhat better solution would be to improve JavadocTester itself, > so that we can optionally specify the encoding to use when reading > files. Then, you would have just one test, your negated test, but > you would create two different testers in main, one for the default > encoding, one for the expected encoding. For the default encoding, > your test would be a negative test case, and for the expected > encoding, your test would be a positive test case. > > -- Jon > > On 10/06/2012 07:49 PM, jayashree viswanathan wrote: >> Hi Jon , >> >> The changed webrev is available here . >> >> http://cr.openjdk.java.net/~jviswana/7006270_02/ >> >> Thanks for all your inputs and information on the JEPs which looks >> interesting . >> I believe adding the regression test to the bucket might help to >> catch this issue ,also help stop the regression in Java 7 . >> >> Thanks and Regards, >> Jayashree Viswanathan >>> Message: 1 >>> Date: Wed, 03 Oct 2012 12:10:03 -0700 >>> From: Jonathan Gibbons >>> Subject: Re: docencoding not available to stylesheet >>> To: jayashree viswanathan >>> Cc: javadoc-dev >>> Message-ID:<506C8D8B.10008 at oracle.com> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> Note that you open the writer twice, once unmodified on like 369, >>> then again in the lines you added. I suggest you either change >>> line 369 to an uninitialized declaration, or merge 369-374 into a >>> declaration whose initialization involved a conditional expression. >>> >>> But, note that there may be big changes in this area coming soon, >>> with work to support JEP 106 [1].which will involve rewriting all code >>> that currently uses File, FileInputStream etc, to use JavaFileObject. >>> >>> -- Jon >> >>> Hi Jon , >>> >>> Got a chance to look at the webrev ? >>> >>> Thanks ! >>> >>> Regards, >>> Jayashree V >>> >>> On 17-09-2012 8:57 PM, Jonathan Gibbons wrote: >>>> OK, I will take a look at your latest webrev. >>>> >>>> -- Jon >>>> >>>> On 09/16/2012 11:54 PM, jayashree viswanathan wrote: >>>>> Hi Jon , >>>>> >>>>> Thanks a lot for looking in and passing your review comments . >>>>> >>>>> I have made the changes Please find the webrev at >>>>> http://cr.openjdk.java.net/~luchsh/7006270_3/ >>>>> >>>>> Regards, >>>>> Jayashree Viswanathan >>>>> >>>>> On 13-09-2012 10:55 PM, Jonathan Gibbons wrote: >>>>>> The basic fix looks OK, I'd recommend a couple of white-space >>>>>> tweaks, such as a space between ")" and "{" on line 370, and >>>>>> after "," on line 373. >>>>>> >>>>>> In the tests, I suggest blank lines before/after the IBM >>>>>> copyright on both files, and remove the space before the comment >>>>>> on line 23 in the Test.java file. >>>>>> >>>>>> Are you claiming the copyright on all three files is 2011, not 2012? >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 08/31/2012 02:50 AM, jayashree viswanathan wrote: >>>>>>> *Problem statement : *Stylesheet.css is not getting encoded like >>>>>>> the other generated html files while using -docencoding >>>>>>> >>>>>>> *Recreation step : * >>>>>>> javadoc -docencoding "use non-ascii encoding" HelloWorld.java >>>>>>> say , >>>>>>> jdk1.8.0\bin\javadoc.exe -docencoding Cp930 -d docencoding3 >>>>>>> HelloWorld.java >>>>>>> >>>>>>> *Explanation :* >>>>>>> The stylesheet.css is not getting generated in the proper >>>>>>> encoding as in the code the configuration.docencoding is not >>>>>>> getting passed to the output stream . >>>>>>> while this scenario works in JDK 6 [as confirmed in Java 6u14] , >>>>>>> below changeset seems to have regressed this when adding new >>>>>>> copyFile method. >>>>>>> >>>>>>> Changeset: >>>>>>> 792 (ffbf2b2a8611) 7006270: Several javadoc regression tests are >>>>>>> failing on windows >>>>>>> >>>>>>> Please find the webrev patch with changes and jtreg test . >>>>>>> >>>>>>> http://cr.openjdk.java.net/~luchsh/ojdk-660/ >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> Jayashree V >>>>>> >>>>> >>>> >>> >> > From jviswana at linux.vnet.ibm.com Thu Oct 11 04:24:02 2012 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Thu, 11 Oct 2012 16:54:02 +0530 Subject: docencoding not available to stylesheet In-Reply-To: <50761D7D.2000808@oracle.com> References: <50408900.8020206@linux.vnet.ibm.com> <50521723.4070208@oracle.com> <5056C943.2030808@linux.vnet.ibm.com> <5057414A.6090403@oracle.com> <506C0497.3050805@linux.vnet.ibm.com> <5070EDB4.4010702@linux.vnet.ibm.com> <507595CE.30404@oracle.com> <50761D7D.2000808@oracle.com> Message-ID: <5076AC52.6060808@linux.vnet.ibm.com> Hi Jon , Thanks for pushing my changes . I agree with your views on the test case, well the JavadocTester is the better means to do I believe , This improvement has to happen for testdocencoding and testencoding , Also currently overwriting of a stylesheet.css doesn't work well . Will make the changes and pass them on . Thanks and Regards, Jayashree V On 11-10-2012 6:44 AM, Jonathan Gibbons wrote: > Jayashree, > > I have pushed your changeset. Note that the test should contain the > issue number that covers the work contained in the changeset, not the > issue number for the changeset that you believe caused the problem. > In this case, I filed a new issue on your behalf, which was allocated > number 8000743, so you will see that number in your test and in the > changeset messages. > > -- Jon > > > > On 10/10/2012 08:35 AM, Jonathan Gibbons wrote: >> Jayashree, >> >> The work to change/update Util is well underway, but I'll push your >> changeset before that, so that your test is included. >> >> As a general comment, the test is very fragile. There is no positive >> test case, just a negative test case. So if we were to change the >> default stylesheet so the background color was something other than >> white, or if we just changed the constant from #ffffff to #FFFFFF, >> the test would continue passing even if the docencoding code was >> broken again. >> >> How hard would it be for you to generate the positive test case >> automatically, by using Java API to translate the string into a >> series of bytes for the expected encoding? >> >> A somewhat better solution would be to improve JavadocTester itself, >> so that we can optionally specify the encoding to use when reading >> files. Then, you would have just one test, your negated test, but >> you would create two different testers in main, one for the default >> encoding, one for the expected encoding. For the default encoding, >> your test would be a negative test case, and for the expected >> encoding, your test would be a positive test case. >> >> -- Jon >> >> On 10/06/2012 07:49 PM, jayashree viswanathan wrote: >>> Hi Jon , >>> >>> The changed webrev is available here . >>> >>> http://cr.openjdk.java.net/~jviswana/7006270_02/ >>> >>> Thanks for all your inputs and information on the JEPs which looks >>> interesting . >>> I believe adding the regression test to the bucket might help to >>> catch this issue ,also help stop the regression in Java 7 . >>> >>> Thanks and Regards, >>> Jayashree Viswanathan >>>> Message: 1 >>>> Date: Wed, 03 Oct 2012 12:10:03 -0700 >>>> From: Jonathan Gibbons >>>> Subject: Re: docencoding not available to stylesheet >>>> To: jayashree viswanathan >>>> Cc: javadoc-dev >>>> Message-ID:<506C8D8B.10008 at oracle.com> >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> >>>> Note that you open the writer twice, once unmodified on like 369, >>>> then again in the lines you added. I suggest you either change >>>> line 369 to an uninitialized declaration, or merge 369-374 into a >>>> declaration whose initialization involved a conditional expression. >>>> >>>> But, note that there may be big changes in this area coming soon, >>>> with work to support JEP 106 [1].which will involve rewriting all code >>>> that currently uses File, FileInputStream etc, to use JavaFileObject. >>>> >>>> -- Jon >>> >>>> Hi Jon , >>>> >>>> Got a chance to look at the webrev ? >>>> >>>> Thanks ! >>>> >>>> Regards, >>>> Jayashree V >>>> >>>> On 17-09-2012 8:57 PM, Jonathan Gibbons wrote: >>>>> OK, I will take a look at your latest webrev. >>>>> >>>>> -- Jon >>>>> >>>>> On 09/16/2012 11:54 PM, jayashree viswanathan wrote: >>>>>> Hi Jon , >>>>>> >>>>>> Thanks a lot for looking in and passing your review comments . >>>>>> >>>>>> I have made the changes Please find the webrev at >>>>>> http://cr.openjdk.java.net/~luchsh/7006270_3/ >>>>>> >>>>>> Regards, >>>>>> Jayashree Viswanathan >>>>>> >>>>>> On 13-09-2012 10:55 PM, Jonathan Gibbons wrote: >>>>>>> The basic fix looks OK, I'd recommend a couple of white-space >>>>>>> tweaks, such as a space between ")" and "{" on line 370, and >>>>>>> after "," on line 373. >>>>>>> >>>>>>> In the tests, I suggest blank lines before/after the IBM >>>>>>> copyright on both files, and remove the space before the comment >>>>>>> on line 23 in the Test.java file. >>>>>>> >>>>>>> Are you claiming the copyright on all three files is 2011, not >>>>>>> 2012? >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 08/31/2012 02:50 AM, jayashree viswanathan wrote: >>>>>>>> *Problem statement : *Stylesheet.css is not getting encoded >>>>>>>> like the other generated html files while using -docencoding >>>>>>>> >>>>>>>> *Recreation step : * >>>>>>>> javadoc -docencoding "use non-ascii encoding" HelloWorld.java >>>>>>>> say , >>>>>>>> jdk1.8.0\bin\javadoc.exe -docencoding Cp930 -d docencoding3 >>>>>>>> HelloWorld.java >>>>>>>> >>>>>>>> *Explanation :* >>>>>>>> The stylesheet.css is not getting generated in the proper >>>>>>>> encoding as in the code the configuration.docencoding is not >>>>>>>> getting passed to the output stream . >>>>>>>> while this scenario works in JDK 6 [as confirmed in Java 6u14] >>>>>>>> , below changeset seems to have regressed this when adding new >>>>>>>> copyFile method. >>>>>>>> >>>>>>>> Changeset: >>>>>>>> 792 (ffbf2b2a8611) 7006270: Several javadoc regression tests >>>>>>>> are failing on windows >>>>>>>> >>>>>>>> Please find the webrev patch with changes and jtreg test . >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~luchsh/ojdk-660/ >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Jayashree V >>>>>>> >>>>>> >>>>> >>>> >>> >> > From deepak.patwardhan at itaas.com Wed Oct 17 01:40:06 2012 From: deepak.patwardhan at itaas.com (Deepak S Patwardhan) Date: Wed, 17 Oct 2012 14:10:06 +0530 Subject: marking a method as default in javadocs Message-ID: <002201cdac43$03f50cf0$0bdf26d0$@itaas.com> Hi, Looking at javadocs (as generated by the javadoc command) there is no way to know if an interface method has a default or if an interface is a functional interface. Is there a plan to address either concerns ? Javadocs should carry this information. It will be helpful, in general, and a necessity if source isn't available. The output of javap also doesn't show which methods have defaults (With the verbose flag, enough information is printed to determine which methods are abstract and which are not) . Should the output of simply javap command show this information ? Why or why not ? Regards, Deepak S Patwardhan. From brian.goetz at oracle.com Wed Oct 17 10:49:35 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 17 Oct 2012 13:49:35 -0400 Subject: marking a method as default in javadocs In-Reply-To: <002201cdac43$03f50cf0$0bdf26d0$@itaas.com> References: <002201cdac43$03f50cf0$0bdf26d0$@itaas.com> Message-ID: Yes, there is such a plan. Sent from my iPhone On Oct 17, 2012, at 4:40 AM, Deepak S Patwardhan wrote: > Hi, > > Looking at javadocs (as generated by the javadoc command) there is no way to > know if an interface method has a default or if an interface is a functional > interface. Is there a plan to address either concerns ? Javadocs should > carry this information. It will be helpful, in general, and a necessity if > source isn't available. > > The output of javap also doesn't show which methods have defaults (With the > verbose flag, enough information is printed to determine which methods are > abstract and which are not) . Should the output of simply javap command show > this information ? Why or why not ? > > Regards, > Deepak S Patwardhan. > > >