Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]

[Iris Clark]

On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy  wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains 44 additional commits since 
> the last revision:
> 
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - ... and 34 more: 
> https://git.openjdk.java.net/jdk/compare/705cfa36...1b29a17c

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8236

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]

[Iris Clark]

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy  wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains 40 additional commits since 
> the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: 
> https://git.openjdk.java.net/jdk/compare/5a6d202d...e495a579

Changes still look good.

-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]

[Iris Clark]

On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy  wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains 36 additional commits since 
> the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbol information for JDK 19 b23.
>  - ... and 26 more: 
> https://git.openjdk.java.net/jdk/compare/d01d01b5...eedd36bd

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8236

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]

[Iris Clark]

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy  wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8236

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]

[Iris Clark]

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy  wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8236

Re: RFR: 8287155: Additional make typos

[Iris Clark]

On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie  wrote:

> Testing ispell + shell magic to locate typos. It worked, but is not scalable 
> to the entire JDK. :-( Keep the fixes for the problems found in the make 
> directory, though.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8837

Re: RFR: 8284209: Replace remaining usages of 'a the' in source code

[Iris Clark]

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> It's the last issue in the series, and it still touches different areas of 
> the code.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8771

Re: RFR: 8265315: Support for CLDR version 41 [v2]

[Iris Clark]

On Fri, 8 Apr 2022 20:17:52 GMT, Naoto Sato  wrote:

>> This is to upgrade the CLDR data from version 39 to version 41 which was 
>> released yesterday. The vast majority of the changes are basically replacing 
>> the CLDR data, along with tools/testcase alignments. Here is the link to 
>> CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41
>
> Naoto Sato has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into cldr+
>  - Merge branch 'master' into cldr+
>  - CLDR v41 final
>  - CLDR v41 beta2
>  - Merge branch 'master' into cldr+
>  - CLDR v41 alpha4
>  - Merge branch 'master' into cldr+
>  - Update copyright year to 2022
>  - CLDR release v40
>  - Merge branch 'master' into cldr
>  - ... and 12 more: 
> https://git.openjdk.java.net/jdk/compare/a8c87526...9ef22a6d

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8150

Re: RFR: 8265315: Support for CLDR version 41

[Iris Clark]

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato  wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was 
> released yesterday. The vast majority of the changes are basically replacing 
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR 
> v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8150

Re: RFR: 8277517: Bump minimum boot jdk to JDK 18

[Iris Clark]

On Tue, 5 Apr 2022 03:19:06 GMT, Mikael Vidstedt  wrote:

> With the JDK 18 GA out it's time to bump the minimum boot JDK version for 
> mainline/JDK 19.
> 
> Testing: tier1-5, GHA builds

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8102

Re: RFR: 8283277: ISO 4217 Amendment 171 Update

[Iris Clark]

On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato  wrote:

> This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE 
> redenomination (removing 3 zeros). Its effective date is 4/1, but I went 
> ahead as JDK19 won't be released by 4/1.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7857

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

[Iris Clark]

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan  wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice tidy of the code.

Is there anything that can be done to prevent re-introduction of this trivial 
problem?  Perhaps a new Skara bot jcheck option similar to what is already in 
place for trailing whitespace?

-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

Re: [jdk18] RFR: 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022

[Iris Clark]

On Thu, 10 Feb 2022 18:46:13 GMT, Pavel Kharskii  wrote:

> …C promotion B35 on February 10, 2022
> 
> Remove EA from JDK 18 version string starting with Initial RC promotion B35 
> on February 10, 2022

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk18/pull/115

Re: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18 build 32

[Iris Clark]

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy  wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for 
> JDK-8270416: "Enhance construction of Identity maps" 
> (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6),
>  I didn't see why the symbol update was triggered.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7165

Re: RFR: 8280032: Update jib-profiles.js to use JMH 1.34 devkit

[Iris Clark]

On Fri, 14 Jan 2022 17:05:45 GMT, Claes Redestad  wrote:

> Change so that jib users pick up and use the latest JMH devkit.
> 
> Testing: verified locally

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7090

Re: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0

[Iris Clark]

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato  wrote:

> Please review the changes for upgrading the Unicode support in the JDK, from 
> version 13 to version 14. Corresponding CSR has also been drafted.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6974

Re: RFR: JDK-8277515: Update --release 18 symbol information for JDK 18 build 29

[Iris Clark]

On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy  wrote:

> Usual update to the JDK 19 symbol files for changes in JDK 18; this time 
> JDK-8276660 in JDK 18 build 28.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6948

Re: RFR: 8279223: Define version in .jcheck/conf

[Iris Clark]

On Thu, 23 Dec 2021 14:16:37 GMT, Erik Joelsson  wrote:

> This patch adds the version field to .jcheck/conf. By doing this we can 
> remove the corresponding configuration from the Skara bots, which in turn 
> reduces the need for timing and general complexity of starting a new JDK 
> release.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6929

Re: RFR: 8278275: Initial nroff manpage generation for JDK 19

[Iris Clark]

On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes  wrote:

> Trivial update to change the version to 19-ea, and update the single 
> reference to the "current release".
> 
> Content changes for 19 will follow.
> 
> Thanks,
> David

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6811

Re: RFR: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks

[Iris Clark]

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy  wrote:

> Exploratory builds indicate it is not currently necessary to exclude the 
> doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6713

Re: RFR: JDK-8278179: Enable all doclint warnings for build of java.naming

[Iris Clark]

On Fri, 3 Dec 2021 03:28:46 GMT, Joe Darcy  wrote:

> An exploratory build indicates that it is not necessary to disable the 
> accessibility doclint check for the java.naming module.



-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6688

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v5]

[Iris Clark]

On Mon, 29 Nov 2021 18:38:35 GMT, Joe Darcy  wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of 
>> start-of-release updates, including CSRs for the javac and javax.lang.model 
>> updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update symbol information for JDK 18 b25.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6493

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

[Iris Clark]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy  wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of 
>> start-of-release updates, including CSRs for the javac and javax.lang.model 
>> updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6493

Re: RFR: 8275766: (tz) Update Timezone Data to 2021e

[Iris Clark]

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato  wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the 
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6144

Re: RFR: 8274407: (tz) Update Timezone Data to 2021c

[Iris Clark]

On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato  wrote:

> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c 
> level. Note that the tz data is "as is", as released by IANA. No `merged 
> links` are retracted.
> The PR also fixes two issues along with the 2021c upgrade.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5832

Re: RFR: 8274658: ISO 4217 Amendment 170 Update

[Iris Clark]

On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato  wrote:

> This is to incorporate the ISO 4217 amendment #170, which has been released 
> today, effective immediately.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5790

Re: RFR: JDK-8274311: Make build.tools.jigsaw.GenGraphs more configurable

[Iris Clark]

On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung  wrote:

