On Mon, 21 Nov 2022 22:55:40 GMT, Daniel D. Daugherty
wrote:
> Misc stress testing related fixes:
>
> [JDK-8295424](https://bugs.openjdk.org/browse/JDK-8295424) adjust timeout for
> another JLI GetObjectSizeIntrinsicsTest.java subtest
> [JDK-8297367](https://bugs.openjdk.org/browse/JDK-8297367
On Tue, 22 Nov 2022 21:05:16 GMT, Daniel D. Daugherty
wrote:
>> test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java line
>> 73:
>>
>>> 71:
>>> 72: import jdk.test.lib.Platform;
>>> 73: import jtreg.SkippedException;
>>
>> Nit: the order of imports on 72-73 needs to be swa
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
r
.java.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 addi
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
> refere
.java.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
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
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, 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 revisi
it more English-like 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
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. Perhaps
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 t
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
>
Please review a cleanup in DocCommentParser to merge blockContent and
inlineContent into a single method to parse "rich content" in a doc comment.
-
Depends on: https://git.openjdk.org/jdk/pull/13362
Commit messages:
- JDK-8305713: DocCommentParser: merge blockContent and inlineCon
> Please review a cleanup in DocCommentParser to merge blockContent and
> inlineContent into a single method to parse "rich content" in a doc comment.
Jonathan Gibbons has updated the pull request incrementally with 42 additional
commits since the last revision:
- Merge remote
> Please review a cleanup in DocCommentParser to merge blockContent and
> inlineContent into a single method to parse "rich content" in a doc comment.
Jonathan Gibbons has updated the pull request with a new target base due to a
merge or a rebase. The pull request now con
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
> curre
On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls wrote:
> Simple doc tag addition.
>
> These are files which describe an interface that has been with us since 1.5.
> The files themselves were previously generated at build time, but have been
> in the repo since jdk15. But the API is since 1.5.
On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote:
> Please review these changes to the nroff manpage files so that they match
> their markdown sources that Oracle maintains.
>
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022
> if needed. Additionally:
>
> T
On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote:
> Please review these changes to the nroff manpage files so that they match
> their markdown sources that Oracle maintains.
>
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022
> if needed. Additionally:
>
> T
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 increas
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 defin
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 u
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
>
> Extern
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 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.
> http://cr.openjdk.java.net/~jjg/82965
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
Please review an update for the troff man pages, following the recent update to
upgrade to use pandoc 2.19.2
(See https://bugs.openjdk.org/browse/JDK-8297165)
In conjunction with this, one javadoc test also needs to be updated, to work
with the new form of output generated by the new version of
On Fri, 18 Nov 2022 02:31:19 GMT, David Holmes wrote:
> Hi @jonathan-gibbons ,
>
> I notice that in the new version dash characters are no longer escaped as
> `-`, do these still display correctly?
Yes, at least in all the files I verified and I have no reason to believe
t generated by the new version of pandoc.
Jonathan Gibbons has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Fix merge issue
- Merge with upstream/master
- JDK-8297164: Update troff man pages and CheckM
On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote:
> Please review an update for the troff man pages, following the recent update
> to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
>
> In conjunction with this, one javadoc test also need
.java.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 ad
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 a
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 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.
> src/jdk.javadoc/share/man/javadoc.1
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, 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 `/**`
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 `/*
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 `/**
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
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Marked as reviewed by jjg (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19119#pullre
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
>>> V
iffs 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
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.
>
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
On Wed, 13 Nov 2024 20:17:24 GMT, Kevin Walls wrote:
> I think this means the one-true-master copy of a man page is now the public
> .md file. All contributors can now change and improve man pages, and would be
> expected to make necessary man page updates when making other changes. (Which
> i
On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote:
> In several (most? all?) of the build system files, the copyright header
> includes the classpath exception. This makes no sense, and should be removed.
>
> I have removed the classpath exception from makefiles, autoconf, shell
> sc
53 matches
Mail list logo
