From stuart.marks at oracle.com Wed Jul 1 05:23:08 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 30 Jun 2020 22:23:08 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> Message-ID: <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> On 6/26/20 6:37 PM, Joe Darcy wrote: > On 6/26/2020 10:54 AM, Brian Goetz wrote: >> To the extent that it forms a ?from the source? set of recommendations for new >> language features (which are coming fast and furious these days!), a >> non-authoritative guide still has significant value. > > As a concrete example, such a style guide would provide a natural and more > discoverable home for useful documents like Stuart's > > ??? "Local Variable Type Inference: Style Guidelines" > ??? https://openjdk.java.net/projects/amber/LVTIstyle.html Thanks for mentioning this, Joe. To this I'd add Jim Laskey's document, Programmer's Guide To Text Blocks https://cr.openjdk.java.net/~jlaskey/Strings/TextBlocksGuide_v9.html I will quibble here with Brian's intimation that these documents are not authoritative. I would argue that being "from the source" implies that the documents *are* authoritative. They were written by people very close to the development of the features themselves, and as such are in the best position to give informed advice about proper and improper use, avoidance of pitfalls, recommended practices, and so forth. With this in mind, I will state that I do not think the Java Style Guide belongs in the Developer's Guide. The reason is that the documents have fundamentally different editorial stances. The Developer's Guide is primarily operational: it contains information about how to do things, where to look, whom to ask, step by step procedures to follow, tips & tricks for working effectively, and so forth. It covers a wide range of topic areas. For example, one tip might be To switch branches, use 'git switch' instead of 'git checkout -b'. Git experts might reasonably take issue with this advice. However, git experts might not have any opinion at all on other topics, such as one that covers the proper usage of the noreg-long label on a JBS issue. As such, the Developer's Guide benefits from input from many individuals with a broad range of interests, each contributing bits of expertise in different areas. A style guide is fundamentally different. To be useful, it must be authoritative -- as mentioned above -- and it also must be highly cohesive. It needs to have a uniform editorial voice that is adhered to consistently throughout the document. For example, it might take a prescriptive vs. a descriptive stance, or it might choose a vocabulary for recommendations of varying strength ("can", "should", "must", etc.) and use that throughout the document. As such, a style guide is not at all amenable to a "crowdsourcing" approach and must be edited by a handful of individuals. Since the editorial approach for the style guide material is so different from that of the Developer's Guide, it follows that the style guide should be a different document. Personally I'm agnostic to the exact process for delivering a style guide. If Mark thinks a JEP is required, then maybe that's the best way forward. But I could imagine other paths forward that wouldn't use a JEP. I would strongly recommend against making the style guide itself be a JEP. Today, editing a JEP with more than a page or two of text is already unwieldy. It's easy to introduce errors inadvertently, and history tracking is virtually nonexistent. It seems unwise to put JIRA+markdown plugin improvements into the critical path of delivering a style guide. Doing that might prove fatal. s'marks From magnus.ihse.bursie at oracle.com Wed Jul 1 08:44:03 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 1 Jul 2020 10:44:03 +0200 Subject: RFR: Updated section on Code Conventions. In-Reply-To: <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> Message-ID: On 2020-07-01 07:23, Stuart Marks wrote: > > > On 6/26/20 6:37 PM, Joe Darcy wrote: >> On 6/26/2020 10:54 AM, Brian Goetz wrote: >>> To the extent that it forms a ?from the source? set of >>> recommendations for new language features (which are coming fast and >>> furious these days!), a non-authoritative guide still has >>> significant value. >> >> As a concrete example, such a style guide would provide a natural and >> more discoverable home for useful documents like Stuart's >> >> ???? "Local Variable Type Inference: Style Guidelines" >> ???? https://openjdk.java.net/projects/amber/LVTIstyle.html > > Thanks for mentioning this, Joe. To this I'd add Jim Laskey's document, > > ????Programmer's Guide To Text Blocks > ????https://cr.openjdk.java.net/~jlaskey/Strings/TextBlocksGuide_v9.html > > I will quibble here with Brian's intimation that these documents are > not authoritative. I would argue that being "from the source" implies > that the documents *are* authoritative. They were written by people > very close to the development of the features themselves, and as such > are in the best position to give informed advice about proper and > improper use, avoidance of pitfalls, recommended practices, and so forth. > > With this in mind, I will state that I do not think the Java Style > Guide belongs in the Developer's Guide. The reason is that the > documents have fundamentally different editorial stances. > > The Developer's Guide is primarily operational: it contains > information about how to do things, where to look, whom to ask, step > by step procedures to follow, tips & tricks for working effectively, > and so forth. It covers a wide range of topic areas. For example, one > tip might be > > ??? To switch branches, use 'git switch' instead of 'git checkout -b'. > > Git experts might reasonably take issue with this advice. However, git > experts might not have any opinion at all on other topics, such as one > that covers the proper usage of the noreg-long label on a JBS issue. > As such, the Developer's Guide benefits from input from many > individuals with a broad range of interests, each contributing bits of > expertise in different areas. > > A style guide is fundamentally different. To be useful, it must be > authoritative -- as mentioned above -- and it also must be highly > cohesive. It needs to have a uniform editorial voice that is adhered > to consistently throughout the document. For example, it might take a > prescriptive vs. a descriptive stance, or it might choose a vocabulary > for recommendations of varying strength ("can", "should", "must", > etc.) and use that throughout the document. As such, a style guide is > not at all amenable to a "crowdsourcing" approach and must be edited > by a handful of individuals. Since the editorial approach for the > style guide material is so different from that of the Developer's > Guide, it follows that the style guide should be a different document. > > Personally I'm agnostic to the exact process for delivering a style > guide. If Mark thinks a JEP is required, then maybe that's the best > way forward. But I could imagine other paths forward that wouldn't use > a JEP. > > I would strongly recommend against making the style guide itself be a > JEP. Today, editing a JEP with more than a page or two of text is > already unwieldy. It's easy to introduce errors inadvertently, and > history tracking is virtually nonexistent. Are you suggesting that we should create a sibling project to the Developer's Guide for the style guide(s), with different rules for engagement? /Magnus > It seems unwise to put JIRA+markdown plugin improvements into the > critical path of delivering a style guide. Doing that might prove fatal. > > s'marks From kim.barrett at oracle.com Wed Jul 1 09:48:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Jul 2020 05:48:27 -0400 Subject: RFR: Updated section on Code Conventions. In-Reply-To: <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> Message-ID: <4CE09277-422A-43E4-91B3-C4AEEE848A82@oracle.com> > On Jul 1, 2020, at 1:23 AM, Stuart Marks wrote: > A style guide is fundamentally different. To be useful, it must be authoritative -- as mentioned above -- and it also must be highly cohesive. It needs to have a uniform editorial voice that is adhered to consistently throughout the document. For example, it might take a prescriptive vs. a descriptive stance, or it might choose a vocabulary for recommendations of varying strength ("can", "should", "must", etc.) and use that throughout the document. As such, a style guide is not at all amenable to a "crowdsourcing" approach and must be edited by a handful of individuals. Since the editorial approach for the style guide material is so different from that of the Developer's Guide, it follows that the style guide should be a different document. > > Personally I'm agnostic to the exact process for delivering a style guide. If Mark thinks a JEP is required, then maybe that's the best way forward. But I could imagine other paths forward that wouldn't use a JEP. > > I would strongly recommend against making the style guide itself be a JEP. Today, editing a JEP with more than a page or two of text is already unwieldy. It's easy to introduce errors inadvertently, and history tracking is virtually nonexistent. It seems unwise to put JIRA+markdown plugin improvements into the critical path of delivering a style guide. Doing that might prove fatal. As someone with another Style Guide update in the works (for HotSpot), I agree having it *be* a JEP is not desirable. It currently resides in the OpenJDK wiki, but that hasn't served us well. It has been suggested that it should reside in the Developers' Guide (by some of the same people suggesting that for the Java Style Guide). I think that would be okay if it can have its own rules for updates. The current draft proposes update rules, which are also in the C++14 update JEP (JDK-8208089) that is driving the document revision. (Whether those are the right rules remains to be seen, though nobody has objected or suggested something else in the 1.5+ years since that was added to the JEP, or in review of the new draft document.) I've also discussed the possibility of putting it in the jdk/jdk repository, probably in the toplevel doc directory. My preference would be to put it in a repository with decent revision control (unlike either the wiki or JBS). Whether that's the Dev-Guide, jdk/jdk, or some other agreeable place is, I think, of less importance. Having it be in the Dev-Guide (or some similar place) has the benefit of having a web "mirror", unlike jdk/jdk/doc. From dmitry.markov at oracle.com Wed Jul 1 18:49:46 2020 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 1 Jul 2020 19:49:46 +0100 Subject: Result: New JDK Reviewer: Anton Litvinov Message-ID: Voting for Anton Litvinov [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Regards, Dmitry [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004433.html From mark.reinhold at oracle.com Thu Jul 2 00:11:46 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Jul 2020 17:11:46 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> Message-ID: <20200701171146.311157322@eggemoggin.niobe.net> 2020/6/29 2:21:21 -0700, Andrew Haley : > On 26/06/2020 15:13, Magnus Ihse Bursie wrote: >> >> ... >> >> On 2020-06-22 18:40, mark.reinhold at oracle.com wrote: >>> No matter what we say about these documents merely being suggestive >>> guidelines, at least some people will treat them as normative and >>> authoritative, and use them as the basis for arguing one way or another. >> >> I do not agree that this is a valid argument. We can't claim that we >> should not publish guidelines, since some people will not understand >> what "guidelines" mean. If you are serious about this argument, then >> we can just as well shut down the entire Developer's Guide, since >> it's all about non-authoritative suggestions. > > Mark's point, and I hope I'm not misrepresenting him, is that figuring > out what the coding style should be, without being over-prescriptive, > is difficult and requires a JEP. Putting non-authoritative Java style > guidelines in the Developers? Guide risks bypassing any review > process. Yes. More precisely, it risks bypassing any meaningful review beyond the small number of people who maintain the Developers? Guide. No matter how well intentioned those people might be, such an important document should be more stable, and changes to it more tightly controlled, than the Developers? Guide is meant to be. (One way to address that is to make every OpenJDK contributor also be a Developers? Guide maintainer, but that doesn?t scale very well. Many contributors will be interested in changes to code-style guidelines. Few, I suspect, will care to review every other change to the Guide.) >> And even if we do think it is desirable, for every year we wait >> until we publish a guide, the harder it will become to create a new, >> globally recognized, normative style guide. > > True, but a nonexistent style guide is far better than one which in > effect constrains developers and reviewers in such a way as to make > working on the JDK worse, in terms of both the experience for the > developer and the outcome. Agreed. - Mark From mark.reinhold at oracle.com Thu Jul 2 00:13:05 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Jul 2020 17:13:05 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> Message-ID: <20200701171305.740786457@eggemoggin.niobe.net> 2020/6/26 15:42:30 -0700, alex.buckley at oracle.com: > The CfV for the Developer's Guide Project said: "The OpenJDK Developer's > Guide is intended to contain tutorial style texts that give examples and > step-by step directions for common parts of the development process. > Strict rules for OpenJDK development are better suited to a process JEP. > The development of such a JEP is outside of the scope of this project > but will be developed as part of a separate effort in parallel." > > With that in mind, some thoughts: > > 1. The OpenJDK Bylaws define "social infrastructure" -- roles, voting, > groups, projects. Where is the definition of "technical infrastructure" > -- repositories, bug trackers, mailing lists, test fleets? Answer: > Locked up in the current OpenJDK Developer's Guide. It seems to me that > a good start would be: throw all the chapters in the current Guide up in > the air, and catch only the ones which let you write a dry, factual > manual about the technical infrastructure. Such a manual relies on the > social infrastructure from the Bylaws, notably the idea of a Project. > The manual is not "normative" in the sense of "using wise judgment to > establish a standard that people must follow". Accordingly, it does not > describe processes (e.g. CSR) or conventions (e.g. code style, or > how-many-changesets-to-become-Committer). Nor is the manual > "informative" in the sense of giving tutorials, discussion, or rationale > about a normative artifact. It's definitional, like the Bylaws. Agreed, so far. > 2. Now turn to normative processes that use the technical > infrastructure: filing a bug, producing and shepherding a changeset, > ensuring compatibility using CSR, etc. For these topics, there is > established behavior that every OpenJDK Participant must follow. It > seems to me that this is what the CfV really wanted to document with > "tutorial style texts". By all means present the process of filing a bug > as a tutorial, but don't pretend it's merely a "non-authoritative > suggestion". There is plainly a right way, a norm, an authoritative > suggestion when it comes to filing a bug, or formatting a changeset > comment, or thinking about the source/binary/behavioral compatibility of > a change. As hinted at the CfV text that you quoted above, the Developer's Guide is not meant to define normative rules and processes but, rather, to elaborate upon them when helpful so that new contributors can get up to speed. The actual definitions of normative rules and other information are meant to reside in the hypothetical JEP ?outside the scope of this project? that ?will be developed as part of a separate effort in parallel.? That?s essentially a JEP for the JDK development process intended to be a sibling to JEP 3, the JDK release process. My expectation, which I discussed with Jesper when he was thinking of proposing the Guide Project, is that as the Guide contributors create or incorporate material for which a normative definition is needed, but does not yet exist, then that will drive the draft of the development-process JEP. New contributors will find the Guide a good way to get started. Experienced contributors can simply refer to the JEP for the short-form definitions of normative information. > 3. Now turn to informative content that every OpenJDK Participant is > free to ignore without consequence. I think you're saying that this > could include non-authoritative suggestions about the formatting of Java > source code in an OpenJDK repository. However, I agree with Mark: any > document connected with Oracle that concerns Java code formatting will > be taken as normative, authoritative rules by a broad swathe of the > worldwide Java developer community. I can tell you 20 ways that people > will interpret your content as "Oracle's Official Java Coding > Guidelines". (Example: "In this article on $DEVELOPER_NEWS_SITE, we > examine Oracle's new coding guide, and see how it compares with guides > from Google and Alibaba!" -- the writer is incentivized to get views, > not to make Magnus happy with how the guidelines are characterized.) This is exactly my primary concern. No matter how we label a code-style document, it will be considered authoritative by many people well beyond the OpenJDK Community. We therefore must do a good job of it. Doing no job would be better than doing a bad job. We serve the Java ecosystem. Like it or not, the eyes of the world are upon us. - Mark From mark.reinhold at oracle.com Thu Jul 2 00:13:29 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Jul 2020 17:13:29 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> Message-ID: <20200701171329.100085111@eggemoggin.niobe.net> 2020/6/29 10:45:26 -0700, alex.buckley at oracle.com: > ... > > I'm not sure if Mark if saying this exactly, but I can see the > Informational-means-normative angle serving as a feature, not a bug. An > Informational JEP "Java Style Guide for OpenJDK Projects" which is > normative for OpenJDK Projects will be taken as normative for ordinary > Java programs around the world, but the JEP "wrapper" is a great > mechanism for stopping outright misrepresentation and confusion. Precisely. - Mark From mark.reinhold at oracle.com Thu Jul 2 00:15:20 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Jul 2020 17:15:20 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> Message-ID: <20200701171520.898247131@eggemoggin.niobe.net> 2020/6/30 22:23:08 -0700, stuart.marks at oracle.com: > ... > > I will quibble here with Brian's intimation that these documents are not > authoritative. I would argue that being "from the source" implies that the > documents *are* authoritative. They were written by people very close to the > development of the features themselves, and as such are in the best position to > give informed advice about proper and improper use, avoidance of pitfalls, > recommended practices, and so forth. Agreed. > With this in mind, I will state that I do not think the Java Style Guide belongs > in the Developer's Guide. The reason is that the documents have fundamentally > different editorial stances. > > The Developer's Guide is primarily operational: it contains information about > how to do things, where to look, whom to ask, step by step procedures to follow, > tips & tricks for working effectively, and so forth. It covers a wide range of > topic areas. For example, one tip might be > > To switch branches, use 'git switch' instead of 'git checkout -b'. > > Git experts might reasonably take issue with this advice. However, git experts > might not have any opinion at all on other topics, such as one that covers the > proper usage of the noreg-long label on a JBS issue. As such, the Developer's > Guide benefits from input from many individuals with a broad range of interests, > each contributing bits of expertise in different areas. > > A style guide is fundamentally different. To be useful, it must be authoritative > -- as mentioned above -- and it also must be highly cohesive. It needs to have a > uniform editorial voice that is adhered to consistently throughout the document. > For example, it might take a prescriptive vs. a descriptive stance, or it might > choose a vocabulary for recommendations of varying strength ("can", "should", > "must", etc.) and use that throughout the document. As such, a style guide is > not at all amenable to a "crowdsourcing" approach and must be edited by a > handful of individuals. Since the editorial approach for the style guide > material is so different from that of the Developer's Guide, it follows that the > style guide should be a different document. Agreed. Strongly. This brings up a related, and important, question: If we?re going to have an authoritative style guide with a uniform editorial voice, then who will sign up to be the editor? Andreas?s draft may be a reasonable starting point, but since he hasn?t been an active OpenJDK contributor for some years now I don?t imagine that he can commit to such a role. Not only would we need an editor to spend time on this, and maintain it for the long haul, but it would inevitably require some of the limited time of at least some of our most experienced contributors. Is that the best use of their time? > Personally I'm agnostic to the exact process for delivering a style guide. If > Mark thinks a JEP is required, then maybe that's the best way forward. But I > could imagine other paths forward that wouldn't use a JEP. > > I would strongly recommend against making the style guide itself be a JEP. > Today, editing a JEP with more than a page or two of text is already unwieldy. > It's easy to introduce errors inadvertently, and history tracking is virtually > nonexistent. It seems unwise to put JIRA+markdown plugin improvements into the > critical path of delivering a style guide. Doing that might prove fatal. Indeed, that would be most unwise. Fortunately, it?s not difficult to address this problem. The job that publishes https://openjdk.java.net/jeps could easily pull the text of select JEPs from any repo that we want, rather than use the bodies of the corresponding JBS issues. We could repurpose the existing jep/jeps repo for that purpose, or (more likely) just set up a new one on GitHub. - Mark From stuart.marks at oracle.com Thu Jul 2 03:54:02 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 1 Jul 2020 20:54:02 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> Message-ID: <1fb7cf56-8eb5-b73f-8fd2-8a5f852af40a@oracle.com> On 7/1/20 1:44 AM, Magnus Ihse Bursie wrote: >> A style guide is fundamentally different. To be useful, it must be >> authoritative -- as mentioned above -- and it also must be highly cohesive. It >> needs to have a uniform editorial voice that is adhered to consistently >> throughout the document. For example, it might take a prescriptive vs. a >> descriptive stance, or it might choose a vocabulary for recommendations of >> varying strength ("can", "should", "must", etc.) and use that throughout the >> document. As such, a style guide is not at all amenable to a "crowdsourcing" >> approach and must be edited by a handful of individuals. Since the editorial >> approach for the style guide material is so different from that of the >> Developer's Guide, it follows that the style guide should be a different >> document. >> >> Personally I'm agnostic to the exact process for delivering a style guide. If >> Mark thinks a JEP is required, then maybe that's the best way forward. But I >> could imagine other paths forward that wouldn't use a JEP. >> >> I would strongly recommend against making the style guide itself be a JEP. >> Today, editing a JEP with more than a page or two of text is already unwieldy. >> It's easy to introduce errors inadvertently, and history tracking is virtually >> nonexistent. > Are you suggesting that we should create a sibling project to the Developer's > Guide for the style guide(s), with different rules for engagement? I'm mainly suggesting that the Style Guide not be a chapter plopped into the middle of the Developer's Guide. They seem like fundamentally different documents and so should be treated differently. That said, where would the Style Guide reside? It could be in a separate OpenJDK Project, though that seems like kind of high overhead for a single document. A Project would have separate Reviewers/Committers/Authors, which also seems like high overhead, but maybe something like that is necessary. Or maybe it could be a Group. For example, recently formed groups like the CSR group and the Vulnerability group have their own, special rules of engagement. Or, the Style Guide could be hosted in the Developer's Guide *Project* but still be a different document, with different norms around who is responsible for modifying and reviewing changes. If the Style Guide has a single editor, or a small editorial board who are responsible for updating it, and everybody understands this, that might work just fine. This works for code. For example, I'm a libraries guy, so I don't go mucking around in Hotspot without talking to Hotspot folks about it first. s'marks From erik.helin at oracle.com Thu Jul 2 10:02:02 2020 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 2 Jul 2020 12:02:02 +0200 Subject: Need to update time zone metadata in tags for some OpenJDK git repositories Message-ID: <61068c40-ca67-a71b-69e7-22347b56439d@oracle.com> Hi all, me and Robin have discovered a minor bug in the Skara repository conversion tools. The bug consisted of using the wrong time zone when converting the metadata for a tag. To be precise, the conversion always used UTC+0 as the time zone for the Git tag metadata, instead of using the time zone recorded in the Mercurial tag metadata. All other metadata for tags is correct, including author, message, UNIX timestamp, the commit the tags points to, etc. The bug did *not* affect conversion of commits due to different code paths. This bug was fixed over a year ago, but it was unfortunately not fixed prior to the last full re-conversion of the jdk/jdk repository (it was fixed a couple of days after the last full re-conversion). The impact of the bug is therefore limited to older tags in primarily the jdk [0] repository having the wrong time zone recorded in their metadata. Specifically this affect selected tags from jdk7-b24 to jdk-14+16. The fix is fortunately relatively easy and consist of two steps: 1. Re-convert the tags with a recent version of Skara that no longer contains the bug. 2. Push the re-converted tags to the impacted OpenJDK repositories Step one is already done. We are planning to do step two a week from now, Wednesday July 8. After we have pushed the re-converted tags, then you will notice the following message when you try to pull: $ git pull --tags https://github.com/openjdk/jdk From https://github.com/openjdk/jdk: * branch HEAD -> FETCH_HEAD ! [rejected] jdk-10+0 -> jdk-10+0 (would clobber existing tag) ! [rejected] jdk-10+1 -> jdk-10+1 (would clobber existing tag) ! [rejected] jdk-10+10 -> jdk-10+10 (would clobber existing tag) ! [rejected] jdk-10+11 -> jdk-10+11 (would clobber existing tag) ! [rejected] jdk-10+12 -> jdk-10+12 (would clobber existing tag) ! [rejected] jdk-10+13 -> jdk-10+13 (would clobber existing tag) // continues for many more lines The above means that the tag objects you have in your local repository are different (have a different hash) compared to the ones in the jdk repository [0]. This is expected, since when we are re-converting the tags we will use the correct time zone (not just UTC+0) and therefore the metadata for the tag object will change and therefore the hash for the tag object will change. See the end of this e-mail for a full list of tag names with their current hash and what will be their new hash. To solve the above, you will have to run the following (just once): $ git pull --tags --force https://github.com/openjdk/jdk You will also most likely have to update your personal fork, this would be done with the following command (run it just once): $ git push --tags --force The tags will be updated in the following repositories on July 8: - https://github.com/openjdk/jdk (read-only) - https://github.com/openjdk/client (read-only) - https://github.com/openjdk/jdk14 (read-only) - https://github.com/openjdk/jdk14u (read-only) - https://github.com/openjdk/jdk13 (read-only) - https://github.com/openjdk/jdk13u (read-only) - https://github.com/openjdk/jdk12u (read-only) - https://github.com/openjdk/jdk11u (read-only) - https://github.com/openjdk/jdk11u-dev (read-only) Project repositories are not as affected since they don't sync tags by default. Those project repositories that wishes to have their tags updated will certainly get that, but can we take that project per project. The recently converted jdk15 repository [1] has tags with *correct* time zone metadata, so you can also browse the tags in the jdk15 repository [1] to verify our statements in this email. The jdk repository [0] has tags with *wrong* time zone metadata, so you can compare the tags in the jdk repository [0] with the tags in the jdk15 repository [1] to verify yourself that all metadata for all tags is identical except for the time zone. If you have any questions, please let us know. Thanks, Erik & Robin [0]: https://github.com/openjdk/jdk [1]: https://github.com/openjdk/jdk15 Q&A: Q: How can the UNIX timestamp be correct even if the time zone is wrong? A: We parsed the date from the Mercurial tag correctly, but when creating the Git tag object we did not record the correct time zone. Q: How could the verification scripts miss this? A: The UNIX timestamps were identical, only the stored time zone differed. Q: Why aren't regular commits affected? A: Tags and regular commits have different code paths in the converter. Q: How can I know that you aren't trying to sneakily change a few tags to point to different commits? A: All hashes of the new tags are included in this email. All tags with correct time zone metadata, and therefore correct hashes, are also available in the jdk15 repository [1]. This allows you to fully verify that the tags you pull down forcefully to your local repository on July 8 are indeed the ones listed here. It also allows you to compare all tags in the jdk repository [0] and in the jdk15 repository [1] to verify that all other metadata, including the commit the tag points to, is the same. Q: Should I in general just use git pull --force when git complains about a tag being clobbered? A: No, never. See https://git-scm.com/docs/git-tag#_on_re_tagging for details. Q: Have you found any other converter bugs because of this? A: We have gone over the code (again), and no, this bug has no additional impact. Q: Will this require a full re-conversion of the jdk repository causing all commit hashes to change? A: No, see answers above for the explanation. Q: Why aren't all tags between jdk7-b24 to jdk-14+16 affected? A: Some tags between jdk7-b24 and jdk-14+16 affected do have a time zone of UTC+0, which meant that the conversion was correct. Q: Why aren't tags after jdk-14+16 affected? A: A more recent version of Skara with the bug fixed was used to convert those tags. Q: How can I know that the metadata is correctly preserved from the Mercurial tags? A: You can choose a few tags at random and compare the metadata with the corresponding tag in the jdk Mercurial repository. Q: Why does Git and Mercurial store the time zone the commit was made in? That doesn't seem to make sense in a distributed system? A: This we actually don't know. Our best guess is that both Mercurial and Git choose to support dates according to RFC 2822 format which does include the time zone. Full list of tags that will change: TAG NAME OLD HASH -> NEW HASH jdk-10+0 56abf3ddbfbca65d9d43344bcb53aff3e168c817 -> cbfedbbe6ebcd34cf8073ceb3b9778338f0de722 jdk-10+1 1768e99d6a9f13867e02edc5c55e81df0395b61d -> a5719b8b503113d34a7037cd95ae9a75df465847 jdk-10+10 41fab65152a5a451cc8e53fae7ee13f1939bd3bf -> 5f7f102d588428f8f5e700c3b0be76f1e5bfddcb jdk-10+11 fb4c56701cae7bbf62f1a42699639d4ba542a230 -> 461ee9721bb0693c2e3f2addf4bbb47b645c6885 jdk-10+12 c9988d821eb72461580563149f15c135c764d603 -> ee812681b38e719e0abf0382c72dfb196ec09f83 jdk-10+13 f76cc3b57d749c8265bd689e4360a854f6003812 -> ffc5b1ebdf0a02687aa9b177dbda3ba1cc2ae32a jdk-10+14 86ffc0eafe2796a6807c6fbb8ff032d4a39bc63b -> ad42d50c857e6e36088008a5d130f4cd60bb7c6e jdk-10+15 c58d2be493f9c1d83ca94463eaa0a82c407bc9ea -> 689d3132b150d15c6934225e3e7b1092fa266e5b jdk-10+16 b48b8ef4cce601bc4dd0ff06d0779dfa6347efc3 -> f75cf7c4e209f2aab57a0f4a9322b4879155381f jdk-10+17 94dd894e29a5b68bb5e135935105f8b0f173d98e -> b781e3196724e8a790a4495b021e6559ba09c576 jdk-10+18 5510ef3e6440803979fe1f94fe8a92cdba1ff4d3 -> 15d921aa5c5f5e7a74d87d0a73b4ff9906ca2fe1 jdk-10+19 5426bc03ac136a1d3fa1c09285542fff55a118c6 -> ba483867b8a25a048cd7bd6671c4e17764061613 jdk-10+2 6a76beb2061fa82bb7f8dc984a6afa4e9ea6d5df -> bae6cc13b2ba7f664d2623cbda0023c83e26d4a0 jdk-10+20 61df92fad072873a777f7146026788eee06b92cd -> cd8f3bc879e19551b62a198a3863c155d31f1d02 jdk-10+21 3c14d883be5d143d79264d75089068d4867377d5 -> 1130c75bbfd94f9c6a65e9df6762ebbecaae8964 jdk-10+22 82ff87a7b20d98e291f327b15f083108aed23f28 -> 6bd3c79ea6c0a224d5d514b7a98abe90d69a220b jdk-10+23 d9d89aa12a5593f6d1eac198e9564d0ea0b03970 -> 231077803760a76522c821f84690e26c1c1e0a52 jdk-10+3 45c470ee766616a2f692c443cb9515c4580f89e9 -> 7cb8df7b70b7d5e2f3bedbded6b158e602a4a42b jdk-10+4 00c226446c5c473d894bc8c90dd148e1fe8be3c9 -> ae0756036271062a547477d8e38f654b88ccbf50 jdk-10+5 a953e6074865b4758dfa87ad196e442453e91d77 -> 281982de41c8193c72b36665ea3deba77e9d3f3f jdk-10+6 acccdb04b77a96689d683dc3f3db5745e3b60abd -> 3ff805ece2993979993b8d4a38a19eedf5cee82c jdk-10+7 65c9eadbf0d27a20b9ce829d7984aa68eee7bde3 -> a16f7f3960bd905f55f99bbc3fcea0b8612cc001 jdk-10+8 907f750e97bed1c3e4cccc28537053a0d90feca4 -> 790b6cb0b07c60cd8498ac22ec9e3bff95239aa3 jdk-10+9 363060b07b5cceb0d5b34168cddbef14c2f66d61 -> 692a723c417f00062a3b3ca4b401ea627c06396e jdk-11+15 51bba3f6c8881ece709f34824c94d5089b12f6aa -> 23fc97ad76fe2fd50c66f6df9eed8af0b82e3e79 jdk-11+16 36c5eea234040e0ad017bf148e587e0472949726 -> b13c8b270d477d104059e8e675f8819dd4f375bc jdk-11+17 a89bc16a886e76a642467d39f026fa49c3959faa -> c3aadd37733cd620c4d6baa37367fb598031924f jdk-11+18 ee7eeac1359039cb5b4e8044d17c3c0ad02f7d8f -> 00bd95880c2d6a113a84983cff091d816aee69ca jdk-11+19 66475a5f9d76d39c8c569a921db3e553d1649623 -> ed1cdef8f8e0ba88a9731e00762775d2b59dca71 jdk-11+20 9b53644fe73f8ae54fcd635189b84c00ce0a6636 -> 38a7f0b2631b5e8a0d401f619300a5c1fc863d79 jdk-11+21 cfad03739c9caac21c4dfc292d389081ad47e751 -> e32e4a2efd2e744aea1b975ab5d094512f029ad9 jdk-11+22 663ebfe873c8b6c0f08d1a9654be637f1b217c09 -> db1d8cc927f44eb5956931ed03997e683fa346cd jdk-11+23 35aa1747aade90d39a7bf996fe5edd3395186027 -> 66fb7c8d4800be881ab519e2da50f98e104b5ebf jdk-11+24 f516d8adcf49afd8d696dba128f8bee0fbfb4091 -> 744bba07a673601512c3e5a6bd1845788635c4b1 jdk-11+25 39b5213e33be6c83a233d87e6cdae9fcaf2fb4c1 -> 5626d9f41e656d488b2b3335ca41b4726e05a63e jdk-11+26 dbe968553594f4516c429eae1fe84ef7e060bea9 -> f88fcdf49eda0fe30f154a9d935631c2a4a38bbb jdk-11+27 a171a0154b1a911be2602a01ffa8e7ea946b0def -> ee78424c97284d9195b87003be54acfb8e34cd1e jdk-11+28 6e5885d939a834e01392e975964d377a24004b8d -> 6953356297f51be519e94a63b2c570d7ac1da826 jdk-12+0 b5b0fdef245ded2afb9bb1ba219644b31cccaea3 -> 9b8db1756bfcff2633049e1f5dd8a8f7c2ed7c9d jdk-12+1 cc19769f1752822586c630a02ea7948700e8fb4e -> ad4caf8d85b8863e9891e19ebaec5f5ae4b18ce1 jdk-12+10 2a0f5c11fa63c8678bc5088aaff75fb3dfcb1bde -> be536339f1b0f4ec0726335c336a266c13f22b48 jdk-12+11 7ae1df96d80afcf0de0e073eae364fb7d9886952 -> d56879ac9dd6d08f20caf5fefac64203e6cd3b87 jdk-12+12 80546944dd93084f559371caec2e8bebad4e6445 -> c812ca8928b7d9727e85eca694a06e2acdd174c7 jdk-12+13 89cc7db3ce85f8e2b3fe2a29413e6a70c0209095 -> 6427b92dc2e0dae2bfb0652e79fcfcc546a6fe3f jdk-12+14 20014767621b9aa7f135c382c120efd4d88ea3f8 -> 7ced54a9737663371ff3fb82c23d9b1f63139fc4 jdk-12+15 82722dd0d25a499d796a8964877b5991b3470c12 -> 5bdc0959c89565e8709b632964a99725e337767e jdk-12+16 6d0771f45b1e5625cf79b1f898040e1762e8ae07 -> 935482ea790aee7da4fe954c077c66e6256ca3f6 jdk-12+17 a6eb0c19eca858b517206fbf15d53f8661741979 -> 210c46ad4a627be1308daabbdb0310d1e0d1f373 jdk-12+18 317458ce59082a3bace88310e34ed8637208ba75 -> 006b92b11a2c32b47acda6faf23f5c4cdb96d77c jdk-12+19 967afa84d6a2ee6f5dcc5861e32375e038d05f3d -> 8e2e78ee5214c323da598ab57e9214b48b408f00 jdk-12+2 cc2d3951ce642b27ad9dee309672b38789a9ccfb -> c3b47c7d216c26a9bd2f40ea0a1b6b195ac15670 jdk-12+20 b561d4d76911ce36a548d5de258b1fc4554709b5 -> edadc5a4ed87fa1216cf6cdf4eb36425d60bdcbb jdk-12+21 e432c88d0ea97ce1aa0ca6eeaf6a3638768ec02e -> 2b509f0b196b983a25fee406350401ac83810cfc jdk-12+22 619ae685910188e10e4e5c5ca9e50bb061f0281b -> c9288e96dba7a5c5fe282466acaf8ee751af73df jdk-12+23 f994f5ce71df63823f0b3ddc104c182e1b20fc06 -> 68e5ecffe48f6e1aec197dc65a64b8918a941a3d jdk-12+24 078511454cd75f01a86f595d9e1c5254dbf86001 -> b1ed6821adefc061af12c5362031d90d8b00259c jdk-12+25 2c218fdeafb2300fb1db90129b564a3b31861790 -> 83332e95c0f77ef7faaf5b67a394751ac85d68ed jdk-12+26 0e780b41b2e335d042a908f92f665e75b9db701f -> e16c222bfac045078cda9a6a237a93f5942f14c1 jdk-12+27 1e875175a9f4897170f7572486287b15985dd838 -> bc18f89d46e59564902ba5110900696f81c39b3a jdk-12+28 379c1ccd608938b3fe8ac4161e6418692c2a30d2 -> aa2562349517abb1f22bb1892df0360013e5584e jdk-12+29 7b50b9329426e7895b82fecc4524c5a6576d73c4 -> 095f5860b1dc7c1e88f67f801bd141328b601fd6 jdk-12+3 ab8a10e7ba04208bfd53c141879691fb8e921da6 -> 06a419b32ce1ef257a80ffba0244ea20ee6c299b jdk-12+30 c459c0ab63f4bba79812f04c1fe8752a8d5435ce -> 2e4741cb7e7ebeec9b9ab959c5dbada61f31a28e jdk-12+31 e5d281f7d5d7b742b5d76740afb2d6af0f9552d1 -> d7d21c1be37803b2a00a4597c9ce84fe5b4e4863 jdk-12+32 4986d2a1d0b6252c5539e3d02cc81c8db8f8f04d -> 66a64c8b17e22ef4743e23b33e353ed9318eac08 jdk-12+33 0cfc17487c0e20cafb5cd80bae7750ac61456f35 -> bbb5ef28071d565e5e89df06b8b43ce8c8e59b7a jdk-12+4 dc6231698b232b08afd058705ad2c7a1ac84b794 -> f6bfc5aecb9d19fa43a9e8e5a45854059812f92c jdk-12+5 b17ca473401c0db567291d480a7a01563b323bb7 -> 61aea3dda8f8bf34a5dee10ef08f04f10791578e jdk-12+6 6a7b7b32dea00bb05a41de97d6ec99f6a5d4c3d3 -> 7d013ffe610c249da34029375c15a80daff2b5bc jdk-12+7 b7bd7b5b2c672c1d398f89b6677107b853898fed -> c2ded2245199098d0ab6004e64d635d6468caafa jdk-12+8 711e3a9496c36ee6526e80b70b79254c5141949a -> e911a5ce3929d2766f2b9c7e598f1f3bf3224a6d jdk-12+9 43d0d4542fa8aba9bdc46a0d02ec364fd801f3b3 -> 754dc1754b2e05588a11152025520164d1ef9371 jdk-12-ga 186859863e228bb275e67bb0205b584d1c354e78 -> 811cfcdd439b26cb43ef94a7a026140727dd8e7a jdk-13+0 11d0b5a7f1fd13c349684bfbd3e3afdf9c83373a -> e4046a86a60f2b5a83bf5eeafaa53e06f96131ab jdk-13+1 16a775f11730f4bde21fbb505518e23070312d9e -> 7c7ecfd4b91691dbb16f64fb8040a84d79e3706b jdk-13+10 10a1295e4a726a07507c4312e3b0fcb443fe8548 -> 882ad1e7a1ed6f2d90078659f392ce0b052b0937 jdk-13+11 11cd73a47633076b7834905cf30ab7f6e28118ba -> bd6bdb77acdef6be54e9eaca2fc3b15c0a5ffead jdk-13+12 b82f0ec390181786c68d8a3d93eed2bae7e952f3 -> 2c1f42e838821a5f7f3cbc8b52e9d93e18e1dc2d jdk-13+13 fbc5f8305e30af5d11ae09dd10767058816f1ff4 -> 00ad0322ca5f0ce2446fe0848e1f76ac3d060502 jdk-13+14 0757b7fe131b0d645c5b7cc1527eea928eeb665e -> 1b7f90951e62b0e6109d7601262a3088732d8d1e jdk-13+15 26a9614460cdb31eb714ddd22bc951b19c0dd338 -> c9761a2537221aee7148f485aadb33ef407fd9fa jdk-13+16 58d54c2afdb9276f5ce525faa01550f20b7c1e61 -> 1ff0bcde4e5770b51635eed1e4246ed0c913a123 jdk-13+17 0a9a39ad5607c506c5773e5e1c32c1fdbe090b28 -> f0c7ac798f82bdd483f17cb6294d33d4501de334 jdk-13+18 5d4d157516315d58dd3ea82b64c677cbbc66b7a6 -> 5297738e3f3ce70f505f2a6453d4702f7ae14b76 jdk-13+19 f5fcc800b587fa51ed41d4be6735d42fd7fcf571 -> 8a761e6667eb67930cd0a269e15432b17d03326d jdk-13+2 6cdc029b59c82fc107437c7897bca89648af8203 -> 4e8d833bca1bfbab67a69519c9916525a17c145f jdk-13+20 2ef24e80bc1f410aa93024c4e4945b1ff76915aa -> 7cd1a111b8892181541640fb7e8675348c41fbfe jdk-13+21 ceda887389ac5fccbd1ebbbec69216c09a9ff179 -> fb783070edb4a64bd2d66ce147eb78a944c63fde jdk-13+22 db75df2c073530d8711a498141b1c7fff7fd9761 -> ea5cfda2e2dbc13913bbb4f5a4cb6b84d13582f2 jdk-13+23 e485f6d8937b16589536a3a6059cbcecd3335092 -> aa3cd722688c6ec38e5960027ae75e6568756523 jdk-13+24 721c0cf4443528921caabc495975f8c5d130abe3 -> 8506b5f491caae26b54cfd1e0c5018ca7e2c5410 jdk-13+25 63959faaafb123be918f1c6d0899d53c7c78a736 -> e84b2c3b811ca2733aa226f04472261a58e7ad34 jdk-13+26 4383f046e34a846340693c438a1114ada4d374e8 -> 7222f2cadbd7982d184eb7bb9b60c5e06c76f0cd jdk-13+27 b4ee3697e966f9144fdc5382e95c4c11d782997f -> 767e987b2308453c67c49c3a8a3170f307df93da jdk-13+28 aacc9de390a04aa423bbc200c1dddc0be859beb0 -> d41571ce957b6c4acabb58b3d3479265849095ce jdk-13+29 03d48f882dcd9f3d7f5c06bc6f049c20cecb2975 -> 142fdf203f146c71f65578bbb982cfceadec90f1 jdk-13+3 9fa337579561bf72cdbaecd02b3e68008fb26485 -> a688551e3b70baff64ebbdbf64d495bebd64e8ce jdk-13+30 d84b55cc559030419430657c4d2d6f376ab0ed3a -> 30833b4ef182aecaea1f7203c85f01af3a107951 jdk-13+31 6a1e4e38753342b2f1e6efb168a20e8d42426573 -> 3d21be4bb1a65ea5f52d58ed7db2b183f9e2bdfb jdk-13+32 e752c480f4f03538d48bd78f39a4345a85d96ad9 -> f33ad7469008f06bef62422c0b44cbc454721b55 jdk-13+33 812ea1dc22a62e17d9f497885b006d801642ef45 -> d2147f122a68ff7dad467f2189692d7a5dcaa994 jdk-13+4 d0b301aa80c3fac87ee16d2c70bb2c4a314f4a55 -> c616d2c467cf135a769f5815552d70a1e7c7ab76 jdk-13+5 4a0a76ca6dbf1fb29a788ad08d5c8f4ba9e5d0c9 -> 5d4c3054372e8130b556db2fd5ed0fecd9aafb04 jdk-13+6 4a4f29de0581b8e1d91de31b81d45da48d581d51 -> 7bf45f7788f3e592b022ce5b282fa2fd1df9cb41 jdk-13+7 fc914d6b576b3b0326ef568c3d54568bed3b4506 -> a5018571f4126fea173607bee493edc4fcec9b43 jdk-13+8 865a6fecaf1ce7c8871d6c66bb7bdc03e1576c84 -> 0e6cb38e885bb31b05e0e6e20b052ec5d1b63b1a jdk-13+9 f33fb0805914f4b8f31851d7a26befee86b10f8e -> 604d805e6ab31f12c223a8e56e221e33bf2bf5fd jdk-13-ga 6dd4feae9d4b3e489dcbf8189b5912bb8511be17 -> 0ad97cfaff032eedad27e6913062190b28d90142 jdk-14+0 3631f9d59b7c0526aceccf8439217d08f5213093 -> 0d4f9c3cf08b1108e3f1f61d7b3222fd09d3f131 jdk-14+1 6098f7f85fe0a7226550f0bb90315f7fba72ba64 -> bc99303c2737d15917be7981bfeb4e476615af72 jdk-14+10 b0c8e05a47d6574c76ae40d7f696936679c83ee4 -> 2413f67fb9f183e8fe3267e7f9dc97bed8bcb904 jdk-14+11 76443ec6209d1040b2d505e15c3f8653f714f41f -> c6c719427790cbcad26d4448924b865db44fa593 jdk-14+12 1c9579a52248bc108f36761ed220ed8b3565fbf1 -> 528d85f386e9e944fa9ff3ab553317e0a98dbbd4 jdk-14+13 3f6845176db0af036cb519810e3a5b71182b90db -> 8897b80a2e56a6c11ca305903ce2052cfcbfc2f8 jdk-14+14 aeb41123e48be3b76878d9becab9faf33dcd536c -> b9e6e91b985767048fcc7d3de485eec6765e3427 jdk-14+15 f65e35df3301d99edaf23c1c5df59a6d08735ba3 -> 8af492815eb40e377e41c1fd3becc11c314faade jdk-14+16 efd4844fb8b2f357ace05570de24adc192a1503d -> 6c7ee03be862179f7bcd6f71aca7268714790580 jdk-14+2 9f41b59a4ec34354234a3145b862502a7ef14173 -> 6c604f0f5872d019062c4014ac35e13caba290af jdk-14+3 201091d6a571c71c2e6c18429a8dced661342aa2 -> f8156701be3c5a299b7db0f602b20647c0393756 jdk-14+4 46c512285e4c67dd41a415ae5204db0c645480fe -> 3f40fb49ef94b3219efe51e21b1cf95b8f6908bf jdk-14+5 f4c5b98f59e7f2c41759d71e07764944aa93a8cf -> 1a8d4850384e564859b22872a371f36c6dcd6722 jdk-14+6 70ad7e414a7628c9db54e962f311fad5ab73867e -> 9a30bfac2500f6fbadda8ac8b9f4d7b2f1b165db jdk-14+7 56fd2001d499da9f8857446c2e035658adcf8433 -> ff6547d9a4e125c06ef686b0dfbe56b3591d3e39 jdk-14+8 5369eba42050d02626cce16a409ff370b81cb084 -> 4ac9e301282ea83ce5aa7c45d50eb847298a3dd9 jdk-14+9 ca754e2127de528260dc2689a7bebb23fb4b389a -> 93572b4bb6104fa691385825fb7a7f6fba42a185 jdk-9+100 90b490cd9b8872b8ab2b9a4ef0eee9cbf8432b66 -> 1582a7e598bb8b1823a5c386b801dc44a1d25249 jdk-9+101 35339f91ba3f32b115e8da2bb98254f957a4b663 -> 69194310cf0464d81d37d8df03e38fc3d2710579 jdk-9+102 ca759f0cc17e9f5d15045db4357dc39c5f36739d -> 6615f036e258e739a2abb71b303790064c4734d3 jdk-9+103 e307b4d912561beccdcd7b4e831a7e85df454115 -> 3a3a073a2da66d9e18ed4c4d19b92d09240ab090 jdk-9+104 3146062e79ad203c11026b41940037ee027b358a -> 4e88fb28c6b1edc8d20e445af39149e3e23d1996 jdk-9+105 282aeb1926ee8dc9673a77b3ea2be94d80f6551e -> 4ce5077f2b106588dc552715e66ad7023cf1eda8 jdk-9+106 b88d654a03ccefabcab190646a89d57d59eb33b1 -> 2df2831b8e08b4c1300db067fe80cf3af0ec40bc jdk-9+107 eacfce97814ff899382f666bd577c8260ebe995c -> d0db872057fbf050ac8deaac7cb47a55712f7482 jdk-9+108 e9823377ac47df21d261d81a6f26d444049fbdf6 -> a11e025c63b93c65781f55c53b7313bbf7c92875 jdk-9+109 d0a6f61a1ef4ab17df284c79742e6ade65172b59 -> dcc8b52a59746b20736d9105e8e0de09857155df jdk-9+110 1fabe19e8b3e631aca11d971dec3221270ca6a05 -> 8441913a0b27212e660ff451eda2370188ac38ff jdk-9+111 3b697686b777177fa0532c3ce1e08e2c7c51bd97 -> 88c5f7382d4ce0a11e92a61c4e3d587934ddb881 jdk-9+112 9cee88d0babbfb3128cdd70f3eb3af4419a440cb -> 778fdbafa31121eb5f1bbcd78b49b9328dd2c7e3 jdk-9+113 37562c132d6fe180a0a7e223520e7b879b7e8045 -> fdd70c9fbdcfc82f251b1160542922bf2cc83d39 jdk-9+114 d846cf6f1fc1b92768fb11a29b2e4a23586a55ed -> 5937ed8624520c254f9399f2a65ad94094aedf73 jdk-9+115 60871d264700b27a04a424bef986243ccfc9afc3 -> 564d309f0d310c084ad2f98f3abf298c979a45af jdk-9+116 8618b5c258788836f521df0b83937aa8978b8c54 -> d5b77b3bc0fb4bbc5fe7f30deb061279eb419e4b jdk-9+117 79d894596b44ecb959477253a0484674af4f1fc8 -> ae90286b9fd00ae17949088dc64f66db08cc98cb jdk-9+118 8cffaea43f25b980199182bf0715d4282972a385 -> a521614410de91f55400a6e246c9694fc148cfb3 jdk-9+119 3f4b3a44add1ee1541a8c6f986e18ee10db9fe5a -> 04ba9e69a4f6a09d5f74235ffdfb829d5cb5d998 jdk-9+120 4e26726c3eeea2aa4118ef47fafa63ad2b3737f4 -> 4168d03091702d5ebc553bfa0c8e14b0a54359dc jdk-9+121 17459968aaee8dc8fd7ac6a33f4fa9722fbe23b4 -> bea448789d1e3bf695d33094adf7e6b39fd5846e jdk-9+122 838016064070260114b52cc1bbea7ee9a383626f -> 0422b80ad16d16ddc1456742b0ae2fbb7cf0df45 jdk-9+123 aa6bb5b359436699b875f193805634e3650a4f3f -> 37f7bcd6d1f8324bb153163b5c754794d2526f5a jdk-9+124 b231bd78eb64da089b23c7246a72379935042669 -> 1e848753437d25fdd0590d3ed9b46328313d4a41 jdk-9+125 402fd8aa898af5b52263c74493871bde83c77787 -> 53a00f16ec6652ea85d7dc381fd38897460f44b0 jdk-9+126 2672f6889ed166a8833bf11d4df304a62d85996e -> 747f6bedd64e86aada33da154dadf2e57db01902 jdk-9+127 5cc5e06ca472f8e7cd185fbf17a7e1b3cacf819f -> a2c7e6a714ca7b2e5a50787035ff14b3b678d94e jdk-9+128 7bdb3f86c3d1c5664e399f6e754380a6a73b2dc6 -> e83a1980e69679b58cbfb906cb48d538300375b5 jdk-9+129 17f13bfca752d9c98e734a4006e0326e69bd90bd -> 67593f151245ee408b03c4f71525ebdc301a61e8 jdk-9+130 6d738a359038b6dcab2bf77865a4a219c5ab71d5 -> 10a78c405152f49db1e8d25ca7b85bfc9d0f4490 jdk-9+131 a646209805a5f0ada8fbc73a939a0e8119503433 -> ae5472b20f020ccc4cbb24c920f9e83a85a335d5 jdk-9+132 735d4938261f5b27d7ba55425103399829c55cd1 -> 2806304c1728c7824844312872529797002e7a83 jdk-9+133 ebe3c1513f72f108ca684c2bfdae5f5954ce5322 -> 1ec5b887d12580ad7a8d48618bfc89e7961662cb jdk-9+134 7d57b04d709bacf20e26952a7d1c9883e5a5aa08 -> 4cc92828a5b6f8a837e70a9de3b294b5b629f249 jdk-9+135 d64fb234933d3f90cec846bc7db9fbb6b05ab2c1 -> 64d8ae2a938a71579daf9a5c74e908a1d23784f1 jdk-9+136 f75ae7ae42f4dec9ece61c46f6604f55b9693b8a -> 188443a1cf685af954f49129759ab15f1b280ca0 jdk-9+137 ea6e9f0fdb3268f244697c3367659d5a3ed4b434 -> babb175caba72b0275c134c4f5d20d6949fb3a4d jdk-9+138 7e1b45b7954cd11131ef26e7fe8e187ba4d1cbb3 -> 111a602803c9ca87f916513bba13caf153c7a48f jdk-9+139 ea56ded9135632f09ba53053420c01be4623f8d9 -> 2c95bd4634f8637edf605b71e0a56d8c7fc7a698 jdk-9+140 7d47376e25e9a9511d1af8cc81183ec779827862 -> 912618bc20d708c9e101dcbc6bbfd5eac518306d jdk-9+141 c4a7f63d1398612a1f332c1d311c36ad9f16ead6 -> 413af7e621ce90e1cae041f84fc6d88c668c2757 jdk-9+142 226f74d2dd0c8480c4d335215b6b164309e02407 -> 3af5051c95bc68fc3288379b2caab2d74d9f510d jdk-9+143 747949a18c3081a88ed7a8ee690596f521dee921 -> 18cd9deffb9334c6d4de4170d3466c7e171e4cc1 jdk-9+144 0c8e590e23d2a474f4f416ffba95f9d26b951947 -> 0ca5855de1e081c5d05cdca36193d1ace0851f7d jdk-9+145 b008ba190ab415f046492979db245192f43aef40 -> fed65b0cb6e5152c7e6825f2b568db7756412ac9 jdk-9+146 e9624d52b0387bc94e2be63694979bb385da9088 -> 4264d788f4f06589935c791af4d832285ead63fe jdk-9+147 99f28b259eab298e4d02edd3bc5e42dbf7158d8b -> 693f974b82632f0c8f8f7f53c336415c15e395a4 jdk-9+148 dc0723fcaf4cc47767bb8f3514ceec0c2c8274a9 -> bb94041006a84518c84fc4ab19a56af7a51fd4c1 jdk-9+149 a28a5a66c224627dc543da81c5bdb24d84c6bc0b -> 9aa750b64d540d41c089c3aa5869d6ac46f06f1d jdk-9+150 f65cfd71515d2dca0b803708be4e88c14a8923bb -> c041586d1ec6f3e1ca4a0cee726578ec1f7477cf jdk-9+151 5819b4b63168301a92783c899a0e4524acb13627 -> 0e1605d316a81f856fe74d8b15d41f2a767de401 jdk-9+152 c95f9b15617644c6428e158420b0e39521dc5e37 -> 7ac6cd64a404e4a06d2e14f8e6094f3ee6111957 jdk-9+153 5c68ce693feba27360d2b68c2d32e5768258e8e3 -> 16eb94ef61f32bd96e5828526797fa5459823ead jdk-9+154 9371fc8665d33b24fdb5a2eae1d6ee73d76e3382 -> b3015bc86a57a81627bc1cab6ffe6fffd483d071 jdk-9+155 9e0113a5627cac2a20bb2a9d153569eb13f955ba -> 530f37b6fc04de413e3565757bb0f8e548c9b56e jdk-9+156 b5547fcda52074a350c7d54bd6e572b6862227dc -> 8bd9152968ef49b41449cd6c87cb89c5202f592b jdk-9+157 39da0a7285df7d9ceb27d411b997c67ae63b5ee9 -> 38701507135dab7863d04fad29623127ec5da86a jdk-9+158 180addab4717ccf0f80a6df8ef119b9bd0fb4430 -> ffd4fd05b24e852a41a43b73a94fec69a51e0ee6 jdk-9+159 c7f44582f8d4db5fa7db51421b64ce7c63577d49 -> 737886208796fa017c65227afb2c813cb482f855 jdk-9+160 586d647648c407cc244902f9d2ee1a9a02041ace -> 85d94b54b00fece2270d6f3c1895b3c0b86a6183 jdk-9+161 4ef141a17fd57b310cc15b2ae00740e647154c6c -> a959851fb040363b5a9dcac447855e0faeec2d6f jdk-9+162 2f839735abf0d00845ce0efcc6029f9bcad31b08 -> 90b7d6d9a9001be7fdc373418142dab2edad0e1d jdk-9+163 e91902ec1629737052873a739d70ba61de6f52a3 -> 0a91adbea47ca754983393773365fb54fee7f64b jdk-9+164 d03ec259dbcf2733e3c2085a53392dd455d5a238 -> ba5c8c289bb8f61a8e2e54b02c3c2cd39e28a0f2 jdk-9+165 34d6c22a3d0300b3713eca39eb8e4520f709d787 -> c6b7ae611e14d1f128f21a786abf647b9ed0b031 jdk-9+166 0887c8329c878198b564fe23b9386b438b070256 -> 816e9b4320a4a4960cda934bfd8e32419f3962d4 jdk-9+167 7ec4eca7dddf6c05e8678d83671d6657cbe0ee01 -> 77acf91b9276326379331f8c50656e7d9def7705 jdk-9+168 b3dd8c5baef665ca6767860a159c27fbbc9d62c0 -> 080713b05a306ba7d7ec0ed8c0bf4c019edd45a9 jdk-9+169 4695935c0d3494057d3b2b297d270e8ad1636e38 -> a6185f03faadf4b8a5c399009fa4eb198a230932 jdk-9+170 91d3be299ce091e3e56b6e44b454d7e0a2ba62e0 -> aae92d1b795fd5f29dd2702e44fb1a977282ac74 jdk-9+171 ca321075f99d483a6787764e1a161d8576ce964c -> 24d55cb33ed010cfc6ec77151f33cb90798c21fc jdk-9+172 a21f4d5cb43bd0c7015b60ad3dc3c5f8102aaa55 -> cb5d4c752c294b4a6079d01b055a811f4b833cc9 jdk-9+173 0d928364c3635ef2f231e1cfb7d69246210e59ff -> 4972c343422f0066c3b567944ec56c55ffa2ed24 jdk-9+174 800d5f707abe4ecbd09e7decb384c9584db50d40 -> 0e9dd1bf210351e5b025cf5e7d2b4e31590cc9f6 jdk-9+175 55336ec981073e513b9be3cd20697226e0be8cc4 -> 492aa438be3c667954f868c9d285103da6cf359e jdk-9+176 ccf12ca7f8384f3a882607e13acaa3302a834ec8 -> 004c097c61970ff6ba07f5825a8c16a4fdccf286 jdk-9+177 3857dd9f2da2c078167b19bb13da1460d8a890e1 -> f53ce208f9d5e1800d5a6a89544ce82f9b28983c jdk-9+178 34c7579c3a52a707d997f900e3243f3a299775cc -> 04fee7d7e5ae95d6daa7f7ce68523cebd4ecfe71 jdk-9+179 f07a227b28ccda378904a78921ed44ce35312b86 -> 24f571942356bb5c165da89ba1fac94371705c36 jdk-9+180 337df1cbd7c95e5b3ba3a1ca3be49be4a7c96ee3 -> a51eb972b7ef381d66cc298df7fddd017ce58186 jdk-9+181 de0dc330e746ff6ff04dc0a9c608a57d8369e5dd -> 7cf862ce18a1b56b8778f32efdf572b5042dc364 jdk-9+95 fda18e1efd0f3da67db4c2913efecb1166d05afd -> 7dc588ba19877cf6cea996f63a18b5275b99cb70 jdk-9+96 d8bff0b78f810028f8245e5389a7bc34de9bf98f -> 2562628672da0bcd2849ae6cc3f9f6a6fcd5ea9d jdk-9+97 eebd51d5a5a11cb9f399af9d58b691fab624c976 -> ec684ad4426fcd8f5f63a6077d536a6d28e8df30 jdk-9+98 bac15ffa10c71bad871e71fda56010698237570f -> 36cfa7f2cd8b3e46b3e81f181e0dcdc1e8526c29 jdk-9+99 d2fced23a868c4827e35ea46d4ef3ebe486cf065 -> ce43713cea0a0416abe43cf6c21cdc49fe61fef9 jdk7-b100 a9ec4ba08a11a7022409d139c3bc7f2540c5ecab -> efd610bdd1bfefb5fec3179e39f7b7abec934892 jdk7-b101 aa449ded7b121719f2915cb50e9cbd9746e9985a -> 41bb883dedc82d6e1382f6a00b7d6db89841e121 jdk7-b102 cb6359464071a93463d94d712a5bd2d9cab95fe7 -> 5ef2431d009c48e564c82758de5875e2bb6b2f76 jdk7-b103 16f5c3c35b33f080006a3a4ac9e666551d859879 -> 8f36543686f0d4b3ce977c557e773dd1146391ff jdk7-b104 c537b4b1b1e2ecdd78c426315891dbc517cf4f43 -> 0a4f8c145553187bf1e6061e9ba1e031b9afab17 jdk7-b105 3acaeaa4da93fb8fc3ebaccf203ca5525d40ba8d -> f2f8b37292929dd4e7ad3f47ba76070f37de67ac jdk7-b106 b5777886d23ad9c104b11b96ecbb70c303588f07 -> 8b5873409cdab86ccd1298050ea1aeec446ae8e9 jdk7-b107 da9f864ef2569251144ea66fe6e8519df76fbf1c -> 669abe597cc4103acddb4eddfa2bc992d9342977 jdk7-b108 2328662f00d7e61a967f594bb0882d0b8979812b -> 412778b6d52bce6eba3af580b676d69c23b54252 jdk7-b109 6996ba108467c4bc3501be4909dd08e2064624e2 -> ad86a3c1408ddeb26d91408b20cce2babb8b5259 jdk7-b110 d3b29a0ee60582faa1d81b067e0315dd0c32b0f2 -> d845d52ae802349532334f5581ee1b5ea46017be jdk7-b111 e6d8ca87b2e6b89c51987642312fd743cdd6101a -> 8f37fc875ee7ca2fe32cb50c6e27ae02b319ab32 jdk7-b112 bb705617fde3bceceea51861a0a4ed7bfb06337f -> 2341024fd83e798d7dd5d597a41e0d65d7c12e97 jdk7-b113 53c5a1eb4182eca3b64dcdb19db01748be757cd2 -> c3a189a0122a37130ca52a2fb9ce29b73841cc36 jdk7-b114 ced824d1fe93b57c91e024bebfdc9c00981f3147 -> 2467ae04daa34a624b247f4f47532956cba1d545 jdk7-b115 815233e2e5fbd60ff3a1d31f3266630df9ad72b4 -> 66e3caaf9dcb14cf80fc8fdaa0909a2884671539 jdk7-b116 f5fdd6243c1f683891ab3f7a396a64f4a0faded0 -> 463eb7cc13b3e154cdd0f869184567f8586db213 jdk7-b117 f8b67e14d91cc772378d25c7f0d5bfd2346927c7 -> b151ed6fc037873e33f30cf216674bb0467d29a5 jdk7-b118 644c4dc41d7aef941169ed459adbe6eacb59a3dd -> d76e2efa929bd6c198b0ac2d9cb7ecd2ff4bb9b4 jdk7-b119 852618b63707ef36486bfc34df35755c5019aaf8 -> 807f8da2bb7dc7f610decf0d160da841ee7b2668 jdk7-b120 c737289c8830c053b66eb0dda96f56730aaff5b4 -> 56bdcc494ce423f9e2a706e66a797ec6a7f52a2e jdk7-b121 7b0cbb1369ded58bbf0574ac07e3332df8ba824a -> 22158d77ae4f035958d2c8eac4a13bbaeffc6d24 jdk7-b122 bb93f57fab25d62fb12938d47618797a1e60c532 -> f4249f693e6dd25ab445032f8c2e830faecb9561 jdk7-b123 e973de8339399e824c7a8ef018eae79b7bd34b05 -> fd0ed100af641d7eb833aa81205675ad491ff03d jdk7-b124 c1a9787b7e16c73df102afa3d4b8131ff8966348 -> 194fd2a8f8b325ef0f49309c707e7786b6775f25 jdk7-b125 d80f5fc35ad5d50e1e61534f2ad9f787ecccf1c9 -> ace234ed336a79357b7f0616fce264c2a63e2563 jdk7-b126 97172cb902ffeaf07e4bf6797ef391e2ce1ed909 -> ba82c6acdb0e6d32bd7d53cdcae1246fe4b94302 jdk7-b127 2ab6230a27cabe48d674c0adf45477d4ff4fadbe -> bdeb6df49744a1ca55f211fa68a1a60236987cb3 jdk7-b128 6f1dc5ee3a53e7d58581fa1e72ac0cc503e57c26 -> 956da41d8cffea06ad856dbb730a4704ba518890 jdk7-b129 f11ed34eb14fb4bf8fb09b3c97d4f8f9dec004d7 -> 51e631d0992715fa9a463e0ef3c9d943bdb534b2 jdk7-b130 96e5c0bdf7aec86ca81860aa0fa6f170a3ccabc0 -> 3c9373d3df3a34bf1e692ef305986a8c5443aeff jdk7-b131 5415e752717a142a2b26d4d440e4f9b0a330881a -> 330b6ca2f9ee9e908318314fbb9c09c3f171ee6f jdk7-b132 17f6776b453bb710c68d29b097bd0d2f9b43b87f -> 5f19ac0afbb570584ad828d3d2fad5f61c714ab5 jdk7-b133 1b100a4dd4760e3eb16aaa6acf26711040a713a3 -> 74bed3ef0e1ed35b99aca9479cd2696479d1f740 jdk7-b134 7d97833b8b9a83fd707ef279eb90ae1030f2c99f -> a34eebc5c315bc373494a76dc3019f7070fffbd2 jdk7-b135 669da964bac7a1460c4160136c9dff2621847641 -> 64f78cd046a40e9a4af7d3af7a8d107246e0ae6b jdk7-b136 b411a9a383b5cfd13d0d55aec47fe196efd031ae -> 4ff9fd0e2348037bb2c8fbbd8fb2b7b1fd286ce5 jdk7-b137 c5e0546869256e9b47f4248ef9fd2908080cf270 -> 70fac480bfa14df49075d241abb3216da117a7ce jdk7-b138 01043aaa1be2d6493888a46285fce5403f4566eb -> 23001cded84e092e5f6aa2e76a3ba211f54fd901 jdk7-b139 52fabe1d5d423fb9f704be6a9f97e4bdc4219f28 -> c6de0d41508a0b14dc0d7c99f8046399b754b6bd jdk7-b140 c4b35fe4eb98bfc65eff6564238d2a2c81612b8b -> 794bdee7df4c8dff9b0468c10293517ed759341b jdk7-b141 028548013bc1be68c9269d727d5697c8026a8b50 -> 1e5e8975f01b04390fd8c6f64140bc20946bc019 jdk7-b142 da6844f28750797cb763d7ba6f4ad015edf41fac -> 47826d25365174ddc966a6dcef521c58e4fdad74 jdk7-b143 b5cd73a20b58c1fa8c101b29d1ebc83c3d1ef206 -> c89735d5cd4388bd4d410d5f571890d4eb71dad5 jdk7-b144 63fe6da6e9a5dcca537a317ae6399fcb6fe3db44 -> 82ba8a6e01a628ed8711a22d732a821ac1740f8f jdk7-b145 f4ebb1378715ebec5d1eaa4dc6dae9cebf415e81 -> db5a9dcc9f9f29ecdf3e0df6736fbc9115cc0a2c jdk7-b146 8edc1f903647ef3e16d9cece4ed9cf35ec77846f -> 951c3e1a01aaf26856a20b0c381b356ca8937455 jdk7-b147 79ccd466bb91350c06ce98cfac2bcd8121adee11 -> 4c18e8f3e93e35d77f2f51b1ca1708bac8bcb828 jdk7-b24 1e45d81ffbd115b9b5bb7cbb64379240e67bcfc2 -> 9b175de44b8d94cc4eb1ffdd9141ebcfbef8837b jdk7-b25 cbd3ff3f9b14a20772184fe4552022d6d339e85d -> 7bab50939039be5f645e155b9ac4d056abbf8532 jdk7-b26 003b63898eb30b65886eba56dcd71292292c5c41 -> 97c1c021cced669d8c19c33ebbe9b6c579a2e9e1 jdk7-b27 1c0418571175d8afb2b3ddb04eee152436177844 -> 8ded10494122afda3c84738ed427779a66c1e0a2 jdk7-b28 8fbc3b4cb74d8430a3d204f4f3cc1f299d03e325 -> cd1004e47abcf6b6a09bdf5ca715e0285662f341 jdk7-b29 2339f448c3d9c118cd7d58699e3da03a6b98d7e5 -> 9e5d9d2db5d07a1481ecf61eeca943bfc972fc7d jdk7-b30 acbd14b31ef1efb2131f4f17db21ef39a86f261a -> ac8631eac98888f58c5489564da769bff3928334 jdk7-b31 adac1160d9ceb34ea4cd79e2c69f96ff02baae61 -> c6ce4bf77c9ceeb0dbd0ec0ec9212cd4e5235040 jdk7-b32 99870969f3f23131112204c378528cbddeddf2ed -> 884fabec050fa169349b7c7cb4aceec581dff9d3 jdk7-b33 250ded658077dd8186c1509f08a32432ab2eeee4 -> 5a415851a75c7608cbb4c58ec8b9474e91defbd8 jdk7-b34 d7aac0055fc3f42726f37d3d72146450fee03723 -> d4f5d536ca4d68d53dc47a20067189c61f637954 jdk7-b35 2c07414f20fa71977645867f2cf558171de9fa08 -> 96faf9559d724880c98940af7e8a671216d46df4 jdk7-b36 04d8a11e27375b5c184995b768604c047a9188a0 -> b87273f30446d181566f1896e58ea66b94080c9a jdk7-b37 9977c9a5637bb41a4ed500bc1a92d51ccaf4d3f0 -> a489551ddee047297daa092d9ebdeb5802c15a39 jdk7-b38 eb8b71c692cbd6664f643654681d5d4a599d1aed -> e46cffbcf32e8b09b461cfec2d02ede0487c483a jdk7-b39 c547d47ad1acb48cfe21b2a98684139e5811ec41 -> d3a70254ca03328b8e7c1ce7c2b81ec5407f576f jdk7-b40 cd1feb1ef75a7e519be115d39b9542d76ac6846f -> c0d75397102ace426666ac42f37072cb24e1e132 jdk7-b41 8405f5d696f7d91424200f4403e92efd509ebc3e -> 7bf378585a58588838ba6d143843a68907fd0fe3 jdk7-b42 372c34073a9809221b6563352fdc284abae0e17c -> d4fea9f8a8fa7196c9d29857104baea4b0c4a602 jdk7-b43 ecf9a9202312003a1cc128d2420a6e8b8958e0db -> 4af814f9a46508986dc1aa9cf99cb9d0432597fa jdk7-b44 422e92cbe72f6b665dd645edfc79bb5a856915e4 -> 1a54172bae772c6f7e9c00abd84e1d1ff184baa4 jdk7-b45 59150ba33ef9bad3fcece7e50403905eda8451b5 -> 422769e492d28335d11cebd18d72402382482cfc jdk7-b46 19a7470c507a7403e3b81a08494b230142b6fa26 -> 54e5a28cf11deb4786bdfe0a7a9dacc4511121e6 jdk7-b47 80c3c650a49338a2499e682e58237635a90b9dbc -> 111b956456ab1346da9fd82271349be42669467c jdk7-b48 fe4e65b9390256236e6335253877aa53c905c8f8 -> 8fd5e55c7b5997b52046b66bb29c92e19a4903af jdk7-b49 38d8cf2680eed7886968dfc671262027e7c510f5 -> 995ff7cb59be7c177d566362f0b3ca6ca7453b7b jdk7-b50 d9beb00643e8847dae9b2f15b0f8c376ef4d7d5a -> c6399cce72f276780e2116f5980744531b0a6a50 jdk7-b51 bdd6d4259d362ed5492a5c9bbbb0b56ab3fff529 -> d9cd99caab6d675d5ee1a6e1b0f998d31764b9cf jdk7-b52 0638e44ae25a48f46698f6598644e75462226e10 -> fca93cf46e5749ff54f77dba67585ff3d8765a6a jdk7-b53 8a17bf5094b0f71be01bf00b88e0542b61eccf4c -> 0af385d2f302647bb3888f42c23958fd6ad25b77 jdk7-b54 24462f60eb4970190623ffbf73d13b8dee1bf62c -> b03b0c6a2154a4ca8ce0c99e1f7f51e07366d02c jdk7-b55 97a41d2b5bb09d0316e7400553b39c597847ae57 -> 6e1a0005ed2844ecd5b2a4e24358540bfb520049 jdk7-b56 ee773eaf54402a06d03b83708687f8eda99f0279 -> 85137260ae007edd1ea14b9cdc6af1b893f17d7f jdk7-b57 4375db73e9f87b88802cd3311b96f5d4e4ebd65d -> f82f3a513bd16122db802d09dfa127dad430abe5 jdk7-b58 e6eeb81c61ea7a7896483b7f3c1b2fd54a48cd74 -> 53bee31d02d9aa3f381bf2d5d51dabe20d9eb1f5 jdk7-b59 fed3abb52415feeeb42337a63b4497f48f9156d1 -> 31168f1b8b98396ec00b9220d5303811fce645eb jdk7-b60 7f963e104c70d099c3e6bc79b8a6c261ed7be2d3 -> 41d9f358754b36548e6b2e5048fb50ae5b2b5d86 jdk7-b61 72ada440747c9f598f3c418064c0f7464a07efcb -> c8035cbd3cb10f6f0b7f04de09fd3cd191d9681d jdk7-b62 428c698aba0e9bdfb67e6445d6e721cc19ccb8d8 -> cd586208c77b4e22d85c49125568dbd515414c61 jdk7-b63 338d8b1b526b383dda1f31247915834de92938ad -> c4bcfc43f9c5338aaefe824de56947b792071ebc jdk7-b64 41975201606f6f0c7d875c0c8abc3ca776226642 -> f9aece23ac937f282c1ef1c2ee553b790b76887d jdk7-b65 d577b315dbb225a95fc0ab08c3d2d22c0135e5ac -> a1a63928026db0f57df81382085cc618ccacf6d7 jdk7-b66 36fdf5706150ee95fe806f52a73ecd59b35afaea -> e08b7e4ba15a36b63f501640efb004fe5837f98f jdk7-b67 c6e9f812947ae20c22900b7eff89c6abbea0d2c9 -> 5a1940077cae9dba048813d509d2ef89bcfb96b1 jdk7-b68 c02d589e9a4c94b7c2719835212a3c0e66cb4bf4 -> 4f03e7978ed7bb68f9aca77e293f795090c478c9 jdk7-b69 de7c21635571140f8fb9e46539832a06a744eb30 -> dc51d5c5c12324e7f56149d729aa82b38c88196f jdk7-b70 c0e1dc11271754439eba100c9c1daff80e150e5f -> 2a38ccab4919e2353ed6386fd854c25f7d6b303b jdk7-b71 3f729b2c86cda5e4c98f3b061b0caa0c37bebad0 -> a1b22ccf58e6d74ce8589164af78788ccab378e4 jdk7-b72 bdc50f279d4e362ea2019158161d26f91153c444 -> 0a75ac9db88ec1dd9433d696cd605adb405c745c jdk7-b73 19ddef1e1989e57535923bb217e30d61cf415e75 -> 0ace9968df934dbacabba0ee45847ffa3fced39f jdk7-b74 d1b442a98e63a4844fa621f00e4633f8e4e8cf9c -> 60145fbfff6148414c835ef9ce262cf0f85d3d98 jdk7-b75 02c205e8e19dc3430723da279d7fcd656b457b83 -> cae9ea4202fe0a0b84c3ba3a4286d3785c3f6ca9 jdk7-b76 ef39a861a205f9b541685f975871f0b36bec6814 -> 375f127b0c34d42bef10a0ac44bf0b25516aed92 jdk7-b77 2abafe6dea0e865e93945e4bd1649d88fde5184e -> 06075f46db0f07ec9839e75d1c4f5f27a6084520 jdk7-b78 af91cbbd718574f043c3c68302003b7857d71c6b -> 499c94d48e4d3cf923aff10dd5dcf541637905d3 jdk7-b79 04cab1fd44cf758afb5aef86f866dd7cf636f2d4 -> 7a59943ff0dd152ee979e2af6589568390e35b57 jdk7-b80 c283bfd39774bc94ffd248b8fd0934d54e9f73ae -> c3121b2c14d248ecd6e581af178a3da05e66c543 jdk7-b81 1f31c4a3ed3b4f3640324a467bc029cd66fa5d85 -> d806fa09e03b29786c1b1776d71e727855a6b7a8 jdk7-b82 77ded4b186c812f007a0bc330da5cdb15fb63fef -> 3594cf726c8b3f8f2a304467ce7c785cd7045156 jdk7-b83 b8a6826db9e0588ac405c8d3ae08c00b4ceb6edd -> 82b342952619d2787843e519097281c271b6acfc jdk7-b84 ebc547f162fb0f6883986fb2e79d75a0155baf3f -> 07e0be28ec548faac20b1ba2064da5a58fad7730 jdk7-b85 0e8d731bf0475ed92361b23e0f46c4e857886ccb -> d4f8aa6d92665bdab465017d25a750b4668c0875 jdk7-b86 7f0d149a84e0d7aa67d54f8b89f883d32f44c10b -> e48bb556d7c2ac32d23e916f46b54e60bca477b9 jdk7-b87 bc183ec1529b1dbbdad6c4ace9fbc37ec35cd081 -> 0f9ae8dd28767d43f858cf18698787a21932e452 jdk7-b88 acd38bb4ccdc86a4b0daa074b64595a9778c997b -> efd4f93dafebaa32b09e7a27f8eb60d55d99ce33 jdk7-b89 8a692ab1c954a8cf60bee27daa63d4551914d1b0 -> f5a00618023720347d6e8bc2b3c675ae277a108f jdk7-b90 515df4a92680a8ddd60e92f0356d5840d95dd686 -> 8d26dd5a9cd3c91d295c339ca3cc3d1cd43fb877 jdk7-b91 d35480d38fbc3d83a3e6f06769f6a28868f9725a -> 01f5980edd1f78ca8a60e08a280f2fbf80b983da jdk7-b92 f1896a491c1c6d493b4733f7f333a0e0d7c0e580 -> d69e7f1549739773cf5213374d4f419a9254ec48 jdk7-b93 e39541ba109eb4e20c0326468dc90645848b3378 -> 1b925484dccfa1a952a3c09ffcda2f1303f259c2 jdk7-b94 cffd05c9b52eec5a7d2713aec785e17666023078 -> 9aaa0184a32764175891f192e3d4c75b5a518484 jdk7-b95 6225c66a97804825955159041221b4b12c388aa5 -> dedb4072824b7b60881f57f6de53a867d4741d55 jdk7-b96 a5cd99a9837b4ba14ca21c509f86bb149cd3703e -> 9039a8bc5cab82c1f9bec78d51acbb72949c5d3d jdk7-b97 682423cd7a7a998e9a7362157d98487d4eeac21b -> 9763c02d42fff23734cf599bca96dcc0e5f07366 jdk7-b98 5424ba8f0180cfeb446637267ff48c7ddea9d4db -> 5b35f0daf2f9e94249779aead0ebad3465469eec jdk7-b99 976a2b0280ce6eb8e56a8aa40351fa7e8ecbd07e -> d0b45eea6f3e6f4c351fcc5a0bfd1763d9823b3a jdk8-b01 f453fc42bc415bfb560cb8cd6b028897d7f2fd83 -> 33852ed5c01906475eba4839854a5b5a39f65309 jdk8-b02 90ccb0a4fcabde933c600d6571acb3ae39f7856c -> a02db6e6acd9a8c2b2aad3d857de939352cf830f jdk8-b03 ca8108264895d7734eb20bf934f06e88fd77ce5c -> fc7477630f94a58df74e1e0ea1a7edc137ef49cc jdk8-b04 b6f90b98671674b67569831649bc43f60deb16ad -> 25af5e82f9f7f61ff66237834b9a21ff5cd60fa0 jdk8-b05 a2b99839ae326e2c4036fdb44b5b8726fdb9a02e -> 4279c95658b930659279147f9569d4e252e92d65 jdk8-b06 613ea29d54d6e46db43eefbe880aecb69ac4a737 -> 1fa8ae54f16314fc34855baa73d6de9da41f3ccf jdk8-b07 56eacc47653861d93e5d63a2ff60d63fb93ee3f2 -> 51c703c885c8bae4ef59745cc1c6db9297e78ab5 jdk8-b08 74e1e50111b2a6083a96275eee97a2975747b062 -> 32dcc60a0764dba8fca0b647b2ff3d50d4a41d10 jdk8-b09 efa0ac8906cc4330bc00e2df8d92db52a04992f2 -> 51b33e55af6050a1cfb6297c0a53aaae4dc7ae9d jdk8-b10 20edb548f0d266c720233b4580fd89a01da5090a -> fda73bc333c7f08de6312f89c620ec232d049131 jdk8-b100 7dcd3249750a938b56ffc903a638c0969141a289 -> fdc37d42f8f00f8358e33fb39993fa807704ebef jdk8-b101 a23515052a9049061ad9483b6e81d9bed56b6222 -> f0431b532429d56d2a39d0c6972be84b899217ce jdk8-b102 ce866b9121e3bd8cb40829fdc3e09a987449d326 -> e2861622725b5276b40d5891c9833cfb0d2a4fc3 jdk8-b103 0e44c50e741cdb080640613dfdf03bf2df07b9ca -> 623d92f31d30968626802ffb3bbceec6b9644dd8 jdk8-b104 817f319d222e5420b1de7885fe98dc97d99f9739 -> 91494f4f152359a82a335ba48266fe24b88b7c7b jdk8-b105 20d5033e98c7b4b68ca4f1b8d1e018c44261ef6b -> f58827194988e5ccddda280ae0950390f6ca4b55 jdk8-b106 bad23b53218377f2837ba67fb82ad16ad9877d8d -> beb501b49ae29f61be0072818710a9d3725c8c20 jdk8-b107 5c0e02338695a91762f2b5e41b65981849866fe2 -> 68e6ddc62e0a13797ddea78883e4df970fc77bc9 jdk8-b108 9300b1ef1dd39e76889f2409e4139d7605fc67a7 -> 450932aa6d03a6ab488aee81961aa5e185138b57 jdk8-b109 44c4a6b19adf7299d0357b359cf9b6b4ea79af79 -> 0a018293a6c9e21745bc444af4b72e84eb2c8c65 jdk8-b11 da4d9392c83b5a6162abf0a61c88d4fc72d48ab4 -> 561c543a67d2d1b0fc4a9026d02f9893e8cba9e8 jdk8-b110 88575397e80bf270631e2f7a86728e94c220a7e3 -> 9d2009d2bb5f2dc1ba023209c610a6ef8f47a0e2 jdk8-b111 41b61b0c12ed99a37fd6833d19672b77da5a43e3 -> f5a5cba1f0b90138b295e07e2c11e6a74a4d8031 jdk8-b112 5d3f6ba2d0156e18293aa90430664a86874a364e -> f98a74d021bd2bb406a457672057d944666e9c4d jdk8-b113 a3abb67c781037467059cb5320c5b5a94b8c027a -> b3141c3a22e3b4dc867e5c0f1ed8897e944ac745 jdk8-b114 dc2f5b4233671cdd53239386b1f9316a26298982 -> 827dc623d0f8c7daff9b19914fd68e6e579f82f4 jdk8-b115 dbeb70af9c092ebd0aa4c29c634da6c3faa5389a -> caddbf8b5820bd6d3d9362136b534a66d0d62570 jdk8-b116 2d5f045d3ec2eea844b9814f07b167cfc83a86d3 -> c0a37161b8fe781ef25ee871e3e4e940f4aec3b6 jdk8-b117 35d9311717f434612d79825ef4e15f49500f8ce9 -> 8dda2f153e7355c2600b4ca90b841616d7ca6b24 jdk8-b118 458ede3f6303449a69dba7edc2b32f6a9d30ee73 -> e0e24f9d0cf5ae728b3852caa88ca58655ff29a3 jdk8-b119 bc7ee8bab5e513a139a6c2f5600aca55553bae04 -> b0b1706af992194fb69c0b8f83f8d3e6efd69eda jdk8-b12 bacafdf17e2f6867121bab13c5ff346923a26d81 -> 9c4e14e02ee2fcacfce94a282cc2bef7286f372b jdk8-b120 84dd4b599bfb6e38f1f737526c2eb98acc15f866 -> be9ff95d58f9bb8620a11a813e51fc88a4d54664 jdk8-b13 d8aa74d8c445a537cb43926509269880735ba754 -> 2fb5e812337daeb99b03666ee758cd0e696290d9 jdk8-b14 50fb5839e9418921c68c8857b657ab9c8a1a9f29 -> b4b6499c23ffc5dd76b9ae5938626e81e6be9891 jdk8-b15 dc0ce599dd741f2a7027bd38205d7db84b254aa9 -> 8900fe0fd894cb14af02de4cc63d8b791c45ede5 jdk8-b16 f1dda35b5a338c755d16ea664474bfab7c31c898 -> c1a0394aa6a7c1224e9b210f4396d0d6b66799a8 jdk8-b17 736a77ff30d0a23e8eecdfb5c6f45a5bc0b6e2a8 -> 058ee1c7d8965630161fa4b5b2e777f2cbed0968 jdk8-b18 36d63d22596b5b5c7c65fe6fe4e2b57f678591fb -> e1de342f56e3c45b731f2b7a93113ac1330e73e7 jdk8-b19 7eba476bcf10eb89cbdb8f6388b02a09d1370d91 -> b5b97b08fd8f84b9012c1417179f8fc86772fba9 jdk8-b20 24d563c53d379351a5ba1d4efd8689b1d35987c3 -> 1590b85bb87b8ea2594a6055f0530376bd44cde3 jdk8-b21 04396bebcc712f1d3d0100f9c3fbdd04ab1125a8 -> 228e5e5fd11137188e3cf286934caf9d4236270f jdk8-b22 e9e7f6451e236115d4142c6852031f4f41bd5d1b -> e54520becb3a80498ca8e08c5458bb22b0b04d60 jdk8-b23 0f2affe0d7d67040a757ebd13d2bd3749ea2f293 -> 0cc6a9dda6fe05647947debc5821f67816c66bac jdk8-b24 f5d5f3cec21f7aa6f143b009359c85b6a045cd58 -> 83ca3edc0bd1bb85cefb3f4d54c1fff4e5928703 jdk8-b25 b9467b4949c59e1bdf8483e3e4beb37e7a7afd03 -> c9a34851b006da5e806b9e5fab993e566558e2ea jdk8-b26 a0ff209c886a0174b17ccdc711fdbaca5bd99ff5 -> a3db0e1600aba0268c2816380cd89c6ba43797c0 jdk8-b27 6d090149192954ccfa797e626b1c49c86b4c3552 -> c0d7f825f41e1ac2f31cdd1941d58b7e4c3e5a26 jdk8-b28 36ce326e16f2a039c93151e8016e233ea595aa2a -> 62b5d4df52d6bd43cac7ff1c54ab322980e5d9d3 jdk8-b29 64a826a01003c78e99dcf2cb3ef6e8c0f94ae75b -> 817f23c52cf86510b41f5d212398365ffcf1edb0 jdk8-b30 c9e395a39ccb6bc9adcc22458b3bc97003cd10cb -> 3eeedc2818cfcfaab60a500737502935f997c501 jdk8-b31 0833953b725b870658245e88e6e5ec94c450d54c -> c3bf3142941b5fdb259e140d7becd8ca5915e4fa jdk8-b32 f58ae5423e5974b8f0ca7ebd3e03af1531cc932f -> f6fdb895dee84338c9de2e8a9850b516611365dc jdk8-b33 1585d730b4b5f397de53ea2f2902f00eef93091d -> 0a5ecb4af210a6821e0b40c8b54895dee3957c70 jdk8-b34 b5071ffa273658f1da2e51abd0beb74be6b2fbf2 -> d262ee9294a3eb09db871f9630e0ef1e405b826a jdk8-b35 36e1d59e40f44cf42ab1c9b1a62bc2ac2c9efbcf -> 399f3e012999b2bda0a5ddf98440f3455670f886 jdk8-b36 44433d2be63356e0a6cddfd7fb94eadb0ee30ec1 -> e0c6075c80c84de7cdb64e11622ee84c15588318 jdk8-b37 043ace2f1b0dcea3ea025b244227725b5ca4a079 -> 076f99900dc9251b72cd599c7bc9abcf12ea7649 jdk8-b38 f063b44a3a919eb7e740f066ebb50833c9b9834b -> 13a921a59bba0dd7821f2e4c11573fc4cac96395 jdk8-b39 543fd1302bd79d271454f140cf4996cf5445e9c3 -> 2c970e04d9cdb83774a3fc7c147b19709f237f8f jdk8-b40 f3b5720d4bafb45ed5520732a55d8ca8d12e7be8 -> 0da3d5c13df505ba47c661cebaa0728c8ce84cf7 jdk8-b41 2cef9366d53602c51d0dbc34578f18c59f03f4f7 -> 703f7c42a2fecbeaef200315ed1c0f9425e0c8d3 jdk8-b42 a8a86a87d0dc23c26356eaa187173eb4b146b260 -> 5b30a7757eea0587041b3ca24f351455516c32eb jdk8-b43 32312c00c51cc72b11f7edffe058a2a4844da355 -> 5cd8ae46b042552ae8b3f73771e92c20c011373c jdk8-b44 188f044195409b8d540f664d0540a30eb59ef831 -> 77b1dd9260e9ef426b87f5d511e8a62fcff3637e jdk8-b45 2c6ad0c77d58e12e7f3abb6e6800ec5ffaeef7a9 -> 2c8668b2097f10ba8c88187b2462f82a2eb330a0 jdk8-b46 ebcb72bd1f536b99c36204ca42251d32257b37c2 -> f52e9db9cf9586d4a13e5b48f4e6f6a077f73870 jdk8-b47 8b5609de00723194d8e0b57861f8692ad4d4b796 -> cb201a6450a1dbbd62d3c2222a4750b556d39323 jdk8-b48 790c0eaba30a0a2a666716d06cd1dbb22091ea60 -> a42e922abfb42cd7a94212381eda86bd797b8105 jdk8-b49 13b7c934a158453cfd6ac62f1f89122b8d8c9429 -> b0e8e30b0add732280a547be984a3cf9a12df68f jdk8-b50 2fd2daedb4e8eba66e74ca92df036a6cde7db9c2 -> f390330de75f3edeb05add4333cf0ded4d0b1ca9 jdk8-b51 e6dd3f719c9c0faa9f2384e3cd526bc581117d63 -> c7b70a66bce35e1bccaafa389c804b505a9e4cc1 jdk8-b52 3ad06e581e8ca1825c35970a5568bb793ed981f3 -> c280fe5b6705e79c24f0dd0e93e690b7e5691796 jdk8-b53 18653ab7b981e71d4d4d4e86a779f8afef17f635 -> fd59f3ea44435c85a06fb0845565c76824265a89 jdk8-b54 1586d3d837f965db537f7a8d4d2dd77fdacb8131 -> c4c77c0beb27be157948a266de74f111277dacd9 jdk8-b55 92998094eaaeaf7b587250aa6eceb5c145100770 -> 7de35fcb4e06005859683edbd4b04c9ebc637bb2 jdk8-b56 232a0f9fde0d929b8aa2ac5c4d042dcc07caa7be -> 8886e35f0cdb0ecb76c23c7aa66e7f95ae865214 jdk8-b57 b387235ab2fe5ab2d0cfec6f7249eb8060be3550 -> 55f0abde6d1bd79364fc2130b2505856dade5132 jdk8-b58 015d62de2de1c4b22538a79cb025c0a0a21bbf2c -> fa9c6eaeb4b60c0f2604d4e09763e9776b20b0e8 jdk8-b59 90975997e732a4835d83fbcab87e647fe90a27af -> bd56a1486356d36b5f221cac91a11d46b4e3c8b2 jdk8-b60 e25a512462fcf32d67c94f885abdefd3b36ccd3e -> 3fd7db6d40dd794b2012b2a78bb83fdada8abed6 jdk8-b61 20a1be5ee77dbaf9129fa4c530a1fd4659d1830d -> 43de065837a30359690f262e6a9c6386a3110a16 jdk8-b62 1a65b98517f28497491ec520f806b1ea07e5c5fe -> f0bcc45527caff96c77894f3e5ee69469819f00a jdk8-b63 3dee964887dfb65cfb3ae2cccb2cbefc76cf8393 -> 1a94953a17e39b6f80370aa293116e326a18a477 jdk8-b64 3279a0485eabd4b519e546f8d19dac7b510a43a7 -> f40577fdfae1064bc26309c56eb00e6d00a049c0 jdk8-b65 a840a2d3e6c8db305ed273af6c8da56de7de0806 -> 7b2e4a34c59908521085550fab7341b4df551e4f jdk8-b66 0e2d6fa1b512a426401bc06c6554a8f68818b159 -> ab2191e3ccb18cef302fb7c125488067dd9c11af jdk8-b67 c6b75137290f489517fc38c84d8b2e0af9fadac6 -> a7ebc22bb6d0ef7ccb66077e784bd8c779271bfc jdk8-b68 27146022921c879f472108b5ebea36522e31c390 -> fb39e375097898fd71b5cc9cef873955b0c71338 jdk8-b69 cbdece5373304b1baf85c7738651a466c947bee0 -> 320e1e9a1c9db090e759888fc520c3865d94d517 jdk8-b70 03455ab9e0152aa02b65013b1392694a1694c7e2 -> 01fdada0af68f6b7a0839840f1db3b40bfbd3b40 jdk8-b71 8106ebb7e9564e346357d6dae7d072c0915d74c3 -> 25da6dfa22f1aa25a85e78926487cdd8ef760412 jdk8-b72 ba4c812f9c35050512c3ae5d489550b57fecd6bd -> d34718c67e882dd5b5048cc0f7c8ecbdf7e8852d jdk8-b73 ba6a8fd6218f6ce65bb81967e8d2fb6b40da7f4b -> 81b4e5400b4b6ed8a755a2993dec6cfb7487c5a0 jdk8-b74 309b6a75fc629c474c1c50c2f1ee8d1d40eb31a6 -> 9df2fa988fbd3cd25a0bc3a016b93738f7cf501e jdk8-b75 a681de848746a46084cac900b6b65aa602ba9d38 -> 9c8df92261d3a50ec11a7b743891f3adf08c7639 jdk8-b76 7498e74b341940f72b273d51a6770670d7b76be9 -> f8fe95d85e22efd8d55945acc30b4ef5a7fba9d7 jdk8-b77 2ec230b2bd4e531d74e75e27dfa0e16e9c2538d0 -> 3fb074be9d7474410efd47b744fe51f04a2ed4f8 jdk8-b78 0ecc3771452dcf0a3f93e25da4f72db5aef80df5 -> 3ead3a74348f1687e7e903ea4346d2f820d144fa jdk8-b79 22b609ebc81312bc8ebbb89d5616ad859bd57c70 -> 76c445339712be147e15e117b3a75d03d827c7f5 jdk8-b80 6ab8d2452379cb0f766953c456f5d342fd6e2c95 -> e47c4ad33dc38b3829baea1114ed42a3afa6c44a jdk8-b81 6e2ad6218e18245e2a3ed506c2c15ab354e14353 -> 932d2c02021d5850582651e8d1bcda95c13cc0c7 jdk8-b82 21927dc109c38826e0c9000ecf25c8f32b39a2ec -> f1c64c13d3eef0308782af9591bfdf344ff40587 jdk8-b83 66963723e80067a00c1630bea54dd8ee7dbc4a4c -> a622c1980a9d917793f357b77ed4b27d75d04a9a jdk8-b84 88ac15a0cce8c640c14f43529f841dfc06bb8c59 -> a532e44f19896cd738d76f436b88817e73279a7c jdk8-b85 522b13175ea71ba5d2ff529e82015a47c1a948a0 -> fe8a12dc5fb276ea1cda6d31c03dfe52c58ee3ac jdk8-b86 6d055467c2c4b920c2993e3b4cb9ba3ab35901e8 -> fee6f44b8b104c5af10eb150967d15b42d87f073 jdk8-b87 7b8678decd58a1e6a6c7a8a9b4570075d1bbefd6 -> b0cebaa4bf1dc1e2165c91878e3d7caa1578e4eb jdk8-b88 cfdced118a7f0f6834a1bbb53d47459344d0e5c6 -> 7550f3f8ac4966ce76d90dcb57e03fc77b070c50 jdk8-b89 b853b84f4ecb6ae4d5241480d8c5a030be6802c8 -> 8633970b1c505c37540b2821b01ce1f3d982f352 jdk8-b90 5c4d01b9ffb7e30ecf2ca87f87cd323a8ce3dd35 -> 4dcb0cc7ae2c2bc8f6db1366d8e1877ad7fb8cc2 jdk8-b91 6a93438cac075ea6872a4fc8bf199e1614eb1a36 -> f17647afbae44da697d846b6719dffc5da22a533 jdk8-b92 1f62c87b7429386240d72474afddaefa400bc128 -> 1b3d50b7f19d59ab6e3e552cf00c30854227dbea jdk8-b93 25afba3a61e390608bbd1c3ba0756e62b8d5264f -> da575ccd3f5e3f063a18bd89c7b9e49c9fb1ad47 jdk8-b94 d792bc561728e168d664270400f00eb71ca0f7b0 -> 5263ce65860555d8eed8a08096bc147170b32903 jdk8-b95 3514ee82f55e25d44fe743175a5dfd2efe57e91d -> b94b179fc604891a76d1befbb7f9933b6e21fad1 jdk8-b96 aa8214f8b13b15dfcbcb427225924002f954f6d9 -> 20a81b3697e720b32c88839e4ca96e40d69d5814 jdk8-b97 52c930851f9ba81c2d70218a592d66a5342be03c -> 477e6634a0107fcd02afc47e096476326d6b0a8f jdk8-b98 bec6be5dc993979c951807632ffb49113030e006 -> d405ff56451054b5b0ba3f780f9ffef100aa5fe3 jdk8-b99 4a45d02a01c1df006676c3141e91c1d3cdd140c2 -> f2da184e305469a090e8e5cfa50018128558036a jdk9-b00 713f2f59f3cd4efc478a43c0c7c403b8c216df46 -> 8950e8e0a06913dfb2b6f78c839ce4a3255c3f8b jdk9-b01 1c87486aefc11e48e6c99785908633c4a7ea0453 -> a4781f7911e76e2908f7cbb6b0ed964a873e670f jdk9-b02 f8f6dd9353aace854b0c57e137af66e5d3d7c0ba -> 3d9ab12cb9c60dcf1d97a63064de2917ae9a00e6 jdk9-b03 dfa471348d018707d0cc6d1afed2fa7985a51686 -> 343fd661c7feefdc8d30eca439db2fb7ec919ef5 jdk9-b04 c5da700534090fe9a0709bdb06ea5230ef9d7870 -> 459a60a718165eacd7fc1aee2d05b43abc784bac jdk9-b05 eb7a4bcddda401388c181f9c34bf4e69bd5d2a77 -> d428be387385f9a12ecbad51eb69b78cf2d02610 jdk9-b06 55cd3a180797fa430c6953e1ecffeebb952fdc50 -> b0d75da07a72f8487088a1be84d813f506350c08 jdk9-b07 b8822e7daef2a40eec7412c7e0f710dfd29aaf50 -> 87dde3df8dc888d82d2825468218805e3c7aeef9 jdk9-b08 c27d4b7d28f280b45872769a2c1dbbbfe7cd9395 -> 40acaee0742285fc04abd0e8150f955732638012 jdk9-b09 712392bf99ed82f7ba63d8bbc1cf9b562259e34f -> 88777efb8d8d6d0ee87b5ebde6ad3f1a4fb379c1 jdk9-b10 84dbe45301a3fc13a7c71da7732bbe122ee4f11e -> 43f9318baadd9837cbb0441bc3bce82c917ebc90 jdk9-b11 508199f30b40a0cca31781489dd6886588eee8d1 -> 9ab1ae689b3fc59c26a86bc95f5de1b3e16ae15b jdk9-b12 6a23106ba49675b410b9d45d5340a242a6792706 -> ea0e4b594af5055ca2d451066b4796a0cd66d15c jdk9-b13 5073807228df13c0212e5eda5add5268f1be3867 -> 881341bfa5507464e55dc06e344d0c24f8ccaed5 jdk9-b14 78a1da96a51c56ed5ac642bc15d69621731f33d5 -> ef5ce609a342df30322f54231b60a514f2df8fd3 jdk9-b15 8362d9b9c5573e3dc0f69ccddd8704b8fd2a7e87 -> 1f130c947959b4bcd506bfca3ff5aff69e903734 jdk9-b16 bf0277e48b339c57429666d17416da7ae189f70c -> b9da1b90f4c9726e38d78de7774142691a26702f jdk9-b17 f3a21e576d53c2217cf1f17b1df7bfd785940654 -> a0e7be25ac56363623757b91f8833dfbad459c35 jdk9-b18 1c32dc4199ab04dc5bc1cac8fb9f418ef91074bf -> d2a3926ea2fd352595f57b14606d836c8db9429b jdk9-b19 109844cc425102f08ef9ec154f4421bb62825573 -> 91851ca5f942bee6983af82460aca57ec55d7dfd jdk9-b20 71821f4180dfe80ce3bb93f980dfdc5320a213ea -> 62e91dd964b6ec7c056775773c0ee8ed7fd24f83 jdk9-b21 d6866ad0691790e46a5491fd376893860df18f24 -> 5d1aab89956a88f6dba057ce4c5a328f7c506230 jdk9-b22 c719823ecab27011956b1791e90c5d1e95350ace -> c57d1155a778fbd8373a9e70e62049b136ba5a67 jdk9-b23 6621552a02ca3ad876b83058028fd09144c96acb -> 3b91fad6fb807e901d429934055108421f21789b jdk9-b24 9224c1a06818fee3a727ce4aa6f385b8177b2114 -> 164cfacef29ce05d6681f38225a13c4476b4a8eb jdk9-b25 49333cb5937e2763a3bca33c913f9f1fd1ce35d0 -> b5b9ec94c2537567f926597f27a2823724a9810a jdk9-b26 1d954e87d10d3e84aa8fd7d23f0cec8aee49ba09 -> 2c2d21bae63b70f22885648f751e92ab9e360941 jdk9-b27 1883033be665a84be67deef168ff8b2d25fe9af3 -> 137faac2bcf39633b47f83cef83b4fa8bf86fd62 jdk9-b28 2904fa0b17fc96f0d07cad5efa04b551942f948a -> 8ac0c7efac15406e5d2777f9c9cc866dfbc25c09 jdk9-b29 658b13b24d0fb9fb1b1dfa11fbf8c1b0885887a0 -> a7adca59d69a5a384cacb06b7627c87b837f2973 jdk9-b30 3c0790c1c9aef422ada26cb350bff143e04c5649 -> 346321263b744b01e4e710eeb25567f2077618f1 jdk9-b31 561840239f027b682512991dc8a2d9fbd685cf5b -> 185a252bd6856073004d1f28772cc91db5265a24 jdk9-b32 c12547c511398ea3693e6d7fb4bec0327b1fc9d0 -> c12fc70b13cbd7973340ecc6497f32a2bcec6e18 jdk9-b33 da89d00f6b11fb22c8bdc8e7e15e5fbfc3b6adbf -> dcf28216b40575059b09a84c764af9c01dcd7d3c jdk9-b34 1c10fa1ffccbe897f0d96bbe6a57bac85b2fca93 -> 4567670051979e1dd0f090acc36a758018ad1073 jdk9-b35 b66ebe3f56baccc516a58ca137d47583ca64f3e6 -> 360d68ad494adeedcd5262a14cd02286f200022e jdk9-b36 b6110039fcac502fa42cfa995331321de9a51e1c -> b3a6ef997beb041fe33ce468e803e66a1795a20b jdk9-b37 9c6acd29b12b450a42f81e1dd4f59bd279563f65 -> 77b4ef42ae30a6ca60b3c118134382d73a51f434 jdk9-b38 24adfb0c8e172cbc38e9716d4cdb42f3c4de3da6 -> 658e432550973b0e98e53e6fd99de2f840e56ec1 jdk9-b39 485ea7fd5e2922365488048ca2c9f7a6fc3e4a3b -> f81d7b2ce025d3480d21854fb51c1795f20c82fb jdk9-b40 58a8ccea1b4daa9f62ca68ffb38149f21b5a1a9a -> a135302d3ee8cf3cfcaa19c001f70290438a0f5e jdk9-b41 8cd356cf3ec4ee97e858ccf5de9bf46976377afa -> c292ae6d93a833247ee0ab24ba82d44145fcd14f jdk9-b42 0936c96718dfc70ab67dbb0d9dc01378a121d902 -> 79e60c3b730d46fd883558d4c25e41344170c1eb jdk9-b43 1eb568947458e92de7aad81931ca74b02d5a698a -> 4b21498206371ac098e10249ef4a870a08e8e0b7 jdk9-b44 7d4b91d284cbb039940f7570206a53612e827e1d -> e7ba06728e111dbfe36a98c99e4cd64621df5497 jdk9-b45 85b30bcf58e37e0567da627c596c6a91ef214172 -> 8d8affb886b0236f8a717987a24f06143aeed025 jdk9-b46 18fc172427a01c6e0faaec2508e5f20ea138d44f -> 8b14cfeb0b2af65b0070c7539bb1a6a3cdf42a50 jdk9-b47 96dbe32c10287a6deeab467ecb84001327821e3b -> d1aabfd0c22f0181c970167fd30cf14156e2592f jdk9-b48 854a967f554a48cee1900afff7c807bcab20ac0d -> da0347c03db51aa8eb3445a3a828d61a4f6b2c99 jdk9-b49 1114a8700fbf5d49951c446ff4d00154e23334de -> 16babc62f41c2ffca3cb05ddfea6868deead03e9 jdk9-b50 73d70c595feb9056f5e312fb57e01a766b348408 -> b4c32db44013abd2533300539a78fdae1a7ada5b jdk9-b51 62f616cd838441615687595d208ba55720b36650 -> 1281b62285505c23101061654ba241edcdb28a56 jdk9-b52 b37eb6882fda011a1326f6c7bc11820c7bd3c79b -> 595161194578e3e9a9ba57ba11029a1833c07d46 jdk9-b53 8328e6ea61eff8fe9c7d9e1bd52eeeecfacc0eb3 -> c0101fb71b37f7c0dcaaba13978e0e459ccec7fb jdk9-b54 2960bc0fc5f8078fc51f633168357e1bcfd2ec23 -> d2364a518d1031cb0c73e7f7cfcfd52eb1f18e94 jdk9-b55 ae9f1a7c53596a19fb7791e2f6fff1e1181697bf -> 1c982cb7f85153ac0c210802d9a9e41460c7ba42 jdk9-b56 c513144800fd7ffe18c3d56a8d99ca5c7e10154d -> c958aae26d5da5c188d589509687282f0b920c56 jdk9-b57 c7c85c928b11bc06424c523559273655f9ebf064 -> a9349830f86c61b5f7c770afd1eb51707325d430 jdk9-b58 bb00e7c20647d1c6c0a6d9345c78aa6b4d63540e -> cf75fc532cbad160a44e934c6a69cb34fbffb0f7 jdk9-b59 c5bd438ad3ddb76c015c266b8a421fcc2a083871 -> 9956b524fa15e5f9057bddd356a3b45bbaab5e82 jdk9-b60 b1bc942e8536ec99113290a354faeac861c474d0 -> f2611cad78090c02826d806fdafd0977d4e68a61 jdk9-b61 ed0eb2082c5366b543b995103ca15e3c9222fabe -> 12de2c36de36821b9cb40f4a6c121d66f1b508c1 jdk9-b62 74f5e27c1a0a3e08a943760196f48023142f8951 -> 0c1c88d2fbdbcd23ea051f2abaf6c4a86db458dc jdk9-b63 1781c02b21fc39f48a321b3a228dfb1416896369 -> 0e509299aac83a0a400d27b033854042ba449e1b jdk9-b64 c4b925670656911f3a6a614ce532c3c860c67874 -> 72098746c7adfa5568a6c214414b66c85ee697af jdk9-b65 688a079096789c5e509e8c7df9be2c83ff0feb2f -> c400eb68ba57ef03714043f93abb610bd5568734 jdk9-b66 04c42553804769359f05031228bad3eb67a86c8a -> a9e4585e621191f5d637ea0ecf01a38809365436 jdk9-b67 b9e17afb88f9568507df8fba8d4fd1151a44862b -> b683e90fcd33347ddba800cb8bad1eb12bdd4180 jdk9-b68 d62f5f6168e1d7bc77ba7ebe4df5d65b7dac40bc -> c37853537a4b840b16e79a55c19f2c8ba1f2ff96 jdk9-b69 49d94aa0b583a57789156e5231a5b0568a9c50dc -> 03f8585bd31e76ac22dde481aa7b72032c97ee21 jdk9-b70 f7db7365de7fb286a09c754b47ab355d6f3c9dbc -> 5ba4552b04af30ad805a1b529abf88121008f031 jdk9-b71 28a909fd1fdb23803a2e6a2f9f0b705f49dfac1e -> efecadee5f0157acbb4eae9af3e34d240cd16849 jdk9-b72 029d76538456cff7b0af7426aa94f587689f15c5 -> 9b32dc03c950d1cc6517b65f7183c7c4ba2abeca jdk9-b73 2fccb792f420dafa5d794a60696919a011d6548d -> e827738fe4b24e044a7cde30848467f0305f6312 jdk9-b74 2b56a417fe9346491d136a66af48253db470ab71 -> 4348771a983ce0e0a3725ff8c3bc47819426ee0e jdk9-b75 82b65d5247c3b70c758e22291ace566a6770af4d -> 5b65b01ac6be96421af884d6a83f9b2485e99685 jdk9-b76 2a9aa81d8b059ba0327e8eb1c9bddb16da348e4d -> 4744cd8ac0c122eafb651acf2e4828da37bf3d98 jdk9-b77 c338b713baf9200145ec010b0c7d619869dac1a4 -> 6cd0bc3967743b9e184103c2266fdac7d6d3fc9d jdk9-b78 889a0bee9ad217a0432ffafa4f33654ad2fdc478 -> dd19c8cf3981f3beb94f78cb6e0618852350ce6b jdk9-b79 0e25715b7751e75364988ab5c6d3d0f9d58225a8 -> e07d3f6a7f4cb3fdb617efee5ae8b86c0a4b4311 jdk9-b80 44d5aadd221f138be030a2511f211412fd8396b0 -> 75282effeb0cbb7d137bd5c70a82d0ae369d4af3 jdk9-b81 f40560dd4acc31c65b6c0a7ba47006940d576609 -> feae4e33a44b8ff054ce00e814263bf3241a5982 jdk9-b82 3d5ea5f2178b4d1dccabe240cd831f2b52f98ae3 -> c87a9e00c41b1d876825865a3957d914f4566e17 jdk9-b83 b3f2d27e6b318012d0b91b84b077d0c7a92598fe -> 94c1374132b62651645a95dfd9c4912f68e8a579 jdk9-b84 7126ea9c3e5939e363dcc51844a1784f982d6fd1 -> 37c057e10b741299b236f0d31434fc5887a6cb70 jdk9-b85 dc27ebe29226ae2fb47f6bc078521b9009e6cc7c -> 3849cb9d2d542abfd7620dbbe54c1eb28d97f38e jdk9-b86 45f77730027fa619cb265c8f7559f3c71f27722b -> e6cc6cb0f2c235edfed1f6fa5396c4768f600ed3 jdk9-b87 36993584a5f14890ef29e2b45a85ccb93b570294 -> 35f1b84b90d68737d90cc9674081c6fd24f727f8 jdk9-b88 fb790047ea0b58163c7e3da52b8d2ebdf10d0462 -> 5bc4d39bd96dd6e273a4b34ed0f11e2dedffff85 jdk9-b89 d76e1884edcea6d22626e18abc42b644f0cb2d5e -> a060162fb5f65f4f2161bbcacde9a906e032a841 jdk9-b90 56de84c4586df4585469ea590ac8f9b800dc9082 -> e70bd431d9d9655f5ef8ffded19f760d55d1eecc jdk9-b91 3c11ef9b01057974ccba9547a22c2affb2cfa450 -> 03a6c2e9f01c69c246dbad6e1a93d2849df7dc07 jdk9-b92 09482af461673090352ddf606a35677941785d66 -> 748526bd1c42cc0454d6c042705eb28435b8afd2 jdk9-b93 bccc9bd46aaaffd7a8958af9d3bcc7f3dd11bded -> b1a75f98bfae7a95dffbb74b0a5ee2ba88f43583 jdk9-b94 66145b502652e8b17501e3231b7b9db0b8c976f1 -> 8cf535c977afe777927f081bdca2549152524104 From LANCE.ANDERSEN at ORACLE.COM Thu Jul 2 12:06:22 2020 From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen) Date: Thu, 2 Jul 2020 08:06:22 -0400 Subject: RFR: Updated section on Code Conventions. In-Reply-To: <1fb7cf56-8eb5-b73f-8fd2-8a5f852af40a@oracle.com> References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> <1fb7cf56-8eb5-b73f-8fd2-8a5f852af40a@oracle.com> Message-ID: <4A71B635-C45D-4F95-92A1-33F810CFA8F6@ORACLE.COM> > On Jul 1, 2020, at 11:54 PM, Stuart Marks wrote: > > On 7/1/20 1:44 AM, Magnus Ihse Bursie wrote: >>> A style guide is fundamentally different. To be useful, it must be authoritative -- as mentioned above -- and it also must be highly cohesive. It needs to have a uniform editorial voice that is adhered to consistently throughout the document. For example, it might take a prescriptive vs. a descriptive stance, or it might choose a vocabulary for recommendations of varying strength ("can", "should", "must", etc.) and use that throughout the document. As such, a style guide is not at all amenable to a "crowdsourcing" approach and must be edited by a handful of individuals. Since the editorial approach for the style guide material is so different from that of the Developer's Guide, it follows that the style guide should be a different document. >>> >>> Personally I'm agnostic to the exact process for delivering a style guide. If Mark thinks a JEP is required, then maybe that's the best way forward. But I could imagine other paths forward that wouldn't use a JEP. >>> >>> I would strongly recommend against making the style guide itself be a JEP. Today, editing a JEP with more than a page or two of text is already unwieldy. It's easy to introduce errors inadvertently, and history tracking is virtually nonexistent. >> Are you suggesting that we should create a sibling project to the Developer's Guide for the style guide(s), with different rules for engagement? > > I'm mainly suggesting that the Style Guide not be a chapter plopped into the middle of the Developer's Guide. They seem like fundamentally different documents and so should be treated differently. > +1 > That said, where would the Style Guide reside? It could be in a separate OpenJDK Project, though that seems like kind of high overhead for a single document. A Project would have separate Reviewers/Committers/Authors, which also seems like high overhead, but maybe something like that is necessary. Or maybe it could be a Group. For example, recently formed groups like the CSR group and the Vulnerability group have their own, special rules of engagement. > > Or, the Style Guide could be hosted in the Developer's Guide *Project* but still be a different document, with different norms around who is responsible for modifying and reviewing changes. How about we keep this simple to start and keep this as an additional document in the Developer Guide Project. If we find the need to place it in its own project later, then we can. I think it is more important to move forward with the updates to the style guide now that we have some momentum behind doing so. > If the Style Guide has a single editor, or a small editorial board who are responsible for updating it, and everybody understands this, that might work just fine. +1 > This works for code. For example, I'm a libraries guy, so I don't go mucking around in Hotspot without talking to Hotspot folks about it first. > +1 > s'marks Best Lance ------------------ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jesper.wilhelmsson at oracle.com Thu Jul 2 17:47:52 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 2 Jul 2020 19:47:52 +0200 Subject: RFR: Updated section on Code Conventions. In-Reply-To: <4A71B635-C45D-4F95-92A1-33F810CFA8F6@ORACLE.COM> References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> <1fb7cf56-8eb5-b73f-8fd2-8a5f852af40a@oracle.com> <4A71B635-C45D-4F95-92A1-33F810CFA8F6@ORACLE.COM> Message-ID: I'll make an attempt at summarizing this discussion so far. There are a few issues that seems to be key to decide where a Style Guide can be located, all of them have pros and cons. The list below is not sorted in any way. 1) Version control + Any git/mercurial based solution will work here. + Even the OpenJDK wiki that was briefly mentioned have adequate change history. - A traditional JBS-based JEP will not work. 2) Small, controlled, set of editors + A JEP has a natural small set of authors and editors. Even though it's not explicitly written anywhere that people shouldn't edit random JEPs I haven't seen a lot of random edits on other people's JEPs. It would be good to explicitly clarify that JEPs are not to be edited without talking to the Author first, but that's a general JEP thing and is unrelated to this discussion. + A separate project or a Group maintaining its own document would also achieve this. + Having a separate document in the Developers' Guide project can also achieve this. We already have examples of different files/areas in the same Project and source tree (in the JDK) with different rules for reviews and different sets of authors. The same holds true for having the Style Guide reside in the JDK repository. - A wiki page will not satisfy this. 3) Make it obvious that this is an OpenJDK style guide + A JEP will provide enough "frame" around the Style Guide to make it obvious that this is intended for OpenJDK. + Any solution where the Style Guide is a separate document can achieve this as you can decorate the guide with any desired wording to make it scream OpenJDK in the same way as a JEP would do. + Having the Style Guide as an inlined chapter in the Developers' Guide will achieve this, but it has never been my intention to inline the Style Guide within the Developers' Guide even if that guide may be merged into a single page. I don't think this is a good idea and it won't happen. 4) Make sure changes are broadly reviewed - No solution discussed so far will achieve this. Changes in JEPs are usually not reviewed at all. Changes in a separate repository (special JEP, Developers' Guide, or other repo) are only reviewed by those who follow that repo. The only way to get a wide audience to look at changes would be to send them to jdk-dev, and this would have to be explicitly stated in some change guide for the Style Guide regardless of where it is published. The exception may be if the Style Guide is located in the JDK source repo, then it could be standard procedure to send changes for review on jdk-dev. It seems to me that there are several options that fulfills three out of four requirements, and in order to meet the last one a separate paragraph with a set of rules for updates would be required regardless of where and how the Style Guide is published. Such a paragraph could easily define who is allowed to edit and how reviews should happen. I personally don't have a strong opinion on where to place the Style Guide other than what I've said before; If it's supposed to be rules rather than guidelines then a JEP is a good place, if these are guidelines I would personally not vote for a JEP. Several experienced voices has expressed what I interpret as "these are rules regardless of what we call them", and I have no evidence to support any other opinion. As a side note I just want to point out that we are currently three Reviewers in the Developers' Guide Project, none who is likely to accept changes to the Style Guide without following the proper protocol. So I can pretty much guarantee that no random updates will happen if the Style Guide would be placed there. There is some more work to do before the same claim can be made for a JEP. /Jesper > On 2 Jul 2020, at 14:06, Lance Andersen wrote: >> On Jul 1, 2020, at 11:54 PM, Stuart Marks > wrote: >> On 7/1/20 1:44 AM, Magnus Ihse Bursie wrote: >>>> A style guide is fundamentally different. To be useful, it must be authoritative -- as mentioned above -- and it also must be highly cohesive. It needs to have a uniform editorial voice that is adhered to consistently throughout the document. For example, it might take a prescriptive vs. a descriptive stance, or it might choose a vocabulary for recommendations of varying strength ("can", "should", "must", etc.) and use that throughout the document. As such, a style guide is not at all amenable to a "crowdsourcing" approach and must be edited by a handful of individuals. Since the editorial approach for the style guide material is so different from that of the Developer's Guide, it follows that the style guide should be a different document. >>>> >>>> Personally I'm agnostic to the exact process for delivering a style guide. If Mark thinks a JEP is required, then maybe that's the best way forward. But I could imagine other paths forward that wouldn't use a JEP. >>>> >>>> I would strongly recommend against making the style guide itself be a JEP. Today, editing a JEP with more than a page or two of text is already unwieldy. It's easy to introduce errors inadvertently, and history tracking is virtually nonexistent. >>> Are you suggesting that we should create a sibling project to the Developer's Guide for the style guide(s), with different rules for engagement? >> >> I'm mainly suggesting that the Style Guide not be a chapter plopped into the middle of the Developer's Guide. They seem like fundamentally different documents and so should be treated differently. >> > > +1 > >> That said, where would the Style Guide reside? It could be in a separate OpenJDK Project, though that seems like kind of high overhead for a single document. A Project would have separate Reviewers/Committers/Authors, which also seems like high overhead, but maybe something like that is necessary. Or maybe it could be a Group. For example, recently formed groups like the CSR group and the Vulnerability group have their own, special rules of engagement. >> >> Or, the Style Guide could be hosted in the Developer's Guide *Project* but still be a different document, with different norms around who is responsible for modifying and reviewing changes. > > How about we keep this simple to start and keep this as an additional document in the Developer Guide Project. If we find the need to place it in its own project later, then we can. > > I think it is more important to move forward with the updates to the style guide now that we have some momentum behind doing so. > >> If the Style Guide has a single editor, or a small editorial board who are responsible for updating it, and everybody understands this, that might work just fine. > > +1 > >> This works for code. For example, I'm a libraries guy, so I don't go mucking around in Hotspot without talking to Hotspot folks about it first. >> > +1 > > >> s'marks > > > Best > Lance > ------------------ > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com From stuart.marks at oracle.com Thu Jul 2 21:56:10 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 2 Jul 2020 14:56:10 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: <4b7d416c-826b-ee79-7623-6e89c8e2ac5c@oracle.com> References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> <1fb7cf56-8eb5-b73f-8fd2-8a5f852af40a@oracle.com> <4A71B635-C45D-4F95-92A1-33F810CFA8F6@ORACLE.COM> <4b7d416c-826b-ee79-7623-6e89c8e2ac5c@oracle.com> Message-ID: On 7/2/20 6:40 AM, Magnus Ihse Bursie wrote: > I thought, or at least hoped (perhaps naively), that we had, as an > organization, finally learned that being a bit more agile -- without > compromising on our high standard of quality -- had done wonders for our > project. That 6-month releases was a boon sine qua non. That doing things > mostly right, releasing them, and then adjusting them based on feedback, was > vastly superior to doing nothing in fear of not doing it perfect from the start. > > But this view collides heavily with Mark's that we, before we even start > considering what a Style Guide should contain, must have one of our most > experienced developers signing up to be the sole editor for a substantial > period of time. With that premise, we can be quite sure that we will never get > a Style Guide. If this is indeed the expected and preferred outcome for the > proponents of this line, I think it borders on dishonesty: if so, please say > that you do not *want* a style guide for OpenJDK. And if you do want a style > guide, can you with a straight face say that it is likely that we will ever > get one with that kind of requirements? We have waited for years, and years > for that kind of perfection, but with nothing to show. What will be different > in the coming five years? Well there's rather a lot to unpack here. It's certainly been frustrating that the 2o-year-old /Code Conventions/ hasn't been updated. Andreas Lundblad made a credible attempt to do so, now five years ago, and I don't know why that stalled out. (Nor do I want to relitigate the issues that led to the effort stalling out.) It seems like adding the style guide to the Developer's Guide offers a path forward. Doing that allows everybody to work on it. We can make quick progress on it after that, right? This is surely better than what we have now (nothing), because the best is the enemy of the good, right? In my estimation, doing this will lead to a "crowdsourcing" of the effort, and this will leave us in a /worse/ position than we're in today. (Believe it or not.) As an example of where crowdsourcing fails, I'll point to Stack Overflow Documentation. [1] (Not Stack Overflow the main Q&A site, which seems reasonably successful as a crowdsourced Q&A site.) Stack Overflow Documentation [2] was an effort to crowdsource fixing the "documentation problem." Documentation does seem to be a general problem in the industry, and certainly Java has its share of documentation problems. Stack Overflow Documentation was launched and then shut down perhaps a year later; the explanation is given in [3]. That explanation offers mostly a business rationale for shutting it down: lack of growth in number of users, inability to generate revenue for Stack Overflow the company, and so forth. Quite reasonable. But little has been said about the /quality/ of documentation produced by the Stack Overflow Documentation project. The SO Documentation materials are all CC BY-SA. The company made an archive of that data available, and it's been re-hosted elsewhere so that it's possible to look at it. For example, take a look at the Collections topic of the Java documentation category. [4] I spent a few minutes with it, and *frankly, it is just terrible.* It was this way when the SO Documentation project was active. Back then I had looked at it for about five minutes, and I quickly decided that it was *beyond repair*. There are so many problems, it's hard to know where to start. Fundamentally I think the choice of topics is bad and they are organized poorly. Apparently no thought was given to what topics are important or what order to cover them in. It's not even clear what audience the material is intended for. (These issues are certainly related.) It's random train-of-thought as far as I can tell. It suffers from an utter lack of cohesion. Stack Overflow Documentation is this way /because/ it's a crowdsourced effort. Surely the Style Guide couldn't get this bad. After all, we'll use Andreas Lundblad's draft as a starting point. It seems to be pretty cohesive already, so it wouldn't get as bad as SO Documentation, right? Well I'm not confident about that. It takes positive effort to keep something in good shape. In the absence of a central editor, a few small changes here and there by a few different individuals will quickly give rise to internal contradictions and other inconsistencies. These will soon damage the credibility of the entire document. You know how quickly bit-rot sets in when software isn't maintained? Well, it's the same way with documents. ** Where does that leave us? I agree with the desire to move forward quickly. I don't think Mark's (or my) approach of having a central editorial authority necessarily implies slow progress. However, people who are willing and able to do that are in short supply, and finding those people could take (and has taken) a long time. I see the temptation to just check it in and let people work on it. It seems like that would allow for lots of progress. But that's a mirage. It will just lead to chaos and disorganization and it will eventually end up being a waste of everybody's time. s'marks [1] https://stackoverflow.com/documentation [2] https://meta.stackoverflow.com/questions/303865/warlords-of-documentation-a-proposed-expansion-of-stack-overflow [3] https://meta.stackoverflow.com/questions/354217/sunsetting-documentation [4] https://riptutorial.com/java/topic/90/collections From tobias.hartmann at oracle.com Fri Jul 3 08:58:15 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Jul 2020 10:58:15 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn Message-ID: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Hi, I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop unswitching and superword optimizations). He investigated and fixed several highly complex and long-standing issues in the code base and improved maintainability and debugability of the JITs. All the while, Christian is constantly updating and extending the sparse documentation, making life easier for other engineers. Votes are due by 09:00 UTC, July 17th, 2020. Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Tobias [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/bylaws#lazy-consensus From tobias.hartmann at oracle.com Fri Jul 3 09:06:05 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Jul 2020 11:06:05 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes Best regards, Tobias On 03.07.20 10:58, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus > From sgehwolf at redhat.com Fri Jul 3 09:17:22 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 Jul 2020 11:17:22 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <6ce810e21d90499332cfa6a78e184fbf8ab3d04b.camel@redhat.com> Vote: yes. On Fri, 2020-07-03 at 10:58 +0200, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus > From adinn at redhat.com Fri Jul 3 10:12:40 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 3 Jul 2020 11:12:40 +0100 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes On 03/07/2020 09:58, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From vladimir.x.ivanov at oracle.com Fri Jul 3 10:14:15 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Jul 2020 13:14:15 +0300 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <77229dc6-82c3-684d-b81a-27a850192a59@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 03.07.2020 11:58, Tobias Hartmann wrote: > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. From dean.long at oracle.com Fri Jul 3 10:50:44 2020 From: dean.long at oracle.com (Dean Long) Date: Fri, 3 Jul 2020 03:50:44 -0700 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes dl On 7/3/20 1:58 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From rwestrel at redhat.com Fri Jul 3 11:49:55 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 03 Jul 2020 13:49:55 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <87k0zkakd8.fsf@redhat.com> Vote: yes Roland. From goetz.lindenmaier at sap.com Fri Jul 3 14:04:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Jul 2020 14:04:53 +0000 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Tobias > Hartmann > Sent: Friday, July 3, 2020 10:58 AM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Christian Hagedorn > > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and > contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the > JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key > areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several > highly complex and > long-standing issues in the code base and improved maintainability and > debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse > documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes > must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.haged > orn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=1 > 00 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From igor.ignatyev at oracle.com Fri Jul 3 14:48:05 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 3 Jul 2020 07:48:05 -0700 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <2AF01238-E453-489B-B737-97F4CD51B8D3@oracle.com> Vote: yes -- Igor > On Jul 3, 2020, at 1:58 AM, Tobias Hartmann wrote: > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. From jesper.wilhelmsson at oracle.com Fri Jul 3 17:26:32 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 3 Jul 2020 19:26:32 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <0EC0BF06-87AE-4FBA-A4B7-8AA410487FA0@oracle.com> Vote: Yes /Jesper > On 3 Jul 2020, at 10:58, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From vladimir.kozlov at oracle.com Fri Jul 3 18:32:35 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Jul 2020 11:32:35 -0700 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <7a48014c-c056-6668-4c33-3c541830bc32@oracle.com> Vote: yes On 7/3/20 1:58 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus > From kim.barrett at oracle.com Fri Jul 3 21:55:49 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 3 Jul 2020 17:55:49 -0400 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: vote: yes > On Jul 3, 2020, at 4:58 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From john.r.rose at oracle.com Sat Jul 4 00:04:56 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 Jul 2020 17:04:56 -0700 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <250B01EC-C662-401E-9B3A-8AFC3C7ABD41@oracle.com> Vote: yes From Alan.Bateman at oracle.com Sat Jul 4 05:29:28 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 4 Jul 2020 06:29:28 +0100 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <0c44a16c-eb65-966c-703b-48892ec0c595@oracle.com> Vote: yes From volker.simonis at gmail.com Sat Jul 4 06:59:01 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 4 Jul 2020 08:59:01 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes Tobias Hartmann schrieb am Fr., 3. Juli 2020, 10:59: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and > contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code > in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key > areas (for example, loop > unswitching and superword optimizations). He investigated and fixed > several highly complex and > long-standing issues in the code base and improved maintainability and > debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse > documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. > Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus > From stanislav.smirnov at oracle.com Sat Jul 4 11:23:35 2020 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Sat, 4 Jul 2020 07:23:35 -0400 Subject: jdk/submit repository reset Message-ID: Hello, The jdk/submit repository was reset. A new repository was created today with no branches except from the default one. http://hg.openjdk.java.net/jdk/submit In order to continue using the submit repo please make a fresh clone and run ?hg out? before push. Also an archive of the old jdk/submit was created https://hg.openjdk.java.net/jdk/submit-archive-2020-07-03 Please continue using the system and report any issues/ask questions related to the jdk/submit repo using ops at openjdk.java.net. Best regards, Stanislav Smirnov From thomas.stuefe at gmail.com Sat Jul 4 20:42:43 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 4 Jul 2020 22:42:43 +0200 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote : yes On Fri 3. Jul 2020 at 10:59, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and > contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code > in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key > areas (for example, loop > unswitching and superword optimizations). He investigated and fixed > several highly complex and > long-standing issues in the code base and improved maintainability and > debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse > documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. > Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus > From shade at redhat.com Sun Jul 5 04:17:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 5 Jul 2020 06:17:48 +0200 Subject: jdk/submit repository reset In-Reply-To: References: Message-ID: On 7/4/20 1:23 PM, Stanislav Smirnov wrote: > The jdk/submit repository was reset. > A new repository was created today with no branches except from the default one. > > http://hg.openjdk.java.net/jdk/submit > > In order to continue using the submit repo please make a fresh clone and run ?hg out? before push. As usual, the refreshed workspace bundle is here: https://builds.shipilev.net/workspaces/jdk-submit.tar.xz -- Thanks, -Aleksey From hohensee at amazon.com Sun Jul 5 19:39:37 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Sun, 5 Jul 2020 19:39:37 +0000 Subject: CFV: New JDK Reviewer: Christian Hagedorn Message-ID: <7076DF4E-4603-48C4-87B9-1254984744A8@amazon.com> Vote: yes ?On 7/3/20, 2:00 AM, "jdk-dev on behalf of Tobias Hartmann" wrote: Hi, I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop unswitching and superword optimizations). He investigated and fixed several highly complex and long-standing issues in the code base and improved maintainability and debugability of the JITs. All the while, Christian is constantly updating and extending the sparse documentation, making life easier for other engineers. Votes are due by 09:00 UTC, July 17th, 2020. Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Tobias [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/bylaws#lazy-consensus From christoph.langer at sap.com Mon Jul 6 06:16:42 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Jul 2020 06:16:42 +0000 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Tobias > Hartmann > Sent: Freitag, 3. Juli 2020 10:58 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Christian Hagedorn > > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and > contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the > JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key > areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several > highly complex and > long-standing issues in the code base and improved maintainability and > debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse > documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes > must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hage > dorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=1 > 00 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From harold.seigel at oracle.com Mon Jul 6 13:46:35 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 6 Jul 2020 09:46:35 -0400 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes. Harold On 7/3/2020 4:58 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From mark.reinhold at oracle.com Mon Jul 6 22:36:16 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 6 Jul 2020 15:36:16 -0700 (PDT) Subject: New candidate JEP: 387: Elastic Metaspace Message-ID: <20200706223616.1370F3BA704@eggemoggin.niobe.net> https://openjdk.java.net/jeps/387 - Mark From felix.yang at huawei.com Tue Jul 7 01:20:34 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 Jul 2020 01:20:34 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Monday, July 6, 2020 4:44 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory > barrier in fast_storefield and fast_accessfield > > On 06/07/2020 03:09, Yangfei (Felix) wrote: > > 1. For 8, I have prepared a backport webrev: > http://cr.openjdk.java.net/~fyang/8248219-8u-backport/webrev.00/ > > Jtreg tested with an 8u aarch64 release build. OK for aarch64- > port/jdk8u-shenandoah? > > We need another approver. When we have one, please push to jdk8u-dev, > not jdk8u-shenandoah. Hmm... I haven't seen an aarch64 port in jdk8u-dev yet. > > 2. For 11, patch applies cleanly to jdk11u-dev and I have added a jdk11u-fix- > request label and corresponding comment on the issue. > > Please also add a jdk8u-fix-request. I saw the jdk11u-fix-yes label was added and I have pushed to jdk11u-dev. As I remembered, jdk8u-fix-request label could be added when the aarch64 port is merged to jdk8u master. > > 3. For 15, should I simply add 15 to " Affects Version/s" of the issue and > push to jdk/jdk15 after necessary test? > > Please confirm if this is correct in procedure. > > I'm not sure. CCing to jdk-dev. So the question is: Is it OK to push this fix to jdk/jdk15 for now given that JDK15 is currently in Rampdown Phase One? Could someone help elaborate on the correct procedure please? From david.holmes at oracle.com Tue Jul 7 01:30:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Jul 2020 11:30:41 +1000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> Message-ID: <240133a3-17c9-ef16-5359-812d153ef0d7@oracle.com> Hi Felix, On 7/07/2020 11:20 am, Yangfei (Felix) wrote: > Hi, > >> -----Original Message----- >> From: Andrew Haley [mailto:aph at redhat.com] >> Sent: Monday, July 6, 2020 4:44 PM >> To: Yangfei (Felix) ; hotspot-runtime- >> dev at openjdk.java.net >> Cc: aarch64-port-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory >> barrier in fast_storefield and fast_accessfield >> >> On 06/07/2020 03:09, Yangfei (Felix) wrote: >>> 1. For 8, I have prepared a backport webrev: >> http://cr.openjdk.java.net/~fyang/8248219-8u-backport/webrev.00/ >>> Jtreg tested with an 8u aarch64 release build. OK for aarch64- >> port/jdk8u-shenandoah? >> >> We need another approver. When we have one, please push to jdk8u-dev, >> not jdk8u-shenandoah. > > Hmm... I haven't seen an aarch64 port in jdk8u-dev yet. > >>> 2. For 11, patch applies cleanly to jdk11u-dev and I have added a jdk11u-fix- >> request label and corresponding comment on the issue. >> >> Please also add a jdk8u-fix-request. > > I saw the jdk11u-fix-yes label was added and I have pushed to jdk11u-dev. > As I remembered, jdk8u-fix-request label could be added when the aarch64 port is merged to jdk8u master. > >>> 3. For 15, should I simply add 15 to " Affects Version/s" of the issue and >> push to jdk/jdk15 after necessary test? >>> Please confirm if this is correct in procedure. >> >> I'm not sure. > > CCing to jdk-dev. > So the question is: Is it OK to push this fix to jdk/jdk15 for now given that JDK15 is currently in Rampdown Phase One? > Could someone help elaborate on the correct procedure please? This is a P3 bug and so can be fixed in RDP1 [1]. It could have been pushed directly to the jdk15 repo and would then have been automatically forward ported to the jdk repo for JDK 16. But it is fine to hg export from the main jdk repo and hg import into jdk15. [1] http://openjdk.java.net/jeps/3#rdp-1 Thanks, David ----- From aph at redhat.com Tue Jul 7 08:50:09 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Jul 2020 09:50:09 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> Message-ID: On 07/07/2020 02:20, Yangfei (Felix) wrote: >>> 1. For 8, I have prepared a backport webrev: >> http://cr.openjdk.java.net/~fyang/8248219-8u-backport/webrev.00/ >>> Jtreg tested with an 8u aarch64 release build. OK for aarch64- >> port/jdk8u-shenandoah? >> >> We need another approver. When we have one, please push to jdk8u-dev, >> not jdk8u-shenandoah. > > Hmm... I haven't seen an aarch64 port in jdk8u-dev yet. Sorry, my brain crashed. You are right. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Tue Jul 7 08:59:48 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 Jul 2020 08:59:48 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, July 7, 2020 4:50 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net; jdk-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory > barrier in fast_storefield and fast_accessfield > > On 07/07/2020 02:20, Yangfei (Felix) wrote: > >>> 1. For 8, I have prepared a backport webrev: > >> http://cr.openjdk.java.net/~fyang/8248219-8u-backport/webrev.00/ > >>> Jtreg tested with an 8u aarch64 release build. OK for aarch64- > >> port/jdk8u-shenandoah? > >> > >> We need another approver. When we have one, please push to jdk8u- > dev, > >> not jdk8u-shenandoah. > > > > Hmm... I haven't seen an aarch64 port in jdk8u-dev yet. > > Sorry, my brain crashed. You are right. Thanks for confirming that. Will push this to aarch64-port/jdk8u-shenandoah. Felix From felix.yang at huawei.com Tue Jul 7 12:47:18 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 Jul 2020 12:47:18 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: <240133a3-17c9-ef16-5359-812d153ef0d7@oracle.com> References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> <240133a3-17c9-ef16-5359-812d153ef0d7@oracle.com> Message-ID: Hi David, > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, July 7, 2020 9:31 AM > To: Yangfei (Felix) ; Andrew Haley > ; hotspot-runtime-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net; jdk-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory > barrier in fast_storefield and fast_accessfield > Cut... > > > > CCing to jdk-dev. > > So the question is: Is it OK to push this fix to jdk/jdk15 for now given that > JDK15 is currently in Rampdown Phase One? > > Could someone help elaborate on the correct procedure please? > > This is a P3 bug and so can be fixed in RDP1 [1]. It could have been pushed > directly to the jdk15 repo and would then have been automatically forward > ported to the jdk repo for JDK 16. But it is fine to hg export from the main jdk > repo and hg import into jdk15. > > [1] http://openjdk.java.net/jeps/3#rdp-1 Thanks for the quick reply. It's clear now. Patch from the main jdk repo applies cleanly to jdk15. I have performed Tier1-3 testing with an aarch64 jdk15 release build. Will push. Felix From gnu.andrew at redhat.com Tue Jul 7 17:00:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 7 Jul 2020 18:00:42 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> Message-ID: <346ecc4f-bf55-6278-30b0-fd64a1586980@redhat.com> On 07/07/2020 09:59, Yangfei (Felix) wrote: >> -----Original Message----- >> From: Andrew Haley [mailto:aph at redhat.com] >> Sent: Tuesday, July 7, 2020 4:50 PM >> To: Yangfei (Felix) ; hotspot-runtime- >> dev at openjdk.java.net >> Cc: aarch64-port-dev at openjdk.java.net; jdk-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory >> barrier in fast_storefield and fast_accessfield >> >> On 07/07/2020 02:20, Yangfei (Felix) wrote: >>>>> 1. For 8, I have prepared a backport webrev: >>>> http://cr.openjdk.java.net/~fyang/8248219-8u-backport/webrev.00/ >>>>> Jtreg tested with an 8u aarch64 release build. OK for aarch64- >>>> port/jdk8u-shenandoah? >>>> >>>> We need another approver. When we have one, please push to jdk8u- >> dev, >>>> not jdk8u-shenandoah. >>> >>> Hmm... I haven't seen an aarch64 port in jdk8u-dev yet. >> >> Sorry, my brain crashed. You are right. > > Thanks for confirming that. Will push this to aarch64-port/jdk8u-shenandoah. > > Felix > It would be preferable to avoid pushing to aarch64-port/jdk8u-shenandoah at the moment, as it is being prepared for the release next week. This change will be part of aarch64-shenandoah-jdk8u272-b01. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From Roger.Riggs at oracle.com Tue Jul 7 17:54:08 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 7 Jul 2020 13:54:08 -0400 Subject: CFV: New JDK Committer: Shravya Rukmannagari In-Reply-To: References: Message-ID: <569fdaa5-3cda-19b8-de28-5df6658a611c@oracle.com> Vote: Yes On 6/30/20 7:37 AM, Vladimir Ivanov wrote: > I hereby nominate Shravya Rukmannagari (srukmannagar) to JDK Committer. From felix.yang at huawei.com Wed Jul 8 01:15:18 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 8 Jul 2020 01:15:18 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: <346ecc4f-bf55-6278-30b0-fd64a1586980@redhat.com> References: <7a418bcb-3abd-d95e-d379-7a5e9722eb45@redhat.com> <346ecc4f-bf55-6278-30b0-fd64a1586980@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Wednesday, July 8, 2020 1:01 AM > To: Yangfei (Felix) ; Andrew Haley > ; hotspot-runtime-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net; jdk-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory > barrier in fast_storefield and fast_accessfield > Cut... > > > > Thanks for confirming that. Will push this to aarch64-port/jdk8u- > shenandoah. > > > > Felix > > > > It would be preferable to avoid pushing to aarch64-port/jdk8u-shenandoah > at the moment, as it is being prepared for the release next week. > > This change will be part of aarch64-shenandoah-jdk8u272-b01. I have pushed before I see this email. Sorry if this causes trouble. This reminds me to put a jdk8u-fix-request label on another 8u-specific bug (JDK-8248851) which is currently under review. I am looking forward to see the merge of aarch64 port into 8u upstream :-) Then push approval could be done the same way. Thanks, Felix From goetz.lindenmaier at sap.com Wed Jul 8 09:42:40 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 8 Jul 2020 09:42:40 +0000 Subject: Please open up closed changes Message-ID: Hi Jesper & authors, Recently, some closed changes have been pushed. Could you please check whether they can be opened up? "8227337: javax/management/remote/mandatory/connection/ReconnectTest.java NoSuchObjectException no such object in table" https://bugs.openjdk.java.net/browse/JDK-8227337 https://hg.openjdk.java.net/jdk/jdk/rev/32afaf310208 "8248264: WinUpgradeUUIDTest application is missing in downgrade scenario" https://bugs.openjdk.java.net/browse/JDK-8248264 https://hg.openjdk.java.net/jdk/jdk/rev/ed2af47e7987 "7107012: sun.jvm.hostspot.code.CompressedReadStream readDouble() conversion to long mishandled" https://bugs.openjdk.java.net/browse/JDK-7107012 https://hg.openjdk.java.net/jdk/jdk/rev/24057288b9ad Best regards, Goetz See also http://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003523.html From aph at redhat.com Wed Jul 8 10:27:18 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jul 2020 11:27:18 +0100 Subject: Please open up closed changes In-Reply-To: References: Message-ID: <91b573a3-6eca-32a3-f7d6-1344fee76064@redhat.com> On 08/07/2020 10:42, Lindenmaier, Goetz wrote: > Recently, some closed changes have been pushed. > Could you please check whether they can be opened up? Thanks for raising this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.helin at oracle.com Wed Jul 8 15:53:44 2020 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 8 Jul 2020 17:53:44 +0200 Subject: Need to update time zone metadata in tags for some OpenJDK git repositories In-Reply-To: <61068c40-ca67-a71b-69e7-22347b56439d@oracle.com> References: <61068c40-ca67-a71b-69e7-22347b56439d@oracle.com> Message-ID: Hi all, selected tags have now been updated with correct time zone metadata in the following repositories: - https://github.com/openjdk/jdk (read-only) - https://github.com/openjdk/client (read-only) - https://github.com/openjdk/jdk14 (read-only) - https://github.com/openjdk/jdk14u (read-only) - https://github.com/openjdk/jdk13 (read-only) - https://github.com/openjdk/jdk13u (read-only) - https://github.com/openjdk/jdk12u (read-only) - https://github.com/openjdk/jdk11u (read-only) - https://github.com/openjdk/jdk11u-dev (read-only) - https://github.com/openjdk/panama-vector (read-only) - https://github.com/openjdk/shenandoah (read-only) - https://github.com/openjdk/jdk-sandbox (read-only) Note: only selected tags were updated, *no* commit hashes have changed (see original e-mail below for details). Even though all the above repositories are read-only mirrors of their corresponding Mercurial repositories, some of you may have created personal forks of them. If you have a personal fork of any of the above repositories, then you will see the following message the next time you pull from one of the above repositories: $ git pull --tags https://github.com/openjdk/jdk From https://github.com/openjdk/jdk: * branch HEAD -> FETCH_HEAD ! [rejected] jdk-10+0 -> jdk-10+0 (would clobber existing tag) ! [rejected] jdk-10+1 -> jdk-10+1 (would clobber existing tag) ! [rejected] jdk-10+10 -> jdk-10+10 (would clobber existing tag) ! [rejected] jdk-10+11 -> jdk-10+11 (would clobber existing tag) ! [rejected] jdk-10+12 -> jdk-10+12 (would clobber existing tag) ! [rejected] jdk-10+13 -> jdk-10+13 (would clobber existing tag) // continues for many more lines To solve the above, you will have to run the following (just once): $ git pull --tags --force https://github.com/openjdk/jdk You will also most likely have to update your personal fork, this would be done with the following command (run it just once): $ git push --tags --force See the original e-mail below if you wish to validate the hashes for the updated tags. If you have any questions, please let us know. Thanks, Erik & Robin On 7/2/20 12:02 PM, Erik Helin wrote: > Hi all, > > me and Robin have discovered a minor bug in the Skara repository > conversion tools. The bug consisted of using the wrong time zone when > converting the metadata for a tag. To be precise, the conversion always > used UTC+0 as the time zone for the Git tag metadata, instead of using > the time zone recorded in the Mercurial tag metadata. All other metadata > for tags is correct, including author, message, UNIX timestamp, the > commit the tags points to, etc. > > The bug did *not* affect conversion of commits due to different code > paths. This bug was fixed over a year ago, but it was unfortunately not > fixed prior to the last full re-conversion of the jdk/jdk repository (it > was fixed a couple of days after the last full re-conversion). > > The impact of the bug is therefore limited to older tags in primarily > the jdk [0] repository having the wrong time zone recorded in their > metadata. Specifically this affect selected tags from jdk7-b24 to > jdk-14+16. > > The fix is fortunately relatively easy and consist of two steps: > > 1. Re-convert the tags with a recent version of Skara that no longer > ?? contains the bug. > 2. Push the re-converted tags to the impacted OpenJDK repositories > > Step one is already done. We are planning to do step two a week from > now, Wednesday July 8. After we have pushed the re-converted tags, then > you will notice the following message when you try to pull: > > ? $ git pull --tags https://github.com/openjdk/jdk > ? From https://github.com/openjdk/jdk: > ?? * branch????? HEAD?????? -> FETCH_HEAD > ?? ! [rejected]? jdk-10+0?? -> jdk-10+0?? (would clobber existing tag) > ?? ! [rejected]? jdk-10+1?? -> jdk-10+1?? (would clobber existing tag) > ?? ! [rejected]? jdk-10+10? -> jdk-10+10? (would clobber existing tag) > ?? ! [rejected]? jdk-10+11? -> jdk-10+11? (would clobber existing tag) > ?? ! [rejected]? jdk-10+12? -> jdk-10+12? (would clobber existing tag) > ?? ! [rejected]? jdk-10+13? -> jdk-10+13? (would clobber existing tag) > > ?? // continues for many more lines > > The above means that the tag objects you have in your local repository > are different (have a different hash) compared to the ones in the jdk > repository [0]. This is expected, since when we are re-converting the > tags we will use the correct time zone (not just UTC+0) and therefore > the metadata for the tag object will change and therefore the hash for > the tag object will change. See the end of this e-mail for a full list > of tag names with their current hash and what will be their new hash. > > To solve the above, you will have to run the following (just once): > > ? $ git pull --tags --force https://github.com/openjdk/jdk > > You will also most likely have to update your personal fork, this would > be done with the following command (run it just once): > > ? $ git push --tags --force > > The tags will be updated in the following repositories on July 8: > - https://github.com/openjdk/jdk??????? (read-only) > - https://github.com/openjdk/client???? (read-only) > - https://github.com/openjdk/jdk14????? (read-only) > - https://github.com/openjdk/jdk14u???? (read-only) > - https://github.com/openjdk/jdk13????? (read-only) > - https://github.com/openjdk/jdk13u???? (read-only) > - https://github.com/openjdk/jdk12u???? (read-only) > - https://github.com/openjdk/jdk11u???? (read-only) > - https://github.com/openjdk/jdk11u-dev (read-only) > > Project repositories are not as affected since they don't sync tags by > default. Those project repositories that wishes to have their tags > updated will certainly get that, but can we take that project per project. > > The recently converted jdk15 repository [1] has tags with *correct* time > zone metadata, so you can also browse the tags in the jdk15 repository > [1] to verify our statements in this email. The jdk repository [0] has > tags with *wrong* time zone metadata, so you can compare the tags in the > jdk repository [0] with the tags in the jdk15 repository [1] to verify > yourself that all metadata for all tags is identical except for the time > zone. > > If you have any questions, please let us know. > > Thanks, > Erik & Robin > > [0]: https://github.com/openjdk/jdk > [1]: https://github.com/openjdk/jdk15 > > Q&A: > > Q: How can the UNIX timestamp be correct even if the time zone is wrong? > A: We parsed the date from the Mercurial tag correctly, but when > ?? creating the Git tag object we did not record the correct time zone. > > Q: How could the verification scripts miss this? > A: The UNIX timestamps were identical, only the stored time zone > ?? differed. > > Q: Why aren't regular commits affected? > A: Tags and regular commits have different code paths in the converter. > > Q: How can I know that you aren't trying to sneakily change a few tags > ?? to point to different commits? > A: All hashes of the new tags are included in this email. All tags with > ?? correct time zone metadata, and therefore correct hashes, are also > ?? available in the jdk15 repository [1]. This allows you to fully > ?? verify that the tags you pull down forcefully to your local > ?? repository on July 8 are indeed the ones listed here. It also allows > ?? you to compare all tags in the jdk repository [0] and in the jdk15 > ?? repository [1] to verify that all other metadata, including the > ?? commit the tag points to, is the same. > > Q: Should I in general just use git pull --force when git complains > ?? about a tag being clobbered? > A: No, never. See https://git-scm.com/docs/git-tag#_on_re_tagging for > ?? details. > > Q: Have you found any other converter bugs because of this? > A: We have gone over the code (again), and no, this bug has no > ?? additional impact. > > Q: Will this require a full re-conversion of the jdk repository causing > ?? all commit hashes to change? > A: No, see answers above for the explanation. > > Q: Why aren't all tags between jdk7-b24 to jdk-14+16 affected? > A: Some tags between jdk7-b24 and jdk-14+16 affected do have a time zone > ?? of UTC+0, which meant that the conversion was correct. > > Q: Why aren't tags after jdk-14+16 affected? > A: A more recent version of Skara with the bug fixed was used to convert > ?? those tags. > > Q: How can I know that the metadata is correctly preserved from the > ?? Mercurial tags? > A: You can choose a few tags at random and compare the metadata with the > ?? corresponding tag in the jdk Mercurial repository. > > Q: Why does Git and Mercurial store the time zone the commit was made > ?? in? That doesn't seem to make sense in a distributed system? > A: This we actually don't know. Our best guess is that both Mercurial > ?? and Git choose to support dates according to RFC 2822 format which > ?? does include the time zone. > > Full list of tags that will change: > > TAG NAME?? OLD HASH -> NEW HASH > jdk-10+0?? 56abf3ddbfbca65d9d43344bcb53aff3e168c817 -> > ?????????? cbfedbbe6ebcd34cf8073ceb3b9778338f0de722 > jdk-10+1?? 1768e99d6a9f13867e02edc5c55e81df0395b61d -> > ?????????? a5719b8b503113d34a7037cd95ae9a75df465847 > jdk-10+10? 41fab65152a5a451cc8e53fae7ee13f1939bd3bf -> > ?????????? 5f7f102d588428f8f5e700c3b0be76f1e5bfddcb > jdk-10+11? fb4c56701cae7bbf62f1a42699639d4ba542a230 -> > ?????????? 461ee9721bb0693c2e3f2addf4bbb47b645c6885 > jdk-10+12? c9988d821eb72461580563149f15c135c764d603 -> > ?????????? ee812681b38e719e0abf0382c72dfb196ec09f83 > jdk-10+13? f76cc3b57d749c8265bd689e4360a854f6003812 -> > ?????????? ffc5b1ebdf0a02687aa9b177dbda3ba1cc2ae32a > jdk-10+14? 86ffc0eafe2796a6807c6fbb8ff032d4a39bc63b -> > ?????????? ad42d50c857e6e36088008a5d130f4cd60bb7c6e > jdk-10+15? c58d2be493f9c1d83ca94463eaa0a82c407bc9ea -> > ?????????? 689d3132b150d15c6934225e3e7b1092fa266e5b > jdk-10+16? b48b8ef4cce601bc4dd0ff06d0779dfa6347efc3 -> > ?????????? f75cf7c4e209f2aab57a0f4a9322b4879155381f > jdk-10+17? 94dd894e29a5b68bb5e135935105f8b0f173d98e -> > ?????????? b781e3196724e8a790a4495b021e6559ba09c576 > jdk-10+18? 5510ef3e6440803979fe1f94fe8a92cdba1ff4d3 -> > ?????????? 15d921aa5c5f5e7a74d87d0a73b4ff9906ca2fe1 > jdk-10+19? 5426bc03ac136a1d3fa1c09285542fff55a118c6 -> > ?????????? ba483867b8a25a048cd7bd6671c4e17764061613 > jdk-10+2?? 6a76beb2061fa82bb7f8dc984a6afa4e9ea6d5df -> > ?????????? bae6cc13b2ba7f664d2623cbda0023c83e26d4a0 > jdk-10+20? 61df92fad072873a777f7146026788eee06b92cd -> > ?????????? cd8f3bc879e19551b62a198a3863c155d31f1d02 > jdk-10+21? 3c14d883be5d143d79264d75089068d4867377d5 -> > ?????????? 1130c75bbfd94f9c6a65e9df6762ebbecaae8964 > jdk-10+22? 82ff87a7b20d98e291f327b15f083108aed23f28 -> > ?????????? 6bd3c79ea6c0a224d5d514b7a98abe90d69a220b > jdk-10+23? d9d89aa12a5593f6d1eac198e9564d0ea0b03970 -> > ?????????? 231077803760a76522c821f84690e26c1c1e0a52 > jdk-10+3?? 45c470ee766616a2f692c443cb9515c4580f89e9 -> > ?????????? 7cb8df7b70b7d5e2f3bedbded6b158e602a4a42b > jdk-10+4?? 00c226446c5c473d894bc8c90dd148e1fe8be3c9 -> > ?????????? ae0756036271062a547477d8e38f654b88ccbf50 > jdk-10+5?? a953e6074865b4758dfa87ad196e442453e91d77 -> > ?????????? 281982de41c8193c72b36665ea3deba77e9d3f3f > jdk-10+6?? acccdb04b77a96689d683dc3f3db5745e3b60abd -> > ?????????? 3ff805ece2993979993b8d4a38a19eedf5cee82c > jdk-10+7?? 65c9eadbf0d27a20b9ce829d7984aa68eee7bde3 -> > ?????????? a16f7f3960bd905f55f99bbc3fcea0b8612cc001 > jdk-10+8?? 907f750e97bed1c3e4cccc28537053a0d90feca4 -> > ?????????? 790b6cb0b07c60cd8498ac22ec9e3bff95239aa3 > jdk-10+9?? 363060b07b5cceb0d5b34168cddbef14c2f66d61 -> > ?????????? 692a723c417f00062a3b3ca4b401ea627c06396e > jdk-11+15? 51bba3f6c8881ece709f34824c94d5089b12f6aa -> > ?????????? 23fc97ad76fe2fd50c66f6df9eed8af0b82e3e79 > jdk-11+16? 36c5eea234040e0ad017bf148e587e0472949726 -> > ?????????? b13c8b270d477d104059e8e675f8819dd4f375bc > jdk-11+17? a89bc16a886e76a642467d39f026fa49c3959faa -> > ?????????? c3aadd37733cd620c4d6baa37367fb598031924f > jdk-11+18? ee7eeac1359039cb5b4e8044d17c3c0ad02f7d8f -> > ?????????? 00bd95880c2d6a113a84983cff091d816aee69ca > jdk-11+19? 66475a5f9d76d39c8c569a921db3e553d1649623 -> > ?????????? ed1cdef8f8e0ba88a9731e00762775d2b59dca71 > jdk-11+20? 9b53644fe73f8ae54fcd635189b84c00ce0a6636 -> > ?????????? 38a7f0b2631b5e8a0d401f619300a5c1fc863d79 > jdk-11+21? cfad03739c9caac21c4dfc292d389081ad47e751 -> > ?????????? e32e4a2efd2e744aea1b975ab5d094512f029ad9 > jdk-11+22? 663ebfe873c8b6c0f08d1a9654be637f1b217c09 -> > ?????????? db1d8cc927f44eb5956931ed03997e683fa346cd > jdk-11+23? 35aa1747aade90d39a7bf996fe5edd3395186027 -> > ?????????? 66fb7c8d4800be881ab519e2da50f98e104b5ebf > jdk-11+24? f516d8adcf49afd8d696dba128f8bee0fbfb4091 -> > ?????????? 744bba07a673601512c3e5a6bd1845788635c4b1 > jdk-11+25? 39b5213e33be6c83a233d87e6cdae9fcaf2fb4c1 -> > ?????????? 5626d9f41e656d488b2b3335ca41b4726e05a63e > jdk-11+26? dbe968553594f4516c429eae1fe84ef7e060bea9 -> > ?????????? f88fcdf49eda0fe30f154a9d935631c2a4a38bbb > jdk-11+27? a171a0154b1a911be2602a01ffa8e7ea946b0def -> > ?????????? ee78424c97284d9195b87003be54acfb8e34cd1e > jdk-11+28? 6e5885d939a834e01392e975964d377a24004b8d -> > ?????????? 6953356297f51be519e94a63b2c570d7ac1da826 > jdk-12+0?? b5b0fdef245ded2afb9bb1ba219644b31cccaea3 -> > ?????????? 9b8db1756bfcff2633049e1f5dd8a8f7c2ed7c9d > jdk-12+1?? cc19769f1752822586c630a02ea7948700e8fb4e -> > ?????????? ad4caf8d85b8863e9891e19ebaec5f5ae4b18ce1 > jdk-12+10? 2a0f5c11fa63c8678bc5088aaff75fb3dfcb1bde -> > ?????????? be536339f1b0f4ec0726335c336a266c13f22b48 > jdk-12+11? 7ae1df96d80afcf0de0e073eae364fb7d9886952 -> > ?????????? d56879ac9dd6d08f20caf5fefac64203e6cd3b87 > jdk-12+12? 80546944dd93084f559371caec2e8bebad4e6445 -> > ?????????? c812ca8928b7d9727e85eca694a06e2acdd174c7 > jdk-12+13? 89cc7db3ce85f8e2b3fe2a29413e6a70c0209095 -> > ?????????? 6427b92dc2e0dae2bfb0652e79fcfcc546a6fe3f > jdk-12+14? 20014767621b9aa7f135c382c120efd4d88ea3f8 -> > ?????????? 7ced54a9737663371ff3fb82c23d9b1f63139fc4 > jdk-12+15? 82722dd0d25a499d796a8964877b5991b3470c12 -> > ?????????? 5bdc0959c89565e8709b632964a99725e337767e > jdk-12+16? 6d0771f45b1e5625cf79b1f898040e1762e8ae07 -> > ?????????? 935482ea790aee7da4fe954c077c66e6256ca3f6 > jdk-12+17? a6eb0c19eca858b517206fbf15d53f8661741979 -> > ?????????? 210c46ad4a627be1308daabbdb0310d1e0d1f373 > jdk-12+18? 317458ce59082a3bace88310e34ed8637208ba75 -> > ?????????? 006b92b11a2c32b47acda6faf23f5c4cdb96d77c > jdk-12+19? 967afa84d6a2ee6f5dcc5861e32375e038d05f3d -> > ?????????? 8e2e78ee5214c323da598ab57e9214b48b408f00 > jdk-12+2?? cc2d3951ce642b27ad9dee309672b38789a9ccfb -> > ?????????? c3b47c7d216c26a9bd2f40ea0a1b6b195ac15670 > jdk-12+20? b561d4d76911ce36a548d5de258b1fc4554709b5 -> > ?????????? edadc5a4ed87fa1216cf6cdf4eb36425d60bdcbb > jdk-12+21? e432c88d0ea97ce1aa0ca6eeaf6a3638768ec02e -> > ?????????? 2b509f0b196b983a25fee406350401ac83810cfc > jdk-12+22? 619ae685910188e10e4e5c5ca9e50bb061f0281b -> > ?????????? c9288e96dba7a5c5fe282466acaf8ee751af73df > jdk-12+23? f994f5ce71df63823f0b3ddc104c182e1b20fc06 -> > ?????????? 68e5ecffe48f6e1aec197dc65a64b8918a941a3d > jdk-12+24? 078511454cd75f01a86f595d9e1c5254dbf86001 -> > ?????????? b1ed6821adefc061af12c5362031d90d8b00259c > jdk-12+25? 2c218fdeafb2300fb1db90129b564a3b31861790 -> > ?????????? 83332e95c0f77ef7faaf5b67a394751ac85d68ed > jdk-12+26? 0e780b41b2e335d042a908f92f665e75b9db701f -> > ?????????? e16c222bfac045078cda9a6a237a93f5942f14c1 > jdk-12+27? 1e875175a9f4897170f7572486287b15985dd838 -> > ?????????? bc18f89d46e59564902ba5110900696f81c39b3a > jdk-12+28? 379c1ccd608938b3fe8ac4161e6418692c2a30d2 -> > ?????????? aa2562349517abb1f22bb1892df0360013e5584e > jdk-12+29? 7b50b9329426e7895b82fecc4524c5a6576d73c4 -> > ?????????? 095f5860b1dc7c1e88f67f801bd141328b601fd6 > jdk-12+3?? ab8a10e7ba04208bfd53c141879691fb8e921da6 -> > ?????????? 06a419b32ce1ef257a80ffba0244ea20ee6c299b > jdk-12+30? c459c0ab63f4bba79812f04c1fe8752a8d5435ce -> > ?????????? 2e4741cb7e7ebeec9b9ab959c5dbada61f31a28e > jdk-12+31? e5d281f7d5d7b742b5d76740afb2d6af0f9552d1 -> > ?????????? d7d21c1be37803b2a00a4597c9ce84fe5b4e4863 > jdk-12+32? 4986d2a1d0b6252c5539e3d02cc81c8db8f8f04d -> > ?????????? 66a64c8b17e22ef4743e23b33e353ed9318eac08 > jdk-12+33? 0cfc17487c0e20cafb5cd80bae7750ac61456f35 -> > ?????????? bbb5ef28071d565e5e89df06b8b43ce8c8e59b7a > jdk-12+4?? dc6231698b232b08afd058705ad2c7a1ac84b794 -> > ?????????? f6bfc5aecb9d19fa43a9e8e5a45854059812f92c > jdk-12+5?? b17ca473401c0db567291d480a7a01563b323bb7 -> > ?????????? 61aea3dda8f8bf34a5dee10ef08f04f10791578e > jdk-12+6?? 6a7b7b32dea00bb05a41de97d6ec99f6a5d4c3d3 -> > ?????????? 7d013ffe610c249da34029375c15a80daff2b5bc > jdk-12+7?? b7bd7b5b2c672c1d398f89b6677107b853898fed -> > ?????????? c2ded2245199098d0ab6004e64d635d6468caafa > jdk-12+8?? 711e3a9496c36ee6526e80b70b79254c5141949a -> > ?????????? e911a5ce3929d2766f2b9c7e598f1f3bf3224a6d > jdk-12+9?? 43d0d4542fa8aba9bdc46a0d02ec364fd801f3b3 -> > ?????????? 754dc1754b2e05588a11152025520164d1ef9371 > jdk-12-ga? 186859863e228bb275e67bb0205b584d1c354e78 -> > ?????????? 811cfcdd439b26cb43ef94a7a026140727dd8e7a > jdk-13+0?? 11d0b5a7f1fd13c349684bfbd3e3afdf9c83373a -> > ?????????? e4046a86a60f2b5a83bf5eeafaa53e06f96131ab > jdk-13+1?? 16a775f11730f4bde21fbb505518e23070312d9e -> > ?????????? 7c7ecfd4b91691dbb16f64fb8040a84d79e3706b > jdk-13+10? 10a1295e4a726a07507c4312e3b0fcb443fe8548 -> > ?????????? 882ad1e7a1ed6f2d90078659f392ce0b052b0937 > jdk-13+11? 11cd73a47633076b7834905cf30ab7f6e28118ba -> > ?????????? bd6bdb77acdef6be54e9eaca2fc3b15c0a5ffead > jdk-13+12? b82f0ec390181786c68d8a3d93eed2bae7e952f3 -> > ?????????? 2c1f42e838821a5f7f3cbc8b52e9d93e18e1dc2d > jdk-13+13? fbc5f8305e30af5d11ae09dd10767058816f1ff4 -> > ?????????? 00ad0322ca5f0ce2446fe0848e1f76ac3d060502 > jdk-13+14? 0757b7fe131b0d645c5b7cc1527eea928eeb665e -> > ?????????? 1b7f90951e62b0e6109d7601262a3088732d8d1e > jdk-13+15? 26a9614460cdb31eb714ddd22bc951b19c0dd338 -> > ?????????? c9761a2537221aee7148f485aadb33ef407fd9fa > jdk-13+16? 58d54c2afdb9276f5ce525faa01550f20b7c1e61 -> > ?????????? 1ff0bcde4e5770b51635eed1e4246ed0c913a123 > jdk-13+17? 0a9a39ad5607c506c5773e5e1c32c1fdbe090b28 -> > ?????????? f0c7ac798f82bdd483f17cb6294d33d4501de334 > jdk-13+18? 5d4d157516315d58dd3ea82b64c677cbbc66b7a6 -> > ?????????? 5297738e3f3ce70f505f2a6453d4702f7ae14b76 > jdk-13+19? f5fcc800b587fa51ed41d4be6735d42fd7fcf571 -> > ?????????? 8a761e6667eb67930cd0a269e15432b17d03326d > jdk-13+2?? 6cdc029b59c82fc107437c7897bca89648af8203 -> > ?????????? 4e8d833bca1bfbab67a69519c9916525a17c145f > jdk-13+20? 2ef24e80bc1f410aa93024c4e4945b1ff76915aa -> > ?????????? 7cd1a111b8892181541640fb7e8675348c41fbfe > jdk-13+21? ceda887389ac5fccbd1ebbbec69216c09a9ff179 -> > ?????????? fb783070edb4a64bd2d66ce147eb78a944c63fde > jdk-13+22? db75df2c073530d8711a498141b1c7fff7fd9761 -> > ?????????? ea5cfda2e2dbc13913bbb4f5a4cb6b84d13582f2 > jdk-13+23? e485f6d8937b16589536a3a6059cbcecd3335092 -> > ?????????? aa3cd722688c6ec38e5960027ae75e6568756523 > jdk-13+24? 721c0cf4443528921caabc495975f8c5d130abe3 -> > ?????????? 8506b5f491caae26b54cfd1e0c5018ca7e2c5410 > jdk-13+25? 63959faaafb123be918f1c6d0899d53c7c78a736 -> > ?????????? e84b2c3b811ca2733aa226f04472261a58e7ad34 > jdk-13+26? 4383f046e34a846340693c438a1114ada4d374e8 -> > ?????????? 7222f2cadbd7982d184eb7bb9b60c5e06c76f0cd > jdk-13+27? b4ee3697e966f9144fdc5382e95c4c11d782997f -> > ?????????? 767e987b2308453c67c49c3a8a3170f307df93da > jdk-13+28? aacc9de390a04aa423bbc200c1dddc0be859beb0 -> > ?????????? d41571ce957b6c4acabb58b3d3479265849095ce > jdk-13+29? 03d48f882dcd9f3d7f5c06bc6f049c20cecb2975 -> > ?????????? 142fdf203f146c71f65578bbb982cfceadec90f1 > jdk-13+3?? 9fa337579561bf72cdbaecd02b3e68008fb26485 -> > ?????????? a688551e3b70baff64ebbdbf64d495bebd64e8ce > jdk-13+30? d84b55cc559030419430657c4d2d6f376ab0ed3a -> > ?????????? 30833b4ef182aecaea1f7203c85f01af3a107951 > jdk-13+31? 6a1e4e38753342b2f1e6efb168a20e8d42426573 -> > ?????????? 3d21be4bb1a65ea5f52d58ed7db2b183f9e2bdfb > jdk-13+32? e752c480f4f03538d48bd78f39a4345a85d96ad9 -> > ?????????? f33ad7469008f06bef62422c0b44cbc454721b55 > jdk-13+33? 812ea1dc22a62e17d9f497885b006d801642ef45 -> > ?????????? d2147f122a68ff7dad467f2189692d7a5dcaa994 > jdk-13+4?? d0b301aa80c3fac87ee16d2c70bb2c4a314f4a55 -> > ?????????? c616d2c467cf135a769f5815552d70a1e7c7ab76 > jdk-13+5?? 4a0a76ca6dbf1fb29a788ad08d5c8f4ba9e5d0c9 -> > ?????????? 5d4c3054372e8130b556db2fd5ed0fecd9aafb04 > jdk-13+6?? 4a4f29de0581b8e1d91de31b81d45da48d581d51 -> > ?????????? 7bf45f7788f3e592b022ce5b282fa2fd1df9cb41 > jdk-13+7?? fc914d6b576b3b0326ef568c3d54568bed3b4506 -> > ?????????? a5018571f4126fea173607bee493edc4fcec9b43 > jdk-13+8?? 865a6fecaf1ce7c8871d6c66bb7bdc03e1576c84 -> > ?????????? 0e6cb38e885bb31b05e0e6e20b052ec5d1b63b1a > jdk-13+9?? f33fb0805914f4b8f31851d7a26befee86b10f8e -> > ?????????? 604d805e6ab31f12c223a8e56e221e33bf2bf5fd > jdk-13-ga? 6dd4feae9d4b3e489dcbf8189b5912bb8511be17 -> > ?????????? 0ad97cfaff032eedad27e6913062190b28d90142 > jdk-14+0?? 3631f9d59b7c0526aceccf8439217d08f5213093 -> > ?????????? 0d4f9c3cf08b1108e3f1f61d7b3222fd09d3f131 > jdk-14+1?? 6098f7f85fe0a7226550f0bb90315f7fba72ba64 -> > ?????????? bc99303c2737d15917be7981bfeb4e476615af72 > jdk-14+10? b0c8e05a47d6574c76ae40d7f696936679c83ee4 -> > ?????????? 2413f67fb9f183e8fe3267e7f9dc97bed8bcb904 > jdk-14+11? 76443ec6209d1040b2d505e15c3f8653f714f41f -> > ?????????? c6c719427790cbcad26d4448924b865db44fa593 > jdk-14+12? 1c9579a52248bc108f36761ed220ed8b3565fbf1 -> > ?????????? 528d85f386e9e944fa9ff3ab553317e0a98dbbd4 > jdk-14+13? 3f6845176db0af036cb519810e3a5b71182b90db -> > ?????????? 8897b80a2e56a6c11ca305903ce2052cfcbfc2f8 > jdk-14+14? aeb41123e48be3b76878d9becab9faf33dcd536c -> > ?????????? b9e6e91b985767048fcc7d3de485eec6765e3427 > jdk-14+15? f65e35df3301d99edaf23c1c5df59a6d08735ba3 -> > ?????????? 8af492815eb40e377e41c1fd3becc11c314faade > jdk-14+16? efd4844fb8b2f357ace05570de24adc192a1503d -> > ?????????? 6c7ee03be862179f7bcd6f71aca7268714790580 > jdk-14+2?? 9f41b59a4ec34354234a3145b862502a7ef14173 -> > ?????????? 6c604f0f5872d019062c4014ac35e13caba290af > jdk-14+3?? 201091d6a571c71c2e6c18429a8dced661342aa2 -> > ?????????? f8156701be3c5a299b7db0f602b20647c0393756 > jdk-14+4?? 46c512285e4c67dd41a415ae5204db0c645480fe -> > ?????????? 3f40fb49ef94b3219efe51e21b1cf95b8f6908bf > jdk-14+5?? f4c5b98f59e7f2c41759d71e07764944aa93a8cf -> > ?????????? 1a8d4850384e564859b22872a371f36c6dcd6722 > jdk-14+6?? 70ad7e414a7628c9db54e962f311fad5ab73867e -> > ?????????? 9a30bfac2500f6fbadda8ac8b9f4d7b2f1b165db > jdk-14+7?? 56fd2001d499da9f8857446c2e035658adcf8433 -> > ?????????? ff6547d9a4e125c06ef686b0dfbe56b3591d3e39 > jdk-14+8?? 5369eba42050d02626cce16a409ff370b81cb084 -> > ?????????? 4ac9e301282ea83ce5aa7c45d50eb847298a3dd9 > jdk-14+9?? ca754e2127de528260dc2689a7bebb23fb4b389a -> > ?????????? 93572b4bb6104fa691385825fb7a7f6fba42a185 > jdk-9+100? 90b490cd9b8872b8ab2b9a4ef0eee9cbf8432b66 -> > ?????????? 1582a7e598bb8b1823a5c386b801dc44a1d25249 > jdk-9+101? 35339f91ba3f32b115e8da2bb98254f957a4b663 -> > ?????????? 69194310cf0464d81d37d8df03e38fc3d2710579 > jdk-9+102? ca759f0cc17e9f5d15045db4357dc39c5f36739d -> > ?????????? 6615f036e258e739a2abb71b303790064c4734d3 > jdk-9+103? e307b4d912561beccdcd7b4e831a7e85df454115 -> > ?????????? 3a3a073a2da66d9e18ed4c4d19b92d09240ab090 > jdk-9+104? 3146062e79ad203c11026b41940037ee027b358a -> > ?????????? 4e88fb28c6b1edc8d20e445af39149e3e23d1996 > jdk-9+105? 282aeb1926ee8dc9673a77b3ea2be94d80f6551e -> > ?????????? 4ce5077f2b106588dc552715e66ad7023cf1eda8 > jdk-9+106? b88d654a03ccefabcab190646a89d57d59eb33b1 -> > ?????????? 2df2831b8e08b4c1300db067fe80cf3af0ec40bc > jdk-9+107? eacfce97814ff899382f666bd577c8260ebe995c -> > ?????????? d0db872057fbf050ac8deaac7cb47a55712f7482 > jdk-9+108? e9823377ac47df21d261d81a6f26d444049fbdf6 -> > ?????????? a11e025c63b93c65781f55c53b7313bbf7c92875 > jdk-9+109? d0a6f61a1ef4ab17df284c79742e6ade65172b59 -> > ?????????? dcc8b52a59746b20736d9105e8e0de09857155df > jdk-9+110? 1fabe19e8b3e631aca11d971dec3221270ca6a05 -> > ?????????? 8441913a0b27212e660ff451eda2370188ac38ff > jdk-9+111? 3b697686b777177fa0532c3ce1e08e2c7c51bd97 -> > ?????????? 88c5f7382d4ce0a11e92a61c4e3d587934ddb881 > jdk-9+112? 9cee88d0babbfb3128cdd70f3eb3af4419a440cb -> > ?????????? 778fdbafa31121eb5f1bbcd78b49b9328dd2c7e3 > jdk-9+113? 37562c132d6fe180a0a7e223520e7b879b7e8045 -> > ?????????? fdd70c9fbdcfc82f251b1160542922bf2cc83d39 > jdk-9+114? d846cf6f1fc1b92768fb11a29b2e4a23586a55ed -> > ?????????? 5937ed8624520c254f9399f2a65ad94094aedf73 > jdk-9+115? 60871d264700b27a04a424bef986243ccfc9afc3 -> > ?????????? 564d309f0d310c084ad2f98f3abf298c979a45af > jdk-9+116? 8618b5c258788836f521df0b83937aa8978b8c54 -> > ?????????? d5b77b3bc0fb4bbc5fe7f30deb061279eb419e4b > jdk-9+117? 79d894596b44ecb959477253a0484674af4f1fc8 -> > ?????????? ae90286b9fd00ae17949088dc64f66db08cc98cb > jdk-9+118? 8cffaea43f25b980199182bf0715d4282972a385 -> > ?????????? a521614410de91f55400a6e246c9694fc148cfb3 > jdk-9+119? 3f4b3a44add1ee1541a8c6f986e18ee10db9fe5a -> > ?????????? 04ba9e69a4f6a09d5f74235ffdfb829d5cb5d998 > jdk-9+120? 4e26726c3eeea2aa4118ef47fafa63ad2b3737f4 -> > ?????????? 4168d03091702d5ebc553bfa0c8e14b0a54359dc > jdk-9+121? 17459968aaee8dc8fd7ac6a33f4fa9722fbe23b4 -> > ?????????? bea448789d1e3bf695d33094adf7e6b39fd5846e > jdk-9+122? 838016064070260114b52cc1bbea7ee9a383626f -> > ?????????? 0422b80ad16d16ddc1456742b0ae2fbb7cf0df45 > jdk-9+123? aa6bb5b359436699b875f193805634e3650a4f3f -> > ?????????? 37f7bcd6d1f8324bb153163b5c754794d2526f5a > jdk-9+124? b231bd78eb64da089b23c7246a72379935042669 -> > ?????????? 1e848753437d25fdd0590d3ed9b46328313d4a41 > jdk-9+125? 402fd8aa898af5b52263c74493871bde83c77787 -> > ?????????? 53a00f16ec6652ea85d7dc381fd38897460f44b0 > jdk-9+126? 2672f6889ed166a8833bf11d4df304a62d85996e -> > ?????????? 747f6bedd64e86aada33da154dadf2e57db01902 > jdk-9+127? 5cc5e06ca472f8e7cd185fbf17a7e1b3cacf819f -> > ?????????? a2c7e6a714ca7b2e5a50787035ff14b3b678d94e > jdk-9+128? 7bdb3f86c3d1c5664e399f6e754380a6a73b2dc6 -> > ?????????? e83a1980e69679b58cbfb906cb48d538300375b5 > jdk-9+129? 17f13bfca752d9c98e734a4006e0326e69bd90bd -> > ?????????? 67593f151245ee408b03c4f71525ebdc301a61e8 > jdk-9+130? 6d738a359038b6dcab2bf77865a4a219c5ab71d5 -> > ?????????? 10a78c405152f49db1e8d25ca7b85bfc9d0f4490 > jdk-9+131? a646209805a5f0ada8fbc73a939a0e8119503433 -> > ?????????? ae5472b20f020ccc4cbb24c920f9e83a85a335d5 > jdk-9+132? 735d4938261f5b27d7ba55425103399829c55cd1 -> > ?????????? 2806304c1728c7824844312872529797002e7a83 > jdk-9+133? ebe3c1513f72f108ca684c2bfdae5f5954ce5322 -> > ?????????? 1ec5b887d12580ad7a8d48618bfc89e7961662cb > jdk-9+134? 7d57b04d709bacf20e26952a7d1c9883e5a5aa08 -> > ?????????? 4cc92828a5b6f8a837e70a9de3b294b5b629f249 > jdk-9+135? d64fb234933d3f90cec846bc7db9fbb6b05ab2c1 -> > ?????????? 64d8ae2a938a71579daf9a5c74e908a1d23784f1 > jdk-9+136? f75ae7ae42f4dec9ece61c46f6604f55b9693b8a -> > ?????????? 188443a1cf685af954f49129759ab15f1b280ca0 > jdk-9+137? ea6e9f0fdb3268f244697c3367659d5a3ed4b434 -> > ?????????? babb175caba72b0275c134c4f5d20d6949fb3a4d > jdk-9+138? 7e1b45b7954cd11131ef26e7fe8e187ba4d1cbb3 -> > ?????????? 111a602803c9ca87f916513bba13caf153c7a48f > jdk-9+139? ea56ded9135632f09ba53053420c01be4623f8d9 -> > ?????????? 2c95bd4634f8637edf605b71e0a56d8c7fc7a698 > jdk-9+140? 7d47376e25e9a9511d1af8cc81183ec779827862 -> > ?????????? 912618bc20d708c9e101dcbc6bbfd5eac518306d > jdk-9+141? c4a7f63d1398612a1f332c1d311c36ad9f16ead6 -> > ?????????? 413af7e621ce90e1cae041f84fc6d88c668c2757 > jdk-9+142? 226f74d2dd0c8480c4d335215b6b164309e02407 -> > ?????????? 3af5051c95bc68fc3288379b2caab2d74d9f510d > jdk-9+143? 747949a18c3081a88ed7a8ee690596f521dee921 -> > ?????????? 18cd9deffb9334c6d4de4170d3466c7e171e4cc1 > jdk-9+144? 0c8e590e23d2a474f4f416ffba95f9d26b951947 -> > ?????????? 0ca5855de1e081c5d05cdca36193d1ace0851f7d > jdk-9+145? b008ba190ab415f046492979db245192f43aef40 -> > ?????????? fed65b0cb6e5152c7e6825f2b568db7756412ac9 > jdk-9+146? e9624d52b0387bc94e2be63694979bb385da9088 -> > ?????????? 4264d788f4f06589935c791af4d832285ead63fe > jdk-9+147? 99f28b259eab298e4d02edd3bc5e42dbf7158d8b -> > ?????????? 693f974b82632f0c8f8f7f53c336415c15e395a4 > jdk-9+148? dc0723fcaf4cc47767bb8f3514ceec0c2c8274a9 -> > ?????????? bb94041006a84518c84fc4ab19a56af7a51fd4c1 > jdk-9+149? a28a5a66c224627dc543da81c5bdb24d84c6bc0b -> > ?????????? 9aa750b64d540d41c089c3aa5869d6ac46f06f1d > jdk-9+150? f65cfd71515d2dca0b803708be4e88c14a8923bb -> > ?????????? c041586d1ec6f3e1ca4a0cee726578ec1f7477cf > jdk-9+151? 5819b4b63168301a92783c899a0e4524acb13627 -> > ?????????? 0e1605d316a81f856fe74d8b15d41f2a767de401 > jdk-9+152? c95f9b15617644c6428e158420b0e39521dc5e37 -> > ?????????? 7ac6cd64a404e4a06d2e14f8e6094f3ee6111957 > jdk-9+153? 5c68ce693feba27360d2b68c2d32e5768258e8e3 -> > ?????????? 16eb94ef61f32bd96e5828526797fa5459823ead > jdk-9+154? 9371fc8665d33b24fdb5a2eae1d6ee73d76e3382 -> > ?????????? b3015bc86a57a81627bc1cab6ffe6fffd483d071 > jdk-9+155? 9e0113a5627cac2a20bb2a9d153569eb13f955ba -> > ?????????? 530f37b6fc04de413e3565757bb0f8e548c9b56e > jdk-9+156? b5547fcda52074a350c7d54bd6e572b6862227dc -> > ?????????? 8bd9152968ef49b41449cd6c87cb89c5202f592b > jdk-9+157? 39da0a7285df7d9ceb27d411b997c67ae63b5ee9 -> > ?????????? 38701507135dab7863d04fad29623127ec5da86a > jdk-9+158? 180addab4717ccf0f80a6df8ef119b9bd0fb4430 -> > ?????????? ffd4fd05b24e852a41a43b73a94fec69a51e0ee6 > jdk-9+159? c7f44582f8d4db5fa7db51421b64ce7c63577d49 -> > ?????????? 737886208796fa017c65227afb2c813cb482f855 > jdk-9+160? 586d647648c407cc244902f9d2ee1a9a02041ace -> > ?????????? 85d94b54b00fece2270d6f3c1895b3c0b86a6183 > jdk-9+161? 4ef141a17fd57b310cc15b2ae00740e647154c6c -> > ?????????? a959851fb040363b5a9dcac447855e0faeec2d6f > jdk-9+162? 2f839735abf0d00845ce0efcc6029f9bcad31b08 -> > ?????????? 90b7d6d9a9001be7fdc373418142dab2edad0e1d > jdk-9+163? e91902ec1629737052873a739d70ba61de6f52a3 -> > ?????????? 0a91adbea47ca754983393773365fb54fee7f64b > jdk-9+164? d03ec259dbcf2733e3c2085a53392dd455d5a238 -> > ?????????? ba5c8c289bb8f61a8e2e54b02c3c2cd39e28a0f2 > jdk-9+165? 34d6c22a3d0300b3713eca39eb8e4520f709d787 -> > ?????????? c6b7ae611e14d1f128f21a786abf647b9ed0b031 > jdk-9+166? 0887c8329c878198b564fe23b9386b438b070256 -> > ?????????? 816e9b4320a4a4960cda934bfd8e32419f3962d4 > jdk-9+167? 7ec4eca7dddf6c05e8678d83671d6657cbe0ee01 -> > ?????????? 77acf91b9276326379331f8c50656e7d9def7705 > jdk-9+168? b3dd8c5baef665ca6767860a159c27fbbc9d62c0 -> > ?????????? 080713b05a306ba7d7ec0ed8c0bf4c019edd45a9 > jdk-9+169? 4695935c0d3494057d3b2b297d270e8ad1636e38 -> > ?????????? a6185f03faadf4b8a5c399009fa4eb198a230932 > jdk-9+170? 91d3be299ce091e3e56b6e44b454d7e0a2ba62e0 -> > ?????????? aae92d1b795fd5f29dd2702e44fb1a977282ac74 > jdk-9+171? ca321075f99d483a6787764e1a161d8576ce964c -> > ?????????? 24d55cb33ed010cfc6ec77151f33cb90798c21fc > jdk-9+172? a21f4d5cb43bd0c7015b60ad3dc3c5f8102aaa55 -> > ?????????? cb5d4c752c294b4a6079d01b055a811f4b833cc9 > jdk-9+173? 0d928364c3635ef2f231e1cfb7d69246210e59ff -> > ?????????? 4972c343422f0066c3b567944ec56c55ffa2ed24 > jdk-9+174? 800d5f707abe4ecbd09e7decb384c9584db50d40 -> > ?????????? 0e9dd1bf210351e5b025cf5e7d2b4e31590cc9f6 > jdk-9+175? 55336ec981073e513b9be3cd20697226e0be8cc4 -> > ?????????? 492aa438be3c667954f868c9d285103da6cf359e > jdk-9+176? ccf12ca7f8384f3a882607e13acaa3302a834ec8 -> > ?????????? 004c097c61970ff6ba07f5825a8c16a4fdccf286 > jdk-9+177? 3857dd9f2da2c078167b19bb13da1460d8a890e1 -> > ?????????? f53ce208f9d5e1800d5a6a89544ce82f9b28983c > jdk-9+178? 34c7579c3a52a707d997f900e3243f3a299775cc -> > ?????????? 04fee7d7e5ae95d6daa7f7ce68523cebd4ecfe71 > jdk-9+179? f07a227b28ccda378904a78921ed44ce35312b86 -> > ?????????? 24f571942356bb5c165da89ba1fac94371705c36 > jdk-9+180? 337df1cbd7c95e5b3ba3a1ca3be49be4a7c96ee3 -> > ?????????? a51eb972b7ef381d66cc298df7fddd017ce58186 > jdk-9+181? de0dc330e746ff6ff04dc0a9c608a57d8369e5dd -> > ?????????? 7cf862ce18a1b56b8778f32efdf572b5042dc364 > jdk-9+95?? fda18e1efd0f3da67db4c2913efecb1166d05afd -> > ?????????? 7dc588ba19877cf6cea996f63a18b5275b99cb70 > jdk-9+96?? d8bff0b78f810028f8245e5389a7bc34de9bf98f -> > ?????????? 2562628672da0bcd2849ae6cc3f9f6a6fcd5ea9d > jdk-9+97?? eebd51d5a5a11cb9f399af9d58b691fab624c976 -> > ?????????? ec684ad4426fcd8f5f63a6077d536a6d28e8df30 > jdk-9+98?? bac15ffa10c71bad871e71fda56010698237570f -> > ?????????? 36cfa7f2cd8b3e46b3e81f181e0dcdc1e8526c29 > jdk-9+99?? d2fced23a868c4827e35ea46d4ef3ebe486cf065 -> > ?????????? ce43713cea0a0416abe43cf6c21cdc49fe61fef9 > jdk7-b100? a9ec4ba08a11a7022409d139c3bc7f2540c5ecab -> > ?????????? efd610bdd1bfefb5fec3179e39f7b7abec934892 > jdk7-b101? aa449ded7b121719f2915cb50e9cbd9746e9985a -> > ?????????? 41bb883dedc82d6e1382f6a00b7d6db89841e121 > jdk7-b102? cb6359464071a93463d94d712a5bd2d9cab95fe7 -> > ?????????? 5ef2431d009c48e564c82758de5875e2bb6b2f76 > jdk7-b103? 16f5c3c35b33f080006a3a4ac9e666551d859879 -> > ?????????? 8f36543686f0d4b3ce977c557e773dd1146391ff > jdk7-b104? c537b4b1b1e2ecdd78c426315891dbc517cf4f43 -> > ?????????? 0a4f8c145553187bf1e6061e9ba1e031b9afab17 > jdk7-b105? 3acaeaa4da93fb8fc3ebaccf203ca5525d40ba8d -> > ?????????? f2f8b37292929dd4e7ad3f47ba76070f37de67ac > jdk7-b106? b5777886d23ad9c104b11b96ecbb70c303588f07 -> > ?????????? 8b5873409cdab86ccd1298050ea1aeec446ae8e9 > jdk7-b107? da9f864ef2569251144ea66fe6e8519df76fbf1c -> > ?????????? 669abe597cc4103acddb4eddfa2bc992d9342977 > jdk7-b108? 2328662f00d7e61a967f594bb0882d0b8979812b -> > ?????????? 412778b6d52bce6eba3af580b676d69c23b54252 > jdk7-b109? 6996ba108467c4bc3501be4909dd08e2064624e2 -> > ?????????? ad86a3c1408ddeb26d91408b20cce2babb8b5259 > jdk7-b110? d3b29a0ee60582faa1d81b067e0315dd0c32b0f2 -> > ?????????? d845d52ae802349532334f5581ee1b5ea46017be > jdk7-b111? e6d8ca87b2e6b89c51987642312fd743cdd6101a -> > ?????????? 8f37fc875ee7ca2fe32cb50c6e27ae02b319ab32 > jdk7-b112? bb705617fde3bceceea51861a0a4ed7bfb06337f -> > ?????????? 2341024fd83e798d7dd5d597a41e0d65d7c12e97 > jdk7-b113? 53c5a1eb4182eca3b64dcdb19db01748be757cd2 -> > ?????????? c3a189a0122a37130ca52a2fb9ce29b73841cc36 > jdk7-b114? ced824d1fe93b57c91e024bebfdc9c00981f3147 -> > ?????????? 2467ae04daa34a624b247f4f47532956cba1d545 > jdk7-b115? 815233e2e5fbd60ff3a1d31f3266630df9ad72b4 -> > ?????????? 66e3caaf9dcb14cf80fc8fdaa0909a2884671539 > jdk7-b116? f5fdd6243c1f683891ab3f7a396a64f4a0faded0 -> > ?????????? 463eb7cc13b3e154cdd0f869184567f8586db213 > jdk7-b117? f8b67e14d91cc772378d25c7f0d5bfd2346927c7 -> > ?????????? b151ed6fc037873e33f30cf216674bb0467d29a5 > jdk7-b118? 644c4dc41d7aef941169ed459adbe6eacb59a3dd -> > ?????????? d76e2efa929bd6c198b0ac2d9cb7ecd2ff4bb9b4 > jdk7-b119? 852618b63707ef36486bfc34df35755c5019aaf8 -> > ?????????? 807f8da2bb7dc7f610decf0d160da841ee7b2668 > jdk7-b120? c737289c8830c053b66eb0dda96f56730aaff5b4 -> > ?????????? 56bdcc494ce423f9e2a706e66a797ec6a7f52a2e > jdk7-b121? 7b0cbb1369ded58bbf0574ac07e3332df8ba824a -> > ?????????? 22158d77ae4f035958d2c8eac4a13bbaeffc6d24 > jdk7-b122? bb93f57fab25d62fb12938d47618797a1e60c532 -> > ?????????? f4249f693e6dd25ab445032f8c2e830faecb9561 > jdk7-b123? e973de8339399e824c7a8ef018eae79b7bd34b05 -> > ?????????? fd0ed100af641d7eb833aa81205675ad491ff03d > jdk7-b124? c1a9787b7e16c73df102afa3d4b8131ff8966348 -> > ?????????? 194fd2a8f8b325ef0f49309c707e7786b6775f25 > jdk7-b125? d80f5fc35ad5d50e1e61534f2ad9f787ecccf1c9 -> > ?????????? ace234ed336a79357b7f0616fce264c2a63e2563 > jdk7-b126? 97172cb902ffeaf07e4bf6797ef391e2ce1ed909 -> > ?????????? ba82c6acdb0e6d32bd7d53cdcae1246fe4b94302 > jdk7-b127? 2ab6230a27cabe48d674c0adf45477d4ff4fadbe -> > ?????????? bdeb6df49744a1ca55f211fa68a1a60236987cb3 > jdk7-b128? 6f1dc5ee3a53e7d58581fa1e72ac0cc503e57c26 -> > ?????????? 956da41d8cffea06ad856dbb730a4704ba518890 > jdk7-b129? f11ed34eb14fb4bf8fb09b3c97d4f8f9dec004d7 -> > ?????????? 51e631d0992715fa9a463e0ef3c9d943bdb534b2 > jdk7-b130? 96e5c0bdf7aec86ca81860aa0fa6f170a3ccabc0 -> > ?????????? 3c9373d3df3a34bf1e692ef305986a8c5443aeff > jdk7-b131? 5415e752717a142a2b26d4d440e4f9b0a330881a -> > ?????????? 330b6ca2f9ee9e908318314fbb9c09c3f171ee6f > jdk7-b132? 17f6776b453bb710c68d29b097bd0d2f9b43b87f -> > ?????????? 5f19ac0afbb570584ad828d3d2fad5f61c714ab5 > jdk7-b133? 1b100a4dd4760e3eb16aaa6acf26711040a713a3 -> > ?????????? 74bed3ef0e1ed35b99aca9479cd2696479d1f740 > jdk7-b134? 7d97833b8b9a83fd707ef279eb90ae1030f2c99f -> > ?????????? a34eebc5c315bc373494a76dc3019f7070fffbd2 > jdk7-b135? 669da964bac7a1460c4160136c9dff2621847641 -> > ?????????? 64f78cd046a40e9a4af7d3af7a8d107246e0ae6b > jdk7-b136? b411a9a383b5cfd13d0d55aec47fe196efd031ae -> > ?????????? 4ff9fd0e2348037bb2c8fbbd8fb2b7b1fd286ce5 > jdk7-b137? c5e0546869256e9b47f4248ef9fd2908080cf270 -> > ?????????? 70fac480bfa14df49075d241abb3216da117a7ce > jdk7-b138? 01043aaa1be2d6493888a46285fce5403f4566eb -> > ?????????? 23001cded84e092e5f6aa2e76a3ba211f54fd901 > jdk7-b139? 52fabe1d5d423fb9f704be6a9f97e4bdc4219f28 -> > ?????????? c6de0d41508a0b14dc0d7c99f8046399b754b6bd > jdk7-b140? c4b35fe4eb98bfc65eff6564238d2a2c81612b8b -> > ?????????? 794bdee7df4c8dff9b0468c10293517ed759341b > jdk7-b141? 028548013bc1be68c9269d727d5697c8026a8b50 -> > ?????????? 1e5e8975f01b04390fd8c6f64140bc20946bc019 > jdk7-b142? da6844f28750797cb763d7ba6f4ad015edf41fac -> > ?????????? 47826d25365174ddc966a6dcef521c58e4fdad74 > jdk7-b143? b5cd73a20b58c1fa8c101b29d1ebc83c3d1ef206 -> > ?????????? c89735d5cd4388bd4d410d5f571890d4eb71dad5 > jdk7-b144? 63fe6da6e9a5dcca537a317ae6399fcb6fe3db44 -> > ?????????? 82ba8a6e01a628ed8711a22d732a821ac1740f8f > jdk7-b145? f4ebb1378715ebec5d1eaa4dc6dae9cebf415e81 -> > ?????????? db5a9dcc9f9f29ecdf3e0df6736fbc9115cc0a2c > jdk7-b146? 8edc1f903647ef3e16d9cece4ed9cf35ec77846f -> > ?????????? 951c3e1a01aaf26856a20b0c381b356ca8937455 > jdk7-b147? 79ccd466bb91350c06ce98cfac2bcd8121adee11 -> > ?????????? 4c18e8f3e93e35d77f2f51b1ca1708bac8bcb828 > jdk7-b24?? 1e45d81ffbd115b9b5bb7cbb64379240e67bcfc2 -> > ?????????? 9b175de44b8d94cc4eb1ffdd9141ebcfbef8837b > jdk7-b25?? cbd3ff3f9b14a20772184fe4552022d6d339e85d -> > ?????????? 7bab50939039be5f645e155b9ac4d056abbf8532 > jdk7-b26?? 003b63898eb30b65886eba56dcd71292292c5c41 -> > ?????????? 97c1c021cced669d8c19c33ebbe9b6c579a2e9e1 > jdk7-b27?? 1c0418571175d8afb2b3ddb04eee152436177844 -> > ?????????? 8ded10494122afda3c84738ed427779a66c1e0a2 > jdk7-b28?? 8fbc3b4cb74d8430a3d204f4f3cc1f299d03e325 -> > ?????????? cd1004e47abcf6b6a09bdf5ca715e0285662f341 > jdk7-b29?? 2339f448c3d9c118cd7d58699e3da03a6b98d7e5 -> > ?????????? 9e5d9d2db5d07a1481ecf61eeca943bfc972fc7d > jdk7-b30?? acbd14b31ef1efb2131f4f17db21ef39a86f261a -> > ?????????? ac8631eac98888f58c5489564da769bff3928334 > jdk7-b31?? adac1160d9ceb34ea4cd79e2c69f96ff02baae61 -> > ?????????? c6ce4bf77c9ceeb0dbd0ec0ec9212cd4e5235040 > jdk7-b32?? 99870969f3f23131112204c378528cbddeddf2ed -> > ?????????? 884fabec050fa169349b7c7cb4aceec581dff9d3 > jdk7-b33?? 250ded658077dd8186c1509f08a32432ab2eeee4 -> > ?????????? 5a415851a75c7608cbb4c58ec8b9474e91defbd8 > jdk7-b34?? d7aac0055fc3f42726f37d3d72146450fee03723 -> > ?????????? d4f5d536ca4d68d53dc47a20067189c61f637954 > jdk7-b35?? 2c07414f20fa71977645867f2cf558171de9fa08 -> > ?????????? 96faf9559d724880c98940af7e8a671216d46df4 > jdk7-b36?? 04d8a11e27375b5c184995b768604c047a9188a0 -> > ?????????? b87273f30446d181566f1896e58ea66b94080c9a > jdk7-b37?? 9977c9a5637bb41a4ed500bc1a92d51ccaf4d3f0 -> > ?????????? a489551ddee047297daa092d9ebdeb5802c15a39 > jdk7-b38?? eb8b71c692cbd6664f643654681d5d4a599d1aed -> > ?????????? e46cffbcf32e8b09b461cfec2d02ede0487c483a > jdk7-b39?? c547d47ad1acb48cfe21b2a98684139e5811ec41 -> > ?????????? d3a70254ca03328b8e7c1ce7c2b81ec5407f576f > jdk7-b40?? cd1feb1ef75a7e519be115d39b9542d76ac6846f -> > ?????????? c0d75397102ace426666ac42f37072cb24e1e132 > jdk7-b41?? 8405f5d696f7d91424200f4403e92efd509ebc3e -> > ?????????? 7bf378585a58588838ba6d143843a68907fd0fe3 > jdk7-b42?? 372c34073a9809221b6563352fdc284abae0e17c -> > ?????????? d4fea9f8a8fa7196c9d29857104baea4b0c4a602 > jdk7-b43?? ecf9a9202312003a1cc128d2420a6e8b8958e0db -> > ?????????? 4af814f9a46508986dc1aa9cf99cb9d0432597fa > jdk7-b44?? 422e92cbe72f6b665dd645edfc79bb5a856915e4 -> > ?????????? 1a54172bae772c6f7e9c00abd84e1d1ff184baa4 > jdk7-b45?? 59150ba33ef9bad3fcece7e50403905eda8451b5 -> > ?????????? 422769e492d28335d11cebd18d72402382482cfc > jdk7-b46?? 19a7470c507a7403e3b81a08494b230142b6fa26 -> > ?????????? 54e5a28cf11deb4786bdfe0a7a9dacc4511121e6 > jdk7-b47?? 80c3c650a49338a2499e682e58237635a90b9dbc -> > ?????????? 111b956456ab1346da9fd82271349be42669467c > jdk7-b48?? fe4e65b9390256236e6335253877aa53c905c8f8 -> > ?????????? 8fd5e55c7b5997b52046b66bb29c92e19a4903af > jdk7-b49?? 38d8cf2680eed7886968dfc671262027e7c510f5 -> > ?????????? 995ff7cb59be7c177d566362f0b3ca6ca7453b7b > jdk7-b50?? d9beb00643e8847dae9b2f15b0f8c376ef4d7d5a -> > ?????????? c6399cce72f276780e2116f5980744531b0a6a50 > jdk7-b51?? bdd6d4259d362ed5492a5c9bbbb0b56ab3fff529 -> > ?????????? d9cd99caab6d675d5ee1a6e1b0f998d31764b9cf > jdk7-b52?? 0638e44ae25a48f46698f6598644e75462226e10 -> > ?????????? fca93cf46e5749ff54f77dba67585ff3d8765a6a > jdk7-b53?? 8a17bf5094b0f71be01bf00b88e0542b61eccf4c -> > ?????????? 0af385d2f302647bb3888f42c23958fd6ad25b77 > jdk7-b54?? 24462f60eb4970190623ffbf73d13b8dee1bf62c -> > ?????????? b03b0c6a2154a4ca8ce0c99e1f7f51e07366d02c > jdk7-b55?? 97a41d2b5bb09d0316e7400553b39c597847ae57 -> > ?????????? 6e1a0005ed2844ecd5b2a4e24358540bfb520049 > jdk7-b56?? ee773eaf54402a06d03b83708687f8eda99f0279 -> > ?????????? 85137260ae007edd1ea14b9cdc6af1b893f17d7f > jdk7-b57?? 4375db73e9f87b88802cd3311b96f5d4e4ebd65d -> > ?????????? f82f3a513bd16122db802d09dfa127dad430abe5 > jdk7-b58?? e6eeb81c61ea7a7896483b7f3c1b2fd54a48cd74 -> > ?????????? 53bee31d02d9aa3f381bf2d5d51dabe20d9eb1f5 > jdk7-b59?? fed3abb52415feeeb42337a63b4497f48f9156d1 -> > ?????????? 31168f1b8b98396ec00b9220d5303811fce645eb > jdk7-b60?? 7f963e104c70d099c3e6bc79b8a6c261ed7be2d3 -> > ?????????? 41d9f358754b36548e6b2e5048fb50ae5b2b5d86 > jdk7-b61?? 72ada440747c9f598f3c418064c0f7464a07efcb -> > ?????????? c8035cbd3cb10f6f0b7f04de09fd3cd191d9681d > jdk7-b62?? 428c698aba0e9bdfb67e6445d6e721cc19ccb8d8 -> > ?????????? cd586208c77b4e22d85c49125568dbd515414c61 > jdk7-b63?? 338d8b1b526b383dda1f31247915834de92938ad -> > ?????????? c4bcfc43f9c5338aaefe824de56947b792071ebc > jdk7-b64?? 41975201606f6f0c7d875c0c8abc3ca776226642 -> > ?????????? f9aece23ac937f282c1ef1c2ee553b790b76887d > jdk7-b65?? d577b315dbb225a95fc0ab08c3d2d22c0135e5ac -> > ?????????? a1a63928026db0f57df81382085cc618ccacf6d7 > jdk7-b66?? 36fdf5706150ee95fe806f52a73ecd59b35afaea -> > ?????????? e08b7e4ba15a36b63f501640efb004fe5837f98f > jdk7-b67?? c6e9f812947ae20c22900b7eff89c6abbea0d2c9 -> > ?????????? 5a1940077cae9dba048813d509d2ef89bcfb96b1 > jdk7-b68?? c02d589e9a4c94b7c2719835212a3c0e66cb4bf4 -> > ?????????? 4f03e7978ed7bb68f9aca77e293f795090c478c9 > jdk7-b69?? de7c21635571140f8fb9e46539832a06a744eb30 -> > ?????????? dc51d5c5c12324e7f56149d729aa82b38c88196f > jdk7-b70?? c0e1dc11271754439eba100c9c1daff80e150e5f -> > ?????????? 2a38ccab4919e2353ed6386fd854c25f7d6b303b > jdk7-b71?? 3f729b2c86cda5e4c98f3b061b0caa0c37bebad0 -> > ?????????? a1b22ccf58e6d74ce8589164af78788ccab378e4 > jdk7-b72?? bdc50f279d4e362ea2019158161d26f91153c444 -> > ?????????? 0a75ac9db88ec1dd9433d696cd605adb405c745c > jdk7-b73?? 19ddef1e1989e57535923bb217e30d61cf415e75 -> > ?????????? 0ace9968df934dbacabba0ee45847ffa3fced39f > jdk7-b74?? d1b442a98e63a4844fa621f00e4633f8e4e8cf9c -> > ?????????? 60145fbfff6148414c835ef9ce262cf0f85d3d98 > jdk7-b75?? 02c205e8e19dc3430723da279d7fcd656b457b83 -> > ?????????? cae9ea4202fe0a0b84c3ba3a4286d3785c3f6ca9 > jdk7-b76?? ef39a861a205f9b541685f975871f0b36bec6814 -> > ?????????? 375f127b0c34d42bef10a0ac44bf0b25516aed92 > jdk7-b77?? 2abafe6dea0e865e93945e4bd1649d88fde5184e -> > ?????????? 06075f46db0f07ec9839e75d1c4f5f27a6084520 > jdk7-b78?? af91cbbd718574f043c3c68302003b7857d71c6b -> > ?????????? 499c94d48e4d3cf923aff10dd5dcf541637905d3 > jdk7-b79?? 04cab1fd44cf758afb5aef86f866dd7cf636f2d4 -> > ?????????? 7a59943ff0dd152ee979e2af6589568390e35b57 > jdk7-b80?? c283bfd39774bc94ffd248b8fd0934d54e9f73ae -> > ?????????? c3121b2c14d248ecd6e581af178a3da05e66c543 > jdk7-b81?? 1f31c4a3ed3b4f3640324a467bc029cd66fa5d85 -> > ?????????? d806fa09e03b29786c1b1776d71e727855a6b7a8 > jdk7-b82?? 77ded4b186c812f007a0bc330da5cdb15fb63fef -> > ?????????? 3594cf726c8b3f8f2a304467ce7c785cd7045156 > jdk7-b83?? b8a6826db9e0588ac405c8d3ae08c00b4ceb6edd -> > ?????????? 82b342952619d2787843e519097281c271b6acfc > jdk7-b84?? ebc547f162fb0f6883986fb2e79d75a0155baf3f -> > ?????????? 07e0be28ec548faac20b1ba2064da5a58fad7730 > jdk7-b85?? 0e8d731bf0475ed92361b23e0f46c4e857886ccb -> > ?????????? d4f8aa6d92665bdab465017d25a750b4668c0875 > jdk7-b86?? 7f0d149a84e0d7aa67d54f8b89f883d32f44c10b -> > ?????????? e48bb556d7c2ac32d23e916f46b54e60bca477b9 > jdk7-b87?? bc183ec1529b1dbbdad6c4ace9fbc37ec35cd081 -> > ?????????? 0f9ae8dd28767d43f858cf18698787a21932e452 > jdk7-b88?? acd38bb4ccdc86a4b0daa074b64595a9778c997b -> > ?????????? efd4f93dafebaa32b09e7a27f8eb60d55d99ce33 > jdk7-b89?? 8a692ab1c954a8cf60bee27daa63d4551914d1b0 -> > ?????????? f5a00618023720347d6e8bc2b3c675ae277a108f > jdk7-b90?? 515df4a92680a8ddd60e92f0356d5840d95dd686 -> > ?????????? 8d26dd5a9cd3c91d295c339ca3cc3d1cd43fb877 > jdk7-b91?? d35480d38fbc3d83a3e6f06769f6a28868f9725a -> > ?????????? 01f5980edd1f78ca8a60e08a280f2fbf80b983da > jdk7-b92?? f1896a491c1c6d493b4733f7f333a0e0d7c0e580 -> > ?????????? d69e7f1549739773cf5213374d4f419a9254ec48 > jdk7-b93?? e39541ba109eb4e20c0326468dc90645848b3378 -> > ?????????? 1b925484dccfa1a952a3c09ffcda2f1303f259c2 > jdk7-b94?? cffd05c9b52eec5a7d2713aec785e17666023078 -> > ?????????? 9aaa0184a32764175891f192e3d4c75b5a518484 > jdk7-b95?? 6225c66a97804825955159041221b4b12c388aa5 -> > ?????????? dedb4072824b7b60881f57f6de53a867d4741d55 > jdk7-b96?? a5cd99a9837b4ba14ca21c509f86bb149cd3703e -> > ?????????? 9039a8bc5cab82c1f9bec78d51acbb72949c5d3d > jdk7-b97?? 682423cd7a7a998e9a7362157d98487d4eeac21b -> > ?????????? 9763c02d42fff23734cf599bca96dcc0e5f07366 > jdk7-b98?? 5424ba8f0180cfeb446637267ff48c7ddea9d4db -> > ?????????? 5b35f0daf2f9e94249779aead0ebad3465469eec > jdk7-b99?? 976a2b0280ce6eb8e56a8aa40351fa7e8ecbd07e -> > ?????????? d0b45eea6f3e6f4c351fcc5a0bfd1763d9823b3a > jdk8-b01?? f453fc42bc415bfb560cb8cd6b028897d7f2fd83 -> > ?????????? 33852ed5c01906475eba4839854a5b5a39f65309 > jdk8-b02?? 90ccb0a4fcabde933c600d6571acb3ae39f7856c -> > ?????????? a02db6e6acd9a8c2b2aad3d857de939352cf830f > jdk8-b03?? ca8108264895d7734eb20bf934f06e88fd77ce5c -> > ?????????? fc7477630f94a58df74e1e0ea1a7edc137ef49cc > jdk8-b04?? b6f90b98671674b67569831649bc43f60deb16ad -> > ?????????? 25af5e82f9f7f61ff66237834b9a21ff5cd60fa0 > jdk8-b05?? a2b99839ae326e2c4036fdb44b5b8726fdb9a02e -> > ?????????? 4279c95658b930659279147f9569d4e252e92d65 > jdk8-b06?? 613ea29d54d6e46db43eefbe880aecb69ac4a737 -> > ?????????? 1fa8ae54f16314fc34855baa73d6de9da41f3ccf > jdk8-b07?? 56eacc47653861d93e5d63a2ff60d63fb93ee3f2 -> > ?????????? 51c703c885c8bae4ef59745cc1c6db9297e78ab5 > jdk8-b08?? 74e1e50111b2a6083a96275eee97a2975747b062 -> > ?????????? 32dcc60a0764dba8fca0b647b2ff3d50d4a41d10 > jdk8-b09?? efa0ac8906cc4330bc00e2df8d92db52a04992f2 -> > ?????????? 51b33e55af6050a1cfb6297c0a53aaae4dc7ae9d > jdk8-b10?? 20edb548f0d266c720233b4580fd89a01da5090a -> > ?????????? fda73bc333c7f08de6312f89c620ec232d049131 > jdk8-b100? 7dcd3249750a938b56ffc903a638c0969141a289 -> > ?????????? fdc37d42f8f00f8358e33fb39993fa807704ebef > jdk8-b101? a23515052a9049061ad9483b6e81d9bed56b6222 -> > ?????????? f0431b532429d56d2a39d0c6972be84b899217ce > jdk8-b102? ce866b9121e3bd8cb40829fdc3e09a987449d326 -> > ?????????? e2861622725b5276b40d5891c9833cfb0d2a4fc3 > jdk8-b103? 0e44c50e741cdb080640613dfdf03bf2df07b9ca -> > ?????????? 623d92f31d30968626802ffb3bbceec6b9644dd8 > jdk8-b104? 817f319d222e5420b1de7885fe98dc97d99f9739 -> > ?????????? 91494f4f152359a82a335ba48266fe24b88b7c7b > jdk8-b105? 20d5033e98c7b4b68ca4f1b8d1e018c44261ef6b -> > ?????????? f58827194988e5ccddda280ae0950390f6ca4b55 > jdk8-b106? bad23b53218377f2837ba67fb82ad16ad9877d8d -> > ?????????? beb501b49ae29f61be0072818710a9d3725c8c20 > jdk8-b107? 5c0e02338695a91762f2b5e41b65981849866fe2 -> > ?????????? 68e6ddc62e0a13797ddea78883e4df970fc77bc9 > jdk8-b108? 9300b1ef1dd39e76889f2409e4139d7605fc67a7 -> > ?????????? 450932aa6d03a6ab488aee81961aa5e185138b57 > jdk8-b109? 44c4a6b19adf7299d0357b359cf9b6b4ea79af79 -> > ?????????? 0a018293a6c9e21745bc444af4b72e84eb2c8c65 > jdk8-b11?? da4d9392c83b5a6162abf0a61c88d4fc72d48ab4 -> > ?????????? 561c543a67d2d1b0fc4a9026d02f9893e8cba9e8 > jdk8-b110? 88575397e80bf270631e2f7a86728e94c220a7e3 -> > ?????????? 9d2009d2bb5f2dc1ba023209c610a6ef8f47a0e2 > jdk8-b111? 41b61b0c12ed99a37fd6833d19672b77da5a43e3 -> > ?????????? f5a5cba1f0b90138b295e07e2c11e6a74a4d8031 > jdk8-b112? 5d3f6ba2d0156e18293aa90430664a86874a364e -> > ?????????? f98a74d021bd2bb406a457672057d944666e9c4d > jdk8-b113? a3abb67c781037467059cb5320c5b5a94b8c027a -> > ?????????? b3141c3a22e3b4dc867e5c0f1ed8897e944ac745 > jdk8-b114? dc2f5b4233671cdd53239386b1f9316a26298982 -> > ?????????? 827dc623d0f8c7daff9b19914fd68e6e579f82f4 > jdk8-b115? dbeb70af9c092ebd0aa4c29c634da6c3faa5389a -> > ?????????? caddbf8b5820bd6d3d9362136b534a66d0d62570 > jdk8-b116? 2d5f045d3ec2eea844b9814f07b167cfc83a86d3 -> > ?????????? c0a37161b8fe781ef25ee871e3e4e940f4aec3b6 > jdk8-b117? 35d9311717f434612d79825ef4e15f49500f8ce9 -> > ?????????? 8dda2f153e7355c2600b4ca90b841616d7ca6b24 > jdk8-b118? 458ede3f6303449a69dba7edc2b32f6a9d30ee73 -> > ?????????? e0e24f9d0cf5ae728b3852caa88ca58655ff29a3 > jdk8-b119? bc7ee8bab5e513a139a6c2f5600aca55553bae04 -> > ?????????? b0b1706af992194fb69c0b8f83f8d3e6efd69eda > jdk8-b12?? bacafdf17e2f6867121bab13c5ff346923a26d81 -> > ?????????? 9c4e14e02ee2fcacfce94a282cc2bef7286f372b > jdk8-b120? 84dd4b599bfb6e38f1f737526c2eb98acc15f866 -> > ?????????? be9ff95d58f9bb8620a11a813e51fc88a4d54664 > jdk8-b13?? d8aa74d8c445a537cb43926509269880735ba754 -> > ?????????? 2fb5e812337daeb99b03666ee758cd0e696290d9 > jdk8-b14?? 50fb5839e9418921c68c8857b657ab9c8a1a9f29 -> > ?????????? b4b6499c23ffc5dd76b9ae5938626e81e6be9891 > jdk8-b15?? dc0ce599dd741f2a7027bd38205d7db84b254aa9 -> > ?????????? 8900fe0fd894cb14af02de4cc63d8b791c45ede5 > jdk8-b16?? f1dda35b5a338c755d16ea664474bfab7c31c898 -> > ?????????? c1a0394aa6a7c1224e9b210f4396d0d6b66799a8 > jdk8-b17?? 736a77ff30d0a23e8eecdfb5c6f45a5bc0b6e2a8 -> > ?????????? 058ee1c7d8965630161fa4b5b2e777f2cbed0968 > jdk8-b18?? 36d63d22596b5b5c7c65fe6fe4e2b57f678591fb -> > ?????????? e1de342f56e3c45b731f2b7a93113ac1330e73e7 > jdk8-b19?? 7eba476bcf10eb89cbdb8f6388b02a09d1370d91 -> > ?????????? b5b97b08fd8f84b9012c1417179f8fc86772fba9 > jdk8-b20?? 24d563c53d379351a5ba1d4efd8689b1d35987c3 -> > ?????????? 1590b85bb87b8ea2594a6055f0530376bd44cde3 > jdk8-b21?? 04396bebcc712f1d3d0100f9c3fbdd04ab1125a8 -> > ?????????? 228e5e5fd11137188e3cf286934caf9d4236270f > jdk8-b22?? e9e7f6451e236115d4142c6852031f4f41bd5d1b -> > ?????????? e54520becb3a80498ca8e08c5458bb22b0b04d60 > jdk8-b23?? 0f2affe0d7d67040a757ebd13d2bd3749ea2f293 -> > ?????????? 0cc6a9dda6fe05647947debc5821f67816c66bac > jdk8-b24?? f5d5f3cec21f7aa6f143b009359c85b6a045cd58 -> > ?????????? 83ca3edc0bd1bb85cefb3f4d54c1fff4e5928703 > jdk8-b25?? b9467b4949c59e1bdf8483e3e4beb37e7a7afd03 -> > ?????????? c9a34851b006da5e806b9e5fab993e566558e2ea > jdk8-b26?? a0ff209c886a0174b17ccdc711fdbaca5bd99ff5 -> > ?????????? a3db0e1600aba0268c2816380cd89c6ba43797c0 > jdk8-b27?? 6d090149192954ccfa797e626b1c49c86b4c3552 -> > ?????????? c0d7f825f41e1ac2f31cdd1941d58b7e4c3e5a26 > jdk8-b28?? 36ce326e16f2a039c93151e8016e233ea595aa2a -> > ?????????? 62b5d4df52d6bd43cac7ff1c54ab322980e5d9d3 > jdk8-b29?? 64a826a01003c78e99dcf2cb3ef6e8c0f94ae75b -> > ?????????? 817f23c52cf86510b41f5d212398365ffcf1edb0 > jdk8-b30?? c9e395a39ccb6bc9adcc22458b3bc97003cd10cb -> > ?????????? 3eeedc2818cfcfaab60a500737502935f997c501 > jdk8-b31?? 0833953b725b870658245e88e6e5ec94c450d54c -> > ?????????? c3bf3142941b5fdb259e140d7becd8ca5915e4fa > jdk8-b32?? f58ae5423e5974b8f0ca7ebd3e03af1531cc932f -> > ?????????? f6fdb895dee84338c9de2e8a9850b516611365dc > jdk8-b33?? 1585d730b4b5f397de53ea2f2902f00eef93091d -> > ?????????? 0a5ecb4af210a6821e0b40c8b54895dee3957c70 > jdk8-b34?? b5071ffa273658f1da2e51abd0beb74be6b2fbf2 -> > ?????????? d262ee9294a3eb09db871f9630e0ef1e405b826a > jdk8-b35?? 36e1d59e40f44cf42ab1c9b1a62bc2ac2c9efbcf -> > ?????????? 399f3e012999b2bda0a5ddf98440f3455670f886 > jdk8-b36?? 44433d2be63356e0a6cddfd7fb94eadb0ee30ec1 -> > ?????????? e0c6075c80c84de7cdb64e11622ee84c15588318 > jdk8-b37?? 043ace2f1b0dcea3ea025b244227725b5ca4a079 -> > ?????????? 076f99900dc9251b72cd599c7bc9abcf12ea7649 > jdk8-b38?? f063b44a3a919eb7e740f066ebb50833c9b9834b -> > ?????????? 13a921a59bba0dd7821f2e4c11573fc4cac96395 > jdk8-b39?? 543fd1302bd79d271454f140cf4996cf5445e9c3 -> > ?????????? 2c970e04d9cdb83774a3fc7c147b19709f237f8f > jdk8-b40?? f3b5720d4bafb45ed5520732a55d8ca8d12e7be8 -> > ?????????? 0da3d5c13df505ba47c661cebaa0728c8ce84cf7 > jdk8-b41?? 2cef9366d53602c51d0dbc34578f18c59f03f4f7 -> > ?????????? 703f7c42a2fecbeaef200315ed1c0f9425e0c8d3 > jdk8-b42?? a8a86a87d0dc23c26356eaa187173eb4b146b260 -> > ?????????? 5b30a7757eea0587041b3ca24f351455516c32eb > jdk8-b43?? 32312c00c51cc72b11f7edffe058a2a4844da355 -> > ?????????? 5cd8ae46b042552ae8b3f73771e92c20c011373c > jdk8-b44?? 188f044195409b8d540f664d0540a30eb59ef831 -> > ?????????? 77b1dd9260e9ef426b87f5d511e8a62fcff3637e > jdk8-b45?? 2c6ad0c77d58e12e7f3abb6e6800ec5ffaeef7a9 -> > ?????????? 2c8668b2097f10ba8c88187b2462f82a2eb330a0 > jdk8-b46?? ebcb72bd1f536b99c36204ca42251d32257b37c2 -> > ?????????? f52e9db9cf9586d4a13e5b48f4e6f6a077f73870 > jdk8-b47?? 8b5609de00723194d8e0b57861f8692ad4d4b796 -> > ?????????? cb201a6450a1dbbd62d3c2222a4750b556d39323 > jdk8-b48?? 790c0eaba30a0a2a666716d06cd1dbb22091ea60 -> > ?????????? a42e922abfb42cd7a94212381eda86bd797b8105 > jdk8-b49?? 13b7c934a158453cfd6ac62f1f89122b8d8c9429 -> > ?????????? b0e8e30b0add732280a547be984a3cf9a12df68f > jdk8-b50?? 2fd2daedb4e8eba66e74ca92df036a6cde7db9c2 -> > ?????????? f390330de75f3edeb05add4333cf0ded4d0b1ca9 > jdk8-b51?? e6dd3f719c9c0faa9f2384e3cd526bc581117d63 -> > ?????????? c7b70a66bce35e1bccaafa389c804b505a9e4cc1 > jdk8-b52?? 3ad06e581e8ca1825c35970a5568bb793ed981f3 -> > ?????????? c280fe5b6705e79c24f0dd0e93e690b7e5691796 > jdk8-b53?? 18653ab7b981e71d4d4d4e86a779f8afef17f635 -> > ?????????? fd59f3ea44435c85a06fb0845565c76824265a89 > jdk8-b54?? 1586d3d837f965db537f7a8d4d2dd77fdacb8131 -> > ?????????? c4c77c0beb27be157948a266de74f111277dacd9 > jdk8-b55?? 92998094eaaeaf7b587250aa6eceb5c145100770 -> > ?????????? 7de35fcb4e06005859683edbd4b04c9ebc637bb2 > jdk8-b56?? 232a0f9fde0d929b8aa2ac5c4d042dcc07caa7be -> > ?????????? 8886e35f0cdb0ecb76c23c7aa66e7f95ae865214 > jdk8-b57?? b387235ab2fe5ab2d0cfec6f7249eb8060be3550 -> > ?????????? 55f0abde6d1bd79364fc2130b2505856dade5132 > jdk8-b58?? 015d62de2de1c4b22538a79cb025c0a0a21bbf2c -> > ?????????? fa9c6eaeb4b60c0f2604d4e09763e9776b20b0e8 > jdk8-b59?? 90975997e732a4835d83fbcab87e647fe90a27af -> > ?????????? bd56a1486356d36b5f221cac91a11d46b4e3c8b2 > jdk8-b60?? e25a512462fcf32d67c94f885abdefd3b36ccd3e -> > ?????????? 3fd7db6d40dd794b2012b2a78bb83fdada8abed6 > jdk8-b61?? 20a1be5ee77dbaf9129fa4c530a1fd4659d1830d -> > ?????????? 43de065837a30359690f262e6a9c6386a3110a16 > jdk8-b62?? 1a65b98517f28497491ec520f806b1ea07e5c5fe -> > ?????????? f0bcc45527caff96c77894f3e5ee69469819f00a > jdk8-b63?? 3dee964887dfb65cfb3ae2cccb2cbefc76cf8393 -> > ?????????? 1a94953a17e39b6f80370aa293116e326a18a477 > jdk8-b64?? 3279a0485eabd4b519e546f8d19dac7b510a43a7 -> > ?????????? f40577fdfae1064bc26309c56eb00e6d00a049c0 > jdk8-b65?? a840a2d3e6c8db305ed273af6c8da56de7de0806 -> > ?????????? 7b2e4a34c59908521085550fab7341b4df551e4f > jdk8-b66?? 0e2d6fa1b512a426401bc06c6554a8f68818b159 -> > ?????????? ab2191e3ccb18cef302fb7c125488067dd9c11af > jdk8-b67?? c6b75137290f489517fc38c84d8b2e0af9fadac6 -> > ?????????? a7ebc22bb6d0ef7ccb66077e784bd8c779271bfc > jdk8-b68?? 27146022921c879f472108b5ebea36522e31c390 -> > ?????????? fb39e375097898fd71b5cc9cef873955b0c71338 > jdk8-b69?? cbdece5373304b1baf85c7738651a466c947bee0 -> > ?????????? 320e1e9a1c9db090e759888fc520c3865d94d517 > jdk8-b70?? 03455ab9e0152aa02b65013b1392694a1694c7e2 -> > ?????????? 01fdada0af68f6b7a0839840f1db3b40bfbd3b40 > jdk8-b71?? 8106ebb7e9564e346357d6dae7d072c0915d74c3 -> > ?????????? 25da6dfa22f1aa25a85e78926487cdd8ef760412 > jdk8-b72?? ba4c812f9c35050512c3ae5d489550b57fecd6bd -> > ?????????? d34718c67e882dd5b5048cc0f7c8ecbdf7e8852d > jdk8-b73?? ba6a8fd6218f6ce65bb81967e8d2fb6b40da7f4b -> > ?????????? 81b4e5400b4b6ed8a755a2993dec6cfb7487c5a0 > jdk8-b74?? 309b6a75fc629c474c1c50c2f1ee8d1d40eb31a6 -> > ?????????? 9df2fa988fbd3cd25a0bc3a016b93738f7cf501e > jdk8-b75?? a681de848746a46084cac900b6b65aa602ba9d38 -> > ?????????? 9c8df92261d3a50ec11a7b743891f3adf08c7639 > jdk8-b76?? 7498e74b341940f72b273d51a6770670d7b76be9 -> > ?????????? f8fe95d85e22efd8d55945acc30b4ef5a7fba9d7 > jdk8-b77?? 2ec230b2bd4e531d74e75e27dfa0e16e9c2538d0 -> > ?????????? 3fb074be9d7474410efd47b744fe51f04a2ed4f8 > jdk8-b78?? 0ecc3771452dcf0a3f93e25da4f72db5aef80df5 -> > ?????????? 3ead3a74348f1687e7e903ea4346d2f820d144fa > jdk8-b79?? 22b609ebc81312bc8ebbb89d5616ad859bd57c70 -> > ?????????? 76c445339712be147e15e117b3a75d03d827c7f5 > jdk8-b80?? 6ab8d2452379cb0f766953c456f5d342fd6e2c95 -> > ?????????? e47c4ad33dc38b3829baea1114ed42a3afa6c44a > jdk8-b81?? 6e2ad6218e18245e2a3ed506c2c15ab354e14353 -> > ?????????? 932d2c02021d5850582651e8d1bcda95c13cc0c7 > jdk8-b82?? 21927dc109c38826e0c9000ecf25c8f32b39a2ec -> > ?????????? f1c64c13d3eef0308782af9591bfdf344ff40587 > jdk8-b83?? 66963723e80067a00c1630bea54dd8ee7dbc4a4c -> > ?????????? a622c1980a9d917793f357b77ed4b27d75d04a9a > jdk8-b84?? 88ac15a0cce8c640c14f43529f841dfc06bb8c59 -> > ?????????? a532e44f19896cd738d76f436b88817e73279a7c > jdk8-b85?? 522b13175ea71ba5d2ff529e82015a47c1a948a0 -> > ?????????? fe8a12dc5fb276ea1cda6d31c03dfe52c58ee3ac > jdk8-b86?? 6d055467c2c4b920c2993e3b4cb9ba3ab35901e8 -> > ?????????? fee6f44b8b104c5af10eb150967d15b42d87f073 > jdk8-b87?? 7b8678decd58a1e6a6c7a8a9b4570075d1bbefd6 -> > ?????????? b0cebaa4bf1dc1e2165c91878e3d7caa1578e4eb > jdk8-b88?? cfdced118a7f0f6834a1bbb53d47459344d0e5c6 -> > ?????????? 7550f3f8ac4966ce76d90dcb57e03fc77b070c50 > jdk8-b89?? b853b84f4ecb6ae4d5241480d8c5a030be6802c8 -> > ?????????? 8633970b1c505c37540b2821b01ce1f3d982f352 > jdk8-b90?? 5c4d01b9ffb7e30ecf2ca87f87cd323a8ce3dd35 -> > ?????????? 4dcb0cc7ae2c2bc8f6db1366d8e1877ad7fb8cc2 > jdk8-b91?? 6a93438cac075ea6872a4fc8bf199e1614eb1a36 -> > ?????????? f17647afbae44da697d846b6719dffc5da22a533 > jdk8-b92?? 1f62c87b7429386240d72474afddaefa400bc128 -> > ?????????? 1b3d50b7f19d59ab6e3e552cf00c30854227dbea > jdk8-b93?? 25afba3a61e390608bbd1c3ba0756e62b8d5264f -> > ?????????? da575ccd3f5e3f063a18bd89c7b9e49c9fb1ad47 > jdk8-b94?? d792bc561728e168d664270400f00eb71ca0f7b0 -> > ?????????? 5263ce65860555d8eed8a08096bc147170b32903 > jdk8-b95?? 3514ee82f55e25d44fe743175a5dfd2efe57e91d -> > ?????????? b94b179fc604891a76d1befbb7f9933b6e21fad1 > jdk8-b96?? aa8214f8b13b15dfcbcb427225924002f954f6d9 -> > ?????????? 20a81b3697e720b32c88839e4ca96e40d69d5814 > jdk8-b97?? 52c930851f9ba81c2d70218a592d66a5342be03c -> > ?????????? 477e6634a0107fcd02afc47e096476326d6b0a8f > jdk8-b98?? bec6be5dc993979c951807632ffb49113030e006 -> > ?????????? d405ff56451054b5b0ba3f780f9ffef100aa5fe3 > jdk8-b99?? 4a45d02a01c1df006676c3141e91c1d3cdd140c2 -> > ?????????? f2da184e305469a090e8e5cfa50018128558036a > jdk9-b00?? 713f2f59f3cd4efc478a43c0c7c403b8c216df46 -> > ?????????? 8950e8e0a06913dfb2b6f78c839ce4a3255c3f8b > jdk9-b01?? 1c87486aefc11e48e6c99785908633c4a7ea0453 -> > ?????????? a4781f7911e76e2908f7cbb6b0ed964a873e670f > jdk9-b02?? f8f6dd9353aace854b0c57e137af66e5d3d7c0ba -> > ?????????? 3d9ab12cb9c60dcf1d97a63064de2917ae9a00e6 > jdk9-b03?? dfa471348d018707d0cc6d1afed2fa7985a51686 -> > ?????????? 343fd661c7feefdc8d30eca439db2fb7ec919ef5 > jdk9-b04?? c5da700534090fe9a0709bdb06ea5230ef9d7870 -> > ?????????? 459a60a718165eacd7fc1aee2d05b43abc784bac > jdk9-b05?? eb7a4bcddda401388c181f9c34bf4e69bd5d2a77 -> > ?????????? d428be387385f9a12ecbad51eb69b78cf2d02610 > jdk9-b06?? 55cd3a180797fa430c6953e1ecffeebb952fdc50 -> > ?????????? b0d75da07a72f8487088a1be84d813f506350c08 > jdk9-b07?? b8822e7daef2a40eec7412c7e0f710dfd29aaf50 -> > ?????????? 87dde3df8dc888d82d2825468218805e3c7aeef9 > jdk9-b08?? c27d4b7d28f280b45872769a2c1dbbbfe7cd9395 -> > ?????????? 40acaee0742285fc04abd0e8150f955732638012 > jdk9-b09?? 712392bf99ed82f7ba63d8bbc1cf9b562259e34f -> > ?????????? 88777efb8d8d6d0ee87b5ebde6ad3f1a4fb379c1 > jdk9-b10?? 84dbe45301a3fc13a7c71da7732bbe122ee4f11e -> > ?????????? 43f9318baadd9837cbb0441bc3bce82c917ebc90 > jdk9-b11?? 508199f30b40a0cca31781489dd6886588eee8d1 -> > ?????????? 9ab1ae689b3fc59c26a86bc95f5de1b3e16ae15b > jdk9-b12?? 6a23106ba49675b410b9d45d5340a242a6792706 -> > ?????????? ea0e4b594af5055ca2d451066b4796a0cd66d15c > jdk9-b13?? 5073807228df13c0212e5eda5add5268f1be3867 -> > ?????????? 881341bfa5507464e55dc06e344d0c24f8ccaed5 > jdk9-b14?? 78a1da96a51c56ed5ac642bc15d69621731f33d5 -> > ?????????? ef5ce609a342df30322f54231b60a514f2df8fd3 > jdk9-b15?? 8362d9b9c5573e3dc0f69ccddd8704b8fd2a7e87 -> > ?????????? 1f130c947959b4bcd506bfca3ff5aff69e903734 > jdk9-b16?? bf0277e48b339c57429666d17416da7ae189f70c -> > ?????????? b9da1b90f4c9726e38d78de7774142691a26702f > jdk9-b17?? f3a21e576d53c2217cf1f17b1df7bfd785940654 -> > ?????????? a0e7be25ac56363623757b91f8833dfbad459c35 > jdk9-b18?? 1c32dc4199ab04dc5bc1cac8fb9f418ef91074bf -> > ?????????? d2a3926ea2fd352595f57b14606d836c8db9429b > jdk9-b19?? 109844cc425102f08ef9ec154f4421bb62825573 -> > ?????????? 91851ca5f942bee6983af82460aca57ec55d7dfd > jdk9-b20?? 71821f4180dfe80ce3bb93f980dfdc5320a213ea -> > ?????????? 62e91dd964b6ec7c056775773c0ee8ed7fd24f83 > jdk9-b21?? d6866ad0691790e46a5491fd376893860df18f24 -> > ?????????? 5d1aab89956a88f6dba057ce4c5a328f7c506230 > jdk9-b22?? c719823ecab27011956b1791e90c5d1e95350ace -> > ?????????? c57d1155a778fbd8373a9e70e62049b136ba5a67 > jdk9-b23?? 6621552a02ca3ad876b83058028fd09144c96acb -> > ?????????? 3b91fad6fb807e901d429934055108421f21789b > jdk9-b24?? 9224c1a06818fee3a727ce4aa6f385b8177b2114 -> > ?????????? 164cfacef29ce05d6681f38225a13c4476b4a8eb > jdk9-b25?? 49333cb5937e2763a3bca33c913f9f1fd1ce35d0 -> > ?????????? b5b9ec94c2537567f926597f27a2823724a9810a > jdk9-b26?? 1d954e87d10d3e84aa8fd7d23f0cec8aee49ba09 -> > ?????????? 2c2d21bae63b70f22885648f751e92ab9e360941 > jdk9-b27?? 1883033be665a84be67deef168ff8b2d25fe9af3 -> > ?????????? 137faac2bcf39633b47f83cef83b4fa8bf86fd62 > jdk9-b28?? 2904fa0b17fc96f0d07cad5efa04b551942f948a -> > ?????????? 8ac0c7efac15406e5d2777f9c9cc866dfbc25c09 > jdk9-b29?? 658b13b24d0fb9fb1b1dfa11fbf8c1b0885887a0 -> > ?????????? a7adca59d69a5a384cacb06b7627c87b837f2973 > jdk9-b30?? 3c0790c1c9aef422ada26cb350bff143e04c5649 -> > ?????????? 346321263b744b01e4e710eeb25567f2077618f1 > jdk9-b31?? 561840239f027b682512991dc8a2d9fbd685cf5b -> > ?????????? 185a252bd6856073004d1f28772cc91db5265a24 > jdk9-b32?? c12547c511398ea3693e6d7fb4bec0327b1fc9d0 -> > ?????????? c12fc70b13cbd7973340ecc6497f32a2bcec6e18 > jdk9-b33?? da89d00f6b11fb22c8bdc8e7e15e5fbfc3b6adbf -> > ?????????? dcf28216b40575059b09a84c764af9c01dcd7d3c > jdk9-b34?? 1c10fa1ffccbe897f0d96bbe6a57bac85b2fca93 -> > ?????????? 4567670051979e1dd0f090acc36a758018ad1073 > jdk9-b35?? b66ebe3f56baccc516a58ca137d47583ca64f3e6 -> > ?????????? 360d68ad494adeedcd5262a14cd02286f200022e > jdk9-b36?? b6110039fcac502fa42cfa995331321de9a51e1c -> > ?????????? b3a6ef997beb041fe33ce468e803e66a1795a20b > jdk9-b37?? 9c6acd29b12b450a42f81e1dd4f59bd279563f65 -> > ?????????? 77b4ef42ae30a6ca60b3c118134382d73a51f434 > jdk9-b38?? 24adfb0c8e172cbc38e9716d4cdb42f3c4de3da6 -> > ?????????? 658e432550973b0e98e53e6fd99de2f840e56ec1 > jdk9-b39?? 485ea7fd5e2922365488048ca2c9f7a6fc3e4a3b -> > ?????????? f81d7b2ce025d3480d21854fb51c1795f20c82fb > jdk9-b40?? 58a8ccea1b4daa9f62ca68ffb38149f21b5a1a9a -> > ?????????? a135302d3ee8cf3cfcaa19c001f70290438a0f5e > jdk9-b41?? 8cd356cf3ec4ee97e858ccf5de9bf46976377afa -> > ?????????? c292ae6d93a833247ee0ab24ba82d44145fcd14f > jdk9-b42?? 0936c96718dfc70ab67dbb0d9dc01378a121d902 -> > ?????????? 79e60c3b730d46fd883558d4c25e41344170c1eb > jdk9-b43?? 1eb568947458e92de7aad81931ca74b02d5a698a -> > ?????????? 4b21498206371ac098e10249ef4a870a08e8e0b7 > jdk9-b44?? 7d4b91d284cbb039940f7570206a53612e827e1d -> > ?????????? e7ba06728e111dbfe36a98c99e4cd64621df5497 > jdk9-b45?? 85b30bcf58e37e0567da627c596c6a91ef214172 -> > ?????????? 8d8affb886b0236f8a717987a24f06143aeed025 > jdk9-b46?? 18fc172427a01c6e0faaec2508e5f20ea138d44f -> > ?????????? 8b14cfeb0b2af65b0070c7539bb1a6a3cdf42a50 > jdk9-b47?? 96dbe32c10287a6deeab467ecb84001327821e3b -> > ?????????? d1aabfd0c22f0181c970167fd30cf14156e2592f > jdk9-b48?? 854a967f554a48cee1900afff7c807bcab20ac0d -> > ?????????? da0347c03db51aa8eb3445a3a828d61a4f6b2c99 > jdk9-b49?? 1114a8700fbf5d49951c446ff4d00154e23334de -> > ?????????? 16babc62f41c2ffca3cb05ddfea6868deead03e9 > jdk9-b50?? 73d70c595feb9056f5e312fb57e01a766b348408 -> > ?????????? b4c32db44013abd2533300539a78fdae1a7ada5b > jdk9-b51?? 62f616cd838441615687595d208ba55720b36650 -> > ?????????? 1281b62285505c23101061654ba241edcdb28a56 > jdk9-b52?? b37eb6882fda011a1326f6c7bc11820c7bd3c79b -> > ?????????? 595161194578e3e9a9ba57ba11029a1833c07d46 > jdk9-b53?? 8328e6ea61eff8fe9c7d9e1bd52eeeecfacc0eb3 -> > ?????????? c0101fb71b37f7c0dcaaba13978e0e459ccec7fb > jdk9-b54?? 2960bc0fc5f8078fc51f633168357e1bcfd2ec23 -> > ?????????? d2364a518d1031cb0c73e7f7cfcfd52eb1f18e94 > jdk9-b55?? ae9f1a7c53596a19fb7791e2f6fff1e1181697bf -> > ?????????? 1c982cb7f85153ac0c210802d9a9e41460c7ba42 > jdk9-b56?? c513144800fd7ffe18c3d56a8d99ca5c7e10154d -> > ?????????? c958aae26d5da5c188d589509687282f0b920c56 > jdk9-b57?? c7c85c928b11bc06424c523559273655f9ebf064 -> > ?????????? a9349830f86c61b5f7c770afd1eb51707325d430 > jdk9-b58?? bb00e7c20647d1c6c0a6d9345c78aa6b4d63540e -> > ?????????? cf75fc532cbad160a44e934c6a69cb34fbffb0f7 > jdk9-b59?? c5bd438ad3ddb76c015c266b8a421fcc2a083871 -> > ?????????? 9956b524fa15e5f9057bddd356a3b45bbaab5e82 > jdk9-b60?? b1bc942e8536ec99113290a354faeac861c474d0 -> > ?????????? f2611cad78090c02826d806fdafd0977d4e68a61 > jdk9-b61?? ed0eb2082c5366b543b995103ca15e3c9222fabe -> > ?????????? 12de2c36de36821b9cb40f4a6c121d66f1b508c1 > jdk9-b62?? 74f5e27c1a0a3e08a943760196f48023142f8951 -> > ?????????? 0c1c88d2fbdbcd23ea051f2abaf6c4a86db458dc > jdk9-b63?? 1781c02b21fc39f48a321b3a228dfb1416896369 -> > ?????????? 0e509299aac83a0a400d27b033854042ba449e1b > jdk9-b64?? c4b925670656911f3a6a614ce532c3c860c67874 -> > ?????????? 72098746c7adfa5568a6c214414b66c85ee697af > jdk9-b65?? 688a079096789c5e509e8c7df9be2c83ff0feb2f -> > ?????????? c400eb68ba57ef03714043f93abb610bd5568734 > jdk9-b66?? 04c42553804769359f05031228bad3eb67a86c8a -> > ?????????? a9e4585e621191f5d637ea0ecf01a38809365436 > jdk9-b67?? b9e17afb88f9568507df8fba8d4fd1151a44862b -> > ?????????? b683e90fcd33347ddba800cb8bad1eb12bdd4180 > jdk9-b68?? d62f5f6168e1d7bc77ba7ebe4df5d65b7dac40bc -> > ?????????? c37853537a4b840b16e79a55c19f2c8ba1f2ff96 > jdk9-b69?? 49d94aa0b583a57789156e5231a5b0568a9c50dc -> > ?????????? 03f8585bd31e76ac22dde481aa7b72032c97ee21 > jdk9-b70?? f7db7365de7fb286a09c754b47ab355d6f3c9dbc -> > ?????????? 5ba4552b04af30ad805a1b529abf88121008f031 > jdk9-b71?? 28a909fd1fdb23803a2e6a2f9f0b705f49dfac1e -> > ?????????? efecadee5f0157acbb4eae9af3e34d240cd16849 > jdk9-b72?? 029d76538456cff7b0af7426aa94f587689f15c5 -> > ?????????? 9b32dc03c950d1cc6517b65f7183c7c4ba2abeca > jdk9-b73?? 2fccb792f420dafa5d794a60696919a011d6548d -> > ?????????? e827738fe4b24e044a7cde30848467f0305f6312 > jdk9-b74?? 2b56a417fe9346491d136a66af48253db470ab71 -> > ?????????? 4348771a983ce0e0a3725ff8c3bc47819426ee0e > jdk9-b75?? 82b65d5247c3b70c758e22291ace566a6770af4d -> > ?????????? 5b65b01ac6be96421af884d6a83f9b2485e99685 > jdk9-b76?? 2a9aa81d8b059ba0327e8eb1c9bddb16da348e4d -> > ?????????? 4744cd8ac0c122eafb651acf2e4828da37bf3d98 > jdk9-b77?? c338b713baf9200145ec010b0c7d619869dac1a4 -> > ?????????? 6cd0bc3967743b9e184103c2266fdac7d6d3fc9d > jdk9-b78?? 889a0bee9ad217a0432ffafa4f33654ad2fdc478 -> > ?????????? dd19c8cf3981f3beb94f78cb6e0618852350ce6b > jdk9-b79?? 0e25715b7751e75364988ab5c6d3d0f9d58225a8 -> > ?????????? e07d3f6a7f4cb3fdb617efee5ae8b86c0a4b4311 > jdk9-b80?? 44d5aadd221f138be030a2511f211412fd8396b0 -> > ?????????? 75282effeb0cbb7d137bd5c70a82d0ae369d4af3 > jdk9-b81?? f40560dd4acc31c65b6c0a7ba47006940d576609 -> > ?????????? feae4e33a44b8ff054ce00e814263bf3241a5982 > jdk9-b82?? 3d5ea5f2178b4d1dccabe240cd831f2b52f98ae3 -> > ?????????? c87a9e00c41b1d876825865a3957d914f4566e17 > jdk9-b83?? b3f2d27e6b318012d0b91b84b077d0c7a92598fe -> > ?????????? 94c1374132b62651645a95dfd9c4912f68e8a579 > jdk9-b84?? 7126ea9c3e5939e363dcc51844a1784f982d6fd1 -> > ?????????? 37c057e10b741299b236f0d31434fc5887a6cb70 > jdk9-b85?? dc27ebe29226ae2fb47f6bc078521b9009e6cc7c -> > ?????????? 3849cb9d2d542abfd7620dbbe54c1eb28d97f38e > jdk9-b86?? 45f77730027fa619cb265c8f7559f3c71f27722b -> > ?????????? e6cc6cb0f2c235edfed1f6fa5396c4768f600ed3 > jdk9-b87?? 36993584a5f14890ef29e2b45a85ccb93b570294 -> > ?????????? 35f1b84b90d68737d90cc9674081c6fd24f727f8 > jdk9-b88?? fb790047ea0b58163c7e3da52b8d2ebdf10d0462 -> > ?????????? 5bc4d39bd96dd6e273a4b34ed0f11e2dedffff85 > jdk9-b89?? d76e1884edcea6d22626e18abc42b644f0cb2d5e -> > ?????????? a060162fb5f65f4f2161bbcacde9a906e032a841 > jdk9-b90?? 56de84c4586df4585469ea590ac8f9b800dc9082 -> > ?????????? e70bd431d9d9655f5ef8ffded19f760d55d1eecc > jdk9-b91?? 3c11ef9b01057974ccba9547a22c2affb2cfa450 -> > ?????????? 03a6c2e9f01c69c246dbad6e1a93d2849df7dc07 > jdk9-b92?? 09482af461673090352ddf606a35677941785d66 -> > ?????????? 748526bd1c42cc0454d6c042705eb28435b8afd2 > jdk9-b93?? bccc9bd46aaaffd7a8958af9d3bcc7f3dd11bded -> > ?????????? b1a75f98bfae7a95dffbb74b0a5ee2ba88f43583 > jdk9-b94?? 66145b502652e8b17501e3231b7b9db0b8c976f1 -> > ?????????? 8cf535c977afe777927f081bdca2549152524104 From jesper.wilhelmsson at oracle.com Wed Jul 8 21:18:29 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 8 Jul 2020 23:18:29 +0200 Subject: Please open up closed changes In-Reply-To: References: Message-ID: <48D8B47B-07D0-4367-9E11-ADE9F62D591E@oracle.com> I have opened the two latter. The first unfortunately have confidential information in it so I can't open that one. /Jesper > On 8 Jul 2020, at 11:42, Lindenmaier, Goetz wrote: > > Hi Jesper & authors, > > Recently, some closed changes have been pushed. > Could you please check whether they can be opened up? > > "8227337: javax/management/remote/mandatory/connection/ReconnectTest.java NoSuchObjectException no such object in table" > https://bugs.openjdk.java.net/browse/JDK-8227337 > https://hg.openjdk.java.net/jdk/jdk/rev/32afaf310208 > > "8248264: WinUpgradeUUIDTest application is missing in downgrade scenario" > https://bugs.openjdk.java.net/browse/JDK-8248264 > https://hg.openjdk.java.net/jdk/jdk/rev/ed2af47e7987 > > "7107012: sun.jvm.hostspot.code.CompressedReadStream readDouble() conversion to long mishandled" https://bugs.openjdk.java.net/browse/JDK-7107012 > https://hg.openjdk.java.net/jdk/jdk/rev/24057288b9ad > > Best regards, > Goetz > > See also http://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003523.html From goetz.lindenmaier at sap.com Thu Jul 9 09:29:06 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 9 Jul 2020 09:29:06 +0000 Subject: Please open up closed changes In-Reply-To: <48D8B47B-07D0-4367-9E11-ADE9F62D591E@oracle.com> References: <48D8B47B-07D0-4367-9E11-ADE9F62D591E@oracle.com> Message-ID: Thanks a lot! Is "8227337: javax/management/remote/mandatory/connection/ReconnectTest.java NoSuchObjectException no such object in table" a candidate for downport? Best regards, Goetz. > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Wednesday, July 8, 2020 11:18 PM > To: Lindenmaier, Goetz > Cc: jdk-dev at openjdk.java.net; Zeller, Arno ; Chris > Plummer ; Daniil Titov > ; alexey.semenyuk at oracle.com > Subject: Re: Please open up closed changes > > I have opened the two latter. The first unfortunately have confidential > information in it so I can't open that one. > /Jesper > > > On 8 Jul 2020, at 11:42, Lindenmaier, Goetz > wrote: > > > > Hi Jesper & authors, > > > > Recently, some closed changes have been pushed. > > Could you please check whether they can be opened up? > > > > "8227337: > javax/management/remote/mandatory/connection/ReconnectTest.java > NoSuchObjectException no such object in table" > > https://bugs.openjdk.java.net/browse/JDK-8227337 > > https://hg.openjdk.java.net/jdk/jdk/rev/32afaf310208 > > > > "8248264: WinUpgradeUUIDTest application is missing in downgrade > scenario" > > https://bugs.openjdk.java.net/browse/JDK-8248264 > > https://hg.openjdk.java.net/jdk/jdk/rev/ed2af47e7987 > > > > "7107012: sun.jvm.hostspot.code.CompressedReadStream readDouble() > conversion to long mishandled" https://bugs.openjdk.java.net/browse/JDK- > 7107012 > > https://hg.openjdk.java.net/jdk/jdk/rev/24057288b9ad > > > > Best regards, > > Goetz > > > > See also http://mail.openjdk.java.net/pipermail/jdk-dev/2019- > November/003523.html From mark.reinhold at oracle.com Thu Jul 9 23:51:33 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 09 Jul 2020 16:51:33 -0700 Subject: RFR: Updated section on Code Conventions. In-Reply-To: References: <20200622094020.797147833@eggemoggin.niobe.net> <15690ebb-6f03-9014-33fb-7c62f458cdc5@oracle.com> <33317468-7359-b1d1-aa05-0ce673128a2a@oracle.com> <1fb7cf56-8eb5-b73f-8fd2-8a5f852af40a@oracle.com> <4A71B635-C45D-4F95-92A1-33F810CFA8F6@ORACLE.COM> Message-ID: <20200709165133.836046289@eggemoggin.niobe.net> 2020/7/2 10:47:52 -0700, jesper.wilhelmsson at oracle.com: > I'll make an attempt at summarizing this discussion so far. There are > a few issues that seems to be key to decide where a Style Guide can be > located, all of them have pros and cons. The list below is not sorted > in any way. Thanks for putting this list together. I think you?ve captured most of the salient issues. I agree with some but not all of your minor points, but rather than discuss those here I?ll just mention one missing issue. > ... > > 2) Small, controlled, set of editors Here?s the missing issue: Who would this set of editors be? As I wrote earlier: Not only would we need an editor to spend time on this, and maintain it for the long haul, but it would inevitably require some of the limited time of at least some of our most experienced contributors. Is that the best use of their time? I don?t know how to answer this question but I don?t see any qualified contributors volunteering, and I certainly can?t take it on myself. Without an answer to this question, all the others are moot. - Mark From daniil.x.titov at oracle.com Thu Jul 9 22:05:29 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 09 Jul 2020 15:05:29 -0700 Subject: Please open up closed changes In-Reply-To: References: <48D8B47B-07D0-4367-9E11-ADE9F62D591E@oracle.com> Message-ID: Hi Goetz, The decision has not yet been made, but usually test bug issues are relatively rarely backported. Best regards, Daniil ?On 7/9/20, 2:29 AM, "Lindenmaier, Goetz" wrote: Thanks a lot! Is "8227337: javax/management/remote/mandatory/connection/ReconnectTest.java NoSuchObjectException no such object in table" a candidate for downport? Best regards, Goetz. > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Wednesday, July 8, 2020 11:18 PM > To: Lindenmaier, Goetz > Cc: jdk-dev at openjdk.java.net; Zeller, Arno ; Chris > Plummer ; Daniil Titov > ; alexey.semenyuk at oracle.com > Subject: Re: Please open up closed changes > > I have opened the two latter. The first unfortunately have confidential > information in it so I can't open that one. > /Jesper > > > On 8 Jul 2020, at 11:42, Lindenmaier, Goetz > wrote: > > > > Hi Jesper & authors, > > > > Recently, some closed changes have been pushed. > > Could you please check whether they can be opened up? > > > > "8227337: > javax/management/remote/mandatory/connection/ReconnectTest.java > NoSuchObjectException no such object in table" > > https://bugs.openjdk.java.net/browse/JDK-8227337 > > https://hg.openjdk.java.net/jdk/jdk/rev/32afaf310208 > > > > "8248264: WinUpgradeUUIDTest application is missing in downgrade > scenario" > > https://bugs.openjdk.java.net/browse/JDK-8248264 > > https://hg.openjdk.java.net/jdk/jdk/rev/ed2af47e7987 > > > > "7107012: sun.jvm.hostspot.code.CompressedReadStream readDouble() > conversion to long mishandled" https://bugs.openjdk.java.net/browse/JDK- > 7107012 > > https://hg.openjdk.java.net/jdk/jdk/rev/24057288b9ad > > > > Best regards, > > Goetz > > > > See also http://mail.openjdk.java.net/pipermail/jdk-dev/2019- > November/003523.html From coleen.phillimore at oracle.com Mon Jul 13 13:39:54 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 Jul 2020 09:39:54 -0400 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes On 7/3/20 4:58 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From calvin.cheung at oracle.com Mon Jul 13 18:17:57 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 13 Jul 2020 11:17:57 -0700 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: <940d42d8-2e21-0169-9060-2f610c7cd576@oracle.com> Vote: yes On 7/3/20 1:58 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Christian Hagedorn (chagedorn) to JDK Reviewer. > > Christian is a member of the HotSpot Compiler Team at Oracle and contributed 47 changes to the JDK > project [1]. At least 35 changes are significant and affect complex code in the JIT compilers. > > Christian has worked on both C1 and C2, acquiring expert knowledge in key areas (for example, loop > unswitching and superword optimizations). He investigated and fixed several highly complex and > long-standing issues in the code base and improved maintainability and debugability of the JITs. All > the while, Christian is constantly updating and extending the sparse documentation, making life > easier for other engineers. > > Votes are due by 09:00 UTC, July 17th, 2020. > > Only current JDK Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > Tobias > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22christian.hagedorn%40oracle.com%22%29%20or%20author%28chagedorn%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/bylaws#lazy-consensus From mark.reinhold at oracle.com Mon Jul 13 19:13:49 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 12:13:49 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols Message-ID: <20200713121349.679081350@eggemoggin.niobe.net> RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ Oracle?s legal department has advised that it is no longer necessary to place trademark symbols after the term ?Java,? nor after compound terms that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory Interface,? etc.). This doc-only patch removes those symbols, on 545 lines across 337 files. For ease of review I?ve placed a couple of other files in the webrev directory: https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch -- Output of `diff -U0` https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines -- Unique added lines only, modulo whitespace Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) Thanks, - Mark From joe.darcy at oracle.com Mon Jul 13 19:29:53 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 Jul 2020 12:29:53 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: Changes under java.lang.*, java.math.*, and javax.lang.model.* look fine. -Joe On 7/13/2020 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From lance.andersen at oracle.com Mon Jul 13 19:35:50 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 13 Jul 2020 15:35:50 -0400 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: The java.sql and java.sql.rowset changes look fine > On Jul 13, 2020, at 3:13 PM, mark.reinhold at oracle.com wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From philip.race at oracle.com Mon Jul 13 19:54:30 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 13 Jul 2020 12:54:30 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <5F0CBBF6.3060603@oracle.com> The 205(!) files updated in java desktop look fine. I estimate that 99% of them were JavaBeans references. Since I overshot by 2 files I noticed in logging we still have a reference to "Java 2" https://cr.openjdk.java.net/~mr/rev/8249205/src/java.logging/share/classes/java/util/logging/package-info.java.udiff.html + * the Java 2 platform's core logging facilities. Looking at the raw patch I then saw a couple of others + * in the JDBC 2.0 API (Java 2 SDK, + * Java 2 SDK, Standard Edition, Another clean up task for another day or add it to this patch ? -phil. On 7/13/20, 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From brian.burkhalter at oracle.com Mon Jul 13 19:56:40 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 Jul 2020 12:56:40 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <8F79353C-7B0E-4EB6-9909-FC180023E413@oracle.com> Changes under java.io look good; nothing under java.nio. Brian > On Jul 13, 2020, at 12:13 PM, mark.reinhold at oracle.com wrote: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` From chris.plummer at oracle.com Mon Jul 13 20:18:38 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Jul 2020 13:18:38 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <9a0fe248-689a-0e57-2c7b-7ebf8fd6504f@oracle.com> Hi Mark, The make/data/jdwp/jdwp_spec, jdk.attach, and jdk.jdi changes look fine. What about "Java" references in src/hotspot/share/prims/jvmti.xml? There's are also J2SE references in that doc with a trademark. Are copyrights going to be updated as part of this change? thanks, Chris On 7/13/20 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From jonathan.gibbons at oracle.com Mon Jul 13 20:55:56 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Jul 2020 13:55:56 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <94d4f1d2-38cb-9bca-70f2-dee61f35123a@oracle.com> FYI, There are various instances of ??? Java® Should these go as well? -- Jon On 7/13/20 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From mark.reinhold at oracle.com Mon Jul 13 21:54:26 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 14:54:26 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <5F0CBBF6.3060603@oracle.com> References: <20200713121349.679081350@eggemoggin.niobe.net> <5F0CBBF6.3060603@oracle.com> Message-ID: <20200713145426.786308298@eggemoggin.niobe.net> 2020/7/13 12:54:30 -0700, philip.race at oracle.com: > The 205(!) files updated in java desktop look fine. > I estimate that 99% of them were JavaBeans references. > > Since I overshot by 2 files I noticed in logging we still have a > reference to "Java 2" > https://cr.openjdk.java.net/~mr/rev/8249205/src/java.logging/share/classes/java/util/logging/package-info.java.udiff.html > > + * the Java 2 platform's core logging facilities. > > > Looking at the raw patch I then saw a couple of others > > + * in the JDBC 2.0 API (Java 2 SDK, > > + * Java 2 SDK, Standard Edition, > > > Another clean up task for another day or add it to this patch ? I have a separate patch to kill off (finally!) the last vestiges of ?Java 2.? - Mark From mark.reinhold at oracle.com Mon Jul 13 21:57:29 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 14:57:29 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <94d4f1d2-38cb-9bca-70f2-dee61f35123a@oracle.com> References: <20200713121349.679081350@eggemoggin.niobe.net> <94d4f1d2-38cb-9bca-70f2-dee61f35123a@oracle.com> Message-ID: <20200713145729.884826392@eggemoggin.niobe.net> 2020/7/13 13:55:56 -0700, jonathan.gibbons at oracle.com: > There are various instances of > Java® > > Should these go as well? No -- those should be retained. - Mark From mark.reinhold at oracle.com Mon Jul 13 22:11:21 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 15:11:21 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <9a0fe248-689a-0e57-2c7b-7ebf8fd6504f@oracle.com> References: <20200713121349.679081350@eggemoggin.niobe.net> <9a0fe248-689a-0e57-2c7b-7ebf8fd6504f@oracle.com> Message-ID: <20200713151121.279238483@eggemoggin.niobe.net> 2020/7/13 13:18:38 -0700, chris.plummer at oracle.com: > What about "Java" references in > src/hotspot/share/prims/jvmti.xml? There's are also J2SE references in > that doc with a trademark. Well spotted! Fixing that will require changing the stylesheet, which is also used to generate code, and we?re in RDP 1 for JDK 15. I?ve filed a separate RFE for that (8249260) and will aim to fix it in 16. > Are copyrights going to be updated as part of this change? No. - Mark From mark.reinhold at oracle.com Mon Jul 13 22:44:55 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 15:44:55 -0700 (PDT) Subject: JEP proposed to target JDK 16: 347: Enable C++14 Language Features Message-ID: <20200713224455.1651B3BB196@eggemoggin.niobe.net> The following JEP is proposed to target JDK 16: 347: Enable C++14 Language Features https://openjdk.java.net/jeps/347 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Monday, 20 July, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 16. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Mon Jul 13 22:56:18 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 15:56:18 -0700 (PDT) Subject: New candidate JEP: 388: Windows/AArch64 Port Message-ID: <20200713225618.5C9503BB19F@eggemoggin.niobe.net> https://openjdk.java.net/jeps/388 - Mark From pavel.rappo at oracle.com Mon Jul 13 23:01:51 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 14 Jul 2020 00:01:51 +0100 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: Mark, Since we are in this area, what about this servicemark? * at the Java Developer Connection SM *
  • Java Foundation Classes (JFC) home page
    • Separately: does that "Java Developer Connection" refer to anything meaningful these days? I could only find archival records such as: https://web.archive.org/web/20000510010920/http://developer.java.sun.com/ https://web.archive.org/web/19991013065927/http://developer.java.sun.com:80/developer/membership.html > On 13 Jul 2020, at 20:13, mark.reinhold at oracle.com wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From mark.reinhold at oracle.com Mon Jul 13 23:09:15 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jul 2020 16:09:15 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <20200713160915.165600656@eggemoggin.niobe.net> 2020/7/13 16:01:51 -0700, pavel.rappo at oracle.com: > Since we are in this area, what about this servicemark? > > * at the Java Developer Connection SM > *
  • * target="_top">Java Foundation Classes (JFC) home page
    • That?s probably not necessary, but I?d have to check with Oracle?s legal department. > Separately: does that "Java Developer Connection" refer to anything > meaningful these days? Not to my knowledge! - Mark From daniel.fuchs at oracle.com Tue Jul 14 09:28:42 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Jul 2020 10:28:42 +0100 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <9d0d11a9-428f-0050-beca-49f4f0b18348@oracle.com> Changes to java.logging, java.management, and java.naming look good to me. best regards, -- daniel On 13/07/2020 20:13, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark > From weijun.wang at oracle.com Tue Jul 14 13:41:59 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Jul 2020 21:41:59 +0800 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <38B907AC-1640-488C-9BCB-11D55213C0C8@oracle.com> Only 3 files security-related, and they looks fine. Thanks, Max > On Jul 14, 2020, at 3:13 AM, mark.reinhold at oracle.com wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From bradford.wetmore at oracle.com Tue Jul 14 16:25:48 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 14 Jul 2020 09:25:48 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <6f7092eb-c61c-c04b-25d7-3eb2a943d8a1@oracle.com> In our group, we have gotten in the habit of updating the copyright years when editing files. But otherwise these look alright. src/java.base/share/classes/java/security/SecureClassLoader.java src/java.base/share/classes/javax/net/ssl/package-info.java src/java.base/share/classes/javax/security/auth/login/package-info.java Brad On 7/13/2020 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark > From huizhe.wang at oracle.com Tue Jul 14 18:13:18 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 14 Jul 2020 11:13:18 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: Only one file in java.xml, and it looks good to me. I also searched '?' but found nothing :-) -Joe On 7/13/20 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark From mark.reinhold at oracle.com Tue Jul 14 19:21:24 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 14 Jul 2020 12:21:24 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <6f7092eb-c61c-c04b-25d7-3eb2a943d8a1@oracle.com> References: <20200713121349.679081350@eggemoggin.niobe.net> <6f7092eb-c61c-c04b-25d7-3eb2a943d8a1@oracle.com> Message-ID: <20200714122124.768541226@eggemoggin.niobe.net> 2020/7/14 9:25:48 -0700, bradford.wetmore at oracle.com: > In our group, we have gotten in the habit of updating the copyright > years when editing files. Generally that?s the right thing to do. In this case the changes are so far from being substantive, however, that it?s not worth the noise or the effort. > But otherwise these look alright. Thanks! - Mark From brent.christian at oracle.com Tue Jul 14 19:45:26 2020 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 14 Jul 2020 12:45:26 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <4c5d8431-7e37-e1c8-f83f-c7156943323a@oracle.com> The changes in: java.util java.util.concurrent java.util.regex jdk.internal.module java.lang.instrument javax.management look fine to me. -Brent On 7/13/20 12:13 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ > > Oracle?s legal department has advised that it is no longer necessary to > place trademark symbols after the term ?Java,? nor after compound terms > that begin with ?Java? (e.g., ?JavaBeans,? ?Java Naming and Directory > Interface,? etc.). > > This doc-only patch removes those symbols, on 545 lines across 337 files. > > For ease of review I?ve placed a couple of other files in the webrev > directory: > > https://cr.openjdk.java.net/~mr/rev/8249205/diff-U0.patch > -- Output of `diff -U0` > https://cr.openjdk.java.net/~mr/rev/8249205/unique-added-lines > -- Unique added lines only, modulo whitespace > > Passes tiers 1-3 on the usual platforms. (Yes, I?m paranoid.) > > Thanks, > - Mark > From iris.clark at oracle.com Tue Jul 14 21:32:26 2020 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 14 Jul 2020 14:32:26 -0700 (PDT) Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: Hi, Mark. > RFE: https://bugs.openjdk.java.net/browse/JDK-8249205 > Webrev: https://cr.openjdk.java.net/~mr/rev/8249205/ I looked at all the changes and they look fine. Thanks, Iris From serguei.spitsyn at oracle.com Wed Jul 15 21:12:22 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jul 2020 14:12:22 -0700 Subject: CFV: New JDK Reviewer: Christian Hagedorn In-Reply-To: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> References: <0c7af55d-70d5-aef6-10ab-471fb9311222@oracle.com> Message-ID: Vote: yes From mark.reinhold at oracle.com Wed Jul 15 21:27:35 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 15 Jul 2020 14:27:35 -0700 Subject: 15 RFR (S) 8249205: Remove unnecessary trademark symbols In-Reply-To: <20200713121349.679081350@eggemoggin.niobe.net> References: <20200713121349.679081350@eggemoggin.niobe.net> Message-ID: <20200715142735.457526681@eggemoggin.niobe.net> Thanks for the reviews! Changeset pushed. - Mark From mark.reinhold at oracle.com Thu Jul 16 16:14:15 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Jul 2020 09:14:15 -0700 (PDT) Subject: JDK 15 is now in Rampdown Phase Two Message-ID: <20200716161415.D0F043BB717@eggemoggin.niobe.net> Per the JDK 15 schedule [1], we are now in Rampdown Phase Two. The overall feature set is frozen. No further JEPs will be targeted to this release. Per the JDK Release Process [2] we now turn our focus to P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are still possible, with approval [4], but the bar is now extraordinarily high. If you?re responsible for any of the bugs on the RDP 2 candidate-bug list [5] then please see JEP 3 for guidance on how to handle them. - Mark [1] https://openjdk.java.net/projects/jdk/15/#Schedule [2] https://openjdk.java.net/jeps/3 [3] https://openjdk.java.net/jeps/3#Fix-Request-Process [4] https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process [5] https://j.mp/jdk-rdp-2 From sgehwolf at redhat.com Fri Jul 17 15:49:20 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 Jul 2020 17:49:20 +0200 Subject: Opening up closed issues? Message-ID: Hi, I've noticed that some bugs referenced in some JDK version of ProblemList.txt are not accessible. Is that intentional? Referenced in ProblemList.txt for runtime/NMT/MallocStressTest.java: https://bugs.openjdk.java.net/browse/JDK-8166548 Referenced in ProblemList.txt for runtime/6929067/Test6929067.sh https://bugs.openjdk.java.net/browse/JDK-8028740 Referenced in ProblemList.txt for runtime/6626217/Test6626217.sh https://bugs.openjdk.java.net/browse/JDK-8028733 Referenced in ProblemList.txt for runtime/jsig/Test8017498.sh https://bugs.openjdk.java.net/browse/JDK-8028806 Is there a good reason for them to be private? Thanks for your help! Cheers, Severin From doko at ubuntu.com Fri Jul 17 16:47:29 2020 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 17 Jul 2020 18:47:29 +0200 Subject: jdk-15+32 can't be built using OpenJDK 14 Message-ID: <0749bca3-4dda-665f-e9db-1484e2da0ebf@ubuntu.com> Seen with jdk-15+32 on platforms with just the zero VM. The build fails with Executing: [/usr/lib/jvm/java-14-openjdk-x32/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp /<>/build/hotspot/variant-zero/tools/jvmti jvmtiGen -IN /<>/src/hotspot/share/prims/jvmti.xml -XSL /<>/src/hotspot/share/prims/jvmtiH.xsl -OUT /<>/build/hotspot/variant-zero/gensrc/jvmtifiles/jvmti.h -PARAM majorversion 15] /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4252: error: switch expressions are a preview feature and are disabled by default. switch (next.kind) { ^ (use --enable-preview to enable switch expressions) /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4253: error: multiple case labels are a preview feature and are disabled by default. case MONKEYS_AT, ABSTRACT, FINAL, STRICTFP, CLASS, INTERFACE, ENUM -> true; ^ (use --enable-preview to enable multiple case labels) /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4253: error: switch rules are a preview feature and are disabled by default. case MONKEYS_AT, ABSTRACT, FINAL, STRICTFP, CLASS, INTERFACE, ENUM -> true; ^ (use --enable-preview to enable switch rules) This is the first build in a bootcycle configuration. Matthias From jan.lahoda at oracle.com Fri Jul 17 17:20:29 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 17 Jul 2020 19:20:29 +0200 Subject: jdk-15+32 can't be built using OpenJDK 14 In-Reply-To: <0749bca3-4dda-665f-e9db-1484e2da0ebf@ubuntu.com> References: <0749bca3-4dda-665f-e9db-1484e2da0ebf@ubuntu.com> Message-ID: <55276d4c-fb5b-1a98-5125-c035850b72a0@oracle.com> Hi Matthias, Do you have more information about what exactly is the boot JDK? E.g. what was the source revision, etc.? Switch expressions have been made final in JDK 14, see: https://openjdk.java.net/jeps/361 https://hg.openjdk.java.net/jdk/jdk/rev/cfc7bb9a5a92 Thanks, Jan On 17. 07. 20 18:47, Matthias Klose wrote: > Seen with jdk-15+32 on platforms with just the zero VM. The build fails with > > Executing: [/usr/lib/jvm/java-14-openjdk-x32/bin/java -XX:+UseSerialGC -Xms32M > -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /<>/build/hotspot/variant-zero/tools/jvmti jvmtiGen -IN > /<>/src/hotspot/share/prims/jvmti.xml -XSL > /<>/src/hotspot/share/prims/jvmtiH.xsl -OUT > /<>/build/hotspot/variant-zero/gensrc/jvmtifiles/jvmti.h -PARAM > majorversion 15] > /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4252: > error: switch expressions are a preview feature and are disabled by default. > switch (next.kind) { > ^ > (use --enable-preview to enable switch expressions) > /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4253: > error: multiple case labels are a preview feature and are disabled by default. > case MONKEYS_AT, ABSTRACT, FINAL, STRICTFP, CLASS, INTERFACE, > ENUM -> true; > ^ > (use --enable-preview to enable multiple case labels) > /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4253: > error: switch rules are a preview feature and are disabled by default. > case MONKEYS_AT, ABSTRACT, FINAL, STRICTFP, CLASS, INTERFACE, > ENUM -> true; > ^ > (use --enable-preview to enable switch rules) > > > This is the first build in a bootcycle configuration. > > Matthias > From alex.buckley at oracle.com Fri Jul 17 17:21:18 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 17 Jul 2020 10:21:18 -0700 Subject: jdk-15+32 can't be built using OpenJDK 14 In-Reply-To: <0749bca3-4dda-665f-e9db-1484e2da0ebf@ubuntu.com> References: <0749bca3-4dda-665f-e9db-1484e2da0ebf@ubuntu.com> Message-ID: <1103e9fd-644d-e538-147c-537ba43b3e05@oracle.com> This is very odd because switch expressions (+ multiple case labels + switch rules) were not a preview feature in JDK 14. They were final and permanent in JDK 14. JDK 14 would not need --enable-preview to compile lines 4252 and 4253 of JavacParser.java. Alex On 7/17/2020 9:47 AM, Matthias Klose wrote: > Seen with jdk-15+32 on platforms with just the zero VM. The build fails with > > Executing: [/usr/lib/jvm/java-14-openjdk-x32/bin/java -XX:+UseSerialGC -Xms32M > -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /<>/build/hotspot/variant-zero/tools/jvmti jvmtiGen -IN > /<>/src/hotspot/share/prims/jvmti.xml -XSL > /<>/src/hotspot/share/prims/jvmtiH.xsl -OUT > /<>/build/hotspot/variant-zero/gensrc/jvmtifiles/jvmti.h -PARAM > majorversion 15] > /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4252: > error: switch expressions are a preview feature and are disabled by default. > switch (next.kind) { > ^ > (use --enable-preview to enable switch expressions) > /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4253: > error: multiple case labels are a preview feature and are disabled by default. > case MONKEYS_AT, ABSTRACT, FINAL, STRICTFP, CLASS, INTERFACE, > ENUM -> true; > ^ > (use --enable-preview to enable multiple case labels) > /<>/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:4253: > error: switch rules are a preview feature and are disabled by default. > case MONKEYS_AT, ABSTRACT, FINAL, STRICTFP, CLASS, INTERFACE, > ENUM -> true; > ^ > (use --enable-preview to enable switch rules) > > > This is the first build in a bootcycle configuration. > > Matthias > From goetz.lindenmaier at sap.com Sun Jul 19 07:47:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 19 Jul 2020 07:47:03 +0000 Subject: Opening up closed issues? In-Reply-To: References: Message-ID: Hi, Yes, please either open them up, or create a copy with the Information you can publish, and adapt the ProblemList. Thanks, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Severin > Gehwolf > Sent: Friday, July 17, 2020 5:49 PM > To: jdk-dev > Subject: Opening up closed issues? > > Hi, > > I've noticed that some bugs referenced in some JDK version of > ProblemList.txt are not accessible. Is that intentional? > > Referenced in ProblemList.txt for runtime/NMT/MallocStressTest.java: > https://bugs.openjdk.java.net/browse/JDK-8166548 > > Referenced in ProblemList.txt for runtime/6929067/Test6929067.sh > https://bugs.openjdk.java.net/browse/JDK-8028740 > > Referenced in ProblemList.txt for runtime/6626217/Test6626217.sh > https://bugs.openjdk.java.net/browse/JDK-8028733 > > Referenced in ProblemList.txt for runtime/jsig/Test8017498.sh > https://bugs.openjdk.java.net/browse/JDK-8028806 > > Is there a good reason for them to be private? > > Thanks for your help! > > Cheers, > Severin > > From Alan.Bateman at oracle.com Sun Jul 19 08:04:56 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Jul 2020 09:04:56 +0100 Subject: Opening up closed issues? In-Reply-To: References: Message-ID: <5fd384f1-1f17-12bb-0fc9-697dcb73f9f4@oracle.com> On 17/07/2020 16:49, Severin Gehwolf wrote: > Hi, > > I've noticed that some bugs referenced in some JDK version of > ProblemList.txt are not accessible. Is that intentional? I just checked the ProblemList files in the jdk/jdk repo and don't see these references. Can you say where you are seeing these references? Just wondering if there is something historical. -Alan > > Referenced in ProblemList.txt for runtime/NMT/MallocStressTest.java: > https://bugs.openjdk.java.net/browse/JDK-8166548 > > Referenced in ProblemList.txt for runtime/6929067/Test6929067.sh > https://bugs.openjdk.java.net/browse/JDK-8028740 > > Referenced in ProblemList.txt for runtime/6626217/Test6626217.sh > https://bugs.openjdk.java.net/browse/JDK-8028733 > > Referenced in ProblemList.txt for runtime/jsig/Test8017498.sh > https://bugs.openjdk.java.net/browse/JDK-8028806 > > Is there a good reason for them to be private? > > Thanks for your help! > > Cheers, > Severin > > > From tobias.hartmann at oracle.com Mon Jul 20 07:07:08 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Jul 2020 09:07:08 +0200 Subject: Result: New JDK Reviewer: Christian Hagedorn Message-ID: Voting for Christian Hagedorn [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Tobias [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004474.html From sgehwolf at redhat.com Mon Jul 20 07:52:15 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 Jul 2020 09:52:15 +0200 Subject: Opening up closed issues? In-Reply-To: <5fd384f1-1f17-12bb-0fc9-697dcb73f9f4@oracle.com> References: <5fd384f1-1f17-12bb-0fc9-697dcb73f9f4@oracle.com> Message-ID: <6de6da24017b2efb9c01b2f3c3d67ab6b9204fe4.camel@redhat.com> Hi Alan, On Sun, 2020-07-19 at 09:04 +0100, Alan Bateman wrote: > On 17/07/2020 16:49, Severin Gehwolf wrote: > > Hi, > > > > I've noticed that some bugs referenced in some JDK version of > > ProblemList.txt are not accessible. Is that intentional? > I just checked the ProblemList files in the jdk/jdk repo and don't see > these references. Can you say where you are seeing these references? > Just wondering if there is something historical. Yes, this info is historical. In particular it was present at some point in the JDK 9 timeframe: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1b0d8f3d0bb3 I'd like to backport adding ProblemList.txt to hotspot to OpenJDK 8u[1], thus, was looking at this change. Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012181.html > -Alan > > > Referenced in ProblemList.txt for runtime/NMT/MallocStressTest.java: > > https://bugs.openjdk.java.net/browse/JDK-8166548 > > > > Referenced in ProblemList.txt for runtime/6929067/Test6929067.sh > > https://bugs.openjdk.java.net/browse/JDK-8028740 > > > > Referenced in ProblemList.txt for runtime/6626217/Test6626217.sh > > https://bugs.openjdk.java.net/browse/JDK-8028733 > > > > Referenced in ProblemList.txt for runtime/jsig/Test8017498.sh > > https://bugs.openjdk.java.net/browse/JDK-8028806 > > > > Is there a good reason for them to be private? > > > > Thanks for your help! > > > > Cheers, > > Severin > > > > > > From mark.reinhold at oracle.com Tue Jul 21 22:31:40 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 21 Jul 2020 15:31:40 -0700 Subject: JEP proposed to target JDK 16: 347: Enable C++14 Language Features In-Reply-To: <20200713224455.1651B3BB196@eggemoggin.niobe.net> References: <20200713224455.1651B3BB196@eggemoggin.niobe.net> Message-ID: <20200721153140.701867821@eggemoggin.niobe.net> 2020/7/13 15:44:55 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 16: > > 347: Enable C++14 Language Features > https://openjdk.java.net/jeps/347 > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:00 UTC on Monday, 20 July, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 16. Hearing no objections, I?ve targeted this JEP to JDK 16. - Mark From vladimir.x.ivanov at oracle.com Wed Jul 22 15:06:05 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Jul 2020 18:06:05 +0300 Subject: Result: New JDK Committer: Shravya Rukmannagari Message-ID: <09687284-0f71-8df2-5362-e89373b64634@oracle.com> Voting for Shravya Rukmannagari [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Best regards, Vladimir Ivanov [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004454.html From STANISLAV.SMIRNOV at ORACLE.COM Wed Jul 22 19:26:30 2020 From: STANISLAV.SMIRNOV at ORACLE.COM (Stanislav Smirnov) Date: Wed, 22 Jul 2020 15:26:30 -0400 Subject: jdk/submit maintenance, July 23rd - July 27th Message-ID: <8754038A-93DA-40AC-9AAA-5AEBA5A59A1D@ORACLE.COM> Hello, A planned maintenance will happen this week, July 23rd - 27th. jdk/submit builds will not be available starting tomorrow (Thursday 23rd) at 10am PT / 17:00 GMT. The system should be back online by 10am PT / 17:00 GMT, July 27th. Best regards, Stanislav Smirnov From STANISLAV.SMIRNOV at ORACLE.COM Thu Jul 23 01:39:40 2020 From: STANISLAV.SMIRNOV at ORACLE.COM (Stanislav Smirnov) Date: Wed, 22 Jul 2020 21:39:40 -0400 Subject: jdk/submit maintenance, July 23rd - July 27th In-Reply-To: <8754038A-93DA-40AC-9AAA-5AEBA5A59A1D@ORACLE.COM> References: <8754038A-93DA-40AC-9AAA-5AEBA5A59A1D@ORACLE.COM> Message-ID: <335D0317-7810-46F1-82B7-BE9268887A83@ORACLE.COM> Hello, Due to circumstances beyond our control the planned maintenance is called off. This means, that jdk/submit will continue to work. Best regards, Stanislav Smirnov > On Jul 22, 2020, at 3:26 PM, Stanislav Smirnov wrote: > > Hello, > > A planned maintenance will happen this week, July 23rd - 27th. > jdk/submit builds will not be available starting tomorrow (Thursday 23rd) at 10am PT / 17:00 GMT. > > The system should be back online by 10am PT / 17:00 GMT, July 27th. > > Best regards, > Stanislav Smirnov From sgehwolf at redhat.com Fri Jul 24 13:15:47 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 24 Jul 2020 15:15:47 +0200 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? Message-ID: Hi, Any particular reason this bug is not public? 8248524: [JVMCI] Memory corruption / segfault during NumPy installation. https://bugs.openjdk.java.net/browse/JDK-8248524 Thanks, Severin From david.holmes at oracle.com Fri Jul 24 13:37:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2020 23:37:29 +1000 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: References: Message-ID: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> On 24/07/2020 11:15 pm, Severin Gehwolf wrote: > Hi, > > Any particular reason this bug is not public? It contains information in the description that requires it not be public - sorry. But it basically says (as seen in the patch) that the resource array may be too small. David ----- > 8248524: [JVMCI] Memory corruption / segfault during NumPy installation. > https://bugs.openjdk.java.net/browse/JDK-8248524 > > Thanks, > Severin > From sgehwolf at redhat.com Fri Jul 24 13:47:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 24 Jul 2020 15:47:10 +0200 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> Message-ID: <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> On Fri, 2020-07-24 at 23:37 +1000, David Holmes wrote: > On 24/07/2020 11:15 pm, Severin Gehwolf wrote: > > Hi, > > > > Any particular reason this bug is not public? > > It contains information in the description that requires it not be > public - sorry. But it basically says (as seen in the patch) that the > resource array may be too small. OK, thanks, David. Does anybody know whether this issue of closed bugs being used to push changes will be rectified once moved to git and skara via JEPs 357/369? It would be nice if that could be caught in future. I.e. if a bug exists that contains internal/confidential info, another bug needs to be created, possibly referencing the other. In a setup which I've in mind only public bug could be used to push changes. Hopefully we'll get there :) Thanks, Severin From david.holmes at oracle.com Fri Jul 24 14:16:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Jul 2020 00:16:10 +1000 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: On 24/07/2020 11:47 pm, Severin Gehwolf wrote: > On Fri, 2020-07-24 at 23:37 +1000, David Holmes wrote: >> On 24/07/2020 11:15 pm, Severin Gehwolf wrote: >>> Hi, >>> >>> Any particular reason this bug is not public? >> >> It contains information in the description that requires it not be >> public - sorry. But it basically says (as seen in the patch) that the >> resource array may be too small. > > OK, thanks, David. > > Does anybody know whether this issue of closed bugs being used to push > changes will be rectified once moved to git and skara via JEPs 357/369? I don't think there is any connection between the two things so the move to git won't change anything there. > It would be nice if that could be caught in future. I.e. if a bug > exists that contains internal/confidential info, another bug needs to > be created, possibly referencing the other. In a setup which I've in > mind only public bug could be used to push changes. Hopefully we'll get > there :) I'm not sure where such a policy decision needs to be made. David ----- > Thanks, > Severin > From matthias.baesken at sap.com Fri Jul 24 14:25:01 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 24 Jul 2020 14:25:01 +0000 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: > It would be nice if that could be caught in future. I.e. if a bug > exists that contains internal/confidential info, another bug needs to > be created, possibly referencing the other. I think this is already how it should be done, but maybe Goetz can comment on it more . Best regards, Matthias From christoph.langer at sap.com Fri Jul 24 16:08:58 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 Jul 2020 16:08:58 +0000 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: Hi, > > Does anybody know whether this issue of closed bugs being used to push > > changes will be rectified once moved to git and skara via JEPs 357/369? > > I don't think there is any connection between the two things so the move > to git won't change anything there. Well, I think at least Skara should give us the technical possibilities to mechanically enforce such a policy. > > It would be nice if that could be caught in future. I.e. if a bug > > exists that contains internal/confidential info, another bug needs to > > be created, possibly referencing the other. In a setup which I've in > > mind only public bug could be used to push changes. Hopefully we'll get > > there :) > > I'm not sure where such a policy decision needs to be made. I guess this decision probably needs to be taken by Mark / the Governing Board? Best regards Christoph From kevin.rushforth at oracle.com Fri Jul 24 17:44:39 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 Jul 2020 10:44:39 -0700 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: <63207dc6-f1e3-bb69-d908-e10a1218d49d@oracle.com> Setting aside the policy discussion, the Skara tooling will at least alert reviewers that something is amiss by showing a warning message where the JBS issue link and description would go: Issue * ?? Failed to retrieve information on issue |8250553|. Perhaps an RFE for the Skara team could make this more explicit in the case where it can't retrieve the information because the bug is Confidential. See the following PR, which is referring to a Confidential bug, for an example of how it looks now: https://github.com/openjdk/jfx/pull/273 -- Kevin On 7/24/2020 9:08 AM, Langer, Christoph wrote: > Hi, > >>> Does anybody know whether this issue of closed bugs being used to push >>> changes will be rectified once moved to git and skara via JEPs 357/369? >> I don't think there is any connection between the two things so the move >> to git won't change anything there. > Well, I think at least Skara should give us the technical possibilities to mechanically enforce such a policy. > >>> It would be nice if that could be caught in future. I.e. if a bug >>> exists that contains internal/confidential info, another bug needs to >>> be created, possibly referencing the other. In a setup which I've in >>> mind only public bug could be used to push changes. Hopefully we'll get >>> there :) >> I'm not sure where such a policy decision needs to be made. > I guess this decision probably needs to be taken by Mark / the Governing Board? > > Best regards > Christoph From ioi.lam at oracle.com Mon Jul 27 23:07:33 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 27 Jul 2020 16:07:33 -0700 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: <96193f8a-75eb-a14b-a82e-0b18341c7eae@oracle.com> On 7/24/20 7:16 AM, David Holmes wrote: > On 24/07/2020 11:47 pm, Severin Gehwolf wrote: >> On Fri, 2020-07-24 at 23:37 +1000, David Holmes wrote: >>> On 24/07/2020 11:15 pm, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Any particular reason this bug is not public? >>> >>> It contains information in the description that requires it not be >>> public - sorry. But it basically says (as seen in the patch) that the >>> resource array may be too small. >> >> OK, thanks, David. >> >> Does anybody know whether this issue of closed bugs being used to push >> changes will be rectified once moved to git and skara via JEPs 357/369? > > I don't think there is any connection between the two things so the > move to git won't change anything there. > >> It would be nice if that could be caught in future. I.e. if a bug >> exists that contains internal/confidential info, another bug needs to >> be created, possibly referencing the other. In a setup which I've in >> mind only public bug could be used to push changes. Hopefully we'll get >> there :) > > I'm not sure where such a policy decision needs to be made. > For these closed bugs, I think we should create a public bug for the general JDK community. Maybe we can standardize on a format so it's easy to search? E.g., the title of the bug should be ??? Public information for JDK-1234567 And maybe we can program JIRA to automatically redirect to the public bug (if the original bug has a link to the public bug, and the title matches the pattern). Or maybe add a new type of "public-info" to the links. Thanks - Ioi From archana.nogriya at uk.ibm.com Tue Jul 28 12:07:20 2020 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Tue, 28 Jul 2020 13:07:20 +0100 Subject: Copyright Issues : JDK15 - GPLv2 is present but Classpath exception is missing Message-ID: Hi, Please can someone help to fix these copyright issues in JDK15. We found these issues in our internal scan. make/ide/idea/langtools/template/copyright/langtools.xml: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/ArgsParser.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/BuildConfig.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/FileTreeCreator.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/FileTreeCreatorVC10.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/ProjectCreator.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/Util.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/WinGammaPlatform.java: GPLv2 is present but Classpath exception is missing make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/WinGammaPlatformVC10.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/intpoly/FieldGen.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/PandocManPageHtmlFilter.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/PandocManPageTroffFilter.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSON.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONArray.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONBoolean.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONDecimal.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONNull.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONNumber.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONObject.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONParser.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONString.java: GPLv2 is present but Classpath exception is missing make/jdk/src/classes/build/tools/pandocfilter/json/JSONValue.java: GPLv2 is present but Classpath exception is missing src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java: GPLv2 is present but Classpath exception is missing Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Tue Jul 28 13:40:22 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jul 2020 23:40:22 +1000 Subject: Copyright Issues : JDK15 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: Message-ID: <772e0556-28b7-aa9e-0f28-aa76330d576d@oracle.com> Hi, On 28/07/2020 10:07 pm, Archana Nogriya wrote: > Hi, > > Please can someone help to fix these copyright issues in JDK15. > We found these issues in our internal scan. Why should these files require the classpath exception? They are not classes you would link against. Cheers, David ----- > > make/ide/idea/langtools/template/copyright/langtools.xml: GPLv2 is present > but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/ArgsParser.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/BuildConfig.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/FileTreeCreator.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/FileTreeCreatorVC10.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/ProjectCreator.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/Util.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/WinGammaPlatform.java: > GPLv2 is present but Classpath exception is missing > > make/ide/visualstudio/hotspot/src/classes/build/tools/projectcreator/WinGammaPlatformVC10.java: > GPLv2 is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/intpoly/FieldGen.java: GPLv2 is present > but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/PandocManPageHtmlFilter.java: > GPLv2 is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/PandocManPageTroffFilter.java: > GPLv2 is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSON.java: GPLv2 is > present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONArray.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONBoolean.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONDecimal.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONNull.java: GPLv2 is > present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONNumber.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONObject.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONParser.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONString.java: GPLv2 > is present but Classpath exception is missing > > make/jdk/src/classes/build/tools/pandocfilter/json/JSONValue.java: GPLv2 > is present but Classpath exception is missing > > src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java: > GPLv2 is present but Classpath exception is missing > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager > IBM Hursley > IBM United Kingdom Ltd > internet email: archana.nogriya at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From sgehwolf at redhat.com Tue Jul 28 13:44:36 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 28 Jul 2020 15:44:36 +0200 Subject: Copyright Issues : JDK15 - GPLv2 is present but Classpath exception is missing In-Reply-To: <772e0556-28b7-aa9e-0f28-aa76330d576d@oracle.com> References: <772e0556-28b7-aa9e-0f28-aa76330d576d@oracle.com> Message-ID: <2fc3326890cdeffdf2a71f4004e0d159e0bd361b.camel@redhat.com> On Tue, 2020-07-28 at 23:40 +1000, David Holmes wrote: > Hi, > > On 28/07/2020 10:07 pm, Archana Nogriya wrote: > > Hi, > > > > Please can someone help to fix these copyright issues in JDK15. > > We found these issues in our internal scan. > > Why should these files require the classpath exception? They are not > classes you would link against. [...] > > src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java: > > GPLv2 is present but Classpath exception is missing ---^ This one probably is? Thanks, Severin From david.holmes at oracle.com Tue Jul 28 13:50:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jul 2020 23:50:57 +1000 Subject: Copyright Issues : JDK15 - GPLv2 is present but Classpath exception is missing In-Reply-To: <2fc3326890cdeffdf2a71f4004e0d159e0bd361b.camel@redhat.com> References: <772e0556-28b7-aa9e-0f28-aa76330d576d@oracle.com> <2fc3326890cdeffdf2a71f4004e0d159e0bd361b.camel@redhat.com> Message-ID: On 28/07/2020 11:44 pm, Severin Gehwolf wrote: > On Tue, 2020-07-28 at 23:40 +1000, David Holmes wrote: >> Hi, >> >> On 28/07/2020 10:07 pm, Archana Nogriya wrote: >>> Hi, >>> >>> Please can someone help to fix these copyright issues in JDK15. >>> We found these issues in our internal scan. >> >> Why should these files require the classpath exception? They are not >> classes you would link against. > [...] > >>> src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java: >>> GPLv2 is present but Classpath exception is missing > > ---^ > > This one probably is? Yes I'll give you that one :) David > Thanks, > Severin > From joe.darcy at oracle.com Tue Jul 28 20:02:30 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 28 Jul 2020 13:02:30 -0700 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: Hello, On 7/24/2020 6:47 AM, Severin Gehwolf wrote: > On Fri, 2020-07-24 at 23:37 +1000, David Holmes wrote: >> On 24/07/2020 11:15 pm, Severin Gehwolf wrote: >>> Hi, >>> >>> Any particular reason this bug is not public? >> It contains information in the description that requires it not be >> public - sorry. But it basically says (as seen in the patch) that the >> resource array may be too small. > OK, thanks, David. > > Does anybody know whether this issue of closed bugs being used to push > changes will be rectified once moved to git and skara via JEPs 357/369? > > It would be nice if that could be caught in future. I.e. if a bug > exists that contains internal/confidential info, another bug needs to > be created, possibly referencing the other. In a setup which I've in > mind only public bug could be used to push changes. Hopefully we'll get > there :) It remains on our list (including my own list) to evaluate some Jira plugins which would allow most of the incidentally non-public bugs to be made public. Note that there are classes are bugs that are eventually pushed publicly, including security vulnerabilities, that would not be made public even with the augmented tooling. HTH,h -Joe From sgehwolf at redhat.com Wed Jul 29 06:52:43 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Jul 2020 08:52:43 +0200 Subject: Fwd: [Mach5] mach5-one-sgehwolf-JDK-8250627-02-20200728-1527-12982568: FAILED References: <835387787.2739.1595972675608@ol7-services-21319.s2.javaplatfo1iad.oraclevcn.com> Message-ID: Hi, Could somebody from Oracle have a look at this and tell me whether this is an actual problem? A slightly modified patch passed on Monday: mach5-one-sgehwolf-JDK-8250627-01-20200727-1737-12966679: PASSED Thanks, Severin From tobias.hartmann at oracle.com Wed Jul 29 07:48:53 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Jul 2020 09:48:53 +0200 Subject: Fwd: [Mach5] mach5-one-sgehwolf-JDK-8250627-02-20200728-1527-12982568: FAILED In-Reply-To: References: <835387787.2739.1595972675608@ol7-services-21319.s2.javaplatfo1iad.oraclevcn.com> Message-ID: <474e229c-51b5-391c-74f1-a2b61bc2921d@oracle.com> Hi Severin, looks like something went wrong on Windows (build task failed after 6 hours) but I don't think it's related to your fix. Nevertheless, I would suggest re-submitting to make sure testing on Windows is executed. Best regards, Tobias On 29.07.20 08:52, Severin Gehwolf wrote: > Hi, > > Could somebody from Oracle have a look at this and tell me whether this > is an actual problem? > > A slightly modified patch passed on Monday: > mach5-one-sgehwolf-JDK-8250627-01-20200727-1737-12966679: PASSED > > Thanks, > Severin > From sgehwolf at redhat.com Wed Jul 29 08:21:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Jul 2020 10:21:10 +0200 Subject: https://bugs.openjdk.java.net/browse/JDK-8248524 public? In-Reply-To: References: <527bb1f7-dd7a-42a3-8e5f-f75675b2bad3@oracle.com> <80be7d625b556a1688b73f7f61ca5e931b719eaa.camel@redhat.com> Message-ID: Hi Joe, On Tue, 2020-07-28 at 13:02 -0700, Joe Darcy wrote: > Hello, > > On 7/24/2020 6:47 AM, Severin Gehwolf wrote: > > On Fri, 2020-07-24 at 23:37 +1000, David Holmes wrote: > > > On 24/07/2020 11:15 pm, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Any particular reason this bug is not public? > > > It contains information in the description that requires it not be > > > public - sorry. But it basically says (as seen in the patch) that the > > > resource array may be too small. > > OK, thanks, David. > > > > Does anybody know whether this issue of closed bugs being used to push > > changes will be rectified once moved to git and skara via JEPs 357/369? > > > > It would be nice if that could be caught in future. I.e. if a bug > > exists that contains internal/confidential info, another bug needs to > > be created, possibly referencing the other. In a setup which I've in > > mind only public bug could be used to push changes. Hopefully we'll get > > there :) > > It remains on our list (including my own list) to evaluate some Jira > plugins which would allow most of the incidentally non-public bugs to be > made public. That's great to hear! Thanks for this. > Note that there are classes are bugs that are eventually pushed > publicly, including security vulnerabilities, that would not be made > public even with the augmented tooling. Understood, thanks. Hopefully we can get to a point where *only* security vulnerability bugs would be private. Cheers, Severin From archana.nogriya at uk.ibm.com Wed Jul 29 09:25:53 2020 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Wed, 29 Jul 2020 10:25:53 +0100 Subject: Copyright Issues : JDK15 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: <772e0556-28b7-aa9e-0f28-aa76330d576d@oracle.com> <2fc3326890cdeffdf2a71f4004e0d159e0bd361b.camel@redhat.com> Message-ID: Thank David for confirming. Yes agree with you they are either hotspot or build tool related. and I will wait for the fix for src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java, as you mentioned :) Thanks again. Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com From: David Holmes To: Severin Gehwolf , Archana Nogriya , jdk-dev at openjdk.java.net Cc: Andrew Leonard , Simon Rushton Date: 28/07/2020 14:51 Subject: [EXTERNAL] Re: Copyright Issues : JDK15 - GPLv2 is present but Classpath exception is missing On 28/07/2020 11:44 pm, Severin Gehwolf wrote: > On Tue, 2020-07-28 at 23:40 +1000, David Holmes wrote: >> Hi, >> >> On 28/07/2020 10:07 pm, Archana Nogriya wrote: >>> Hi, >>> >>> Please can someone help to fix these copyright issues in JDK15. >>> We found these issues in our internal scan. >> >> Why should these files require the classpath exception? They are not >> classes you would link against. > [...] > >>> src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java: >>> GPLv2 is present but Classpath exception is missing > > ---^ > > This one probably is? Yes I'll give you that one :) David > Thanks, > Severin > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Wed Jul 29 14:02:56 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Jul 2020 16:02:56 +0200 Subject: Fwd: [Mach5] mach5-one-sgehwolf-JDK-8250627-02-20200728-1527-12982568: FAILED In-Reply-To: <474e229c-51b5-391c-74f1-a2b61bc2921d@oracle.com> References: <835387787.2739.1595972675608@ol7-services-21319.s2.javaplatfo1iad.oraclevcn.com> <474e229c-51b5-391c-74f1-a2b61bc2921d@oracle.com> Message-ID: Hi, On Wed, 2020-07-29 at 09:48 +0200, Tobias Hartmann wrote: > Hi Severin, > > looks like something went wrong on Windows (build task failed after 6 hours) but I don't think it's > related to your fix. Nevertheless, I would suggest re-submitting to make sure testing on Windows is > executed. Thanks, Tobias. I've resubmitted and it passed. Looks like a false alarm. Cheers, Severin > Best regards, > Tobias > > On 29.07.20 08:52, Severin Gehwolf wrote: > > Hi, > > > > Could somebody from Oracle have a look at this and tell me whether this > > is an actual problem? > > > > A slightly modified patch passed on Monday: > > mach5-one-sgehwolf-JDK-8250627-01-20200727-1737-12966679: PASSED > > > > Thanks, > > Severin > > From erik.joelsson at oracle.com Wed Jul 29 15:03:43 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Jul 2020 08:03:43 -0700 Subject: Fwd: [Mach5] mach5-one-sgehwolf-JDK-8250627-02-20200728-1527-12982568: FAILED In-Reply-To: References: <835387787.2739.1595972675608@ol7-services-21319.s2.javaplatfo1iad.oraclevcn.com> <474e229c-51b5-391c-74f1-a2b61bc2921d@oracle.com> Message-ID: <17658c8e-463b-e9f5-a303-bf1609501b19@oracle.com> On 2020-07-29 07:02, Severin Gehwolf wrote: > Hi, > > On Wed, 2020-07-29 at 09:48 +0200, Tobias Hartmann wrote: >> Hi Severin, >> >> looks like something went wrong on Windows (build task failed after 6 hours) but I don't think it's >> related to your fix. Nevertheless, I would suggest re-submitting to make sure testing on Windows is >> executed. > Thanks, Tobias. I've resubmitted and it passed. Looks like a false > alarm. It was a false alarm. The windows build got stuck due to an internal unplanned outage and couldn't be saved unfortunately. A fix for handling this particular problem has been deployed. /Erik > Cheers, > Severin > >> Best regards, >> Tobias >> >> On 29.07.20 08:52, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody from Oracle have a look at this and tell me whether this >>> is an actual problem? >>> >>> A slightly modified patch passed on Monday: >>> mach5-one-sgehwolf-JDK-8250627-01-20200727-1737-12966679: PASSED >>> >>> Thanks, >>> Severin >>>