8276124: Provide snippet support for properties files #6397

pavelrappo · 2021-11-15T20:34:20Z

The initial integration (JDK-8266666) of JEP 413 did not support properties files. This commit rights that wrong.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8276124: Provide snippet support for properties files

Reviewers

Jonathan Gibbons (@jonathan-gibbons - Reviewer)

Contributors

Jonathan Gibbons <jjg@openjdk.org>
Hannes Wallnöfer <hannesw@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6397/head:pull/6397
$ git checkout pull/6397

Update a local copy of the PR:
$ git checkout pull/6397
$ git pull https://git.openjdk.java.net/jdk pull/6397/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6397

View PR using the GUI difftool:
$ git pr show -t 6397

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6397.diff

After JDK-8267636 has been integrated, jdk.javadoc is compiled using JDK 17. So we can finally use sealed classes where they were originally envisioned.

@bug

8266666 didn't test this option. This commit adds such a test with the "@bug 8266666" declaration. The test improves code coverage of jdk.javadoc.internal.doclets.toolkit.taglets.SnippetTaglet as follows: %method %block %branch %line -----------+-----------+----------+------------ before 100%(11/11) 88%(92/104) 84%(81/96) 88%(128/145) after 100%(11/11) 90%(94/104) 89%(86/96) 89%(130/145) Note that the table might become outdated due to rebases.

