On 23-11-2012 12:57 PM, jayashree viswanathan wrote:
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
Hi Jon ,
This has the changeset on the improvement of testcase that you suggested
. Can we take this up or continue with our existing testcase added ?
Thanks and Regards,
Jayashree Viswanathan