> GenGraphs tool generates the module graph. It currently supports the 
> configuration via javadoc-graphs.properties. However, 
> `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only 
> documents two properties. It should be updated to cover all configurable 
> properties.
> 
> There are a couple other properties not configurable such as nodesep and node 
> margin. This extends the configuration to allow to set additional properties. 
> 
> This also fixes `requiresMandatedColor` in javadoc-graphs.properties to light 
> gray to match the default configuration in the implementation, i.e. the color 
> of the edge to java.base.  It seems a bug that was unnoticed until Alex and 
> Iris spotted it.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5690

Re: RFR: 8267636: Bump minimum boot jdk to JDK 17

[Iris Clark]

On Wed, 22 Sep 2021 20:03:55 GMT, Mikael Vidstedt  wrote:

> With the JDK 17 GA out it's time to bump the minimum boot JDK version for 
> mainline/JDK 18.
> 
> Testing: tier1-5, GHA builds

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5639

Re: RFR: 8272859: Javadoc external links should only have feature version number in URL

[Iris Clark]

On Wed, 25 Aug 2021 13:57:29 GMT, Magnus Ihse Bursie  wrote:

> Link to license terms from the JavaDoc API footer is broken in point releases 
> (for example, 16.0.2). 
> 
> Instead of using VERSION_NUMBER, VERSION_FEATURE should be used,

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5253

Re: RFR: JDK-8272667: substandard error messages from the docs build

[Iris Clark]

On Wed, 18 Aug 2021 22:06:13 GMT, Jonathan Gibbons  wrote:

> Please review a small (delete one character) change to improve the error 
> messages reported when bad HTML is detected when post-processing the output 
> from pandoc to generate the docs.
> 
> The change is just to pass the filename as an argument to the command, 
> instead of just piping the input to stdin. As a result, the name of any file 
> containing bad input is reported in the message, instead of the message 
> simply referring to ``

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5175

Re: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly.

[Iris Clark]

On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato  wrote:

> Please review the fix to the subject issue. The root cause of this problem is 
> that the currency for the country code `XK` is undefined because the country 
> code is user-defined in the ISO 3166 standard. However, it is commonly used 
> to represent the region `Kosovo`, which CLDR supports and subsequently is 
> supported by the JDK since JDK9. Adding the data `EUR` for the country code 
> `XK` will fix the issue.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5033

Re: [jdk17] RFR: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)

[Iris Clark]

On Fri, 30 Jul 2021 06:47:07 GMT, Saravana Kumar Vijayasekaran 
 wrote:

> 8271150: Remove EA from JDK 17 version string starting with Initial RC 
> promotion on Aug 5, 2021(B34)

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/297

Re: RFR: 8268637: Update --release 17 symbol information for JDK 17 build 28

[Iris Clark]

On Wed, 30 Jun 2021 16:54:57 GMT, Joe Darcy  wrote:

> JDK 17 b28 had two fixes which updated the symbol information. A 
> CallerSensitive annotation was removed as part of JDK-8268349 and API changes 
> in JDK-826.
> 
> These should be reflected in the JDK 18 symbol information for 17.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4641

Re: RFR: 8267634: Update --release 17 symbol information for JDK 17 build 26

[Iris Clark]

On Fri, 11 Jun 2021 22:44:03 GMT, Joe Darcy  wrote:

> Update symbol files in JDK 18 for changes in JDK 17 b26.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4477

Re: RFR: 8267630: Start of release updates for JDK 18 [v11]

[Iris Clark]

On Thu, 10 Jun 2021 14:42:24 GMT, Joe Darcy  wrote:

>> 8267630: Start of release updates for JDK 18
>
> Joe Darcy has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into 8267630
>  - Update copyright year.
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - ... and 15 more: 
> https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4175

Re: RFR: 8267630: Start of release updates for JDK 18 [v5]

[Iris Clark]

On Mon, 7 Jun 2021 19:38:58 GMT, Joe Darcy  wrote:

>> 8267630: Start of release updates for JDK 18
>
> Joe Darcy has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains 17 additional commits since 
> the last revision:
> 
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Update symbols for JDK 17 b25.
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - Merge branch 'master' into 8267630
>  - ... and 7 more: 
> https://git.openjdk.java.net/jdk/compare/41bce524...34480e50

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4175

Re: RFR: 8268299: jvms tag produces incorrect URL

[Iris Clark]

On Sun, 6 Jun 2021 22:03:46 GMT, Joe Darcy  wrote:

> The @jls and @jvms taglet share most of their functionality.  A  JLS URL 
> looks like
> 
> https://docs.oracle.com/javase/specs/jls/se16/html/**jls**-8.html#jls-8.1
> 
> and a JVMS URL looks like
> 
> 
> https://docs.oracle.com/javase/specs/jvms/se16/html/**jvms**-4.html#jvms-4.3.2
> 
> The current taglet incorrectly uses "jls" in from the chapter for both JLS 
> and JVMS URLs. The patch corrects this to use "jvms" for JVMS URLs.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4381

Re: RFR: 8267630: Start of release updates for JDK 18

[Iris Clark]

On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy  wrote:

> 8267630: Start of release updates for JDK 18

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4175

Re: RFR: JDK-8266254: Update to use jtreg 6

[Iris Clark]

On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons  wrote:

> Please review the change to update to using jtreg 6. 
> 
> The primary change is to the jib-profiles.js file, which specifies the 
> version of jtreg to use, for those systems that rely on this file. In 
> addition, the `requiredVersion` has been updated in the various `TEST.ROOT` 
> files.
> 
> All the tests that could be updated ahead of time have been updated. There 
> are a few tests remaining that need to be done at this time, because of the 
> change in the module name for TestNG 7.3. It changed from a default of 
> `testng` to and explicit `org.testng`.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4315

Re: RFR: 8266318: Switch to macos prefix for macOS bundles [v2]

[Iris Clark]

On Fri, 30 Apr 2021 03:51:18 GMT, Mikael Vidstedt  wrote:

>> Apple rebranded the operating system as "macOS" back in 2016. The JDK 
>> bundles files are still use the legacy "osx" string. They should be 
>> modernized to use "macos" instead.
>
> Mikael Vidstedt has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix GHA

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3801

Re: RFR: 8266318: Switch to macos prefix for macOS bundles

[Iris Clark]

On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt  wrote:

> Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles 
> files are still use the legacy "osx" string. They should be modernized to use 
> "macos" instead.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3801

Re: RFR: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter

[Iris Clark]

On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad  wrote:

> I'm not exactly sure what I intended to say in this partial comment. Removing 
> it.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3766

Re: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle

[Iris Clark]

On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt  wrote:

> The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 
> from early December, so does not include all the JDK 16 GA functionality. 
> This leads to build issues after JDK-8263621 which uses a method not included 
> in the custom version. Let's bump the bootjdk used for macosx-aarch64 to 
> jdk-17+19 instead.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3636

Re: RFR: JDK-8265483: All-caps “JAVA” in the top navigation bar

[Iris Clark]

On Tue, 20 Apr 2021 22:36:28 GMT, Jonathan Gibbons  wrote:

> Please review a moderately simple change to `make/Docs.gmk` to move the link 
> for "Other Versions" from a "hidden" link in the top nav bar to an explicit 
> link in the "bottom" text. The link is placed to appear after the sentence 
> beginning "For more information..." and before all the legal text (i.e. 
> trademark, copyright, license, etc)
> 
> A side effect of moving the link is that the top text reverts to its intended 
> appearance of "Java ...", without all-caps.
> 
> As before, the presence of the link is optional, and depends on the specific 
> docs target. It is set up to just appear for the main JDK/JavaSE 
> documentation, and not the other docs bundles, such as docs-reference.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3594

Re: RFR: 8257459: Bump minimum boot jdk to JDK 16

[Iris Clark]

On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt  wrote:

> With JDK 16 having gone GA about a month ago it's time to bump the minimum 
> boot JDK version for mainline/JDK 17.
> 
> Testing: tier1-5.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3555

Re: RFR: 8264779: Fix doclint warnings in java/nio [v2]

[Iris Clark]

On Wed, 7 Apr 2021 14:40:48 GMT, Conor Cleary  wrote:

>> This fix addresses the following warnings which were generated by building 
>> JDK API documentation with the `-Xdoclint:all` option enabled:
>> 
>> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47:
>>  warning: no comment
>> private String charsetName;
>>^
>> ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44:
>>  warning: no comment
>> private int inputLength;
>> ^
>> ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44:
>>  warning: no comment
>> private int inputLength;
>> ^
>> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47:
>>  warning: no comment
>> private String charsetName;
>>^
>> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81:
>>  warning: no @param for s
>> private void readObject(ObjectInputStream s)
>>  ^
>> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81:
>>  warning: no @throws for java.lang.ClassNotFoundException
>> private void readObject(ObjectInputStream s)
>>  ^
>> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43:
>>  warning: no comment
>> private final String file;
>>  ^
>> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44:
>>  warning: no comment
>> private final String other;
>>  ^
>> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43:
>>  warning: no comment
>> private int index;
>> ^
>> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42:
>>  warning: no comment
>> private String input;
>>^
>> ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43:
>>  warning: no comment
>> private final String name;
>>  ^
>> Changes to 
>> [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2)
>>  and the two 
>> [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2)
>>  templates are to address the warnings concerned with 
>> `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` 
>> which are generated when `make jdk-image` is run. A CSR will be filed in due 
>> course with respect to these changes.
>
> Conor Cleary has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8264779: Simplified comments

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3376

Re: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module

[Iris Clark]

On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore  wrote:

> Disable the "missing" target for java.smartcardio from doclint.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2930

Re: RFR: JDK-8251210: Link JDK api docs to other versions

[Iris Clark]

On Sat, 6 Mar 2021 02:21:00 GMT, Jonathan Gibbons  wrote:

> Please review a small change to Docs.gmk, such that the short version string 
> in the upper right corner of the main API docs bundle is linked to a page 
> that links to other versions of the documentation.  While it is not so useful 
> in this release, to be able to access _older_ versions, going forward, this 
> will simplify the ability to get to _newer_ versions when search engines take 
> you to the docs for an older release.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2854

Re: RFR: JDK-8260669: Missing quotes in fixpath.sh

[Iris Clark]

On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson  wrote:

> The build on Windows can fail if certain directory names are present in root 
> directory of the workspace. In particular I've observed that the single 
> letter 'p' is triggering this problem. This is caused by missing quotes 
> around [:upper:] in a 'tr' call in fixpath.sh.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2318

Re: [jdk16] RFR: JDK-8259429: Update reference to README.md

[Iris Clark]

On Thu, 7 Jan 2021 22:01:51 GMT, Erik Joelsson  wrote:

> In JDK-8251551, the top level README file changed names to README.md. In 
> jib-profiles.js we have a reference to this file to identify if the current 
> source tree is likely to be complete. This reference needs to be updated.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk16/pull/94

Re: [jdk16] RFR: JDK-8258657: Doc build is broken by use of new language features

[Iris Clark]

On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson  wrote:

> This patch changes how the docs-reference make target behaves to better 
> support the requirements for it. This target is used to generate javadocs in 
> a more stable way between releases, so that they those docs are better suited 
> for generating diffs between releases. Currently we use the boot JDK to run 
> javadoc for these, but this has shown to be problematic. This patch 
> introduced a specific configure parameter for the JDK to use just for 
> generating these docs. If not set, it will revert to the default interim 
> javadoc, just like the main docs are built (but still with a separate set of 
> parameters).
> 
> This fix needs to go into JDK 16 so that the docs-reference target there can 
> be used to generate diffs for JDK 17.

Do you need to update the copyright year?  Other than that, your changes appear 
to implement the described behaviour.

Thanks!
Iris

-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/88

Re: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later

[Iris Clark]

On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy  wrote:

> Updating to the symbol files for JDK 16 b30; change generated with the script 
> 
> make/scripts/generate-symbol-data.sh
> 
> The change to the java.desktop module looks to be for JDK-8258373.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1954

Re: RFR: 8257450: Start of release updates for JDK 17

[Iris Clark]

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy  wrote:

> Start of JDK 17 updates.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1531

RE: 15 RFR (XXS) 8250216: The README need not mention retrieving source code

[Iris Clark]

Hi, Mark.

>> I think it would be nice if you could reference the JDK Project page 
>> (ojn/projects/jdk), not just ojn.
>
> Good idea ... but I just pushed the changeset.  I’ll fix that later.

Sorry for the late review.  You change wasn't there when I visited the README 
source and I haven't received the push notification yet.

Iris

RE: 15 RFR (XXS) 8250216: The README need not mention retrieving source code

[Iris Clark]

Hi, Mark.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
> 
> [ ... ]
> 
> Patch below.

Looks good.

I think it would be nice if you could reference the JDK Project page 
(ojn/projects/jdk), not just ojn.

Thanks,
Iris

RE: [16] RFR (XS) 8246803: Update link to license in Docs.gmk

[Iris Clark]

Hi, Joe.

> Updating the link for JDK 16 looks fine; thanks,

Thanks for the amazingly fast review!

Iris

RE: [16] RFR (XS) 8246803: Update link to license in Docs.gmk

[Iris Clark]

Hi, Mikael.

Thanks for the review!

iris

-Original Message-
From: Mikael Vidstedt 
Sent: Monday, June 8, 2020 10:35 PM
To: Iris Clark 
Cc: build-dev@openjdk.java.net; Jesper Wilhelmsson 

Subject: Re: [16] RFR (XS) 8246803: Update link to license in Docs.gmk


Looks good.

Cheers,
Mikael

> On Jun 8, 2020, at 10:31 PM, Iris Clark  wrote:
> 
> Hi.
> 
> Please review this small change to update the link to the 
> Specification license referenced by the JavaDoc API for JDK 16:
> 
> bug:
> 
>8246803: Update link to spec license in Docs.gmk
>https://bugs.openjdk.java.net/browse/JDK-8246803
> 
> webrev:
> 
>https://cr.openjdk.java.net/~iris/8246803/webrev/
> 
> Due to changes in the server hosting the Spec license redirect, we 
> must use a new URL in JDK 16 which omits the "technetwork" token.  The 
> following link for 16 is now live:
> 
>
> https://www.oracle.com/java/javase/terms/license/java16speclicense.htm
> l
> 
> It should correspond to the new link generated at JDK 16 build time  
> The link for JDK 15 is unchanged.
> 
> Thanks,
> Iris

[16] RFR (XS) 8246803: Update link to license in Docs.gmk

[Iris Clark]

Hi.

Please review this small change to update the link to the Specification license 
referenced
by the JavaDoc API for JDK 16:

bug:

8246803: Update link to spec license in Docs.gmk
https://bugs.openjdk.java.net/browse/JDK-8246803

webrev:

https://cr.openjdk.java.net/~iris/8246803/webrev/

Due to changes in the server hosting the Spec license redirect, we must use a 
new URL
in JDK 16 which omits the "technetwork" token.  The following link for 16 is 
now live:

https://www.oracle.com/java/javase/terms/license/java16speclicense.html

It should correspond to the new link generated at JDK 16 build time  The link 
for
JDK 15 is unchanged.

Thanks,
Iris

RE: RFR: S, 13 JDK-8226628 The copyright footer should be enclosed in

[Iris Clark]

Hi, Jon.

> JBS: https://bugs.openjdk.java.net/browse/JDK-8226628

Looks good.  Thanks for taking care of this.

Iris

RE: RFR: JDK-8223319: Add copyright footer to specs and man pages

[Iris Clark]

Hi, Erik.

> New webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.02/

The revised webrev looks good.

Thank you!

Iris

RE: RFR: JDK-8223319: Add copyright footer to specs and man pages

[Iris Clark]

Hi, Erik.

I'm happy to see this change go in.  It looks good.

Just one comment.  When removing the footer in jvmit.html, I suspect that you 
also need to make changes to jvmti.xsl, which was also modified when the 
copyright footer was inserted in this changeset:

http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed

Thanks,
iris

-Original Message-
From: Erik Joelsson 
Sent: Friday, May 3, 2019 9:38 AM
To: build-dev ; OpenJDK Serviceability 

Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages

The (optional) specs and man pages should have the same copyright footer as the 
generated API docs. This patch adds the logic to add such footers. It also 
removes the existing footer in jvmti.html.

Bug: https://bugs.openjdk.java.net/browse/JDK-8223319

Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html

/Erik

RE: RFR(XS): 8212994: Links to Oracle websites should use "https:"

[Iris Clark]

Hi, Lance and Erik.

 

Thanks for the super-speedy reviews.  Pushed.

 

iris

 

From: Lance Andersen 
Sent: Thursday, October 25, 2018 1:48 PM
To: Iris Clark 
Cc: build-dev@openjdk.java.net; Jonathan Gibbons 
Subject: Re: RFR(XS): 8212994: Links to Oracle websites should use "https:"

 

+1

On Oct 25, 2018, at 4:33 PM, Iris Clark mailto:iris.cl...@oracle.com"iris.cl...@oracle.com> wrote:

 

Hi.

Please review changes to use "https" instead of "http" for links in the
generated JavaDoc API pages:

8212994:  Links to Oracle websites should use "https:"
bug:  https://bugs.openjdk.java.net/browse/JDK-8212994
webrev:  https://cr.openjdk.java.net/~iris/8212994/webrev/

I did a full "make docs" build and verified that the old links are
no longer in the created image.

Thanks,
iris

$ pwd
/u/iris/se/full-jdk/build/images

$ find . -name "*.html" -print | xargs grep 
"http://www.oracle.com/technetwork/java/redist-137594.html; | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://www.oracle.com/technetwork/java/redist-137594.html; | wc -l
20312

## link in banner and footer
$ find . -name "*.html" -print | xargs grep 
"http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html;
 | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html;
 | wc -l
40624

$ find . -name "*.html" -print | xargs grep 
"http://bugreport.java.com/bugreport/; | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://bugreport.java.com/bugreport/; | wc -l
20312

$ find . -name "*.html" -print | xargs grep 
"http://www.oracle.com/pls/topic/lookup?ctx=javase12\\;id=homepage; | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://www.oracle.com/pls/topic/lookup?ctx=javase12\\;id=homepage; | wc -l
20312

 

http://oracle.com/us/design/oracle-email-sig-198324.gif

HYPERLINK "http://oracle.com/us/design/oracle-email-sig-198324.gif;
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
HYPERLINK "mailto:lance.ander...@oracle.com"lance.ander...@oracle.com

 





 

RFR(XS): 8212994: Links to Oracle websites should use "https:"

[Iris Clark]

Hi.

Please review changes to use "https" instead of "http" for links in the
generated JavaDoc API pages:

 8212994:  Links to Oracle websites should use "https:"
 bug:  https://bugs.openjdk.java.net/browse/JDK-8212994
 webrev:  https://cr.openjdk.java.net/~iris/8212994/webrev/

I did a full "make docs" build and verified that the old links are
no longer in the created image.

Thanks,
iris

$ pwd
/u/iris/se/full-jdk/build/images

$ find . -name "*.html" -print | xargs grep 
"http://www.oracle.com/technetwork/java/redist-137594.html; | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://www.oracle.com/technetwork/java/redist-137594.html; | wc -l
20312

## link in banner and footer
$ find . -name "*.html" -print | xargs grep 
"http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html;
 | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html;
 | wc -l
40624

$ find . -name "*.html" -print | xargs grep 
"http://bugreport.java.com/bugreport/; | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://bugreport.java.com/bugreport/; | wc -l
20312

$ find . -name "*.html" -print | xargs grep 
"http://www.oracle.com/pls/topic/lookup?ctx=javase12\\;id=homepage; | wc -l
0
$ find . -name "*.html" -print | xargs grep 
"https://www.oracle.com/pls/topic/lookup?ctx=javase12\\;id=homepage; | wc -l
20312

RE: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11

[Iris Clark]

Looks good to me.

iris

-Original Message-
From: Jonathan Gibbons 
Sent: Tuesday, August 21, 2018 11:58 AM
To: build-dev@openjdk.java.net
Subject: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to 
javase11

Please review a simple high priority fix for JDK 11 that updates the link in 
the bottom of each page of the generated API docs.

Instead of simply changing "10" to "11", the fix is to use the macro
$(VERSION_NUMBER) instead, in line with other URLs nearby in the same makefile, 
and in the ExtLink taglet [1]

JBS: https://bugs.openjdk.java.net/browse/JDK-8209806
Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html

[1]: 
http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66

-- Jon

RE: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Iris Clark]

Hi.

I believe that the internal page Christian references is for the test system.

If you want to know whether the push arrived in the repository, you could 
subscribe to jdk-submit-chan...@openjdk.java.net.  The archive of recent push 
notifications is public:


http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-April/thread.html

I wonder if the test system could be enhanced to send a brief notification when 
a job is queued?

Thanks,
Iris

-Original Message-
From: Christian Tornqvist 
Sent: Thursday, April 12, 2018 6:12 AM
To: Baesken, Matthias 
Cc: core-libs-...@openjdk.java.net; Alexey Ivanov ; 
Doerr, Martin ; build-dev 
Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function 
declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some 
places in function declarations/implementations



> On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias  
> wrote:
> 
>> Your submit job ran without failures, we were doing maintenance on 
>> the jdk- submit repo yesterday and had turned off notifications. 
>> Sorry for the inconvenience.
> 
> Hi Christian , Thanks for  the information about the submit job success.
> 
> Is there a way  to check (e.g. webpage)  that a submit job has "arrived"  and 
> is queued for   build/test  ?

Unfortunately that webpage is only available internally at this point, we could 
look into sending an email notification that the job has been started if that 
would help?

Thanks,
Christian

> Would have been helpful  in this situation .
> 
> Best regards, Matthias
> 
> 
>> -Original Message-
>> From: Christian Tornqvist [mailto:christian.tornqv...@oracle.com]
>> Sent: Donnerstag, 12. April 2018 14:58
>> To: Baesken, Matthias 
>> Cc: Alexey Ivanov ; Magnus Ihse Bursie 
>> ; build-dev > d...@openjdk.java.net>; Doerr, Martin 
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in 
>> function declarations/implementations - was : RE: missing JNIEXPORT / 
>> JNICALL at some places in function declarations/implementations
>> 
>> Hi Matthias,
>> 
>> 
>>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias
>>  wrote:
>>> 
>>> Hi,  could  someone please  sponsor  the change  now ?
>>> 
>>> And  could someone please check  what happened  to the submit-repo ?
>>> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no
>> response   so far .
>>> Maybe  the submit repo  is not working currently  ,  not sure  about it .
>> 
>> Your submit job ran without failures, we were doing maintenance on 
>> the jdk- submit repo yesterday and had turned off notifications. 
>> Sorry for the inconvenience.
>> 
>> Thanks,
>> Christian
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
>>> 
>>> 
 -Original Message-
 From: Baesken, Matthias
 Sent: Mittwoch, 11. April 2018 11:20
 To: 'Alexey Ivanov' ; Magnus Ihse Bursie 
 
 Cc: build-dev ; Doerr, Martin 
 
 Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
 declarations/implementations - was : RE: missing JNIEXPORT / 
 JNICALL at some places in function declarations/implementations
 
> 
> Was main() exported via map files?
> 
 
 Seems main was exported , I can find it in jdk10  in  e.g.  :
 
 make/mapfiles/launchers/mapfile-sparcv9
 make/mapfiles/launchers/mapfile-x86_64
 
 
 Best regards, Matthias
 
 
> -Original Message-
> From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
> Sent: Mittwoch, 11. April 2018 11:11
> To: Baesken, Matthias ; Magnus Ihse
>> Bursie
> 
> Cc: build-dev ; Doerr, Martin 
> 
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
 function
> declarations/implementations - was : RE: missing JNIEXPORT / 
> JNICALL at some places in function declarations/implementations
> 
> 
> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>> Hi  Alexey, yes that's true .
>> 
>>> Please remove JNIEXPORT from main():
>>> src/java.base/share/native/launcher/main.c
>>> src/jdk.pack/share/native/unpack200/main.cpp
>> I would  prefer to keep it for now .
>> I notice  some  comments  in our SAPJVM code base  about needing
> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM 
> without mapfiles in the past already).
>> Maybe  that’s related to
>> 
>> 

RE: RFR(XS): 8200469: Update link to license in Docs.gmk

[Iris Clark]

Thanks, Tim!

Pushed.

iris

-Original Message-
From: Tim Bell 
Sent: Thursday, March 29, 2018 9:11 PM
To: Iris Clark <iris.cl...@oracle.com>
Cc: build-dev <build-dev@openjdk.java.net>
Subject: Re: RFR(XS): 8200469: Update link to license in Docs.gmk

Iris:

> Bug:
>
>  8200469: Update link to license in Docs.gmk
>  https://bugs.openjdk.java.net/browse/JDK-8200469
>
> webrev:
>
>  http://cr.openjdk.java.net/~iris/8200469/webrev/

Looks good.

Tim

RFR(XS): 8200469: Update link to license in Docs.gmk

[Iris Clark]

Please review this small change to update the link to the
Specification license referenced by the JavaDoc API.  To
avoid the need for future updates based on the version
number, we should use $(VERSION_NUMBER) instead of a
specific version number.

Bug:

8200469: Update link to license in Docs.gmk
https://bugs.openjdk.java.net/browse/JDK-8200469

webrev:

http://cr.openjdk.java.net/~iris/8200469/webrev/

Thanks,
Iris

RE: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[Iris Clark]

Hi, Paul.

> We should be able to automate all the following by referring to the latest 
> release variable, yes?

[ ... ]

>   Update link to license in Docs.gmk
>   https://bugs.openjdk.java.net/browse/JDK-818999
>   http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12

Yes!

iris

-Original Message-
From: Paul Sandoz 
Sent: Friday, December 15, 2017 10:41 AM
To: Iris Clark <iris.cl...@oracle.com>
Cc: Erik Joelsson <erik.joels...@oracle.com>; Joseph D. Darcy 
<joe.da...@oracle.com>; compiler-...@openjdk.java.net; build-dev 
<build-dev@openjdk.java.net>; Stuart Marks <stuart.ma...@oracle.com>; David 
Holmes <david.hol...@oracle.com>
Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 
to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Hi Iris, Erik

We should be able to automate all the following by referring to the latest 
release variable, yes?

  Nashorn build targets version 9 source
  https://bugs.openjdk.java.net/browse/JDK-8188012
  http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511

  symbolgenerator targets jdk 9 source
  https://bugs.openjdk.java.net/browse/JDK-8188013
  http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105

  Update link to license in Docs.gmk
  https://bugs.openjdk.java.net/browse/JDK-818999
  http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12

Paul.


> On 15 Dec 2017, at 08:43, Iris Clark <iris.cl...@oracle.com> wrote:
> 
> Hi.
> 
> Another build target we need to update is LICENSE_URL in make/Docs.gmk.  
> Here's the equivalent bug for 10:
> 
>https://bugs.openjdk.java.net/browse/JDK-8189919
> 
> I've requested this link:
> 
>
> http://www.oracle.com/technetwork/java/javase/terms/license/java11spec
> license.html
> 
> Thanks,
> iris
> 
> -Original Message-
> From: Erik Joelsson
> Sent: Friday, December 15, 2017 4:41 AM
> To: joe darcy <joe.da...@oracle.com>; compiler-...@openjdk.java.net; 
> build-dev <build-dev@openjdk.java.net>; STUART.MARKS 
> <stuart.ma...@oracle.com>
> Cc: David Holmes <david.hol...@oracle.com>
> Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and 
> -target 11 to javac - Java Bug System & JDK-8193291: Add 
> SourceVersion.RELEASE_11
> 
> Looking at JDK-8188015, I was just reminded of JDK-8188012 and
> JDK-8188013 which indicates that we have more than one place where 10 
> needs to be bumped to 11
> 
> make/BuildNashorn.gmk
> make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDepen
> dencies.java
> 
> /Erik
> 
> On 2017-12-12 16:36, Erik Joelsson wrote:
>> Build change looks good.
>> 
>> /Erik
>> 
>> 
>> On 2017-12-12 08:04, joe darcy wrote:
>>> Hello,
>>> 
>>> With the JDK 11 line of development opening up in a few days, a few 
>>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>>> 11 one including:
>>> 
>>> JDK-8173382: Add -source 11 and -target 11 to javac
>>> JDK-8193291: Add SourceVersion.RELEASE_11
>>> 
>>> Webev:
>>> http://cr.openjdk.java.net/~darcy/8173382.1/
>>> CSRs:
>>> JDK-8193350: Add -source 11 and -target 11 to javac
>>> JDK-8193351: Add SourceVersion.RELEASE_11
>>> 
>>> Please review the preliminary webrev and CSRs.
>>> 
>>> Note that breaking with previous contentions, the current iteration 
>>> of the change does *not* add -source/-target "1.11" as an alias for 
>>> "11". Only "11" is recognized.
>>> 
>>> I didn't see how to add support for an "11" value for "--release" so 
>>> I problem listed two tests until that is sorted out.
>>> 
>>> The build is simultaneously updated to user -source/-target 11, 
>>> hence the inclusion of build-dev.
>>> 
>>> Various langtools tests and test infrastructure is updated too.
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>> 
> 

RE: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[Iris Clark]

Hi.

Another build target we need to update is LICENSE_URL in make/Docs.gmk.  Here's 
the equivalent bug for 10:

https://bugs.openjdk.java.net/browse/JDK-8189919

I've requested this link:


http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html

Thanks,
iris

-Original Message-
From: Erik Joelsson 
Sent: Friday, December 15, 2017 4:41 AM
To: joe darcy ; compiler-...@openjdk.java.net; build-dev 
; STUART.MARKS 
Cc: David Holmes 
Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 
to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Looking at JDK-8188015, I was just reminded of JDK-8188012 and
JDK-8188013 which indicates that we have more than one place where 10 needs to 
be bumped to 11

make/BuildNashorn.gmk
make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java

/Erik

On 2017-12-12 16:36, Erik Joelsson wrote:
> Build change looks good.
>
> /Erik
>
>
> On 2017-12-12 08:04, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 line of development opening up in a few days, a few 
>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>> 11 one including:
>>
>>     JDK-8173382: Add -source 11 and -target 11 to javac
>>     JDK-8193291: Add SourceVersion.RELEASE_11
>>
>>     Webev:
>>     http://cr.openjdk.java.net/~darcy/8173382.1/
>>     CSRs:
>>     JDK-8193350: Add -source 11 and -target 11 to javac
>>     JDK-8193351: Add SourceVersion.RELEASE_11
>>
>> Please review the preliminary webrev and CSRs.
>>
>> Note that breaking with previous contentions, the current iteration 
>> of the change does *not* add -source/-target "1.11" as an alias for 
>> "11". Only "11" is recognized.
>>
>> I didn't see how to add support for an "11" value for "--release" so 
>> I problem listed two tests until that is sorted out.
>>
>> The build is simultaneously updated to user -source/-target 11, hence 
>> the inclusion of build-dev.
>>
>> Various langtools tests and test infrastructure is updated too.
>>
>> Thanks,
>>
>> -Joe
>>
>

RE: RFR(XXS): 8189919: Update link to license in Docs.gmk

[Iris Clark]

Thanks for the review, Mark.

>> http://cr.openjdk.java.net/~iris/8189919/webrev/

Pushed.

iris

RFR(XXS): 8189919: Update link to license in Docs.gmk

[Iris Clark]

Please review this small change to update the link to the

Specification license referenced by the JavaDoc API.  For

JDK 10, we should reference the 10 redirect.

 

Bug:

 

8189919: Update link to license in Docs.gmk

https://bugs.openjdk.java.net/browse/JDK-8189919

 

webrev:

 

http://cr.openjdk.java.net/~iris/8189919/webrev/

 

Thanks,

Iris

 

RE: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

[Iris Clark]

Hi, Erik.

Your change looks good.

Thanks,
iris

-Original Message-
From: Erik Joelsson 
Sent: Thursday, January 26, 2017 5:57 AM
To: build-dev
Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

The default major version for the jdk 10 repos needs to be updated from 
9 to 10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8029942

Patch:

diff -r 07f6f1f4140e common/autoconf/version-numbers
--- a/common/autoconf/version-numbers
+++ b/common/autoconf/version-numbers
@@ -25,7 +25,7 @@

  # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_MAJOR=9
+DEFAULT_VERSION_MAJOR=10
  DEFAULT_VERSION_MINOR=0
  DEFAULT_VERSION_SECURITY=0
  DEFAULT_VERSION_PATCH=0


/Erik

RE: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Iris Clark]

Hi, Volker.

>> I've also filed build bug (8162687) referencing 8145919 and 8162686.

> I suppose you wanted to refer to "java.vm.specification.version" in
"8162687: ava.specification.version is always set to $MAJOR at build time" 
because "java.vm.specification.version" is actually being set in the code 
snippet you reference in the bug. Also, this is done at run-time, during 
HotSpot initialization and not at build time.
> Finally, I think this is more of a HotSpot issue and not a build issue.
> 
> So I've changed the bug accordingly. If you think I've misunderstood 
> something, please feel free to change it back.

The change needs to occur for both java.specification.version and 
java.vm.specification.version.  I suspect that the VM code will
depend on how the build change is made, as

I've modified the bug to more clearly indicate this and moved it
back to build because it's possible that the VM code may set their
value from the build implementation.  The build team may choose to
file a separate bug to handle the VM issue, but ideally they should
be handled at the same time.

thanks,
iris

RE: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Iris Clark]

Hi, Volker.

Thanks for your patience.

I think that the solution that you've provided solves the immediate problem, 
the java.specification.version number is incorrectly set to be identical to 
java.version.  The java.{vm.}?specification.version system properties should be 
independent of java.version and are determined by the JCP (either a JSR or an 
Maintenance Release).  If there's ever an MR against JSR 379 (Java SE 9 Release 
Contents) the value may need to be updated to something besides $MAJOR.

Let's go with what you've got now.  Before you commit, I recommend that you 
update the title of 8149519 to describe either the problem or the solution.  
Something like "Set java.specification.version to $MAJOR" would be appropriate.

I've filled the following two follow-on bugs:

8162686 is a Java SE 9 spec bug against myself to update the spec of 
java.{vm.}?specification.version system properties as described above.  I'll 
also modify the Verona JEP to adjust the syntax of these system properties.

I've also filed build bug (8162687) referencing 8145919 and 8162686.

Regards,
Iris

For the build team's bug, I'll reference 8145919 and the spec bug.  I suspect 
that they won't feel compelled to fix it for 9, but I leave it to them to 
determine how to best handle the issue.  I think it would be reasonable for 
them to decline to add complexity to the build without any current need for 
such a feature.

-Original Message-
From: Volker Simonis [mailto:volker.simo...@gmail.com] 
Sent: Tuesday, July 26, 2016 5:20 AM
To: build-dev
Subject: RFR(XXS): 8149519: Investigate implementation of 
java.specification.version

Forwarding to build-dev in the hope to get a review there :) More details can 
be found in the bug description.

Thank you and best regards,
Volker


-- Forwarded message --
From: Volker Simonis 
Date: Mon, Apr 4, 2016 at 6:47 PM
Subject: RFR(XXS): 8149519: Investigate implementation of 
java.specification.version
To: Java Core Libs 
Cc: verona-...@openjdk.java.net


Hi,

can I please have a review for this small fix:

http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519
https://bugs.openjdk.java.net/browse/JDK-8149519

Currently the value of the java.specification.version property comes from 
VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is currently set to 
VERSION_NUMBER which is the same value which is also used for the java.version 
property.

This is a bad idea, because VERSION_NUMBER is a dot separated sequence of 
numbers (e.g. 9.0.1) which is expected to change frequently (i.e.
for every build and/or update version). If we are configuring with 
"--with-version-patch=1" for example, VERSION_NUMBER and java.version will be 
"9.0.0.1". But it makes no sense that VERSION_SPECIFICATION and 
java.specification.version have the same, dotted value. And it breaks a lot of 
legacy applications which parse java.specification.version as a float number. 
That code would still work if java.specification.version would be a concrete 
number (e.g.
'9' or '10').

I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in 
common/autoconf/spec.gmk.in. This should be the "right value" until we get a 
specification change during a major release which hasn't happened for quite 
some time now.

Regards,
Volker

RE: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

[Iris Clark]

HI, Claes.

> Sorry, uploaded the previous diff again by mistake, updated in-place now.

I see the expected changes for unmodifiableList() now.  Your changeset is
ready to go from my point of view.

Regards,
iris

-Original Message-
From: Claes Redestad 
Sent: Monday, June 27, 2016 3:07 PM
To: Mandy Chung
Cc: Iris Clark; core-libs-dev; build-dev
Subject: Re: RFR: 816: Runtime.version() cause startup regressions in 9+119

Sorry, uploaded the previous diff again by mistake, updated in-place now.

On 2016-06-28 00:04, Mandy Chung wrote:
>
>> On Jun 27, 2016, at 2:43 PM, Claes Redestad <claes.redes...@oracle.com> 
>> wrote:
>>
>> To accommodate your change request w.r.t. unmodifiableList above I took the 
>> liberty of cleaning up VersionBuilder.parse() a bit, though. Hope you don't 
>> mind:
>>
>> http://cr.openjdk.java.net/~redestad/816/webrev.6/
>
> Moving Collections.unmodifiableList to the Version constructor is a good 
> idea. But I don’t see that change in the webrev.6 though - is that updated?
>
>   940 List versionNumbers = 
> VersionProps.versionNumbers();
>   941 version = new 
> Version(Collections.unmodifiableList(versionNumbers),
>   942 VersionProps.pre(),
>   943 VersionProps.build(),
>   944 VersionProps.optional());
>
> 1090 this.version = version;
>
> 1509 version = Collections.unmodifiableList(list);
>
> Mandy
>

RE: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

[Iris Clark]

Hi, Claes.

[ Sorry for the premature send, my keyboard started interpreting my shortcuts
in unexpected ways. ]

> http://cr.openjdk.java.net/~redestad/816/webrev.5/

Nice bugid.

Overall, this change looks good.  I just have a few concerns.

Have you built this forcing alternative build numbers using the makefile
"--with-version-<...>" options?  For JDK 9 builds, the default version number
is only "9".  You should make sure that versions "9.0.X" and "9.0.0.X" for
arbitrary value of X work as expected.

Runtime.java:  I wonder if unmodifiablelist() should be invoked at new line
1090 instead of 941?  Depending on the caller to provide an unmodifiable list
without additional verification seems like a potential problem.  If you move
the invocation, then you may want to consider reducing the arguments of
Version() at lines 1086-1089 to the single VersionProps.

I expect to address the following outstanding issues in the coming weeks.  I
don't think that they will impact your changes, but I leave it for you to
judge:

8156711: Runtime.Version.version should be an int[] instead of a
  List
https://bugs.openjdk.java.net/browse/JDK-8156711

This is an implementation change that was suggested during review.  The
thought was that using an int[] is more efficient for space and comparisons.
If you believe that there is benefit to adding this change to yours, feel free
to take on the bug.  Otherwise, assuming that there is still benefit to making
this change, I'll take care of it after your changes are in a promotion.

8156907: Runtime.Version.{major(),security()} return value of 0 may be
  ambiguous
https://bugs.openjdk.java.net/browse/JDK-8156907

After careful consideration, this issue will be resolved by changing the
parse() implementation to allow trialing zero elements (now in
VersionBuilder.parse()).  As an example of the target behavior,
v = Runtime.Version.parse("9.0.0") will not throw an IAE and v.toString()
will return "9".  Specification adjustments will be needed.  Since
VersionBuilder does not change the parse() implementation, I believe that
there won't be any problems.

Thanks,
iris

RE: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

[Iris Clark]

Hi, Claes.

http://cr.openjdk.java.net/~redestad/816/webrev.4/

Overall, this change looks good.  I just have a few concerns.

Have you built this forcing alternative build numbers?  I 


-Original Message-
From: Claes Redestad 
Sent: Sunday, June 26, 2016 12:56 PM
To: core-libs-dev Libs; build-dev
Subject: RFR: 816: Runtime.version() cause startup regressions in 9+119

Hi,

9+119 changed java.util.regex to initialize java.lang.invoke early, 
causing a number of easily reproducible startup regressions.

This patch uses the fact that we already maintain the version string 
constituents during build time to simplify creation of the 
java.lang.Runtime.version().

Webrev: http://cr.openjdk.java.net/~redestad/816/webrev.3/
Bug: https://bugs.openjdk.java.net/browse/JDK-816

Since getting Runtime.version() now does not have to touch 
java.util.regex classes we end up slightly ahead of previous builds for 
applications which does not use regular expressions.

Thanks!

/Claes

RE: RFR: JDK-8137259 configure needs to parse Verona-style version strings for bootjdk

[Iris Clark]

Hi, Magnus.

Thanks for taking care of this.

The modified regular expression looks like it will handle Verona builds now.

Regards,
iris

-Original Message-
From: Magnus Ihse Bursie 
Sent: Monday, September 28, 2015 5:43 AM
To: build-dev@openjdk.java.net
Cc: jdk9-versioning_ww_grp
Subject: RFR: JDK-8137259 configure needs to parse Verona-style version strings 
for bootjdk

Normally, the JDK should be built by a JDK from previous version (e.g. 
JDK8 for JDK9). However, building with JDK9 on JDK9 is (somewhat) supported.

A JDK9 bootjdk with the new Verona-style version string will currently not be 
recognized by configure.

This fix will be pushed to verona/stage.

Bug: https://bugs.openjdk.java.net/browse/JDK-8137259
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8137259-support-verona-style-bootjdk/webrev.01

/Magnus

RE: RFR: 8135083 Product version string for DLLs and EXEs should not include trailing zeros

[Iris Clark]

Hi, Daniil.

You change looks good to me.

Thanks for tracking down this issue.

Regards,
iris (not a Reviewer)

-Original Message-
From: Daniil Titov 
Sent: Wednesday, September 09, 2015 2:12 PM
To: build-dev@openjdk.java.net
Cc: verona-...@openjdk.java.net
Subject: RFR: 8135083 Product version string for DLLs and EXEs should not 
include trailing zeros

This review request is a part of the work for JEP-223 that adjusts the changes 
in RC_FLAGS implemented in the initial patch "JDK-8085822 JEP 223: New 
Version-String Scheme (initial integration)" to ensure that the product version 
string for Windows DLL/EXEs consists of dot-separated digits WITHOUT trailing 
zeros.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8135083

 

The changes are in one line only (please see inline diff below, changes in 
generated common/autoconf/generated-configure.sh are omitted).

 

diff -r 35e118e5bcb4 common/autoconf/flags.m4

--- a/common/autoconf/flags.m4Tue Sep 08 10:24:22 2015 -0700

+++ b/common/autoconf/flags.m4 Wed Sep 09 13:52:54 2015 -0700

@@ -102,7 +102,7 @@

 -D\"JDK_VERSION_STRING=\$(VERSION_STRING)\" \

 -D\"JDK_COMPANY=\$(COMPANY_NAME)\" \

 -D\"JDK_COMPONENT=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) binary\" \

--D\"JDK_VER=\$(VERSION_NUMBER_FOUR_POSITIONS)\" \

+-D\"JDK_VER=\$(VERSION_NUMBER)\" \

 -D\"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \

 -D\"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) 
\$(VERSION_MAJOR)\" \

 -D\"JDK_FVER=\$(subst .,\$(COMMA),\$(VERSION_NUMBER_FOUR_POSITIONS))\""

 

[1] http://openjdk.java.net/jeps/223

 

Thanks!

 

Best regards,

Daniil

 

RE: RFR: JDK-8075056 Remove Version.java.template from jconsole

[Iris Clark]

Hi, Staffan.

 bug: https://bugs.openjdk.java.net/browse/JDK-8075056
 webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ 
 http://cr.openjdk.java.net/~sla/8075056/webrev.00/

Looks good.  I'm always happy to see changes where complexity is reduced.

Thanks,
iris

RE: Official and community supported build platforms for JDK 8 and 9

[Iris Clark]

Hi, Martijn.

 Likewise - is it possible to get edit access?

https://wiki.openjdk.java.net/display/Build/Supported+build+platforms

That wikispace is owned by the Build Group, so all Members of that Group as 
listed in the Census [0] should be able to edit the page.

Thanks,
iris

[0] http://openjdk.java.net/census#build

-Original Message-
From: Martijn Verburg [mailto:martijnverb...@gmail.com] 
Sent: Monday, December 01, 2014 7:24 AM
To: Patrick Reinhart
Cc: jdk8-dev; build-dev; jdk9-...@openjdk.java.net
Subject: Re: Official and community supported build platforms for JDK 8 and 9

Likewise - is it possible to get edit access?

Cheers,
Martijn

RE: Adding hg version check to get_source.sh?

[Iris Clark]

Hi, Mike.

The minimum recommended version of Hg on the client side is 2.6.3 [1, 2].  I'd 
recommend a warning for anything older than that.

Thanks,
iris

[1]: http://mail.openjdk.java.net/pipermail/announce/2014-March/000164.html
[2]: http://openjdk.java.net/guide/repositories.html#installConfig

-Original Message-
From: Mike Duigou 
Sent: Tuesday, June 17, 2014 2:36 PM
To: build-dev build-dev
Subject: Adding hg version check to get_source.sh?

With the upgrade of the hg.openjdk.java.net servers very old mercurial clients 
can no longer be used (0.9.5) and there have been persistent reports of more 
frequent connection failures. The older your mercurial client the more likely 
the failures are.

jdk:   hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk
jdk:   requesting all changes
jdk:   adding changesets
jdk:   adding manifests
jdk:   transaction abort!
jdk:   rollback completed
jdk:   abort: stream ended unexpectedly (got 8372 bytes, 
expected 10932)

I would like to add a version check to get_source.sh which will require 
mercurial 1.5 or later and warn for clients older than 1.9. 

Seem reasonable?

Mike

RE: RFR: JDK-8042348: Copyright link in Javadoc page for Java SE 8

[Iris Clark]

Hi, Erik.

I think the change looks fine.

Thanks,
iris

-Original Message-
From: Erik Joelsson 
Sent: Monday, May 05, 2014 6:28 AM
To: build-dev
Subject: RFR: JDK-8042348: Copyright link in Javadoc page for Java SE 8

Hello,

Please review this small patch to javadoc generation. The Copyright footer, at 
the bottom of the page, should be a link, but in jdk8 and 9 it isn't. This is 
caused by COPYRIGHT_URL being empty if JDK_MINOR_VERSION is not 7. I see no 
reason to have a jdk version dependency on this URL since the value isn't 
dependent on jdk version.

This will likely need a backport to 8 too.

Bug: https://bugs.openjdk.java.net/browse/JDK-8042348
Patch inline:
diff -r 183052721803 make/Javadoc.gmk
--- a/make/Javadoc.gmk
+++ b/make/Javadoc.gmk
@@ -115,10 +115,7 @@
  DOCSDIR_URL = {@docroot}/$(GET2DOCSDIR)

  # Url to copyright html file
-COPYRIGHT_URL-7 = $(DOCSDIR_URL)/legal/cpyr.html -# This isn't added in old 
build yet.
-#COPYRIGHT_URL-8 = $(DOCSDIR_URL)/legal/cpyr.html -COPYRIGHT_URL = 
$(COPYRIGHT_URL-$(JDK_MINOR_VERSION))
+COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html

  # Url to bug filing site

RE: CFV: Nomination of Tim Bell as the new Build Group Lead

[Iris Clark]

Yes, you're still a member... just not the Lead.

iris

-Original Message-
From: Kelly O'Hair [mailto:kellyoh...@gmail.com] 
Sent: Wednesday, April 02, 2014 8:56 AM
To: Magnus Ihse Bursie
Cc: build-dev
Subject: Re: CFV: Nomination of Tim Bell as the new Build Group Lead

Do I get to vote?   Am I still a member of the Build Group? ;)

-kto

On Apr 2, 2014, at 2:58 AM, Magnus Ihse Bursie wrote:

 Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group 
 Lead. 
 
 I hereby nominate Tim Bell as the new Build Group Lead. With the exception of 
 a hiatus some years ago, Tim has been working with OpenJDK since it's 
 creation, and on the closed JDK on Sun prior to that. He has a valuable 
 knowledge of the OpenJDK build system, and a profound understanding of all 
 the intricacies that comes with the real-world problem of building OpenJDK.
 
 Votes are due by Wednesday, 16 April 2014.
 
 According to the Bylaws [1], only current Members of the Build Group [2] are 
 eligible to vote on this nomination. Votes must be cast in the open by 
 replying to this mailing list. If this nomination is approved by the Build 
 Group, it will then need to be ratified by the Governing Board.
 
 For Simple Majority voting instructions, see [3].
 
 [1] http://openjdk.java.net/bylaws#group-lead
 [2] http://openjdk.java.net/census#build
 [3] http://openjdk.java.net/bylaws#simple-majority
 
 /Magnus

RE: Notice: Build Group Lead resignation

[Iris Clark]

Hi, Kelly.

You've been Build Group Lead since 2007!  Thanks for all of your hard work and 
dedication!

For those wishing to nominate a new Group Lead, please see these instructions 
for Group Lead nomination, approval, and ratification on the Group overview 
page [1].

Thanks,
iris

[1]: http://openjdk.java.net/groups/#lead

-Original Message-
From: Kelly O'Hair [mailto:kellyoh...@gmail.com] 
Sent: Tuesday, April 01, 2014 3:27 PM
To: build-dev
Subject: Notice: Build Group Lead resignation


I am not able to actively work with the OpenJDK community, and therefore at 
this time, I wish to resign as Build Group Lead.

According to the bylaws, any member of the Build Group [1] can now nominate a 
successor to the role of Group Lead.

-kto

[1] http://openjdk.java.net/census#build

RE: RFR (XS): Enable new build on Linux/PPC64 (jdk part)

[Iris Clark]

Hi, Volker.

I think that the right thing for this change [1] is for you to push into 
ppc-aix-port/stage once you get the necessary reviews (presumably Erik and 
possibly Alan).  While your changeset contains some general purpose updates, it 
also contains PPC/AIX-specific files which can't be added to a JDK release 
repository until stage is pushed into the a JDK release.

The recommendation to push to stage of course assumes that Vladimir doesn't 
think that this will adversely affect the Hotspot work already being pushed to 
stage.

Thanks,
iris

[1]: http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/

-Original Message-
From: Volker Simonis [mailto:volker.simo...@gmail.com] 
Sent: Thursday, June 27, 2013 9:23 AM
To: Erik Joelsson
Cc: Kumar Srinivasan; build-dev; ppc-aix-port-...@openjdk.java.net; Alan Bateman
Subject: Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)

Hi Erik,

we have no polices which are carved in stone:) It's all done informally and by 
common sense.

The main reason for the ppc-aix-port/stage repository is to have a sandbox for 
in-depth review and testing of changes we had to make in shared code before 
pushing them to the main repository (and this especially applies to hotspot 
changes). If you feel comfortable with the current changes and don't think that 
they will break anything (e.g. by running tests build on your supported 
platforms including the closed source ones) I'd really appreciate if you could 
push them to the build repository.

Otherwise I'll push them to the staging repository and you'll get them once 
we're finished with the integration of the port.

Thank you and best regards,
Volker

On Thu, Jun 27, 2013 at 1:51 PM, Erik Joelsson erik.joels...@oracle.com wrote:


 On 2013-06-27 13:00, Volker Simonis wrote:




 On Thu, Jun 27, 2013 at 12:16 PM, Erik Joelsson 
 erik.joels...@oracle.com
 wrote:

 Hello Volker,

 I wasn't aware of this project until now. From what I (now) 
 understand, generic patches can go into jdk8 repos, but port specific 
 things need to go to staging and go in with the rest later. These 
 changes contain a couple of port specific things so as it looks now 
 they would need to go through staging.


 Yes, that's the general approach. But I'd argue that for the most part 
 this changes are generic (enable CPP-interpreter, enable CORE build, 
 fix for broken ld on SuSE, replacing OPENWIN_LIB by X_LIB, fix typos) 
 with only very few PPC64 specific parts (map-files and a few defines). 
 The problem we want to avoid is that some of our fixes go into the 
 main repositories in parallel which would result in merging pain when 
 integrating the staging into the main repository.

 So if you think you don't need any of the general fixes any time soon, 
 I'll push the changes into the staging repository. Otherwise I think 
 it would be better to push them right into the main repositories.

 Several of the general fixes in there are good and I don't want to 
 hinder those getting in. I also don't want to break policies I'm not familiar 
 with.

 /Erik

 Thanks,
 Volker


 /Erik


 On 2013-06-27 12:03, Volker Simonis wrote:

 Hi Erik,

 as Vladimir explained, we have a special staging repository for our 
 PPC64/AIX port:

 I would be happy if you could push the changes right into the 
 build-infra repositories and we will then get them into our staging 
 repository via jdk8/jdk8.

 Otherwise I'll have to push them to our staging repository and later 
 when the whole port is completed in the staging repo they will be 
 bulk-integrated into jdk8.

 What do you think?

 Regards,
 Volker


 On Wed, Jun 26, 2013 at 6:53 PM, Vladimir Kozlov 
 vladimir.koz...@oracle.com wrote:

 Erik,

 We have special staging forest for PPC64/AIX port:

 http://hg.openjdk.java.net/ppc-aix-port/stage

 We collect Hotspot and JDK changes there for testing before pushing 
 into main sources in a future. But some general fixes we push 
 directly into our main sources.
 If you think these build changes are acceptable for main, please, 
 ask someone sponsor these changes.

 Alan is our official contact for PPC64/AIX project. I CC him.

 Thanks,
 Vladimir


 On 6/26/13 8:56 AM, Erik Joelsson wrote:

 Hello,

 If you by staging area mean the build-infra forest, that's more or 
 less dead now.

 I think these changes look good now (both top level and jdk). It 
 should be fine to push this to jdk8/build.

 /Erik

 On 2013-06-26 17:28, Volker Simonis wrote:

 Hi Erik,

 thank you for looking at this. I've prepared a new webrev at:

 http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/
 http://cr.openjdk.java.net/%7Esimonis/webrevs/8017568_jdk/


 What do you think, do you want to push this directly into the 
 build repositories or should I push it into the staging repository first?

 Please see my further comments inline.

 Thank you and best regards,
 Volker

 On Tue, Jun 25, 2013 at 12:41 PM, Erik Joelsson 
 erik.joels...@oracle.com 

Re: [PATCH] Remove dependency on JScheme for generating CORBA exceptions

[iris clark]

Hi.

 The CORBA code isn't maintained directly in OpenJDK, but rather in a
 sub-project of GlassFish (https://glassfish-corba.dev.java.net/).

 That's why there's no CORBA Group.  (The same goes for JAXWS and JAXP.)

For a list of projects and their associated mailing lists (including
contact info for portions of the not maintained directly in OpenJDK,
see this table in the Developers' Guide:

  http://openjdk.java.net/guide/repositories.html#projects

Thanks,
iris

Re: What am I doing wrong here?

[iris clark]

 I'll make sure that these comments gets to the guide writing team: 
 [EMAIL PROTECTED]

Received.

Thanks,
iris