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.jav
,
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/aft
I have posted a preview of the API and implementation [1] of JEP 105:
DocTree API [2].
This provides the ability to get a structured representation of a
javadoc comment that can be used by tools to analyze the content of
comments.
The API is a natural extension of the existing Compiler Tree
I have posted a preview of an experimental new utility to detect issues
in javadoc comments [1], based on the recently announced [2]
implementation of JEP 105: DocTree API.
The utility is currently called "doccheck", since it is at least
partially inspired by the old Sun "doccheck" doclet, whi
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
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:<[email protected]>
Content-Type: text/plain; charset
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 ge
On 11/05/2012 08:06 AM, jayashree viswanathan wrote:
Hi Jon ,
Can you please review the changeset for the bug 7198272 ?
The Changeset and example page are available in the below link .
http://cr.openjdk.java.net/~jviswana/7198272/
Thanks a lot !
Regards,
Jayashree V
Jayashree,
My initia
On 11/05/2012 12:25 PM, Jonathan Gibbons wrote:
On 11/05/2012 08:06 AM, jayashree viswanathan wrote:
Hi Jon ,
Can you please review the changeset for the bug 7198272 ?
The Changeset and example page are available in the below link .
http://cr.openjdk.java.net/~jviswana/7198272/
Thanks a lot
On 11/05/2012 08:06 AM, jayashree viswanathan wrote:
Hi Jon ,
Can you please review the changeset for the bug 7198272 ?
The Changeset and example page are available in the below link .
http://cr.openjdk.java.net/~jviswana/7198272/
Thanks a lot !
Regards,
Jayashree V
Jayashree,
javadoc is
he tool requires JDK 8 to run.
Thanks to those folk who have been testing the tool, and fixing the
errors in
JDK doc comments that have been identified.
-- Jon
On 09/28/2012 04:28 PM, Jonathan Gibbons wrote:
I have posted a preview of an experimental new utility to detect
issues in javadoc co
On 11/14/2012 10:26 PM, jayashree viswanathan wrote:
Hi Jon ,
http://www.w3.org/TR/wai-aria/appendices
Please read through "10.1.6. HTML 4.01 plus WAI-ARIA DTD" . The
question on if we would like to move upto HTML 5, XHTML now can be a
separate discussion as always with each offering some ad
On 11/14/2012 10:05 PM, jayashree viswanathan wrote:
On 06-11-2012 3:48 AM, Jonathan Gibbons wrote:
On 11/05/2012 12:25 PM, Jonathan Gibbons wrote:
On 11/05/2012 08:06 AM, jayashree viswanathan wrote:
Hi Jon ,
Can you please review the changeset for the bug 7198272 ?
The Changeset and
For those that are interested, note that the implementation of JEP 106,
"Add Javadoc to javax.tools",
is now in jdk8 b66, by way of this changeset:
6493690: javadoc should have a javax.tools.Tool service provider
installed in tools.jar
However, that was only the top of the tip of the iceberg.
See
http://bugs.sun.com/view_bug.do?bug_id=8002304
http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/522a1ee72340
-- Jon
On 12/03/2012 11:18 AM, Zhong Yu wrote:
Hi, would it make more sense in javadoc to group static methods and
give them a distinct section? So we'll probably have sections
On 01/31/2013 07:53 AM, jayashree viswanathan wrote:
On 05-11-2012 1:18 PM, jayashree viswanathan wrote:
Hi Jon,
I have made the changeset based on the possible latest TL level I see
that there are more changes happening in this area of code .
Please find the changeset for the bug 7198273 . Pl
On 01/31/2013 07:52 AM, jayashree viswanathan wrote:
On 05-11-2012 1:53 PM, jayashree viswanathan wrote:
Hi Jon,
I have made the changeset based on the possible latest TL level I see
that there are more changes happening in this area .
Please find the changeset for the bug 7198274 . Requestin
On 01/31/2013 07:54 AM, Roger Riggs wrote:
(Retry, first try may have gotten stuck in the non-subscriber filter)
Please review this fix:
JDK-8004353: Generated html is wrong for overview.html; content has
incorrect css footer class
The webrev includes a description of the problem and solutio
On 02/25/2013 10:03 AM, Uwe Schindler wrote:
Hi,
I already filed bug reports about this to bugs.sun.com approx. 3 weeks ago, but
until today there was no repose at all from the bug reviewers - so I don't even
have a bug number.
We are testing Apache Lucene and Apache Solr with recent snapshot
On 02/25/2013 11:00 AM, Uwe Schindler wrote:
On 02/25/2013 10:42 AM, Uwe Schindler wrote:
Hi,
We are aware of the issues caused by enabling doclint by default in
javadoc -- but it was a deliberate decision to enable the feature by
default, so that authors are aware of problems in their doc com
Both seem odd.
I will investigate. Thanks for the reports.
You can probably work around the issues by disabling doclint for now,
-Xdoclint:none.
-- Jon
On 04/10/2013 06:31 AM, Dawid Weiss wrote:
Hi there,
I've switched to the latest 1.8 snapshot (b84) and javadoc went nuts
about the follo
ny help,
Dawid
On Thu, Apr 11, 2013 at 2:30 AM, Jonathan Gibbons
wrote:
Both seem odd.
I will investigate. Thanks for the reports.
You can probably work around the issues by disabling doclint for now,
-Xdoclint:none.
-- Jon
On 04/10/2013 06:31 AM, Dawid Weiss wrote:
Hi there,
I've switc
Filed 8015523.
-- Jon
On 05/28/2013 12:14 PM, Martin Buchholz wrote:
Hi javadoc folk,
This is a bug report. On my Ubuntu system, using recent lambda-dev
binaries, I see this:
$ man javadoc > /dev/null
:29: warning [p 1, 1.8i]: cannot adjust line
:1556: warning [p 20, 10.3i, div `b+', 0.7i]
On 05/29/2013 12:05 AM, Sven Reimers wrote:
Hi,
I hope this is the correct place to ask. With ea b91 installed from JDK8 I
wanted to use the doclint feature. It seems that is is available from javac
but not from javadoc at the moment, if I look at the help output from javac
-X vs. javadoc -X.
H
The issue number needs to be in the JDK project, not INTJDK.
Please break long lines. In general, unless there are really
good reasons why you should not do so, try and make lines
less than half a screen width wide, on a typical big screen
(e.g. 1920x1200) in a typical font.
In general, the co
Martin,
Thanks for the report. I suspect that is another instance of a known
bug, for which the fix is in review.
-- Jon
On 06/02/2013 09:45 AM, Martin Buchholz wrote:
This is a doclint bug report.
I was playing around with doclint on a recent lambda forest with a
recent jsr166 CVS check
Martin,
Thanks for the report. Filed as 8021010.
-- Jon
On 07/22/2013 10:45 AM, Martin Buchholz wrote:
Hi javadoc team,
This is a bug report.
If javadoc contains something like this:
* This class compares primitive {@code double}
then links like generated javadoc.
However, when this text is
FYI, Sean Hogan has posted an interesting followup comment [1] to my
recent blog entry on javadoc TLC. He demos how to use AJAX and
pushState to provide an improved javadoc viewer that does not use frames.
-- Jon
[1] https://blogs.oracle.com/jjg/entry/javadoc_tlc#comment-1374553083469
I'll take that as a bug report...
-- Jon
On 07/24/2013 05:50 PM, Martin Buchholz wrote:
You're not the only one annoyed by the giant sample code font. I
agree with you that the "regular" text should be regular text size,
and the sample text not too much different - that's why we have
differe
Issue 8021313, should be available on bugs.sun.com soon.
-- Jon
On 07/24/2013 06:23 PM, Jonathan Gibbons wrote:
I'll take that as a bug report...
-- Jon
On 07/24/2013 05:50 PM, Martin Buchholz wrote:
You're not the only one annoyed by the giant sample code font. I
agree with yo
I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's
part of every enum. Is this an oversight or is there a good reason why it's
not documented?
--
Cheers,
Paul
Paul,
Can you give more details?
On a s
Martin,
Noted.
-- Jon
On 09/09/2013 11:49 AM, Martin Buchholz wrote:
Hi doclint/javac folk,
I reported this problem earlier, but that wasn't perhaps the best bug
report. Here's another attempt that is independent of ant and
hopefully provides a cleaner bug report with easy repro. (Inspire
Martin,
Thanks for the clever/thorough test case/demo.
-- Jon
On 09/10/2013 09:58 AM, Jonathan Gibbons wrote:
This is now being tracked as 8024538.
Normally, this should show up soon on bugs.sun.com, but the sync is "a
bit sluggish" right now.
-- Jon
On 09/09/2013 11:49
This is now being tracked as 8024538.
Normally, this should show up soon on bugs.sun.com, but the sync is "a
bit sluggish" right now.
-- Jon
On 09/09/2013 11:49 AM, Martin Buchholz wrote:
Hi doclint/javac folk,
I reported this problem earlier, but that wasn't perhaps the best bug
report.
On 09/19/2013 10:00 AM, Michael Simacek wrote:
Hi,
I thought about improving performance of the default doclet implementation a
bit.
According to profiler results, most of the CPU time is spent in constructing
the member map in VisibleMemberMap.java.
So I've rewritten part of the VisbleMemberM
On 09/19/2013 10:00 AM, Michael Simacek wrote:
Is there any chance of this patch (attached) being accepted into OpenJDK?
I've never made any contribution to OpenJDK before, so I would like to ask for
code review and guidance through the contribution process.
Michael
For reference, the general
On 09/19/2013 10:00 AM, Michael Simacek wrote:
Hi,
I thought about improving performance of the default doclet implementation a
bit.
According to profiler results, most of the CPU time is spent in constructing
the member map in VisibleMemberMap.java.
So I've rewritten part of the VisbleMemberM
On 09/19/2013 11:02 AM, Jonathan Gibbons wrote:
On 09/19/2013 10:00 AM, Michael Simacek wrote:
Hi,
I thought about improving performance of the default doclet
implementation a bit.
According to profiler results, most of the CPU time is spent in
constructing the member map in
On 09/19/2013 10:46 AM, Jonathan Gibbons wrote:
There are two criteria for a change like this:
-- the obvious one -- do all the javadoc regression tests pass. These
are the tests
langtools/test/com/sun/javadoc
langtools/test/tools/javadoc
Two regression tests fail when the patch
On 09/19/2013 10:46 AM, Jonathan Gibbons wrote:
-- does the change affect the generated docs.
... and the answer is "yes". :-)
The order of some parts of the generated docs differs before/after the
patch. This is an issue which needs to be fixed.
At first, I thought it was due
On 09/23/2013 05:36 AM, Michael Simacek wrote:
Thank you for your help, Jon.
I've rewritten it a bit (also had to change the Util.executableMembersEqual
method to fix some issues),
so now all the tests should pass and I have fixed some other bugs.
Now the order of classes is the same and order
On 09/23/2013 05:36 AM, Michael Simacek wrote:
Thank you for your help, Jon.
I've rewritten it a bit (also had to change the Util.executableMembersEqual
method to fix some issues),
so now all the tests should pass and I have fixed some other bugs.
Now the order of classes is the same and order
The new diagnostics are generated by the new doclint feature which is
available from the javac and javadoc command lines.
When invoked from javadoc, it only checks the comments being used for
the docs that you are generating. So, if you are generating docs for
just your public and protected me
On 09/26/2013 06:00 PM, Martin Buchholz wrote:
On Thu, Sep 26, 2013 at 5:45 PM, Jonathan Gibbons
mailto:[email protected]>> wrote:
The new diagnostics are generated by the new doclint feature which
is available from the javac and javadoc command lines.
When i
On 11/25/2013 11:15 AM, Paul Benedict wrote:
If you look at the types that have @Documented annotations, the first
annotation is correctly left-aligned but all others are indented by
one space. If this is already reported, my apologies; if not, please
confirm.
Example:
http://download.java.ne
On 12/23/2013 04:40 AM, Rory O'Donnell Oracle, Dublin Ireland wrote:
Hi Stefan,
CC'ing the javadoc mailing list, best place to discuss.
Rgds,Rory
On 22/12/2013 07:22, Stefan Bodewig wrote:
On 2013-12-19, Rory O'Donnell Oracle, Dublin Ireland wrote:
Some problems may have been fixed, but the
On 01/06/2014 01:22 PM, Jonathan Gibbons wrote:
* @link and @see have changed behavior, in particular we have quite a
few places with
@see "http://www.winzip.com/wz54.htm";
that used to work just fine but now creates "unexpected text"
warnings
- "foo
On 01/07/2014 12:03 AM, Zhong Yu wrote:
That is*not* in the best interest of javadoc.
Also note that, people who write do so from their own "moral"
ground, they think it is the right thing to do.
Javadoc can choose to produce strict html 4.01, but it doesn't have to
only consume strict html 4
On 01/14/2014 06:38 AM, Rory O'Donnell Oracle, Dublin Ireland wrote:
We see that the javadoc executable has become stricter.
Especially the "reference not found" is tricky, since there's a good
chance the sources are from a dependency, something we cannot change.
The only workaround I could f
On 01/14/2014 06:38 AM, Rory O'Donnell Oracle, Dublin Ireland wrote:
Another issue with the javadoc executable is that the
excludedocfilessubdir argument is ignored (on Win7). This seems to be
regression.
Please file a bug in the usual manner.
-- Jon
Christine,
Have you tried doing a docs build and looking at the output. These lines
stand out as being probably wrong:
91 {@code
92 import com.sun.javadoc.*;
93
94 public class ListParams extendsDoclet {
Having HTML inside a "{@code" section means that the HTML will be
rendered lit
Looks good enough.
Do you need me to commit/push it for you?
-- Jon
On 02/03/2014 01:11 PM, Christine wrote:
I have uploaded a new webrev at
http://cr.openjdk.java.net/~cl/8032526/webrev.01/
I removed {@code } and replace the 3 "<" signs with <
Thanks
Christine
Looks good to me.
-- Jon
On 02/12/2014 03:48 AM, Yuri Nesterenko wrote:
Here's a second version, please review:
http://cr.openjdk.java.net/~yan/6457406/webrev.01
A regression test added. One substring call instead of yesterday's two,
as Jonathan suggested in a comment to
https://bugs.openjdk.
The comments at the end of the webrev could be improved as well at some
point.
You can barely see the code for all the dust and spiders. I think it
talks about
"large 32 bits machines" but surely that can't be right... :-)
1200 #release version of core packages
1201
1202 # The rel-cor
Hmmm. That sounds like a bug. Thanks for the report and the detailed
analysis.
-- Jon
On 04/23/2014 06:09 AM, Gilles Duboscq wrote:
Hello,
When using jdk8 to generate javadoc for a 7 source base (some
paths/arguments replaced by ...):
javadoc -J-Xmx2g -XDignore.symbol.file -classpath ...
Filed as JDK-8041628
https://bugs.openjdk.java.net/browse/JDK-8041628
-- Jon
On 04/23/2014 07:33 AM, Jonathan Gibbons wrote:
Hmmm. That sounds like a bug. Thanks for the report and the detailed
analysis.
-- Jon
On 04/23/2014 06:09 AM, Gilles Duboscq wrote:
Hello,
When using jdk8 to
On 07/23/2014 05:28 PM, Zhong Yu wrote:
As an example, on this page
http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html
the 'FRAMES' link is
http://docs.oracle.com/javase/8/docs/api/index.html?java/lang/Class.html
i.e. the `targetPage` is embedded as a query.
This is a proble
FWIW, here is a simple script which we use on the Javadoc team to remove
timestamps from docs. Run the script giving a single argument of a
directory containing html files to be "un-stamped".
For JDK API docs, we not only have to strip out the javadoc timestamps;
we also have to strip out the
igou wrote:
Why not just use the -notimestamp option?
Mike
On Jul 24 2014, at 10:32 , Jonathan Gibbons
mailto:[email protected]>> wrote:
FWIW, here is a simple script which we use on the Javadoc team to
remove timestamps from docs. Run the script giving a single argument
Ivan,
Changes to the source code like this require a corresponding test.
-- Jon
On 11/03/2014 05:16 AM, Ivan Gerasimov wrote:
Thanks David.
Forwarding the request to the correct ML.
Sincerely yours,
Ivan
On 03.11.2014 5:30, David Holmes wrote:
Ivan,
javadoc tool changes need to be review
Bhavesh,
Check out this page:
http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html#invoke-java.lang.Object-java.lang.reflect.Method-java.lang.Object:A-
Look at the large paragraphs for the Parameters, Returns and Throws
sections.
Is there are good reason why the p
This page is notable for having unusually long text (paragraphs) for
these tags instead of the normally shorter text (phrases). That makes
the different format more than usually obvious.
-- Jon
On 11/10/2014 07:26 AM, Kumar Srinivasan wrote:
Curiosity question: But why only this specific page
Finally pushed.
-- Jon
On 04/23/2014 07:40 AM, Jonathan Gibbons wrote:
Filed as JDK-8041628
https://bugs.openjdk.java.net/browse/JDK-8041628
-- Jon
On 04/23/2014 07:33 AM, Jonathan Gibbons wrote:
Hmmm. That sounds like a bug. Thanks for the report and the detailed
analysis.
-- Jon
On
Emmanuel,
Thanks for this report.
As outlined in JEP 221 [1] we are currently working on rewriting
substantial parts of javadoc. The work is being done in the
javadoc.next project [2]. As part of this work, we have encountered
and fixed a number of issues such as you describe, and so it may
be t
Sean,
It's always fun to see people experimenting with ways to improve javadoc
output,
but in this case, there's something even more fun coming up, which will
make your
improvements somewhat unnecessary.
I'm referring to "javadoc search", JEP 225, http://openjdk.java.net/jeps/225
Although it
This patch adds a new factory class to the Compiler Tree API for
creating DocTree nodes.
RFE: https://bugs.openjdk.java.net/browse/JDK-8146208
Webrev: http://cr.openjdk.java.net/~jjg/8146208/webrev.03/
-- Jon
Please review this cleanup to convert the javadoc DocFile impl class to
use java.nio.file.Path instead of java.io.File.
Some related dead code is also deleted.
webrev: http://cr.openjdk.java.net/~jjg/8149773/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8149773
-- Jon
Looks OK to me.
-- Jon
On 02/17/2016 10:26 AM, Volker Simonis wrote:
Hi,
can I please have a review for the following small change which fixes
two javac compilation errors during the build of javadoc if the boot
jdk is older than 8u40:
http://cr.openjdk.java.net/~simonis/webrevs/2016/8150077/
Paul,
Yes, we know about this one and it's on the list to be fixed. It's not
specific to the new doclet; it happens in the ofl doclet as well, and
is related to the transition to supporting HTML 5.
That being said, with the recent arrival of the Search feature, the
index frames on the left
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 r
In the langtools test suite, the convention has been to use the jtreg
@ignore mechanism to identify tests which should not be executed for
some reason.But other repos in OpenJDK use the more recent and more
flexible "exclude list" mechanism, as exemplified by files such as
/test/ProblemList
Sebastian,
I think you've already hit the high points.
-- Jon
On 03/20/2016 04:23 AM, Sebastian Kürten wrote:
Hi,
I have seen that there are several improvements to Javadoc schedulded
for the next release of Java. I'm doing research on the relevance of
the HTML documentation and would appreci
Martin,
Can you provide details on how to reproduce this (e.g. including repo paths)
-- Jon
On 03/24/2016 04:10 PM, Martin Buchholz wrote:
Hi jigsaw/javadoc folk,
I'm trying to update jsr166 CVS to latest jdks and failing.
If I run "ant docs" with a -Djdk9.home pointing at jdk-9+110 binaries
On 04/07/2016 10:04 PM, Martin Buchholz wrote:
I'm not really qualified, but here are random comments:
I think the general idea is right - javac and javadoc need the same
kind of support for modules.
I worry that details may be different, e.g. javadoc has diamond
inheritance and pulls in via @
On 04/11/2016 04:12 PM, Martin Buchholz wrote:
On Mon, Apr 11, 2016 at 3:57 PM, Jonathan Gibbons
wrote:
On 04/07/2016 10:04 PM, Martin Buchholz wrote:
I'm not really qualified, but here are random comments:
I think the general idea is right - javac and javadoc need the same
ki
FYI
On 04/17/2016 04:03 AM, Robert Scholte wrote:
Hi,
in preparation of the DevoxxFr talk about Maven and Java9 by Hervé
Boutemy and Arnaud Héritier I noticed some issues with custom taglets
when generation Javadoc reports.
For the developers of Maven plugins we have a set of Annotations or
On 04/16/2016 03:45 PM, Martin Buchholz wrote:
exec $JDK/bin/javadoc \
-d docs \
-Xdoclint:all \
-Xmodule:java.base \
-modulesourcepath "$JDKSRC/jdk/src/java.base/share/classes" \
javadoc folk,
This looks like a bug. Assuming Martin is using reasonably up to date
JDK 9 code, yo
On 04/18/2016 09:52 AM, Robert Scholte wrote:
Hi,
in preparation of the DevoxxFr talk about Maven and Java9 by Hervé
Boutemy and Arnaud Héritier I noticed some issues with custom taglets
when generation Javadoc reports.
For the developers of Maven plugins we have a set of Annotations or
D
On 04/18/2016 11:33 AM, Martin Buchholz wrote:
On Mon, Apr 18, 2016 at 11:11 AM, Jonathan Gibbons
wrote:
On 04/16/2016 03:45 PM, Martin Buchholz wrote:
exec $JDK/bin/javadoc \
-d docs \
-Xdoclint:all \
-Xmodule:java.base \
-modulesourcepath "$JDKSRC/jdk/src/java.base/
The conversion from using sun.boot.class.path to jdk.launcher.patch.*
was imperfect, and becoming more so with the move towards using multiple
-Xpatch options, in different system properties.
A more complete/general solution would be shared infrastructure to fork
tools and inherit selected jdk
Start.java, line 241, 241, use &&, not nested if
Start:490, generally, the terminology in langtools is to use "path"
to mean a complete search path, as in a series of file system locations,
such as a class path or source path. With that in mind, the decl
on 490 would be better named "userTagle
Please review this fix to move internal classes from an exported package.
Although the webrev appears long, the work itself is fundamentally simple:
Using an IDE, all classes in com.sun.tools.javadoc except Main were moved
as one into a subpackage com.sun.tools.javadoc.main. A few constructors
OK
On 04/29/2016 09:20 AM, Kumar Srinivasan wrote:
Hello,
Fixes incorrect sorting in the All Classes and Index files.
https://bugs.openjdk.java.net/browse/JDK-8155061
Webrev at:
http://cr.openjdk.java.net/~ksrini/8155061/webrev.00/
Thanks
Kumar
OK, but one has to wonder why ExitJavadoc is defined in Messager, and not
at the top level.
-- Jon
On 04/29/2016 11:28 AM, Kumar Srinivasan wrote:
Please review, this addresses all your comments below.
http://cr.openjdk.java.net/~ksrini/8154482/webrev.02/
Thanks
Kumar
Start.java, line 241,
OK, but webrevs are not hard to generate and upload, and would have been
preferable.
-- Jon
On 04/30/2016 08:32 AM, Alan Bateman wrote:
On 30/04/2016 15:50, Kumar Srinivasan wrote:
Hello,
Please review this easy fix.
http://cr.openjdk.java.net/~ksrini/8154578
https://bugs.openjdk.java.n
Doh! I missed the webrev. Mea-culpa.
-- Jon
On 05/02/2016 11:01 AM, Jonathan Gibbons wrote:
OK, but webrevs are not hard to generate and upload, and would have
been preferable.
-- Jon
On 04/30/2016 08:32 AM, Alan Bateman wrote:
On 30/04/2016 15:50, Kumar Srinivasan wrote:
Hello
On 05/16/2016 07:52 AM, Paul Benedict wrote:
I was wondering if JavaDoc in JDK 9 provides any visual indicator
(color, format, textual output, or otherwise) to indicate exported
packages vs non-exported packages?
Cheers,
Paul
javadoc is still a work in progress, and somewhat late to the modu
ey can be stylized differently.
Cheers,
Paul
On Mon, May 16, 2016 at 11:10 AM, Jonathan Gibbons
mailto:[email protected]>> wrote:
On 05/16/2016 07:52 AM, Paul Benedict wrote:
I was wondering if JavaDoc in JDK 9 provides any visual
indicator (color, form
quot;Exported Packages"
PS: But I don't want to go through so many clicks :-) Having the
option listed immediately is preferable for my taste.
https://docs.oracle.com/javase/8/docs/api/
Cheers,
Paul
On Mon, May 16, 2016 at 11:40 AM, Jonathan Gibbons
mailto:[email protected]
ic and internal APIs. I
think this will be the default in the OSS world.
Now, I wouldn't expect non-exported packages for commercial/private
software, but that is a different matter.
Cheers,
Paul
On Mon, May 16, 2016 at 12:15 PM, Jonathan Gibbons
mailto:jonathan.gibb...@oracl
OK by me.
We might at some point want to do additional cleanup of the names (the
current names are archaic and do not accurately reflect their intent)
and we might want to redice the overloads in jdk.javadoc, but for the
issue being addressed, the proposed change is good.
-- Jon
On 05/16/20
Uwe,
Getting a message like "An unknown error has occurred" without any
additional details is enough of a reason to file a bug.
I note your comment about issues with -Xold and Ant. If you are just
trying to document packages (i.e. no modules), to workaround this bug in
the new doclet, it sh
Please review this small change to deprecate the entry points to
the old javadoc tool, and the containing package.
JBS: https://bugs.openjdk.java.net/browse/JDK-8157608
webrev: http://cr.openjdk.java.net/~jjg/8157608/webrev.00
-- Jon
(Fixed subject line to be more helpful)
On 05/25/2016 06:37 PM, Jonathan Gibbons wrote:
Please review this small change to deprecate the entry points to
the old javadoc tool, and the containing package.
JBS: https://bugs.openjdk.java.net/browse/JDK-8157608
webrev: http://cr.openjdk.java.net
Please review this change to deprecate the old com.sun.javadoc API, and
along with that, to also deprecate the corresponding implementation classes.
You can see the updated API docs, and the webrev, at the link below.
The webrev can be reviewed in two parts:
1. The types in com.sun.javadoc have
Please review this simple fix for two related aspects of the same problem:
Export the "standard doclet" used by javadoc, such that it is possible
to derive alternative doclets, either by delegation or subtyping.
In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old one
remains
On 06/20/2016 04:18 PM, Kumar Srinivasan wrote:
Hello,
Please review the changes to fix:
https://bugs.openjdk.java.net/browse/JDK-8159305
The webrev is here:
http://cr.openjdk.java.net/~ksrini/8159305/webrev.00/
The spec-diff is here for reference:
http://cr.openjdk.java.net/~ksrini/8159305/
On 07/11/2016 06:28 PM, Rick Hillegas wrote:
Hey folks,
Is there a primer for writing Java 9 Taglets which is similar to the
primer for writing old-style Taglets found here:
http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/taglet/overview.html.
I am trying to get a clean, warni
On 07/12/2016 06:45 PM, Rick Hillegas wrote:
Hi Jon,
Thanks for replying. Some comments inline...
On 7/11/16 7:00 PM, Jonathan Gibbons wrote:
On 07/11/2016 06:28 PM, Rick Hillegas wrote:
Hey folks,
Is there a primer for writing Java 9 Taglets which is similar to the
primer for writing
Joe, all,
Work for javadoc support for modules is a work in progress. While we
should have caught yesterday's problems ahead of time, it will also be
the case that as javadoc moves along, we will refine the contents of the
module summary page, so that items which should not be documented are
1 - 100 of 1804 matches
Mail list logo
