From volker.simonis at gmail.com Tue Nov 3 10:51:37 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Nov 2020 11:51:37 +0100 Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: References: Message-ID: Hi Vladimir, this is an interesting step and I wonder how it affects the OpenJDK Graal, Metropolis and Leyden projects? - Project Graal [1] seems to have already been merged into project Metropolis as it states on its project page: "Further work on integrating Graal in the OpenJDK has moved to Project Metropolis." - Project Metropolis [2] has the following mission statement on its project page: "The goal of this Project is to provide a venue to explore and incubate advanced "Java-on-Java" implementation techniques for HotSpot. Our starting point is earlier proposals for using the Graal compiler and AOT static compilation technology to replace the HotSpot server compiler, and possibly other components of HotSpot." It seems that this goal becomes void when Graal AOT and Grall JIT are abandoned in the OpenJDK. - Project Leyden [?]: @Mark: what's actually the state of Project Leyden? We had a discussion [3], a vote [4] and the approval of the project [5] yet nothing has happened ever since. There's neither a project page nor a mailing list. Considering the fact that Leyden was supposed to "be based upon existing components in the JDK such as the HotSpot JVM, the `jaotc` ahead-of-time compiler, application class-data sharing, and the `jlink` linking tool" I wonder if Leyden is already dead before its instantiation if "jaotc", one of its core components, has now been deprecated? Or are there any plans to enhance C2 for AOT scenarios? Thank you and best regards, Volker [1] http://openjdk.java.net/projects/graal/ [2] http://openjdk.java.net/projects/metropolis/ [3] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html [4] https://mail.openjdk.java.net/pipermail/discuss/2020-May/005475.html [5] https://mail.openjdk.java.net/pipermail/announce/2020-June/000290.html On Fri, Oct 30, 2020 at 6:47 PM Vladimir Kozlov wrote: > > We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an experimental feature. We shipped Graal as an experimental JIT compiler in JDK 10. We haven't seen much use of these features, and the effort required to support and enhance them is significant. We therefore intend to disable these features in Oracle builds as of JDK 16. > > We'll leave the sources for these features in the repository, in case any one else is interested in building them. But we will not update or test them. > > We'll continue to build and ship JVMCI as an experimental feature in Oracle builds. > > Tested changes in all tiers. > > I verified that with these changes I still able to build Graal in open repo and run graalunit testing: > > `open$ bash test/hotspot/jtreg/compiler/graalunit/downloadLibs.sh /mydir/graalunit_lib/` > `open$ bash configure --with-debug-level=fastdebug --with-graalunit-lib=/mydir/graalunit_lib/ --with-jtreg=/mydir/jtreg` > `open$ make jdk-image` > `open$ make test-image` > `open$ make run-test TEST=compiler/graalunit/HotspotTest.java` > > ------------- > > Commit messages: > - 8255616: Disable AOT and Graal in Oracle OpenJDK > > Changes: https://git.openjdk.java.net/jdk/pull/960/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=960&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8255616 > Stats: 36 lines in 4 files changed: 21 ins; 11 del; 4 mod > Patch: https://git.openjdk.java.net/jdk/pull/960.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/960/head:pull/960 > > PR: https://git.openjdk.java.net/jdk/pull/960 From vladimir.kozlov at oracle.com Wed Nov 4 22:53:47 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 Nov 2020 14:53:47 -0800 Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: References: Message-ID: Hi, Volker and Monica On 11/3/20 2:51 AM, Volker Simonis wrote: > Hi Vladimir, > > this is an interesting step and I wonder how it affects the OpenJDK > Graal, Metropolis and Leyden projects? > > - Project Graal [1] seems to have already been merged into project > Metropolis as it states on its project page: > "Further work on integrating Graal in the OpenJDK has moved to Project > Metropolis." This page is outdated and currently incorrect. The main development of Graal is done in GraalVM. OpenJDK and Metropolis are downstream. > > - Project Metropolis [2] has the following mission statement on its > project page: > "The goal of this Project is to provide a venue to explore and > incubate advanced "Java-on-Java" implementation techniques for > HotSpot. Our starting point is earlier proposals for using the Graal > compiler and AOT static compilation technology to replace the HotSpot > server compiler, and possibly other components of HotSpot." > > It seems that this goal becomes void when Graal AOT and Grall JIT are > abandoned in the OpenJDK. No, this goal is still valid. We still think "Java-on-Java" is right direction for some components of HotSpot. We learned a lot and made some progress with Graal as JIT in Metropolis. And we have got very good expertise from AOT work which will help us with Project Leyden. We will return to work on Metropolis later on. But right now, we think the work on C2 improvement is more important to keep Java vibrant and competitive. I will let Mark to talk about Project Leyden. Best regards, Vladimir Kozlov > > - Project Leyden [?]: @Mark: what's actually the state of Project > Leyden? We had a discussion [3], a vote [4] and the approval of the > project [5] yet nothing has happened ever since. There's neither a > project page nor a mailing list. > > Considering the fact that Leyden was supposed to "be based upon > existing components in the JDK such as the HotSpot JVM, the `jaotc` > ahead-of-time compiler, application class-data sharing, and the > `jlink` linking tool" I wonder if Leyden is already dead before its > instantiation if "jaotc", one of its core components, has now been > deprecated? Or are there any plans to enhance C2 for AOT scenarios? > > Thank you and best regards, > Volker > > [1] http://openjdk.java.net/projects/graal/ > [2] http://openjdk.java.net/projects/metropolis/ > [3] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html > [4] https://mail.openjdk.java.net/pipermail/discuss/2020-May/005475.html > [5] https://mail.openjdk.java.net/pipermail/announce/2020-June/000290.html > > On Fri, Oct 30, 2020 at 6:47 PM Vladimir Kozlov wrote: >> >> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an experimental feature. We shipped Graal as an experimental JIT compiler in JDK 10. We haven't seen much use of these features, and the effort required to support and enhance them is significant. We therefore intend to disable these features in Oracle builds as of JDK 16. >> >> We'll leave the sources for these features in the repository, in case any one else is interested in building them. But we will not update or test them. >> >> We'll continue to build and ship JVMCI as an experimental feature in Oracle builds. >> >> Tested changes in all tiers. >> >> I verified that with these changes I still able to build Graal in open repo and run graalunit testing: >> >> `open$ bash test/hotspot/jtreg/compiler/graalunit/downloadLibs.sh /mydir/graalunit_lib/` >> `open$ bash configure --with-debug-level=fastdebug --with-graalunit-lib=/mydir/graalunit_lib/ --with-jtreg=/mydir/jtreg` >> `open$ make jdk-image` >> `open$ make test-image` >> `open$ make run-test TEST=compiler/graalunit/HotspotTest.java` >> >> ------------- >> >> Commit messages: >> - 8255616: Disable AOT and Graal in Oracle OpenJDK >> >> Changes: https://git.openjdk.java.net/jdk/pull/960/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=960&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8255616 >> Stats: 36 lines in 4 files changed: 21 ins; 11 del; 4 mod >> Patch: https://git.openjdk.java.net/jdk/pull/960.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/960/head:pull/960 >> >> PR: https://git.openjdk.java.net/jdk/pull/960 From mark.reinhold at oracle.com Wed Nov 4 23:06:07 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Nov 2020 15:06:07 -0800 Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: References:

