> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: Properties files is essentially source code. It should have
>> the same whitespace checks as all other source code, so we don't get
>> spurious tra
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
On Mon, 12 Feb 2024 17:27:42 GMT, Jonathan Gibbons wrote:
>>> I guess it depends how much we want to import the code as-is, without
>>> knowing any lint-warts.
>>
>> I think it would be nice not to have to modify code beyond superficial
>> edits: addition of headers, renaming of packages, and
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
On Mon, 12 Feb 2024 17:44:29 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> refactor recent new test case in TestMarkdown.java
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/fo
On Fri, 9 Feb 2024 22:17:43 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Mon, 12 Feb 2024 17:23:56 GMT, Pavel Rappo wrote:
>> It's possible, but that would be a more global setting, whereas this is a
>> very targeted modification.
>>
>> I guess it depends how much we want to import the code as-is, without
>> knowing any lint-warts.
>>
>> FWIW, any module can be
On Mon, 12 Feb 2024 16:29:19 GMT, Jonathan Gibbons wrote:
> I guess it depends how much we want to import the code as-is, without knowing
> any lint-warts.
I think it would be nice not to have to modify code beyond superficial edits:
addition of headers, renaming of packages, and converting of
On Thu, 8 Feb 2024 17:20:23 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 28 commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into
>> 8298405.doclet-markdown-v3 # Plea
On Thu, 8 Feb 2024 18:52:54 GMT, Jonathan Gibbons wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java
>> line 145:
>>
>>> 143: }
>>> 144:
>>> 145: Pattern tag = Pattern.compile("<(?[A-Za-z0-9]+)(\\s|>)");
>>
>> I'm not sure I grok this
On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie wrote:
> A common scenario is for a developer to have two configurations, a product
> and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the
> latter using `CONF` is just a matter of using `CONF=debug`, but to select the
>
On Tue, 30 Jan 2024 23:47:00 GMT, Jonathan Gibbons wrote:
>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java
>> line 771:
>>
>>> 769: copyTo(getStartPos(link));
>>> 770: // push temporary value for {@code trees} while
>>> handlin
On Thu, 1 Feb 2024 00:19:42 GMT, Jonathan Gibbons wrote:
>> I'll add a test case.
>
> Done
Thank you. I double-checked: if that `replace` is removed,
jdk/javadoc/doclet/testMarkdown/TestMarkdown.java fails.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r14
On Wed, 31 Jan 2024 22:15:23 GMT, Jonathan Gibbons wrote:
>> I guess I don't see this as being as big a deal as you seem to think it is.
>> What is it that you are so concerned about?
>>
>> I also think it is a potential feature to document and use reference links
>> with `code:` URLs, using t
On Tue, 30 Jan 2024 23:15:32 GMT, Jonathan Gibbons wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
>> line 790:
>>
>>> 788:
>>> 789: // end of paragraph is newline, followed by a blank line or
>>> the beginning of the next block
>>> 790: pri
On Mon, 12 Feb 2024 14:09:49 GMT, Julian Waters wrote:
> That said, should I test autoconf on all platforms too?
No, that seems over the top. For this purpose, we must assume that all autoconf
on all platforms behave the same.
-
PR Comment: https://git.openjdk.org/jdk/pull/17401#i
On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie wrote:
> A common scenario is for a developer to have two configurations, a product
> and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the
> latter using `CONF` is just a matter of using `CONF=debug`, but to select the
>
On 2/11/24 03:14, Julian Waters wrote:
Hi Erik,
Thanks for the clarification! How then does Oracle compile the JDK,
such that the versioning numbers appear in the following manner?
C:\Users\vertig0>java --version
java 21 2023-09-19 LTS
Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
J
On Mon, 12 Feb 2024 13:57:55 GMT, Magnus Ihse Bursie wrote:
> I have verified that this works fine in the Oracle internal CI.
>
> Erik's point still stands:
>
> > I still think it would be prudent to verify this patch with all the
> > currently accepted versions of autoconf (2.69, 2.70, 2.71,
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
A common scenario is for a developer to have two configurations, a product and
a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the latter
using `CONF` is just a matter of using `CONF=debug`, but to select the former,
the complete name needs to be supplied: `CONF=linux-x64`.
In
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesystem ID field in statvfs
On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt wrote:
> Graphviz (aka. dotty/dot) is used when building "full" docs, and in
> particular for creating various module graph images (.svg). This change
> upgrades the Graphviz version used to 9.0.0 (latest).
>
> In particular, the change:
>
> *
On 2/11/24 11:14, Julian Waters wrote:
Hi Erik,
Thanks for the clarification! How then does Oracle compile the JDK, such that
the versioning numbers appear in the following manner?
C:\Users\vertig0>java --version
java 21 2023-09-19 LTS
Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
Jav
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesystem ID field in statvfs
On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: 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 wh
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
This pull request has now been integrated.
Changeset: e5cb7
On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Upda
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now c
37 matches
Mail list logo