- subclasses JavadocTester to provide reusable check and utility methods that will be shared by multiple snippet test classes - fixes a stupid regex mistake: \s -> \\s (filed a bug https://youtrack.jetbrains.com/issue/IDEA-279378) - re-orders some imports

The new test improves code coverage of jdk.javadoc.internal.doclets.toolkit.taglets.snippet as follows: %method %block %branch %line -----------+------------+------------+------------ before 70%(80/114) 76%(310/407) 65%(178/273) 81%(413/508) after 82%(94/114) 84%(344/407) 73%(202/273) 90%(459/508) Note that the table might become outdated due to rebases.

- removes dead code - uses autogenerated getters instead of field access for records

Changes tests names to match the terminology change that happened long ago: redundant snippets -> hybrid snippets.

A test may exercise both markup and tag syntax. Generally speaking, a test may be a part of multiple hierarchies. To model that, tests should be organized using tags (i.e. labels). A name component can be such a tag.

This commit immediately removes some amount of repetition.

Ideally, these tests should be implemented using hybrid snippets, to show how inline and external parts differ in treatment of */ and \uxxxx.

Increases test coverage for the "region" tag attribute. Fixes the bug where the valueless "region" attribute caused a crash (NPE).

Unifies error handling in the taglet by extracting an internal method and wrapping that method in try-catch. Fixes a few bugs where the attribute unexpectedly lacks value.

Covers extra 5 lines of SnippetTaglet: [244, 248]

Covers extra 2 lines of MarkupParser: [101, 102]

bridgekeeper · 2021-11-15T20:34:43Z

👋 Welcome back prappo! A progress list of the required criteria for merging this PR into pr/6359 will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-11-15T20:37:32Z

@pavelrappo The following label will be automatically applied to this pull request:

javadoc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-11-15T20:42:52Z

Webrevs

jonathan-gibbons

I think you can simplify the code by reducing CoarseParser down to a language-specific regular expression with "standard" named groups for the payload and markup.

I'd also recommend not using an enum for Language to leave open the possibility of easily/dynamically adding support for additional languages.

jonathan-gibbons · 2021-11-18T18:52:59Z

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java

+        @Override
+        public int payloadEnd() {return m.end(1);}
+
+        @Override
+        public int markupStart() {return m.start(3);}


Suggest using named groups

I'll answer this below.

jonathan-gibbons · 2021-11-18T18:54:37Z

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java

+        private final Matcher m = Pattern.compile("^(.*)(//(\\s*@\\s*\\w+.+?))$").matcher("");
+
+        @Override
+        public boolean parse(String line) {return m.reset(line).matches();}


Given that matchers are lightweight objects, what is the benefit of using a pre-allocated matcher and reset as compared to a temporary Matcher object? Is it just style, or is there something more?

Mostly style, I think.

jonathan-gibbons · 2021-11-18T19:00:36Z

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java

+    // Without this interface regular expressions that describe comments would have to
+    // to be standardized or needlessly complex.

-    private String eolMarker;
-    private Matcher markedUpLine;
+    private interface CoarseParser {
+        boolean parse(String line);
+        int payloadEnd();
+        int markupStart();
+    }


I'm surprised/disappointed that this may be necessary, although I accept there is a notable difference between "whole-line comments" and "end-of-line comments". Is it possible to reduce CoarseParser down to a language-specific regular expression with named groups for the payload and markup, such that the regular expression could be a property of the Language object?

I'm going to answer both of your comments, this and that one above:

I think you can simplify the code by reducing CoarseParser down to a language-specific regular expression with "standard" named groups for the payload and markup.

Regular expressions with named groups were the initial design. However, I changed it to CoarseParser halfway through the implementation, when saw how bulky the named regex were becoming. As you also note, "end-of-line comments" and "comment lines" differ. I couldn't quickly come up with a regex that accounts for both of them.

You may be somewhat missing the point I was trying to make.

You have two impls of CoarseParser, both of which contain a regular expression for the parsing, hidden inside their private matcher field.

The only other functionality of CoarseParser is payloadEnd and markupStart.

My suggestion is to start by updating each of the regex with named groups for the payload and markup parts of the line, such that you can derive payloadEnd and markupStart from the appropriate named groups.

At that point, the only thing unique about the impls of CoarseParser is their regex, and that regex could become a property of the Language object.

As you also note, "end-of-line comments" and "comment lines" differ. I couldn't quickly come up with a regex that accounts for both of them.

To be clear, I am not suggesting a single regex. I am suggesting a regex per supported language.

I abstracted out the mechanics behind the CoarseParser precisely because I couldn't come up with a simple way to derive payloadEnd and markupStart using only groups, be they named or otherwise. My regex fu is not strong enough. If you could find a way that does not look too ugly and passes the added TestLangProperties test, be my guest.

I think the following regexes with named groups should yield the same results as yours:

"^(?<payload>.*)//(?<markup>\\s*@\\s*\\w+.+?)$" "^(?<payload>[ \t]*([#!].*)?)[#!](?<markup>\\s*@\\s*\\w+.+?)$"

(Note that I didn't try running them through the test, maybe I should have :)

Above regexes do pass the test, but I just saw (too late) that Jon posted a generic (language agnostic) solution below in the main conversation thread, which probably makes above solution obsolete.

Your regexes are good. To me, they are conceptually simpler than those proposed by Jon. Both yours and Jon's are simpler than what I initially had.

jonathan-gibbons · 2021-11-18T19:02:33Z

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java

 */
 public class SnippetTaglet extends BaseTaglet {

+    public enum Language {


The idea of a Language object is good, but using an enum precludes easy extensibility.

We'll figure out the extensibility when the need comes. The language of a snippet defines both the comment marker and the comment type. For now, an alternative to that enum would be a boolean flag, which is less readable.

All I'm suggesting is to make Language a class, with a public constructor and (for now) some standard static members. In other words, plan for the possibility of additional languages, by not limiting the code to an enum at this time.

Let's figure out the CoarseParser and "plain text" issues first and then circle back to this discussion. That said, we need to be mindful of time since we're close to RDP 1.

jonathan-gibbons · 2021-11-18T19:06:07Z

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java

+/*
+ * @test
+ * @bug 8266666
+ * @summary Implementation for snippets
+ * @library /tools/lib ../../lib
+ * @modules jdk.compiler/com.sun.tools.javac.api
+ *          jdk.compiler/com.sun.tools.javac.main
+ *          jdk.javadoc/jdk.javadoc.internal.tool
+ * @build javadoc.tester.* toolbox.ToolBox toolbox.ModuleBuilder builder.ClassBuilder
+ * @run main TestLangProperties
+ */


move before imports

jonathan-gibbons · 2021-11-18T19:06:53Z

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java

+ */
+public class TestLangProperties extends SnippetTester {
+
+    private final ToolBox tb = new ToolBox();


Suggest moving to SnippetTester (suggested in dependent PR)

jonathan-gibbons · 2021-11-18T19:07:36Z

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java

+
+    private final ToolBox tb = new ToolBox();
+
+    private TestLangProperties() {}


Just curious: why force this?

You mean, why make that constructor private? No reason. This file started as a copy-paste. Fixed.

- Hoist the tb (toolbox) field to SnippetTester - Use use default ctors instead of private no-arg ctors for test classes - Re-implement SnippetTester.checkOutputEither on top of JavadocTester.OutputChecker.checkAnyOf - Follow convention for jtreg comment - Improve method names with underscores

openjdk-notifier · 2021-11-19T20:54:33Z

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout 8273544
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

openjdk · 2021-11-19T20:56:24Z

@pavelrappo this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout 8276124
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

openjdk · 2021-11-22T16:19:51Z

⚠️ @pavelrappo This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

pavelrappo · 2021-11-22T17:54:50Z

Apologies to those who read my previous reply to Jon on the javadoc-dev mailing list. Apparently, comment order on GitHub differs from that of the mailing list. So my relative references such as "above" and "below" are broken.

jonathan-gibbons · 2021-11-22T23:29:51Z

It would be nice to define/support the markup characteristics of "plain text" snippets, where "plain text" might be a stand-in for commands, or stack traces, or other less common formats.

pavelrappo · 2021-11-23T12:56:14Z

It would be nice to define/support the markup characteristics of "plain text" snippets, where "plain text" might be a stand-in for commands, or stack traces, or other less common formats.

If we are to do it, we should discuss and implement it quickly, before RDP 1. We would still be able to do it later, before RC, but only with approval. Here are some questions to discuss.

What lang identifier(s) should plain text use?
What comment rules and markup marker(s) should plain text use?

jonathan-gibbons · 2021-11-23T17:11:38Z

It would be nice to define/support the markup characteristics of "plain text" snippets, where "plain text" might be a stand-in for commands, or stack traces, or other less common formats.

If we are to do it, we should discuss and implement it quickly, before RDP 1. We would still be able to do it later, before RC, but only with approval. Here are some questions to discuss.

What lang identifier(s) should plain text use?

What comment rules and markup marker(s) should plain text use?

Either "text" or none
Right now, it defaults to // which is OK, but # might be better.

Maybe too late for now, allow a new attribute to specify the markup "prefix" (//, #, !, etc)

pavelrappo · 2021-11-23T21:36:51Z

It would be nice to define/support the markup characteristics of "plain text" snippets, where "plain text" might be a stand-in for commands, or stack traces, or other less common formats.

If we are to do it, we should discuss and implement it quickly, before RDP 1. We would still be able to do it later, before RC, but only with approval. Here are some questions to discuss.

What lang identifier(s) should plain text use?

What comment rules and markup marker(s) should plain text use?

Either "text" or none

Right now, it defaults to // which is OK, but # might be better.

Maybe too late for now, allow a new attribute to specify the markup "prefix" (//, #, !, etc)

Introducing such an attribute just for plain text seems ad-hoc. This is because there are dependencies between these three elements that make them not completely orthogonal:

Comment marker (i.e. #, --, //, !, etc.)
Comment type (i.e. whether it's an EOL comment or a comment line)
lang or type of external file (e.g. file extension)

jonathan-gibbons · 2021-11-23T21:38:42Z

Here's a suggestion for a method to generate a pattern to do the coarse parsing of snippet lines, to see if they contain markup comments.


    Pattern getPattern(String cmt, boolean eol) {
        Pattern payload = eol
                ? Pattern.compile("(?<payload>.*)")
                : Pattern.compile("(?<payload>[ \t]*(" + cmt + ".*)?)");
        Pattern prefix = Pattern.compile(cmt + "(?=[ \t]*@[a-z]+\\b)");
        Pattern markup = Pattern.compile("(?<markup>.*)");

        return Pattern.compile(payload.pattern() + prefix.pattern() + markup.pattern());
    }

The cmt parameter can be one of

a pattern-safe literal string, such as //, or
a pattern-quoted string, using Pattern.quote
a pattern denoting alternative acceptable comment sequences, such as [#!] for properties files

The boolean eol parameter indicates whether end-of-line comments are supported, or just whole-line comments.

The pattern contains named groups for the payload and markup parts of the line, which can be used to determine the start and end of those regions.

Uses named groups and positive lookahead to make both regexes uniform in respect to accessing the components of a match.

Substitutes regex for CoarseParser and its implementations.

Cleans up.

Shortens regexes and makes them use fewer concepts (no lookahead).

pavelrappo · 2021-11-24T12:44:00Z

Thank you, Jon and Hannes. I believe this PR fully addresses the linked JBS issue. I would prefer to leave these discussions for later, unless any of them are showstoppers, and integrate the change ASAP:

Enum vs class
Custom pattern (getPattern as described by Jon)
The prefix attribute
The plain-text identifier

hns · 2021-11-24T15:52:15Z

test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java

        testPositive(base, testCases);
    }

+    // @replace on a blank line will not do anything bad!


What is the purpose of this comment? Is this used as snippet source somewhere?

This is an artifact of me thinking of three interdependent PRs simultaneously. A marginal note, if you will. This line should be translated into a new test in the upcoming PR, #6461. I'll move it there, thanks.

jonathan-gibbons

Approved, for now. It's good to have simplified CoarseParser down to regular expressions.

I look forward to the next step of cleanup (for 19?) where the design contained here can be extended to additional languages, perhaps dynamically (in some fashion TBD).

The regular expressions are a function on the comment character(s), and whether the comment is a "line comment" or "end-of-line comment". These properties could be described in members of Language and the corresponding regular expressions generated by the following method:

Pattern getPattern(String cmt, boolean eol) {
    Pattern payload = eol
            ? Pattern.compile("(?<payload>.*)")
            : Pattern.compile("(?<payload>[ \t]*(" + cmt + ".*)?)");
    Pattern prefix = Pattern.compile(cmt + "(?=[ \t]*@[a-z]+\\b)");
    Pattern markup = Pattern.compile("(?<markup>.*)");

    return Pattern.compile(payload.pattern() + prefix.pattern() + markup.pattern());
}

Related, Language could usefully be converted from an enum to a record, and maybe have a cache-map of Map<Language, Pattern> to reduce the costs of creating those patterns.

openjdk · 2021-11-24T18:39:23Z

@pavelrappo This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8276124: Provide snippet support for properties files

Co-authored-by: Jonathan Gibbons <jjg@openjdk.org>
Co-authored-by: Hannes Wallnöfer <hannesw@openjdk.org>
Reviewed-by: jjg

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 51 new commits pushed to the master branch:

951247c: 8235876: Misleading warning message in java source-file mode
663e33d: 8272728: javac ignores any -J option in @argfiles silently
0384739: 8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException
cf7adae: 8275320: NMT should perform buffer overrun checks
96e3607: 8275063: Implementation of Foreign Function & Memory API (Second incubator)
17e68ca: 8277042: add test for 8276036 to compiler/codecache
8a8bc29: 8277562: Remove dead method c1 If::swap_sux
d085c2b: 8273328: Compiler implementation for Pattern Matching for switch (Second Preview)
6d73460: 8277399: ZGC: Move worker thread logging out of gc+phase=debug
712b875: 8277397: ZGC: Add JFR event for temporary latency measurements
... and 41 more: https://git.openjdk.java.net/jdk/compare/2ab43ec2428edaebfe9a7fb0e716ff7141a28de0...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

pavelrappo · 2021-11-24T18:43:52Z

/contributor add jjg
/contributor add hannesw

openjdk · 2021-11-24T18:44:46Z

@pavelrappo
Contributor Jonathan Gibbons <jjg@openjdk.org> successfully added.

openjdk · 2021-11-24T18:46:10Z

@pavelrappo
Contributor Hannes Wallnöfer <hannesw@openjdk.org> successfully added.

pavelrappo · 2021-11-24T20:12:18Z

/integrate

openjdk · 2021-11-24T20:13:18Z

Going to push as commit e785f69.
Since your change was applied there have been 53 commits pushed to the master branch:

96fe1d0: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
077b2de: 8274161: Cleanup redundant casts in jdk.compiler
951247c: 8235876: Misleading warning message in java source-file mode
663e33d: 8272728: javac ignores any -J option in @argfiles silently
0384739: 8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException
cf7adae: 8275320: NMT should perform buffer overrun checks
96e3607: 8275063: Implementation of Foreign Function & Memory API (Second incubator)
17e68ca: 8277042: add test for 8276036 to compiler/codecache
8a8bc29: 8277562: Remove dead method c1 If::swap_sux
d085c2b: 8273328: Compiler implementation for Pattern Matching for switch (Second Preview)
... and 43 more: https://git.openjdk.java.net/jdk/compare/2ab43ec2428edaebfe9a7fb0e716ff7141a28de0...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-11-24T20:13:34Z

@pavelrappo Pushed as commit e785f69.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

pavelrappo added 18 commits November 11, 2021 16:07

Leverage sealed classes in the implementation

93f01b9

After JDK-8267636 has been integrated, jdk.javadoc is compiled using JDK 17. So we can finally use sealed classes where they were originally envisioned.

Refactor and clean up tests

511e62b

- subclasses JavadocTester to provide reusable check and utility methods that will be shared by multiple snippet test classes - fixes a stupid regex mistake: \s -> \\s (filed a bug https://youtrack.jetbrains.com/issue/IDEA-279378) - re-orders some imports

Further increase test coverage

74d3bc5

- removes dead code - uses autogenerated getters instead of field access for records

Rename test methods

fef073f

Changes tests names to match the terminology change that happened long ago: redundant snippets -> hybrid snippets.

Apply test a naming convention

4acad75

A test may exercise both markup and tag syntax. Generally speaking, a test may be a part of multiple hierarchies. To model that, tests should be organized using tags (i.e. labels). A name component can be such a tag.

Encapsulate HTML representation of a snippet

baaf961

This commit immediately removes some amount of repetition.

Add tests that showcases */ and \uxxxx

c2f3514

Ideally, these tests should be implemented using hybrid snippets, to show how inline and external parts differ in treatment of */ and \uxxxx.

Cover blank and valueless "region" attribute

6acc9ed

Increases test coverage for the "region" tag attribute. Fixes the bug where the valueless "region" attribute caused a crash (NPE).

Improve error handling in SnippetTaglet

6bbc92a

Unifies error handling in the taglet by extracting an internal method and wrapping that method in try-catch. Fixes a few bugs where the attribute unexpectedly lacks value.

Add TODO entries for FileManager-related issues

425e75e

Test markup issues in an external snippet

92b8709

Covers extra 5 lines of SnippetTaglet: [244, 248]

Use the feature from JDK-8273154

c3bad64

Add negative tests for next-line markup

6fe8667

Covers extra 2 lines of MarkupParser: [101, 102]

Remove trailing whitespace for jcheck

3975b0c

Test one more corner case example

fd33d86

Initial commit

2e43402

openjdk bot added the rfr Pull request is ready for review label Nov 15, 2021

openjdk bot added the javadoc javadoc-dev@openjdk.org label Nov 15, 2021

openjdk bot mentioned this pull request Nov 18, 2021

8277026: Remove blank lines remaining from snippet markup #6461

Closed

3 tasks

jonathan-gibbons reviewed Nov 18, 2021

View reviewed changes

pavelrappo added 2 commits November 19, 2021 15:33

Repair a confusing commit 93f01b9

b7c8c48

openjdk-notifier bot changed the base branch from pr/6359 to master November 19, 2021 20:54

Merge branch 'master' into 8276124

bd9aada

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Nov 22, 2021

Address feedback

19e8db2

pavelrappo added 4 commits November 24, 2021 12:12

Implement Jon's suggestion (1)

9e5a91e

Uses named groups and positive lookahead to make both regexes uniform in respect to accessing the components of a match.

Implement Jon's suggestion (2)

1ca2025

Substitutes regex for CoarseParser and its implementations.

Implement Jon's suggestion (3)

32bae39

Cleans up.

Use Hannes' regex

d22cbf7

Shortens regexes and makes them use fewer concepts (no lookahead).

hns reviewed Nov 24, 2021

View reviewed changes

Remove unrelated comment

8e01ab1

jonathan-gibbons approved these changes Nov 24, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Nov 24, 2021

openjdk bot closed this Nov 24, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 24, 2021


		private final ToolBox tb = new ToolBox();

		private TestLangProperties() {}

8276124: Provide snippet support for properties files #6397

8276124: Provide snippet support for properties files #6397

Uh oh!

Conversation

pavelrappo commented Nov 15, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Contributors

Reviewing

Uh oh!

bridgekeeper bot commented Nov 15, 2021

Uh oh!

openjdk bot commented Nov 15, 2021

Uh oh!

mlbridge bot commented Nov 15, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

jonathan-gibbons left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonathan-gibbons Nov 22, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hns Nov 24, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openjdk-notifier bot commented Nov 19, 2021

Uh oh!

openjdk bot commented Nov 19, 2021

Uh oh!

openjdk bot commented Nov 22, 2021

Uh oh!

pavelrappo commented Nov 22, 2021

Uh oh!

jonathan-gibbons commented Nov 22, 2021

Uh oh!

pavelrappo commented Nov 23, 2021

pavelrappo commented Nov 15, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Nov 15, 2021 •

edited

Loading

jonathan-gibbons Nov 22, 2021 •

edited

Loading

hns Nov 24, 2021 •

edited

Loading

pavelrappo commented Nov 23, 2021 •

edited

Loading

jonathan-gibbons left a comment •

edited

Loading

openjdk bot commented Nov 24, 2021 •

edited

Loading