Message-ID: <20201104150607.735653032@eggemoggin.niobe.net> 2020/11/4 14:53:47 -0800, vladimir.kozlov at oracle.com: > On 11/3/20 2:51 AM, Volker Simonis wrote: >> this is an interesting step and I wonder how it affects the OpenJDK >> Graal, Metropolis and Leyden projects? >> > ... > > I will let Mark to talk about Project Leyden. > > Best regards, > Vladimir Kozlov > > ... >> >> - Project Leyden [?]: @Mark: what's actually the state of Project >> Leyden? We had a discussion [3], a vote [4] and the approval of the >> project [5] yet nothing has happened ever since. There's neither a >> project page nor a mailing list. Unfortunately, due to other priorities I haven?t had the time to get this project started properly. I hope to be able to do that soon. >> Considering the fact that Leyden was supposed to "be based upon >> existing components in the JDK such as the HotSpot JVM, the `jaotc` >> ahead-of-time compiler, application class-data sharing, and the >> `jlink` linking tool" I wonder if Leyden is already dead before its >> instantiation if "jaotc", one of its core components, has now been >> deprecated? Or are there any plans to enhance C2 for AOT scenarios? We are considering the possibility of using C2 for ahead-of-time compilation. - Mark From volker.simonis at gmail.com Thu Nov 5 09:02:15 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 5 Nov 2020 10:02:15 +0100 Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: <20201104150607.735653032@eggemoggin.niobe.net> References:

<20201104150607.735653032@eggemoggin.niobe.net> Message-ID: On Thu, Nov 5, 2020 at 12:06 AM wrote: > > 2020/11/4 14:53:47 -0800, vladimir.kozlov at oracle.com: > > On 11/3/20 2:51 AM, Volker Simonis wrote: > >> this is an interesting step and I wonder how it affects the OpenJDK > >> Graal, Metropolis and Leyden projects? > >> > > ... > > > > I will let Mark to talk about Project Leyden. > > > > Best regards, > > Vladimir Kozlov > > > > ... > >> > >> - Project Leyden [?]: @Mark: what's actually the state of Project > >> Leyden? We had a discussion [3], a vote [4] and the approval of the > >> project [5] yet nothing has happened ever since. There's neither a > >> project page nor a mailing list. > > Unfortunately, due to other priorities I haven?t had the time to get > this project started properly. I hope to be able to do that soon. > > >> Considering the fact that Leyden was supposed to "be based upon > >> existing components in the JDK such as the HotSpot JVM, the `jaotc` > >> ahead-of-time compiler, application class-data sharing, and the > >> `jlink` linking tool" I wonder if Leyden is already dead before its > >> instantiation if "jaotc", one of its core components, has now been > >> deprecated? Or are there any plans to enhance C2 for AOT scenarios? > > We are considering the possibility of using C2 for ahead-of-time > compilation. > Vladimir, Mark, thanks a lot for your answers. It's encouraging to see that you keep on investing in C2. Best regards, Volker > - Mark > From Monica.Beckwith at microsoft.com Sat Nov 7 17:52:52 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Sat, 7 Nov 2020 17:52:52 +0000 Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: <20201104150607.735653032@eggemoggin.niobe.net> References:

