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<[email protected]>
Subject: Re: docencoding not available to stylesheet
To: jayashree viswanathan<[email protected]>
Cc: javadoc-dev<[email protected]>
Message-ID:<[email protected]>
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
