docencoding not available to stylesheet

Thu Nov 22 23:27:53 PST 2012

On 23-11-2012 12:52 PM, jayashree viswanathan wrote:
> 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<jonathan.gibbons at oracle.com>
>>>>> Subject: Re: docencoding not available to stylesheet
>>>>> To: jayashree viswanathan<jviswana at linux.vnet.ibm.com>
>>>>> Cc: javadoc-dev<javadoc-dev at openjdk.java.net>
>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> Hi Jon ,
>
> Here is a patch for improving the javadocTester and getting the search 
> using the specified encoding .
>
> http://cr.openjdk.java.net/~jviswana/8000743_test/webrev.01/
>
> Thanks and Regards,
> Jayashree V

Additionally I noted that the stylesheet.css is not getting overwritten 
, which results in retaining the same old stylesheet.css [while other 
html files are overwritten] stylesheet.css. In scenario when we are 
switching between encoding /between java 6/7 it becomes evident .

It is an existing behavior for a time now .

Thanks and Regards,
Jayashree Viswanathan