On Tue, 6 Aug 2024 16:17:07 GMT, Magnus Ihse Bursie wrote:
> @jonathan-gibbons Is this a bug in jtreg, or where these files actually
> improperly named?
Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had
problems with filenames that could cause con
On Tue, 4 Jun 2024 16:24:23 GMT, Alexey Ivanov wrote:
>> Nizar Benalla has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Swing was added in JDK 1.2
>
> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 297:
>
>> 295:
the language or tools, (e.g.
>> `the name of this class`, ``, ``.
>>
>> This change seems to be going backwards.
>>
>> Whatever the policy we use for translating (or not translating) parts of a
>> message, we should be consistent across all tools and documents.
>
y, the diffs are viewable here and was generated using Jonathan
> Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
line 409:
> 407: compiler.err.unconditional.pattern.and.default=Switch umfas
On Sun, 9 Jun 2024 22:07:44 GMT, Damon Nguyen wrote:
>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
>> line 183:
>>
>>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach
>>> Umschalt+Tab.\nVerwenden Sie "I" für automatischen Import, "V" zur
>>>
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` t
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/*
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/*
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Mispla
On Fri, 19 Apr 2024 19:29:31 GMT, Alexey Ivanov wrote:
> > We do not have an overall style guide. The conventional wisdom for editing
> > any existing file is to follow the style in that file, if such a style can
> > be discerned.
>
> That's what I do.
>
> I saw either style used in JDK. Yet
On Fri, 19 Apr 2024 20:38:05 GMT, Naoto Sato wrote:
> OK, fair enough. Approving for the `icu` part
Thank you.
-
PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067280359
On Fri, 19 Apr 2024 19:47:20 GMT, Naoto Sato wrote:
> Unless it is absolutely necessary, I would not fix comments in
> `jdk.internal.icu` sources, as they are in the upstream code, and would like
> to minimize the merging effort.
@naotoj Given the policy and strong desire to compile
On Fri, 19 Apr 2024 11:32:55 GMT, Pavel Rappo wrote:
> This comment is not a review. I simply use the opportunity provided by this
> PR to suggest that we stop making new `/** ... */` and separately fix old
> jtreg comments like this:
>
> ```
> /**
> * @test TestSmallHeap
> * @bug 8067438
On Fri, 19 Apr 2024 10:49:11 GMT, Alexey Ivanov wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update
>> src/java.base/share/classes/sun/net/www/protocol/file/FileURL
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Mispla
comments before a declaration were merged, which fixes a
> bug/omission in the documented serialized form.
Jonathan Gibbons has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnec
On Fri, 19 Apr 2024 10:44:27 GMT, Alexey Ivanov wrote:
>> Please review a set of updates to clean up use of `/**` comments in the
>> vicinity of declarations.
>>
>> There are various categories of update:
>>
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package
On Fri, 19 Apr 2024 10:53:11 GMT, Alexey Ivanov wrote:
>> Please review a set of updates to clean up use of `/**` comments in the
>> vicinity of declarations.
>>
>> There are various categories of update:
>>
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/*
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` t
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**`
Please review a set of updates to clean up use of `/**` comments in the
vicinity of declarations.
There are various categories of update:
* "Box comments" beginning with `/**`
* Misplaced doc comments before package or import statements
* Misplaced doc comments after the annotations for a
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**`
On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust call for `saveDanglingDocComments` for enum members
>
> The build change
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` t
On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo wrote:
> Would this be the first lint -- not doclint -- warning related to comments,
> let alone doc comments?
No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated`
tags in doc comments.
>
Please review the updates to support a proposed new
`-Xlint:dangling-doc-comments` option.
The work can be thought of as in 3 parts:
1. An update to the `javac` internal class `DeferredLintHandler` so that it is
possible to specify the appropriately configured `Lint` object when it is time
to
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using
On Mon, 26 Jun 2023 18:38:26 GMT, Jonathan Gibbons wrote:
> Please review a trivial update to normalize an `@since` tag.
This pull request has now been integrated.
Changeset: 8f5b6771
Author: Jonathan Gibbons
URL:
https://git.openjdk.org/jdk/com
Please review a trivial update to normalize an `@since` tag.
-
Commit messages:
- JDK-8310908: Non-standard `@since` tag in
`com.sun.java.accessibility.util.package-info`
Changes: https://git.openjdk.org/jdk/pull/14663/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14663=00
On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato wrote:
> Left some comments on the translations mainly in Japanese. It is now very
> easy to look at the l10n changes in the generated HTML. One small comment to
> the tool is that it would be nice if the order in HTML (alphabetically sorted
>
On Wed, 5 Apr 2023 17:29:17 GMT, Jonathan Gibbons wrote:
> Please review a docs-only change to add `@spec` tags into `java.desktop`
> public API files
This pull request has now been integrated.
Changeset: 34f0a6ec
Author:Jonathan Gibbons
URL:
https://git.openjdk.org/jdk/
On Wed, 7 Jun 2023 21:37:42 GMT, Jonathan Gibbons wrote:
>> Sure we can; this relates to an earlier comment of yours on
>> Utils.isDirectSupertype here:
>> https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011
>
> The general criticism here is whether we sh
On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 7 Jun 2023 20:48:58 GMT, Pavel Rappo wrote:
>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java
>> line 673:
>>
>>> 671: *
>>> 672: * For now a warning is issued if a doc comment inherits from
>>> 673: * an indirect supertype.
>>
>>
On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo wrote:
> Please review this long-awaited change to documentation inheritance.
>
> This change improves "methods comment algorithm" and introduces directed
> documentation inheritance. While "methods comment algorithm" -- automatic
> search for
> Please review a docs-only change to add `@spec` tags into `java.desktop`
> public API files
Jonathan Gibbons 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 r
On Fri, 5 May 2023 22:19:38 GMT, Jonathan Gibbons wrote:
>> Sorry, but no matter how many times I try, it seems wrong to even for some
>> short amount of time to have @spec point to one place and the javadoc point
>> to another. They should always be consistent.
>>
On Fri, 7 Apr 2023 01:36:37 GMT, Phil Race wrote:
>> Please review a docs-only change to add `@spec` tags into `java.desktop`
>> public API files
>
> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java
> line 227:
>
>> 225: * @spec
On Wed, 3 May 2023 20:51:15 GMT, Phil Race wrote:
>> This work is primarily about adding `@spec` tags, in a semi-automated
>> fashion, using a custom utility that scans comments in the public API,
>> looking for `href`s to "well-known" sites hosting external specifications.
>> While "mostly
On Fri, 7 Apr 2023 01:35:58 GMT, Phil Race wrote:
>> Please review a docs-only change to add `@spec` tags into `java.desktop`
>> public API files
>
> src/java.desktop/share/classes/java/awt/Desktop.java line 591:
>
>> 589: * subprocess
>> 590: * @spec
On Wed, 5 Apr 2023 17:29:17 GMT, Jonathan Gibbons wrote:
> Please review a docs-only change to add `@spec` tags into `java.desktop`
> public API files
On the use of `rfc-editor.org`, this site came up during the original
all-in-one version of this work in PR #11073.
See, for e
Please review a docs-only change to add `@spec` tags into `java.desktop` public
API files
-
Commit messages:
- JDK-8305593: Add @spec tags in java.desktop
Changes: https://git.openjdk.org/jdk/pull/13360/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=13360=00
Issue:
On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote:
> This PR converts Unicode sequences to UTF-8 native in .properties file.
> (Excluding the Unicode space and tab sequence). The conversion was done using
> native2ascii.
>
> In addition, the build logic is adjusted to support reading in the
On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote:
>> Please review this superficial documentation cleanup that was triggered by
>> unrelated analysis of doc comments in JDK API.
>>
>> The only effect that this multi-area PR has on the JDK API Documentation
>> (i.e. the observable effect on
On Fri, 3 Mar 2023 11:31:04 GMT, Alexey Ivanov wrote:
>> Yes, iff means if-and-only-if and is used for extra precision in formal
>> logic, mathematics. As @pavelrappo points out it's a relatively common
>> occurrence in the OpenJDK sources, though perhaps not in the public
>> javadocs.
ike and separate two otherwise consecutive occurrences of
> "type" in that sentence, I split the words with a hyphen and lower-cased
> them: exception-type.
>
> @jonathan-gibbons thoughts?
While the text is technically correct, it may not be as clear as it could be to
all folk tha
On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen wrote:
>> Open l10n drop. Files have been updated with translated versions. Whitespace
>> tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last
On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove updates from unexported files
>
> src/java.xml/share/classes/javax/xml/XMLCo
.net/~jjg/8296546/api.00/external-specs.html)
> page, which you can also find via the new link near the top of the
> [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html)
> pages.
Jonathan Gibbons has updated the pull request with a new target base due to a
On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato wrote:
>> Jonathan Gibbons 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 contai
On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs wrote:
> The java.base/net/, java.http/, java.naming/ changes look reasonable to me -
> though like Alan I wonder if it wouldn't be better to have an inline `{@spec
> }` tag - similar to `{@systemProperty }`, rather than repeating all the
>
.net/~jjg/8296546/api.00/external-specs.html)
> page, which you can also find via the new link near the top of the
> [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html)
> pages.
Jonathan Gibbons has updated the pull request incrementally with one additiona
On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs wrote:
> Thanks for adding the RFC prefix to the RFC link. What is the purpose of
> editing non exported classes though, like those in the `sun.net` subpackages?
That was not intentional, and is a result of the scripted edit. I will look to
.net/~jjg/8296546/api.00/external-specs.html)
> page, which you can also find via the new link near the top of the
> [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html)
> pages.
Jonathan Gibbons has updated the pull request incrementally with one additio
On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 wrote:
> did you changed 420 files ?
I ran a custom utility that edited these files, yes.
-
PR: https://git.openjdk.org/jdk/pull/11073
On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman wrote:
> I'm trying to understand what "fix-ups" will be needed if the automated patch
> is applied. In some cases, it looks the same spec will be linked from "See
> also" and "External Specifications", e.g.
>
On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote:
> > When referencing an RFC, it might be good to keep the RFC number in the
> > text link. For instance I see that java.net.URL now has this:
>
> I agree and also to add that some RFCs have commas in their titles, the same
> separator used
On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote:
> Hi Jon,
>
> When referencing an RFC, it might be good to keep the RFC number in the text
> link. For instance I see that java.net.URL now has this:
>
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
>
>
Please review a "somewhat automated" change to insert `@spec` tags into doc
comments, as appropriate, to leverage the recent new javadoc feature to
generate a new page listing the references to all external specifications
listed in the `@spec` tags.
"Somewhat automated" means that I wrote and
On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to
On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo wrote:
>> This adds exception documentation to JDK methods that would otherwise lose
>> that documentation once JDK-8287796 is integrated. While adding this
>> exception documentation now does not change [^1] the JDK API Documentation,
>> it will
On Mon, 11 Jul 2022 08:04:20 GMT, Joe wrote:
> 8289562: Change bugs.java.com and bugreport.java.com URL's to https
`jdk.compiler` and `jdk.javadoc` changes look OK
-
Marked as reviewed by jjg (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9445
71 matches
Mail list logo
