Hi Bhavesh,
This looks fine to get the build going again; please push this right away.
As we discussed off-list, there will probably need to be some additional
javadoc mechanisms so that checking for this kind of implementation
detail doesn't run afoul of doclint unnecessarily.
Thanks,
-Joe
+1
-Joe
On 1/15/2019 3:02 PM, Jonathan Gibbons wrote:
Please review this trivial change to reconcile a bad merge.
One changeset added a new test which depends on the JavadocTester
library; a different changeset moved the library. The test needs to
be updated for the new location of the lib
Hi Pavel,
Looks fine in general, assuming the change to Class.java renders
correctly in output.
Thanks,
-Joe
On 4/7/2020 8:28 AM, Pavel Rappo wrote:
Hi Ivan,
On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote:
Hi Pavel!
A couple of comments.
1)
java/util/logging/Formatter.java
This has on
ortion was necessary at the time to get (almost) the
desired effect.
Thanks,
-Joe
On 7 Apr 2020, at 20:23, Joe Darcy wrote:
Hi Pavel,
Looks fine in general, assuming the change to Class.java renders correctly in
output.
Thanks,
-Joe
On 4/7/2020 8:28 AM, Pavel Rappo wrote:
Hi Ivan,
Looks fine Jon; cheers,
-Joe
On 6/10/2020 9:07 PM, Jonathan Gibbons wrote:
Please review a trivial doc-only change to fix 3 missing doc comments
detected by doclint. The new comments do not add any semantically
new or interesting information, so no CSR.
For the javac case, a preferable solutio
On Mon, 21 Sep 2020 21:36:39 GMT, Vicente Romero wrote:
>> Co-authored-by: Vicente Romero
>> Co-authored-by: Harold Seigel
>> Co-authored-by: Jonathan Gibbons
>> Co-authored-by: Brian Goetz
>> Co-authored-by: Maurizio Cimadamore
>> Co-authored-by: Joe Dar
FYI, I had a good experience taking a trial run of this patch to update
the java.compiler APIs to use the new feature. I didn't find any issues;
a specdiff comparing with and without use of the new tag didn't have any
unexpected diffs. (There were cases where small wording differences
existed a
On Thu, 3 Dec 2020 06:52:49 GMT, Hannes Wallnöfer wrote:
> This fixes the problem that some tests in TestLinkPlatform.java rely on a
> static list of properties, causing them to fail when a new Java source
> version is added. The solution is to create the properties file on the fly.
>
> I als
On Wed, 2 Dec 2020 15:39:56 GMT, Roger Riggs wrote:
>
>
> There is lots of other duplication/repetition in most javadoc. I'd rather see
> some kind of text macro that would allow a single definition of a string that
> can be repeated. The source would be a bit less readable, but it would be
On Fri, 27 Nov 2020 16:33:27 GMT, Roger Riggs wrote:
>
>
> ```
> /**
> * {@return the result} Optional additional text.
> */
> ```
>
> The java source looks a bit odd/unusual because the "first sentence" does not
> appear to end with a period.
> Though it seems like a convenience to inclu
On Wed, 24 Feb 2021 02:09:10 GMT, Jonathan Gibbons wrote:
> Fix test to work on Windows.
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2702
On Thu, 25 Feb 2021 21:37:01 GMT, Jonathan Gibbons wrote:
> Please review this doc fix to provide a couple of missing `@param` tags
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2731
On Fri, 28 May 2021 19:07:17 GMT, Jan Lahoda wrote:
>> As noted in:
>> https://bugs.openjdk.java.net/browse/JDK-8265981?focusedCommentId=14423316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423316
>>
>> Methods in various utility visitor classes in jdk.compile
The @jls and @jvms taglet share most of their functionality. A JLS URL looks
like
https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1
and a JVMS URL looks like
https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2
The current taglet inc
On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy wrote:
> The @jls and @jvms taglet share most of their functionality. A JLS URL
> looks like
>
> https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1
>
> and a JVMS URL looks like
>
>
> htt
Simple cleanup as a follow-on to JDK-8264865. Clean langtools test run.
-
Commit messages:
- 8264866: Remove unneeded WorkArounds.isAutomaticModule
Changes: https://git.openjdk.java.net/jdk/pull/4417/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4417&range=00
Issue:
On Tue, 8 Jun 2021 19:37:28 GMT, Joe Darcy wrote:
> Simple cleanup as a follow-on to JDK-8264865. Clean langtools test run.
This pull request has now been integrated.
Changeset: 7a378165
Author: Joe Darcy
URL:
https://git.openjdk.java.net/jdk/com
Switch out logic in WorkArounds for a different expression implemented using
javax.lang.model.Elements logic.
Langtools regression test suite passes with the changes.
-
Commit messages:
- 8271711: Remove WorkArounds.isSynthetic
Changes: https://git.openjdk.java.net/jdk/pull/4967/f
On Tue, 3 Aug 2021 04:40:33 GMT, Joe Darcy wrote:
> Switch out logic in WorkArounds for a different expression implemented using
> javax.lang.model.Elements logic.
>
> Langtools regression test suite passes with the changes.
This pull request has now been integrated.
Changes
On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote:
> Please review a semi-automatic update of the nroff man pages from the
> upstream files.
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk17/pull/303
On Wed, 11 Aug 2021 17:38:49 GMT, Jonathan Gibbons wrote:
> Please review a do-over of JDK-8249634, to report a missing doc comment when
> an implicit/default constructor is used.
>
> The `src` code is the same as before. The previous version had missing test
> files (now added), and had a t
This is an initial PR for expanded lint warnings done under two bugs:
8202056: Expand serial warning to check for bad overloads of serial-related
methods and ineffectual fields
8160675: Issue lint warning for non-serializable non-transient instance fields
in serializable type
to get feedback on
") or other changes in place.
> For one module, I temporarily disabled the Xlint:serial check.
>
> In terms of performance, I have not done benchmarks of the JDK build with and
> without these changes, but informally the build seems to take about as long
> as before.
Joe Darc
Augmentations to javac's Xlint:serial checking are out for review (#5709) and
various javac and javadoc implementation libraries would need some changes to
pass under the expanded checks.
The changes are to suppress warnings where non-transient fields in serializable
types are not declared with
") or other changes in place.
> For one module, I temporarily disabled the Xlint:serial check.
>
> In terms of performance, I have not done benchmarks of the JDK build with and
> without these changes, but informally the build seems to take about as long
> as before.
Joe Darc
") or other changes in place.
> For one module, I temporarily disabled the Xlint:serial check.
>
> In terms of performance, I have not done benchmarks of the JDK build with and
> without these changes, but informally the build seems to take about as long
> as before.
Joe Dar
On Wed, 29 Sep 2021 17:35:03 GMT, Pavel Rappo wrote:
>
>
> Is there any semantic difference between "not statically Serilizable" and
> "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.
Same semantics. The first phase of this cleanup used "not statically
Serilizable"; however, I
On Wed, 29 Sep 2021 18:11:24 GMT, Pavel Rappo wrote:
>
>
> > > Is there any semantic difference between "not statically Serilizable" and
> > > "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.
> >
> >
> > Same semantics. The first phase of this cleanup used "not statically
> >
t for review separately in an effort to de-bulk the
> review needed for the new checks themselves.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request co
t for review separately in an effort to de-bulk the
> review needed for the new checks themselves.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback.
-
Changes:
- all: https://git.openjdk.java.net/jdk
t for review separately in an effort to de-bulk the
> review needed for the new checks themselves.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update copyright years.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pul
On Tue, 28 Sep 2021 00:07:16 GMT, Joe Darcy wrote:
> Augmentations to javac's Xlint:serial checking are out for review (#5709) and
> various javac and javadoc implementation libraries would need some changes to
> pass under the expanded checks.
>
> The changes are to sup
On Wed, 29 Sep 2021 22:52:08 GMT, Jonathan Gibbons wrote:
>
>
> There are 3, maybe just 2, groups of files in this review.
>
> `sjavac` is an internal utility that ought not to be in the `src/` tree, so
> the changes there don't matter.
>
> The various `Result` classes and the javadoc except
") or other changes in place.
> For one module, I temporarily disabled the Xlint:serial check.
>
> In terms of performance, I have not done benchmarks of the JDK build with and
> without these changes, but informally the build seems to take about as long
> as before.
Joe D
On Thu, 4 Nov 2021 11:48:04 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they are
On Wed, 26 Jan 2022 02:20:24 GMT, Jonathan Gibbons wrote:
> Please review a small modification to the way that bad references are
> reported by DocLint.
>
> A new "mode" is introduced, `strictReferenceChecks`.
>
> If the mode is _not_ set, references that explicitly include a module name
>
The changes in this PR on top of the out-for-review changes in
https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking
to be enabled in all JDK modules.
Typically, a @SuppressWarnings("doclint:refernce") annotation is added to
declaration with javadoc blocks that have alr
On Fri, 28 Jan 2022 00:04:34 GMT, Naoto Sato wrote:
> Looks fine. Nit: some files need copyright year updates.
Acknowledged; I'll run a copyright update script before pushing (I tend to run
that close to pushing to avoid spurious, if minor, merge conflicts). Thanks.
-
PR: https://
On Wed, 26 Jan 2022 16:46:23 GMT, Jonathan Gibbons wrote:
>> Please review a small modification to the way that bad references are
>> reported by DocLint.
>>
>> A new "mode" is introduced, `strictReferenceChecks`.
>>
>> If the mode is _not_ set, references that explicitly include a module n
nnotation type is not declared to allow its annotations to
> be applied to package declarations. I'll look into amending that, but in the
> mean time, I think it is beneficial for the JDK build, and the base module in
> particular, to have compile-time doclint protections turned on.
Joe
On Wed, 26 Jan 2022 16:46:23 GMT, Jonathan Gibbons wrote:
>> Please review a small modification to the way that bad references are
>> reported by DocLint.
>>
>> A new "mode" is introduced, `strictReferenceChecks`.
>>
>> If the mode is _not_ set, references that explicitly include a module n
nnotation type is not declared to allow its annotations to
> be applied to package declarations. I'll look into amending that, but in the
> mean time, I think it is beneficial for the JDK build, and the base module in
> particular, to have compile-time doclint protections turned on.
Joe
On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote:
> The changes in this PR on top of the out-for-review changes in
> https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint
> checking to be enabled in all JDK modules.
>
> Typically, a @SuppressWarnings(&q
On Tue, 1 Feb 2022 00:22:31 GMT, Jonathan Gibbons wrote:
> Remove review a trivial fix to remove a workaround for the absence of some
> CSS classes in HtmlStyle.java. Those snippet-related classes have now been
> added, and the workaround needs to be removed.
Marked as reviewed by darcy (Revie
On Fri, 25 Feb 2022 17:46:05 GMT, Pavel Rappo wrote:
>> Explorative refactoring performed while looking into multiple `@inheritDoc`
>> issues. The easiest way to review it is to, probably, go commit by commit;
>> they are quite focused and commented. Not only the branch as a whole, but
>> all
On Sat, 26 Feb 2022 01:12:39 GMT, Jonathan Gibbons wrote:
> > ElementKind.isExecutable[Element]
> > ElementKind.isVariable[Element]
> > ElementKind.isDeclaredType() // isClass || isInterface currently
>
> Yes, predicates for the "unions" would be useful, especially now that the
> language is ad
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7268
On Tue, 8 Mar 2022 17:58:28 GMT, Jonathan Gibbons wrote:
>> Out of all executable elements, inherit documentation only for methods.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
> line 311:
>
>> 309: // Note that e.getKind().isInterface() is not the
On Thu, 28 Apr 2022 22:32:59 GMT, Jonathan Gibbons wrote:
> Please review a trivial update for doclint, to check for `@param` tags for
> type parameters of classes and interfaces.
>
> The bug was discovered recently, while making an update for record
> components, but this part of the fix was
On Wed, 18 May 2022 14:56:47 GMT, Christian Stein wrote:
> This PR adds an optional description accessor on `ToolProvider` interface.
>
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpack
50 matches
Mail list logo
