On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Wallnöfer wrote:
> Please review an enhancement to make `DocCommentParser` normalize whitespace
> inside `` elements. The normalization is conceptually simple and and
> intended to be minimally invasive. Before parsing, `DocCommentParser` checks
> whethe
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
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 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
;>
>> Regardless of the details, I was wondering if instead of adding a new tag
>> with an attribute, we should just add an attribute to an existing tag.
>>
>> `dfn` seems to be designed exactly for that [^1][^2]. Additionally, keeping
>> tags to a minimum might n
On Fri, 20 Sep 2024 14:02:14 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest relea
On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest relea
On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest relea
On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest relea
On Thu, 19 Sep 2024 16:38:54 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest relea
On Mon, 9 Sep 2024 18:37:47 GMT, Joe Darcy wrote:
> Use index and definition tags in AnnotatedElement.
OK.
As a subsidiary follow-up, one might ask whether `{@index...}` should
implicitly include `` tags in its output.
-
Marked as reviewed by jjg (Reviewer).
PR Review: https://g
On Fri, 6 Sep 2024 12:09:16 GMT, Pavel Rappo wrote:
> Thoughts?
My initial thought is, at least we're working with specific tags (`@jls` and
`@jvms`) rather than generic HTML links (`...`), since that
permits the kind of detailed analysis and checking you are doing.
Preview-ness is a pervasiv
On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo wrote:
> This fixes some of the recently discovered [issues] with the block variants
> of the specification tags. While reviewing, please check the proposed changes
> against the actual specifications. Since the specifications for JDK 23 are
> not y
On Tue, 27 Aug 2024 22:15:17 GMT, Chen Liang wrote:
> `TypeKind` enum constants are named in wrong code style; correct them before
> finalization.
>
> Also improved `TypeKind` specification to talk about not mentioned
> `returnType`, `void`, and subword types being erased to int (and how). See
On Mon, 12 Aug 2024 18:42:25 GMT, Joe Darcy wrote:
>> Hi all,
>>
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014)
>> improving the use of `@jvms` tags by adding `JVMS` prior to the tag.
>>
>> Thanks,
>> Sonia
>
> Looks fine; increasing review count to also include
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
On Wed, 26 Jun 2024 18:08:21 GMT, Nizar Benalla wrote:
>> Nizar Benalla 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 contains four additional
>> commi
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.
>
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
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
On Fri, 7 Jun 2024 21:05:33 GMT, Joe Darcy wrote:
> Use the value tag to make the javadoc for various format-related constants
> more informative to readers. Currently the information is available by
> following the "Constant Field Values" link.
>
> I'll reflow the paragraphs before a push.
Y
On Mon, 13 May 2024 20:14:38 GMT, Nizar Benalla wrote:
>> Please review this PR that aims to add all the remaining needed `@since`
>> tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are
On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote:
> With the advent of JEP 467, `///` comments may be treated as documentation
> comments, and may be subject to the recently new `javac` warning about
> "dangling doc comments" in unexpected places.
>
> In keepin
> exact form of the comment prefix was not significant. (Phew!)
>
>
> (This PR is informally blocked by JEP 467).
Jonathan Gibbons has updated the pull request incrementally with one additional
commit since the last revision:
incorporate review comments
-
Chan
On Tue, 28 May 2024 20:01:46 GMT, Alan Bateman wrote:
> > OK. I was just trying to honor the apparent intent to make the comment
> > stand out more than just a plain `//` comment, but I have no strong
> > feelings against reducing `///` to `//`
>
> In this case I would reduce it to '//' but ot
On Thu, 23 May 2024 05:52:57 GMT, Alan Bateman wrote:
> > A long vertical series of lines beginning /// is replaced by lines
> > beginning //|.
>
> This one looks unusual when it's just one line, I could imagine deleting the
> "|" in these cases.
OK. I was just trying to honor the apparent in
On Wed, 22 May 2024 20:13:08 GMT, Naoto Sato wrote:
>> With the advent of JEP 467, `///` comments may be treated as documentation
>> comments, and may be subject to the recently new `javac` warning about
>> "dangling doc comments" in unexpected places.
>>
>> In keeping with the policy to keep
With the advent of JEP 467, `///` comments may be treated as documentation
comments, and may be subject to the recently new `javac` warning about
"dangling doc comments" in unexpected places.
In keeping with the policy to keep the `java.base` module free of all `javac`
warnings, this patch prop
On Sun, 12 May 2024 08:36:44 GMT, Chen Liang wrote:
> Some tests are not migrated to the ClassFile API in previous migrations.
>
> - Some are simple oversights that didn't remove usages of
> com.sun.tools.classfile;
> - The CallerSensitive ones used an old utility, replaced by CF API-based ne
On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan wrote:
> Clean up non-standard use of /// comments in `java.base`
This PR is premature.
Until JEP 467 is integrated, there is nothing special about `///` comments, and
the compiler does not report on non-standard use.
There is a Draft PR for this iss
On Thu, 9 May 2024 14:23:37 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merge
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
While `@since` might not be considered a normative part of the
specification, (it's effectively a cache of derived meta-data) it is
part of the generated documentation, and as such deserves to be correct.
-- Jon
On 5/5/24 4:33 PM, Pavel Rappo wrote:
On Mon, 29 Apr 2024 17:46:24 GMT, Nizar Ben
On Mon, 29 Apr 2024 11:31:23 GMT, Nizar Benalla wrote:
>> test/jdk/tools/sincechecker/SinceChecker.java line 423:
>>
>>> 421: }
>>> 422:
>>> 423: //these were preview in before the introduction of the
>>> @PreviewFeature
>>
>> Just curious: where do you find this information?
>
> Used
On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla wrote:
> This checker checks the values of the `@since` tag found in the documentation
> comment for an element against the release in which the element first
> appeared.
>
> Real since value of an API element is computed as the oldest release in
On Wed, 1 May 2024 18:42:12 GMT, Weibing Xiao wrote:
>> nroff man page update for jar tool.
>> This update is caused by the change of
>> https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got
>> updated in other repos, the corresponding nroff man page was never updated
>> in
On Wed, 1 May 2024 17:52:13 GMT, Weibing Xiao wrote:
> nroff man page update for jar tool.
> This update is caused by the change of
> https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got
> updated in other repos, the corresponding nroff man page was never updated in
> Open
On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla wrote:
> This checker checks the values of the `@since` tag found in the documentation
> comment for an element against the release in which the element first
> appeared.
>
> Real since value of an API element is computed as the oldest release in
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 `/**`
> * Misplaced
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 `java.base
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 81
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: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 `/**`
> * Misplaced
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 or
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 or
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 declar
On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy wrote:
> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
Marked as reviewed by jjg (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18828#pullrequestreview-2007300284
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.
> src/jdk.javadoc/share/man/javadoc.1
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 Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote:
> Please review this simple bugfix to properly construct links to preview JEPs.
>
> The most straightforward fix I could think of was to pass `String` rather
> than `int` (`Integer`) to a method, which eventually calls
> `java.text.MessageFo
On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx wrote:
>> Update the documentation for `@return` tag of `putIfAbsent` to match the
>> main description. `putIfAbsent` uses the same wording as `put` for its
>> `@return` tag, but that is incorrect. `putIfAbsent` never returns the
>> **previous**
On Thu, 14 Dec 2023 22:17:54 GMT, Alisen Chung wrote:
>> Translation drop for JDK22 RDP1
>
> Alisen Chung has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed quotes around Ablehnen
The diffs are more conveniently available here:
https:
On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey wrote:
> The comments are attached to the modifiers (first thing it encounters.) I’m
> sure the javadoc toolset has a method that gets the comments from the right
> thing.
In the AST created by the parser, doc comments should be attached to
_declar
On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to the way Java modules work, t
On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona wrote:
>> Classfile API is an internal library under package `jdk.internal.classfile`
>> in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves
>> it into `java.lang.classfile`.
>> It repackages all uses across JDK
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
On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons wrote:
> Please review a trivial update to remove a redundant `@since` tag.
This pull request has now been integrated.
Changeset: 46add3f8
Author: Jonathan Gibbons
URL:
https://git.openjdk.org/jdk/com
Please review a trivial update to remove a redundant `@since` tag.
-
Commit messages:
- JDK-8310909: java.io.InvalidObjectException has redundant `@since` tag
Changes: https://git.openjdk.org/jdk/pull/14662/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14662&range=00
Iss
On Fri, 23 Jun 2023 11:32:04 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [4bf78162](https://github.com/openjdk/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
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, 8 Jun 2023 21:36:03 GMT, Jonathan Gibbons wrote:
> Please review a trivial docs change to fix a URL in a `@spec` tag consistent
> with equivalent URLs in other tags.
> (Consistency will be required when the External Specifications page is
> enabled.)
This pull request
Please review a trivial docs change to fix a URL in a `@spec` tag consistent
with equivalent URLs in other tags.
(Consistency will be required when the External Specifications page is enabled.)
-
Commit messages:
- JDK-8309686: inconsistent URL for https://www.unicode.org/reports/tr
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 inher
On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy wrote:
> Time to get JDK 22 underway...
test/langtools/tools/javac/versions/Versions.java line 26:
> 24: /*
> 25: * @test
> 26: * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545
> 8000961 8030610 8028546 8188870 8173382 8173382
On Fri, 21 Apr 2023 21:14:00 GMT, Christian Stein wrote:
>> This pull request addresses the open ends left by
>> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>>
>> Changes:
>> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt`
>> to `jdk.com
On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote:
> This pull request addresses the open ends left by
> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
>
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt`
> to `jdk.compiler`
On Tue, 18 Apr 2023 12:08:50 GMT, Andrey Turbanov wrote:
> Interesting, why this JBS ticked is considered as a bug?
There's no obvious best choice here (bug, enhancement, task) and as is, it was
the same as for similar previous items.
-
PR Comment: https://git.openjdk.org/jdk/pull
> 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
> 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.
-
Depends on: https://git.openjdk.org/jdk/pull/13362
Commit messages:
- JDK-8305713: DocCommentParser: merge blockContent and inlineCon
On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons wrote:
> Please review a change to add `@spec` tags (and remove some equivalent `@see`
> tags) to the main "core-libs" packages in `java.base` module.
>
> This is similar to, and a subset of, PR #11073. That PR was with
On Fri, 31 Mar 2023 16:28:14 GMT, Sean Mullan wrote:
> I didn't see any changes to security APIs - are they coming in a follow-on
> issue?
Yes, this is _Add `@spec` tags in java.base/java.* (part 1)_
The rest of `java.base` will be in part 2.
-
PR Comment: https://git.openjdk.org/
80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]:
> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
Jonathan Gibbons has updated the pull request incrementally with one additional
commit since the last revision:
revert re
On Fri, 31 Mar 2023 10:45:39 GMT, Lance Andersen wrote:
> > Hi Jon,
> > This looks fine. I was wondering if we should do the same for java.util.zip
> > and the PKWare Zip Spec or where java.sql references the JDBC Spec?
>
> Well, I must need coffee this morning as obviously JDBC is in the java.
On Fri, 31 Mar 2023 17:14:01 GMT, Iris Clark wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review feedback
>
> src/java.base/share/classes/java/io/ObjectOutputStream.jav
On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons wrote:
> Please review a change to add `@spec` tags (and remove some equivalent `@see`
> tags) to the main "core-libs" packages in `java.base` module.
>
> This is similar to, and a subset of, PR #11073. That PR was with
80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]:
> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
Jonathan Gibbons has updated the pull request incrementally with one additional
commit since the last revision:
address revie
On Thu, 30 Mar 2023 19:42:33 GMT, Alan Bateman wrote:
>> Please review a change to add `@spec` tags (and remove some equivalent
>> `@see` tags) to the main "core-libs" packages in `java.base` module.
>>
>> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and
>> based on
1 - 100 of 147 matches
Mail list logo