, <20201104150607.735653032@eggemoggin.niobe.net> Message-ID: Thanks Vladimir and Mark. Great to hear the positivity in your replies. Please let me know how we can be of help. Regards, Monica Get Outlook for Android ________________________________ From: hotspot-dev on behalf of mark.reinhold at oracle.com Sent: Wednesday, November 4, 2020, 5:06 PM To: volker.simonis at gmail.com; vladimir.kozlov at oracle.com Cc: hotspot-dev at openjdk.java.net; discuss at openjdk.java.net Subject: Re: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK 2020/11/4 14:53:47 -0800, vladimir.kozlov at oracle.com: > On 11/3/20 2:51 AM, Volker Simonis wrote: >> this is an interesting step and I wonder how it affects the OpenJDK >> Graal, Metropolis and Leyden projects? >> > ... > > I will let Mark to talk about Project Leyden. > > Best regards, > Vladimir Kozlov > > ... >> >> - Project Leyden [?]: @Mark: what's actually the state of Project >> Leyden? We had a discussion [3], a vote [4] and the approval of the >> project [5] yet nothing has happened ever since. There's neither a >> project page nor a mailing list. Unfortunately, due to other priorities I haven?t had the time to get this project started properly. I hope to be able to do that soon. >> Considering the fact that Leyden was supposed to "be based upon >> existing components in the JDK such as the HotSpot JVM, the `jaotc` >> ahead-of-time compiler, application class-data sharing, and the >> `jlink` linking tool" I wonder if Leyden is already dead before its >> instantiation if "jaotc", one of its core components, has now been >> deprecated? Or are there any plans to enhance C2 for AOT scenarios? We are considering the possibility of using C2 for ahead-of-time compilation. - Mark From Marius at volkhart.com Sat Nov 7 18:54:06 2020 From: Marius at volkhart.com (Marius Volkhart) Date: Sat, 7 Nov 2020 19:54:06 +0100 Subject: First time contributor experience Message-ID: Hello, I've been working on making my first JDK contribution, and thought I'd provide some feedback on the process. My motivation for contributing is that I found 2 bugs in javax.xml. My first thought was to 1. see if there is an existing bug, and 2. if not, file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net. This was a pretty big demotivator, and caused me to stop JDK work for the day. In my previous experiences with open source projects, be it Apache, OpenJ9, or other projects on GitHub, filing a bug was very easy. Getting the source code was really easy thanks to it being on Github now! This was great. Unfortunately, I found myself running up a steep cliff pretty quickly thereafter. The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to easier CA processes, typically something like https://cla-assistant.io/ but it was alright. One thing that was not clear from the contributing page is that I need to specify my GitHub username in the Username field of the OCA. The OCA process was really fast, and Dalibor was very prompt. Now, given that I had something I wanted to work on, and it was a minor change most likely best discussed via code, and I already figured out where/what the bug was, I figured I'd make a PR next. The contributing guide doesn't know what PRs are yet, and I don't have a sponsor, so I figured that from here on out, I was on my own. Next I tried to get working with the code, and quickly realized that I had absolutely no idea of how to get started with this in an IDE (Intellij in my case). I'm used to having a Maven or Gradle project, or even something like Bazel that lets me generate IDE project files. A guide on how to edit the Java parts of the JDK in the popular IDEs would be immensely helpful. Fortunately my first bug is an easy 1 line change, and doesn't need any imports or formatting or whatever. I chose to hold off with writing a unit test because I don't even know how to run it yet. So now I figured I'd try the build instructions linked in the README. The TL;DR is exactly what I wanted, and all went well until I got to running the tier 1 tests. That step fails because something called jtreg is missing. I tried to install via my package manager (homebrew, I'm on a Mac) but jtreg isn't on there. I found the GitHub repo for it, but there are no prebuilt artifacts on GitHub, and building jtreg wasn't something I wanted to delve into. Ant & talk of JDK 7. (Several days later I found https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact but I don't know why there are 2 versions there.) In the course of trying to figure out what jtreg is, I learned that TestNG is used, so I wrote my unit test in an out of band Gradle project and copy/pasted the file into the JDK tree. I decided to just make the change, push it, and have the GitHub Workflow build and run the tests. The Workflow is great, and it was pretty easy to get my fork to run the tests. How to get your fork to run the tests is probably something that should be explained or called out in CONTRIBUTING.md. I now wanted to see if my tests got picked up by the tool and passed. I downloaded the test results ZIP, but am completely overwhelmed by the contents. Is my test in testresults_part1? testsupport? debug_testresults_common? I couldn't find it. I gave up at this point, and just pushed the change, hoping that someone who knows how this all works can tell me exactly what changes to make, or will pick up the patch and do what needs to be done. The biggest hurdles for me for working on the code are 1. Getting the code into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle to contributing is the inability to file bugs. I hope this helps in improving the contributor experience. -- Cheers, Marius Volkhart From sirinath1978m at gmail.com Sun Nov 8 05:45:25 2020 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Sun, 8 Nov 2020 11:15:25 +0530 Subject: Reference parameters, return values and variables For Value Types Message-ID: Hello, With much of the material on value types for Java, I have not seen any material on reference parameters, return types and variables. When references are introduced there will be some copying overhead. In order to address this references needs to be introduced to Java. Suminda From sirinath1978m at gmail.com Sun Nov 8 06:16:40 2020 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Sun, 8 Nov 2020 11:46:40 +0530 Subject: Interface Related Improvements Message-ID: Hello, I am not sure where to post this, hope some one interested picks this up for consideration. With the introduction of default methods, private methods and static methods in interfaces a few more changes are desirable to improve usability. *Private fields* Since interfaces currently can have private methods it would be much desirable to have private fields also. These can static or instance fields, but minimally at least private static fields initially. If they are instance fields they will be only initialised once regardless of how many places the interface is extended. *Initializers* Interfaces can add initialisers. These will only run one. Minimally at least static initialisers initially. *Reuse of Default Interface Methods* Default methods can improve code reuse in anonymous inner classes and enums. *Improvements to Annonymous Inner Classes to work with the new Java Interfaces* In order to reuse default methods, it will be convenient if something like the following can be valid code. This is similar to what Scala and Groovy does with traits. class X {} interface P { default void f() {} } ... X x = new X() implements P; *Improving Enums to work with the new Java Interfaces* In Enums there are times one does not need to share all implementations like in: enum E { X { f() {} }, Y { g() {} }; } In such cases some times the implementation of f and g can be shared if following is allowed: interface P { default void f() {} } interface Q { default void g() {} } enum E { X impliments P, Y impliments Q; } *Protected Methods* Protected methods could be considered to control what can be accessed on interfaces. *Allow this* Make the meaning of this pointer special in interfaces so features in the implementing classes can be accessed: interface P { X this; default void f() { x(); } } interface Q { X this; default void g() { x(); } } class X implements P, Q { void x() {} } Groovy and Scala has ways to implement something similar with traits. Suminda From magnus.ihse.bursie at oracle.com Thu Nov 12 00:33:46 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Nov 2020 01:33:46 +0100 Subject: First time contributor experience In-Reply-To: References: Message-ID: <9b6f4468-f885-1703-7d82-f43f5e9f86a8@oracle.com> On 2020-11-07 19:54, Marius Volkhart wrote: > Hello, > > I've been working on making my first JDK contribution, and thought I'd > provide some feedback on the process. Hello Marius, Thank you for reporting your experiences, in such a constructive tone. This is all very new to us, and there are certainly road bumps that need to be flattened. Some may be easy to fix, and other may be harder. But getting feedback about what's the pain points of a new contributor certainly helps us understand where there are work left to do. /Magnus > > My motivation for contributing is that I found 2 bugs in javax.xml. > > My first thought was to 1. see if there is an existing bug, and 2. if not, > file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net. > This was a pretty big demotivator, and caused me to stop JDK work for the > day. In my previous experiences with open source projects, be it Apache, > OpenJ9, or other projects on GitHub, filing a bug was very easy. > > Getting the source code was really easy thanks to it being on Github now! > This was great. Unfortunately, I found myself running up a steep cliff > pretty quickly thereafter. > > The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to > easier CA processes, typically something like https://cla-assistant.io/ but > it was alright. One thing that was not clear from the contributing page is > that I need to specify my GitHub username in the Username field of the OCA. > The OCA process was really fast, and Dalibor was very prompt. > > Now, given that I had something I wanted to work on, and it was a minor > change most likely best discussed via code, and I already figured out > where/what the bug was, I figured I'd make a PR next. The contributing > guide doesn't know what PRs are yet, and I don't have a sponsor, so I > figured that from here on out, I was on my own. > > Next I tried to get working with the code, and quickly realized that I had > absolutely no idea of how to get started with this in an IDE (Intellij in > my case). I'm used to having a Maven or Gradle project, or even something > like Bazel that lets me generate IDE project files. A guide on how to edit > the Java parts of the JDK in the popular IDEs would be immensely helpful. > > Fortunately my first bug is an easy 1 line change, and doesn't need any > imports or formatting or whatever. I chose to hold off with writing a unit > test because I don't even know how to run it yet. > > So now I figured I'd try the build instructions linked in the README. The > TL;DR is exactly what I wanted, and all went well until I got to running > the tier 1 tests. That step fails because something called jtreg is > missing. I tried to install via my package manager (homebrew, I'm on a Mac) > but jtreg isn't on there. I found the GitHub repo for it, but there are no > prebuilt artifacts on GitHub, and building jtreg wasn't something I wanted > to delve into. Ant & talk of JDK 7. (Several days later I found > https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact > but I don't know why there are 2 versions there.) > > In the course of trying to figure out what jtreg is, I learned that TestNG > is used, so I wrote my unit test in an out of band Gradle project and > copy/pasted the file into the JDK tree. > > I decided to just make the change, push it, and have the GitHub Workflow > build and run the tests. The Workflow is great, and it was pretty easy to > get my fork to run the tests. How to get your fork to run the tests is > probably something that should be explained or called out in > CONTRIBUTING.md. I now wanted to see if my tests got picked up by the tool > and passed. I downloaded the test results ZIP, but am completely > overwhelmed by the contents. Is my test in testresults_part1? testsupport? > debug_testresults_common? I couldn't find it. > > I gave up at this point, and just pushed the change, hoping that someone > who knows how this all works can tell me exactly what changes to make, or > will pick up the patch and do what needs to be done. > > The biggest hurdles for me for working on the code are 1. Getting the code > into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle to > contributing is the inability to file bugs. > > I hope this helps in improving the contributor experience. > > -- > Cheers, > Marius Volkhart From Marius at volkhart.com Tue Nov 17 22:32:34 2020 From: Marius at volkhart.com (Marius Volkhart) Date: Tue, 17 Nov 2020 23:32:34 +0100 Subject: First time contributor experience In-Reply-To: <9b6f4468-f885-1703-7d82-f43f5e9f86a8@oracle.com> References: <9b6f4468-f885-1703-7d82-f43f5e9f86a8@oracle.com> Message-ID: Hi Magnus, I haven't been able to get any traction with my Pull Request. I've sent 2 mails to core-libs-dev mailing list. I believe I've found a bug in the javax.xml module. An issue for this behavior does not exist in the bug tracker, and I do not have a OpenJDK account so I can't open an issue. The PR includes a fix with a test. What's the right course of action for me here? -- Cheers, Marius Volkhart On Thu, Nov 12, 2020 at 1:33 AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2020-11-07 19:54, Marius Volkhart wrote: > > Hello, > > > > I've been working on making my first JDK contribution, and thought I'd > > provide some feedback on the process. > Hello Marius, > > Thank you for reporting your experiences, in such a constructive tone. > This is all very new to us, and there are certainly road bumps that need > to be flattened. Some may be easy to fix, and other may be harder. But > getting feedback about what's the pain points of a new contributor > certainly helps us understand where there are work left to do. > > /Magnus > > > > My motivation for contributing is that I found 2 bugs in javax.xml. > > > > My first thought was to 1. see if there is an existing bug, and 2. if > not, > > file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net > . > > This was a pretty big demotivator, and caused me to stop JDK work for the > > day. In my previous experiences with open source projects, be it Apache, > > OpenJ9, or other projects on GitHub, filing a bug was very easy. > > > > Getting the source code was really easy thanks to it being on Github now! > > This was great. Unfortunately, I found myself running up a steep cliff > > pretty quickly thereafter. > > > > The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to > > easier CA processes, typically something like https://cla-assistant.io/ > but > > it was alright. One thing that was not clear from the contributing page > is > > that I need to specify my GitHub username in the Username field of the > OCA. > > The OCA process was really fast, and Dalibor was very prompt. > > > > Now, given that I had something I wanted to work on, and it was a minor > > change most likely best discussed via code, and I already figured out > > where/what the bug was, I figured I'd make a PR next. The contributing > > guide doesn't know what PRs are yet, and I don't have a sponsor, so I > > figured that from here on out, I was on my own. > > > > Next I tried to get working with the code, and quickly realized that I > had > > absolutely no idea of how to get started with this in an IDE (Intellij in > > my case). I'm used to having a Maven or Gradle project, or even something > > like Bazel that lets me generate IDE project files. A guide on how to > edit > > the Java parts of the JDK in the popular IDEs would be immensely helpful. > > > > Fortunately my first bug is an easy 1 line change, and doesn't need any > > imports or formatting or whatever. I chose to hold off with writing a > unit > > test because I don't even know how to run it yet. > > > > So now I figured I'd try the build instructions linked in the README. The > > TL;DR is exactly what I wanted, and all went well until I got to running > > the tier 1 tests. That step fails because something called jtreg is > > missing. I tried to install via my package manager (homebrew, I'm on a > Mac) > > but jtreg isn't on there. I found the GitHub repo for it, but there are > no > > prebuilt artifacts on GitHub, and building jtreg wasn't something I > wanted > > to delve into. Ant & talk of JDK 7. (Several days later I found > > > https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact > > but I don't know why there are 2 versions there.) > > > > In the course of trying to figure out what jtreg is, I learned that > TestNG > > is used, so I wrote my unit test in an out of band Gradle project and > > copy/pasted the file into the JDK tree. > > > > I decided to just make the change, push it, and have the GitHub Workflow > > build and run the tests. The Workflow is great, and it was pretty easy to > > get my fork to run the tests. How to get your fork to run the tests is > > probably something that should be explained or called out in > > CONTRIBUTING.md. I now wanted to see if my tests got picked up by the > tool > > and passed. I downloaded the test results ZIP, but am completely > > overwhelmed by the contents. Is my test in testresults_part1? > testsupport? > > debug_testresults_common? I couldn't find it. > > > > I gave up at this point, and just pushed the change, hoping that someone > > who knows how this all works can tell me exactly what changes to make, or > > will pick up the patch and do what needs to be done. > > > > The biggest hurdles for me for working on the code are 1. Getting the > code > > into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle > to > > contributing is the inability to file bugs. > > > > I hope this helps in improving the contributor experience. > > > > -- > > Cheers, > > Marius Volkhart > > From mp at jugs.org Tue Nov 17 22:43:48 2020 From: mp at jugs.org (Michael Paus) Date: Tue, 17 Nov 2020 23:43:48 +0100 Subject: First time contributor experience In-Reply-To: References: <9b6f4468-f885-1703-7d82-f43f5e9f86a8@oracle.com> Message-ID: <34b0fa59-d492-7ca5-40db-ab8e63cd8010@jugs.org> Hi, everybody can (and should) file bugs here: https://bugs.java.com/bugdatabase/ Have you tried that already? Michael Am 17.11.20 um 23:32 schrieb Marius Volkhart: > Hi Magnus, > > I haven't been able to get any traction with my Pull Request. I've sent 2 > mails to core-libs-dev mailing list. > > I believe I've found a bug in the javax.xml module. An issue for this > behavior does not exist in the bug tracker, and I do not have a OpenJDK > account so I can't open an issue. The PR includes a fix with a test. What's > the right course of action for me here? > > -- > Cheers, > Marius Volkhart > > > > On Thu, Nov 12, 2020 at 1:33 AM Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> On 2020-11-07 19:54, Marius Volkhart wrote: >>> Hello, >>> >>> I've been working on making my first JDK contribution, and thought I'd >>> provide some feedback on the process. >> Hello Marius, >> >> Thank you for reporting your experiences, in such a constructive tone. >> This is all very new to us, and there are certainly road bumps that need >> to be flattened. Some may be easy to fix, and other may be harder. But >> getting feedback about what's the pain points of a new contributor >> certainly helps us understand where there are work left to do. >> >> /Magnus >>> My motivation for contributing is that I found 2 bugs in javax.xml. >>> >>> My first thought was to 1. see if there is an existing bug, and 2. if >> not, >>> file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net >> . >>> This was a pretty big demotivator, and caused me to stop JDK work for the >>> day. In my previous experiences with open source projects, be it Apache, >>> OpenJ9, or other projects on GitHub, filing a bug was very easy. >>> >>> Getting the source code was really easy thanks to it being on Github now! >>> This was great. Unfortunately, I found myself running up a steep cliff >>> pretty quickly thereafter. >>> >>> The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to >>> easier CA processes, typically something like https://cla-assistant.io/ >> but >>> it was alright. One thing that was not clear from the contributing page >> is >>> that I need to specify my GitHub username in the Username field of the >> OCA. >>> The OCA process was really fast, and Dalibor was very prompt. >>> >>> Now, given that I had something I wanted to work on, and it was a minor >>> change most likely best discussed via code, and I already figured out >>> where/what the bug was, I figured I'd make a PR next. The contributing >>> guide doesn't know what PRs are yet, and I don't have a sponsor, so I >>> figured that from here on out, I was on my own. >>> >>> Next I tried to get working with the code, and quickly realized that I >> had >>> absolutely no idea of how to get started with this in an IDE (Intellij in >>> my case). I'm used to having a Maven or Gradle project, or even something >>> like Bazel that lets me generate IDE project files. A guide on how to >> edit >>> the Java parts of the JDK in the popular IDEs would be immensely helpful. >>> >>> Fortunately my first bug is an easy 1 line change, and doesn't need any >>> imports or formatting or whatever. I chose to hold off with writing a >> unit >>> test because I don't even know how to run it yet. >>> >>> So now I figured I'd try the build instructions linked in the README. The >>> TL;DR is exactly what I wanted, and all went well until I got to running >>> the tier 1 tests. That step fails because something called jtreg is >>> missing. I tried to install via my package manager (homebrew, I'm on a >> Mac) >>> but jtreg isn't on there. I found the GitHub repo for it, but there are >> no >>> prebuilt artifacts on GitHub, and building jtreg wasn't something I >> wanted >>> to delve into. Ant & talk of JDK 7. (Several days later I found >>> >> https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact >>> but I don't know why there are 2 versions there.) >>> >>> In the course of trying to figure out what jtreg is, I learned that >> TestNG >>> is used, so I wrote my unit test in an out of band Gradle project and >>> copy/pasted the file into the JDK tree. >>> >>> I decided to just make the change, push it, and have the GitHub Workflow >>> build and run the tests. The Workflow is great, and it was pretty easy to >>> get my fork to run the tests. How to get your fork to run the tests is >>> probably something that should be explained or called out in >>> CONTRIBUTING.md. I now wanted to see if my tests got picked up by the >> tool >>> and passed. I downloaded the test results ZIP, but am completely >>> overwhelmed by the contents. Is my test in testresults_part1? >> testsupport? >>> debug_testresults_common? I couldn't find it. >>> >>> I gave up at this point, and just pushed the change, hoping that someone >>> who knows how this all works can tell me exactly what changes to make, or >>> will pick up the patch and do what needs to be done. >>> >>> The biggest hurdles for me for working on the code are 1. Getting the >> code >>> into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle >> to >>> contributing is the inability to file bugs. >>> >>> I hope this helps in improving the contributor experience. >>> >>> -- >>> Cheers, >>> Marius Volkhart >> From Marius at volkhart.com Tue Nov 17 23:03:50 2020 From: Marius at volkhart.com (Marius Volkhart) Date: Wed, 18 Nov 2020 00:03:50 +0100 Subject: First time contributor experience In-Reply-To: <34b0fa59-d492-7ca5-40db-ab8e63cd8010@jugs.org> References: <9b6f4468-f885-1703-7d82-f43f5e9f86a8@oracle.com> <34b0fa59-d492-7ca5-40db-ab8e63cd8010@jugs.org> Message-ID: I had not found that before, thanks! I don't believe any of the contributing docs that I read directed to that page, and the bug database JIRA homepage doesn't have a link to it either. -- Cheers, Marius Volkhart On Tue, Nov 17, 2020 at 11:47 PM Michael Paus wrote: > Hi, > everybody can (and should) file bugs here: > https://bugs.java.com/bugdatabase/ > Have you tried that already? > Michael > > Am 17.11.20 um 23:32 schrieb Marius Volkhart: > > Hi Magnus, > > > > I haven't been able to get any traction with my Pull Request. I've sent 2 > > mails to core-libs-dev mailing list. > > > > I believe I've found a bug in the javax.xml module. An issue for this > > behavior does not exist in the bug tracker, and I do not have a OpenJDK > > account so I can't open an issue. The PR includes a fix with a test. > What's > > the right course of action for me here? > > > > -- > > Cheers, > > Marius Volkhart > > > > > > > > On Thu, Nov 12, 2020 at 1:33 AM Magnus Ihse Bursie < > > magnus.ihse.bursie at oracle.com> wrote: > > > >> On 2020-11-07 19:54, Marius Volkhart wrote: > >>> Hello, > >>> > >>> I've been working on making my first JDK contribution, and thought I'd > >>> provide some feedback on the process. > >> Hello Marius, > >> > >> Thank you for reporting your experiences, in such a constructive tone. > >> This is all very new to us, and there are certainly road bumps that need > >> to be flattened. Some may be easy to fix, and other may be harder. But > >> getting feedback about what's the pain points of a new contributor > >> certainly helps us understand where there are work left to do. > >> > >> /Magnus > >>> My motivation for contributing is that I found 2 bugs in javax.xml. > >>> > >>> My first thought was to 1. see if there is an existing bug, and 2. if > >> not, > >>> file a bug. As it turns out, I can't file a bug at > bugs.openjdk.java.net > >> . > >>> This was a pretty big demotivator, and caused me to stop JDK work for > the > >>> day. In my previous experiences with open source projects, be it > Apache, > >>> OpenJ9, or other projects on GitHub, filing a bug was very easy. > >>> > >>> Getting the source code was really easy thanks to it being on Github > now! > >>> This was great. Unfortunately, I found myself running up a steep cliff > >>> pretty quickly thereafter. > >>> > >>> The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to > >>> easier CA processes, typically something like > https://cla-assistant.io/ > >> but > >>> it was alright. One thing that was not clear from the contributing page > >> is > >>> that I need to specify my GitHub username in the Username field of the > >> OCA. > >>> The OCA process was really fast, and Dalibor was very prompt. > >>> > >>> Now, given that I had something I wanted to work on, and it was a minor > >>> change most likely best discussed via code, and I already figured out > >>> where/what the bug was, I figured I'd make a PR next. The contributing > >>> guide doesn't know what PRs are yet, and I don't have a sponsor, so I > >>> figured that from here on out, I was on my own. > >>> > >>> Next I tried to get working with the code, and quickly realized that I > >> had > >>> absolutely no idea of how to get started with this in an IDE (Intellij > in > >>> my case). I'm used to having a Maven or Gradle project, or even > something > >>> like Bazel that lets me generate IDE project files. A guide on how to > >> edit > >>> the Java parts of the JDK in the popular IDEs would be immensely > helpful. > >>> > >>> Fortunately my first bug is an easy 1 line change, and doesn't need any > >>> imports or formatting or whatever. I chose to hold off with writing a > >> unit > >>> test because I don't even know how to run it yet. > >>> > >>> So now I figured I'd try the build instructions linked in the README. > The > >>> TL;DR is exactly what I wanted, and all went well until I got to > running > >>> the tier 1 tests. That step fails because something called jtreg is > >>> missing. I tried to install via my package manager (homebrew, I'm on a > >> Mac) > >>> but jtreg isn't on there. I found the GitHub repo for it, but there are > >> no > >>> prebuilt artifacts on GitHub, and building jtreg wasn't something I > >> wanted > >>> to delve into. Ant & talk of JDK 7. (Several days later I found > >>> > >> > https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact > >>> but I don't know why there are 2 versions there.) > >>> > >>> In the course of trying to figure out what jtreg is, I learned that > >> TestNG > >>> is used, so I wrote my unit test in an out of band Gradle project and > >>> copy/pasted the file into the JDK tree. > >>> > >>> I decided to just make the change, push it, and have the GitHub > Workflow > >>> build and run the tests. The Workflow is great, and it was pretty easy > to > >>> get my fork to run the tests. How to get your fork to run the tests is > >>> probably something that should be explained or called out in > >>> CONTRIBUTING.md. I now wanted to see if my tests got picked up by the > >> tool > >>> and passed. I downloaded the test results ZIP, but am completely > >>> overwhelmed by the contents. Is my test in testresults_part1? > >> testsupport? > >>> debug_testresults_common? I couldn't find it. > >>> > >>> I gave up at this point, and just pushed the change, hoping that > someone > >>> who knows how this all works can tell me exactly what changes to make, > or > >>> will pick up the patch and do what needs to be done. > >>> > >>> The biggest hurdles for me for working on the code are 1. Getting the > >> code > >>> into my IDE, and 2. Acquiring and working with jtreg. The biggest > hurdle > >> to > >>> contributing is the inability to file bugs. > >>> > >>> I hope this helps in improving the contributor experience. > >>> > >>> -- > >>> Cheers, > >>> Marius Volkhart > >> > > From cjashfor at linux.ibm.com Wed Nov 18 17:54:34 2020 From: cjashfor at linux.ibm.com (Corey Ashford) Date: Wed, 18 Nov 2020 09:54:34 -0800 Subject: Fwd: Question about when mailing list postings are made following a PR In-Reply-To: <270fb95f-5197-0159-fc53-9215723e10ce@linux.ibm.com> References: <270fb95f-5197-0159-fc53-9215723e10ce@linux.ibm.com> Message-ID: <9ede83b0-ad14-337a-3aea-491dc3c5f17a@linux.ibm.com> Hi I made the following posting yesterday in the skara-dev mailing list, but it seems the discuss list is more active for this kind of question. Any ideas? -------- Forwarded Message -------- Subject: Question about when mailing list postings are made following a PR Date: Tue, 17 Nov 2020 12:59:55 -0800 From: Corey Ashford To: skara-dev at openjdk.java.net Hello, I made a new PR two days ago: https://github.com/openjdk/jdk/pull/1245 It was automatically labeled with hotspot-compiler but I haven't seen any posting on the hotspot-compiler-dev mailing list. What is the criteria for making an automatic posting on the mailing list? Thanks for your consideration, - Corey Corey Ashford Software Engineer IBM Systems, LTC OpenJDK team cjashfor at us.ibm.com IBM From jesper.wilhelmsson at oracle.com Thu Nov 19 03:46:15 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 19 Nov 2020 04:46:15 +0100 Subject: First time contributor experience In-Reply-To: References: Message-ID: <3A8ED2E8-5932-4943-926C-6AFAC76D33F0@oracle.com> Hi Marius, Thank you for your experience report! This is gold to me as I'm working on improving the OpenJDK Developers' Guide. Eventually the OpenJDK Developers' Guide should be referenced from CONTRIBUTING.md but we have a few more updates to make before we want to attract too much attention to it :-) But here it is: https://openjdk.java.net/guide/ The major update that's still pending is the move to git. The Guide still refers to mercurial. Need to fix that. I see that you've already got the link to the bug report tool. This is mainly to be used by anyone who isn't working on OpenJDK development. Instructions on how to file a bug exists in the current Guide: https://openjdk.java.net/guide/#filing-a-bug It's a bit hidden right now but I intend to give it a more prominent position soon. What I really want to direct your attention to is a new section that's currently in review: https://github.com/openjdk/guide/pull/38 This intends to explain how to attack the OpenJDK as a new developer in the project. Among other things it mentions the OCA and the need for using your GitHub username. With this new section together with what's already in the Guide many of your concerns should be addressed. From your mail I've identified the following ToDos: * How to work with the code in an IDE * How to create a PR (part of git rewrite) * Where to find JTReg bundles * How to run tests with your fork and how to navigate the test result ZIP I'll add these to the Guide ToDo list. Please let me know if there are any questions you're still looking for answers to and I'll try to make it a priority to get those sections into the Guide asap. Thank you! /Jesper > On 7 Nov 2020, at 19:54, Marius Volkhart wrote: > > Hello, > > I've been working on making my first JDK contribution, and thought I'd > provide some feedback on the process. > > My motivation for contributing is that I found 2 bugs in javax.xml. > > My first thought was to 1. see if there is an existing bug, and 2. if not, > file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net. > This was a pretty big demotivator, and caused me to stop JDK work for the > day. In my previous experiences with open source projects, be it Apache, > OpenJ9, or other projects on GitHub, filing a bug was very easy. > > Getting the source code was really easy thanks to it being on Github now! > This was great. Unfortunately, I found myself running up a steep cliff > pretty quickly thereafter. > > The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to > easier CA processes, typically something like https://cla-assistant.io/ but > it was alright. One thing that was not clear from the contributing page is > that I need to specify my GitHub username in the Username field of the OCA. > The OCA process was really fast, and Dalibor was very prompt. > > Now, given that I had something I wanted to work on, and it was a minor > change most likely best discussed via code, and I already figured out > where/what the bug was, I figured I'd make a PR next. The contributing > guide doesn't know what PRs are yet, and I don't have a sponsor, so I > figured that from here on out, I was on my own. > > Next I tried to get working with the code, and quickly realized that I had > absolutely no idea of how to get started with this in an IDE (Intellij in > my case). I'm used to having a Maven or Gradle project, or even something > like Bazel that lets me generate IDE project files. A guide on how to edit > the Java parts of the JDK in the popular IDEs would be immensely helpful. > > Fortunately my first bug is an easy 1 line change, and doesn't need any > imports or formatting or whatever. I chose to hold off with writing a unit > test because I don't even know how to run it yet. > > So now I figured I'd try the build instructions linked in the README. The > TL;DR is exactly what I wanted, and all went well until I got to running > the tier 1 tests. That step fails because something called jtreg is > missing. I tried to install via my package manager (homebrew, I'm on a Mac) > but jtreg isn't on there. I found the GitHub repo for it, but there are no > prebuilt artifacts on GitHub, and building jtreg wasn't something I wanted > to delve into. Ant & talk of JDK 7. (Several days later I found > https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact > but I don't know why there are 2 versions there.) > > In the course of trying to figure out what jtreg is, I learned that TestNG > is used, so I wrote my unit test in an out of band Gradle project and > copy/pasted the file into the JDK tree. > > I decided to just make the change, push it, and have the GitHub Workflow > build and run the tests. The Workflow is great, and it was pretty easy to > get my fork to run the tests. How to get your fork to run the tests is > probably something that should be explained or called out in > CONTRIBUTING.md. I now wanted to see if my tests got picked up by the tool > and passed. I downloaded the test results ZIP, but am completely > overwhelmed by the contents. Is my test in testresults_part1? testsupport? > debug_testresults_common? I couldn't find it. > > I gave up at this point, and just pushed the change, hoping that someone > who knows how this all works can tell me exactly what changes to make, or > will pick up the patch and do what needs to be done. > > The biggest hurdles for me for working on the code are 1. Getting the code > into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle to > contributing is the inability to file bugs. > > I hope this helps in improving the contributor experience. > > -- > Cheers, > Marius Volkhart From Marius at volkhart.com Thu Nov 19 14:00:57 2020 From: Marius at volkhart.com (Marius Volkhart) Date: Thu, 19 Nov 2020 15:00:57 +0100 Subject: First time contributor experience In-Reply-To: <3A8ED2E8-5932-4943-926C-6AFAC76D33F0@oracle.com> References: <3A8ED2E8-5932-4943-926C-6AFAC76D33F0@oracle.com> Message-ID: Thanks Jesper! That guide and the coming changes are helpful, and the ToDos you've identified seem right based on my experience. Thanks for taking the time to reply and to improve the guide! -- Cheers, Marius Volkhart On Thu, Nov 19, 2020 at 4:46 AM Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Hi Marius, > > Thank you for your experience report! This is gold to me as I'm working on > improving the OpenJDK Developers' Guide. Eventually the OpenJDK Developers' > Guide should be referenced from CONTRIBUTING.md but we have a few more > updates to make before we want to attract too much attention to it :-) But > here it is: https://openjdk.java.net/guide/ > > The major update that's still pending is the move to git. The Guide still > refers to mercurial. Need to fix that. > > I see that you've already got the link to the bug report tool. This is > mainly to be used by anyone who isn't working on OpenJDK development. > Instructions on how to file a bug exists in the current Guide: > https://openjdk.java.net/guide/#filing-a-bug > It's a bit hidden right now but I intend to give it a more prominent > position soon. > > What I really want to direct your attention to is a new section that's > currently in review: https://github.com/openjdk/guide/pull/38 > > This intends to explain how to attack the OpenJDK as a new developer in > the project. Among other things it mentions the OCA and the need for using > your GitHub username. > > With this new section together with what's already in the Guide many of > your concerns should be addressed. From your mail I've identified the > following ToDos: > > * How to work with the code in an IDE > * How to create a PR (part of git rewrite) > * Where to find JTReg bundles > * How to run tests with your fork and how to navigate the test result ZIP > > I'll add these to the Guide ToDo list. Please let me know if there are any > questions you're still looking for answers to and I'll try to make it a > priority to get those sections into the Guide asap. > > Thank you! > /Jesper > > > On 7 Nov 2020, at 19:54, Marius Volkhart wrote: > > > > Hello, > > > > I've been working on making my first JDK contribution, and thought I'd > > provide some feedback on the process. > > > > My motivation for contributing is that I found 2 bugs in javax.xml. > > > > My first thought was to 1. see if there is an existing bug, and 2. if > not, > > file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net > . > > This was a pretty big demotivator, and caused me to stop JDK work for the > > day. In my previous experiences with open source projects, be it Apache, > > OpenJ9, or other projects on GitHub, filing a bug was very easy. > > > > Getting the source code was really easy thanks to it being on Github now! > > This was great. Unfortunately, I found myself running up a steep cliff > > pretty quickly thereafter. > > > > The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to > > easier CA processes, typically something like https://cla-assistant.io/ > but > > it was alright. One thing that was not clear from the contributing page > is > > that I need to specify my GitHub username in the Username field of the > OCA. > > The OCA process was really fast, and Dalibor was very prompt. > > > > Now, given that I had something I wanted to work on, and it was a minor > > change most likely best discussed via code, and I already figured out > > where/what the bug was, I figured I'd make a PR next. The contributing > > guide doesn't know what PRs are yet, and I don't have a sponsor, so I > > figured that from here on out, I was on my own. > > > > Next I tried to get working with the code, and quickly realized that I > had > > absolutely no idea of how to get started with this in an IDE (Intellij in > > my case). I'm used to having a Maven or Gradle project, or even something > > like Bazel that lets me generate IDE project files. A guide on how to > edit > > the Java parts of the JDK in the popular IDEs would be immensely helpful. > > > > Fortunately my first bug is an easy 1 line change, and doesn't need any > > imports or formatting or whatever. I chose to hold off with writing a > unit > > test because I don't even know how to run it yet. > > > > So now I figured I'd try the build instructions linked in the README. The > > TL;DR is exactly what I wanted, and all went well until I got to running > > the tier 1 tests. That step fails because something called jtreg is > > missing. I tried to install via my package manager (homebrew, I'm on a > Mac) > > but jtreg isn't on there. I found the GitHub repo for it, but there are > no > > prebuilt artifacts on GitHub, and building jtreg wasn't something I > wanted > > to delve into. Ant & talk of JDK 7. (Several days later I found > > > https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact > > but I don't know why there are 2 versions there.) > > > > In the course of trying to figure out what jtreg is, I learned that > TestNG > > is used, so I wrote my unit test in an out of band Gradle project and > > copy/pasted the file into the JDK tree. > > > > I decided to just make the change, push it, and have the GitHub Workflow > > build and run the tests. The Workflow is great, and it was pretty easy to > > get my fork to run the tests. How to get your fork to run the tests is > > probably something that should be explained or called out in > > CONTRIBUTING.md. I now wanted to see if my tests got picked up by the > tool > > and passed. I downloaded the test results ZIP, but am completely > > overwhelmed by the contents. Is my test in testresults_part1? > testsupport? > > debug_testresults_common? I couldn't find it. > > > > I gave up at this point, and just pushed the change, hoping that someone > > who knows how this all works can tell me exactly what changes to make, or > > will pick up the patch and do what needs to be done. > > > > The biggest hurdles for me for working on the code are 1. Getting the > code > > into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle > to > > contributing is the inability to file bugs. > > > > I hope this helps in improving the contributor experience. > > > > -- > > Cheers, > > Marius Volkhart > >