Re: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools

On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking > Adam's patch. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8706

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona wrote: >> That's good to know. I think the tricky part is mostly about keeping track >> of all these disabled warnings, so they are not kept around longer than >> necessary. And that needs coordination with all the subtasks of the umbrella >>

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]

On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the >> https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive >> Unmatched

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

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 Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7268

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

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 We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client

Re: RFR: 8176706: Additional Date-Time Formats [v3]

On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject >> enhancement. CSR has also been updated according to the suggestion. >> >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto

Re: RFR: 8176706: Additional Date-Time Formats [v3]

On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject >> enhancement. CSR has also been updated according to the suggestion. >> >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto

Re: RFR: 8176706: Additional Date-Time Formats

On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato wrote: > Following the prior discussion [1], here is the PR for the subject > enhancement. CSR has also been updated according to the suggestion. > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html

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

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

[jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example

On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread > example. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk17/pull/292

[jdk17] RFR: 8271489: (doc) Clarify Filter Factory example

Improve the clarity of comments in the ObjectInputFilter FilterInThread example. - Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int -

Re: RFR: 8267123: Remove RMI Activation

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to

Re: RFR: 8263677: Improve Character.isLowerCase/isUpperCase lookups [v2]

On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad wrote: >> This patch changes the otherLowercase / otherUppercase bits to be set if >> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or >> the Unicode Other_Lowercase / Other_Uppercase property is set. This >> simplifies

Re: RFR: 8263677: Improve Character.isLowerCase/isUpperCase lookups

On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad wrote: > This patch changes the otherLowercase / otherUppercase bits to be set if > either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the > Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies > the

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

On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Please assign a new bug and title to ignore/suppress the warnings. The original issue 8252833 should be left open. Thanks - Changes requested by rriggs

Re: OpenJDK 16 (ee1d592a9f53+ tip) - compilation error in "sharedRuntime.cpp:2849"

Hi, Likely this is new checking in XCode 12. You are more likely to get an informed response on hotspot-runtime.dev. Moving build-dev to Bcc. Roger On 2/23/21 8:37 AM, Chris W. Johnson wrote: I'm experiencing an OpenJDK build failure on macOS 10.15.7 with OpenJDK 15.0.2 (15.0.2+7-27) and

Re: RFR: 8253497: Core Libs Terminology Refresh

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: >

Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version

On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote: > Please review a small change that replaces use of objc_msgSend_stret in macOS > platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 > support, where objc_msgSend_stret is not available. Looks ok to me. But it

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class"

Re: RFR: 8254102: use ProcessHandle::pid instead of ManagementFactory::getRuntimeMXBean to get pid in tests [v2]

On Wed, 7 Oct 2020 18:12:19 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small cleanup which replaces >> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ >> `ProcessHandle.current().pid()` to get current >> process pid? Thanks, >> -- Igor > > Igor

Re: RFR: 8254102: use ProcessHandle::pid instead of ManagementFactory::getRuntimeMXBean to get pid in tests

On Tue, 6 Oct 2020 23:08:40 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small cleanup which replaces > `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ > `ProcessHandle.current().pid()` to get current > process pid? Thanks, > -- Igor All of these

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

0-08-25 12:21, Roger Riggs wrote: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. Yes, I get that part, but why are those warnings not triggered today? I

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

Hi Joe, The updates to those files are fine, I mixed up the two packages. Roger On 8/25/20 2:47 PM, Joe Wang wrote: org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint war

Re: RFR [XS]: 8248429: Add --enable-preview as VM argument when running microbenchmarks

Hi, I have found it very useful to be able to run benchmarks against multiple versions of the JDK.  Build the benchmark jar once and to compare results. If all of the classes are built with --enable-preview, none of them will run against older JDKs. So an approach that only compiles those

Re: RFR [15] 8247936: Fix typos in man pages

Hi Pavel, The changes look fine. I'm not sure only build-dev would be interested in reviewing. But I know many man page reviewers are on build-dev. Thanks, Roger On 6/19/20 10:55 AM, Pavel Rappo wrote: Hello, Please review the below change for

RFR 15 8225319: Remove the RMI static stub compiler rmic

Please review the CSR[1] and changes to remove the RMI static stub compiler (rmic). RMIC was deprecated for removal in JDK 13 [3]. The components modified are:  - remove the jdk.rmic module  - remove the jdk.rmic man page  - remove all tests of rmic or relying on rmic  - update or remove

Re: RFR (S): 8241947: Minor comment fixes for system property handling

My mistake, I mistook it for the spec table. On 4/1/20 12:06 PM, Alan Bateman wrote: On 01/04/2020 17:03, Roger Riggs wrote: Hi, Does dropping the "The following properties are guaranteed to be defined:" would seem to be a spec change. It's a comment on a private field, there's

Re: RFR (S): 8241947: Minor comment fixes for system property handling

Hi, Does dropping the "The following properties are guaranteed to be defined:" would seem to be a spec change. Just linking to the properties page makes no such guarantee. Roger On 4/1/20 10:45 AM, Alan Bateman wrote: On 31/03/2020 19:57, Langer, Christoph wrote: Hi Mandy, this is a good

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

Hi Alan, The mismatches are due to the combination of generated Stub and old stub source. I'll clean it up a bit before pushing.  As pretty static code it didn't seem worth much investment. Thanks, Roger On 3/19/20 3:39 AM, Alan Bateman wrote: On 18/03/2020 21:24, Roger Riggs wrote: Hi

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

:07, Roger Riggs wrote: Hi Magnus, Erik, Thanks for the pointers, I'm not familiar with those early build intricacies. Updated: http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-2/ Looking much better! Please remove the reference to "rmic" in Global.gmk as well. I

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

ng this. :-) Now the prospect of a fully warning-free build seems closer than ever! /Magnus /Erik On 2020-03-16 15:19, Roger Riggs wrote: Hi Erik, Please review a new webrev that adds the change to remove the interim build parts. (Passes Tier 1-3 of CI testing) http://cr.openjdk.java.ne

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

in the makefiles. This file should also be removed: make/CompileInterimRmic.gmk In make/Main.gmk, all the targets concerning rmic needs to be removed as well as any dependencies declared that involves them. Searching for "rmic" should find all relevant lines. /Erik On 2020-03-16 09

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

3/2020 16:02, Roger Riggs wrote: Please review adding pre-generated RMI stub classes to the jdk repo and the removal of make files supporting the specific APIs. It removes a dependency on build time generation invoking RMIC. RMIC was  deprecated in JDK 13 [1]. The source files have been edited to

Re: RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

/Main.gmk, all the targets concerning rmic needs to be removed as well as any dependencies declared that involves them. Searching for "rmic" should find all relevant lines. /Erik On 2020-03-16 09:02, Roger Riggs wrote: Please review adding pre-generated RMI stub classes to th

RFR 8241073: Pre-generated Stubs for javax.management, Activation, Naming

Please review adding pre-generated RMI stub classes to the jdk repo and the removal of make files supporting the specific APIs. It removes a dependency on build time generation invoking RMIC. RMIC was  deprecated in JDK 13 [1]. The source files have been edited to remove or suppress compilation

Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite

Hi, I would suggest "Java Flight Recorder"  instead of "JDK Flight Recorder" Regards, Roger On 2/21/20 10:36 AM, Magnus Ihse Bursie wrote: On 2020-02-21 16:15, Erik Gahlin wrote: jfr should be JDK Flight Recorder. Thanks, I should have checked and not guessed. :) I updated the code but

Re: RFR: JDK-8239019: testmake fails with FATAL: VCS_TYPE is empty

Looks good. Thanks, Roger On 2/18/20 2:05 PM, Erik Joelsson wrote: Here is an updated webrev with the whole check removed: http://cr.openjdk.java.net/~erikj/8239019/webrev.02 /Erik On 2020-02-14 09:16, Roger Riggs wrote: Hi Erik, Agree it should run outside of any source code system. Idea

Re: RFR: JDK-8239019: testmake fails with FATAL: VCS_TYPE is empty

Hi Erik, Agree it should run outside of any source code system. Idea supports that with the empty string. So even the warning can be removed. Thanks, Roger On 2/13/20 7:41 PM, Erik Joelsson wrote: Hello, The fix to make idea.sh support both git and mercurial had the unfortunate side effect

RFR [15] 8238918 idea.sh should work with both mercurial and git repo

Please review a small change to the idea.sh script that generates an IntelliJ project. It detects either Mercurial or Git repos and generates the appropriate vcs.xml. Webrev:    http://cr.openjdk.java.net/~rriggs/webrev-idea-git-8238918/ Issue:  

Re: [13] RFR: 8221431: Support for Unicode 12.1

Hi Naoto, Looks ok. src/java.base/share/legal/icu.md: Line 7:  Can the copyright character be changed to (c) to make it easier to check copyrights Thanks, Roger On 05/22/2019 09:36 PM, naoto.s...@oracle.com wrote: Hi Erik, Thank you for your comments. Updated the webrev accordingly:

Re: RFR: 8223804: [macos] remove obsoleted reference to security framework in launcher code

Hi Phil, Looks fine. Roger On 05/16/2019 03:30 PM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8223804 Webrev: http://cr.openjdk.java.net/~prr/8223804/ This is a small cleanup fix. When doing a previous launcher fix : https://bugs.openjdk.java.net/browse/JDK-8222819 I

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, Some comments, a initial batch... Having support for the ToolProvider is great. However, there is no indication about whether it is valid to use it from multiple threads. The implementation is structured to be deliberately single thread use only with the invocation being via a static

Re: RFR: JDK-8212091 : Move native code under platform specific folders and files

are not planing to keep history when moving jpackage from sandbox. Thanks, Alexander On 2/19/2019 8:49 AM, Roger Riggs wrote: Hi Alexander, Some files appear to be moved with hg, but others are copied and deleted. Please use hg mv to retain the continuity of the history. Thanks, Roger On 02/15

Re: RFR: JDK-8212091 : Move native code under platform specific folders and files

Hi Alexander, Some files appear to be moved with hg, but others are copied and deleted. Please use hg mv to retain the continuity of the history. Thanks, Roger On 02/15/2019 10:03 PM, Alexander Matveev wrote: Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

Hi, It is a nice feature that charsets are selected at build time using the stdcs-xxx files. This change breaks that pattern and embeds os specific information in more than one place. That does not seem like an improvement.  Is there any alternative? Thanks, Roger On 12/06/2018 12:05 PM,

Re: RFR 8214794 : java.specification.version should be only the major version number

/webrev-spec-ver-8214700-3/ Thanks, Roger On 12/04/2018 01:41 PM, Mandy Chung wrote: On 12/4/18 8:16 AM, Roger Riggs wrote: Please review correctly setting the java.specification.version property with only the major version number.  A test is added to ensure the java spec version agrees

Re: RFR 8214794 : java.specification.version should be only the major version number

Including build-dev for the change to GensrcMisc.gmk. thx. On 12/04/2018 11:16 AM, Roger Riggs wrote: Please review correctly setting the java.specification.version property with only the major version number.  A test is added to ensure the java spec version agrees with the major version

Re: RFR: 8212794 IBM-964 is required for AIX default charset

/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ Thanks, Ichiroh Takiguchi On 2018-12-04 23:36, Roger Riggs wrote: Hi Ichiroh, On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: Hello Roger. Thank you for your suggestion. src/jdk.charsets/share/classes/sun

Re: RFR: 8212794 IBM-964 is required for AIX default charset

jdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, looks fine. Regards, Roger Thanks, Ichiroh Takiguchi On 2018-12-04 05:50, Roger Riggs wrote: Hi Ichiroh, src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java:     I think this is no longer nee

Re: RFR: 8212794 IBM-964 is required for AIX default charset

Hi Ichiroh, src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java:     I think this is no longer needed since it only has imports.     By the way, the style is to import each specific class and avoid wild card imports. TestIBMBugs:   - Please use a style consistent with other methods

Re: RFR 4947890 : Minimize JNI upcalls in system property initialization

to verify FIXED_LENGTH in the test. - Ensure that configure passes the --vendor-... arguments through to   initialize the system properties. Thanks to all the reviewers. Roger On 11/26/2018 06:12 PM, Brent Christian wrote: Hi, On 11/19/18 3:37 PM, Roger Riggs wrote: Raw::xxx_NDX are initialized

Re: RFR 4947890 : Minimize JNI upcalls in system property initialization

are correctly initialized. Added a test that uses reflection to verify the uniqueness and sequence. Thanks, Roger Mandy On 11/16/18 10:49 AM, Roger Riggs wrote: Updates to include the suggestions made by Mandy and Brent:  - Move the build-time properties from native code

Re: RFR 4947890 : Minimize JNI upcalls in system property initialization

from a build point of view. /Erik On 2018-11-16 10:49, Roger Riggs wrote: Updates to include the suggestions made by Mandy and Brent:  - Move the build-time properties from native code to the VersionProps.java.template    including java.vendor.* and java.specification.* properties, plus

RFR 4947890 : Minimize JNI upcalls in system property initialization

Updates to include the suggestions made by Mandy and Brent:  - Move the build-time properties from native code to the VersionProps.java.template    including java.vendor.* and java.specification.* properties, plus the java.class.version (major.minor)    This included two changes to the build

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Hi, There are enough files unique to each platform to put them in separate packages otherwise you get too many (IMHO) files in a single package/directory and its harder to tell which go with which.  There isn't much of a problem with classes being public because they are all in a module and

Re: JDK Memory Allocation

Hi, Given the level of your questions, you will find it more rewarding to seek out and study presentations and articles about the structure of JVMs and their implementations. Regards, Roger On 7/21/18 7:51 PM, mr rupplin wrote: Having looked for some while at the OpenJDK source code I am

Re: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java

good enough. Roger On 7/26/2017 2:34 AM, Nishit Jain wrote: Thanks Roger, Made the suggested changes related to hardcoded copyright year. Please check the updated webrev http://cr.openjdk.java.net/~nishjain/8177472/webrev.06/ Regards, Nishit Jain On 25-07-2017 22:55, Roger Riggs wrote

Re: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java

lsr data is updated in jdk. Regards, Nishit Jain On 25-07-2017 21:28, Roger Riggs wrote: Hi Nishit, Can the hardcoded copyright be made more automatic? I see the make/src/classes/build/tools/cldrconverter has functions to create/convert copyrights. Can that be leveraged to generate the nee

Re: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java

Hi Nishit, Can the hardcoded copyright be made more automatic? I see the make/src/classes/build/tools/cldrconverter has functions to create/convert copyrights. Can that be leveraged to generate the needed copyright and reduce some potential maintenance of the copyright date and or contents?

Re: JDK 10 Review Request for JDK-8176583: Move currency data to /lib

Hi Nishit, I haven't seen any comments in the past month... From the code perspective, this looks ok. It should have a build Reviewer too. Thanks, Roger On 6/13/2017 12:57 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8176583 Bug:

Re: RFR: JDK-8179556 Add specs copyright file

Hi, This change looks ok, I have some other links to the copyright.html to fix in serialization and can fix the tools/docs/docs-bundle-page at the same time. Roger On 6/12/17 12:19 PM, Mandy Chung wrote: jdk/make/src/classes/build/tools/docs/docs-bundle-page.html has a reference to

Re: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc

Thanks, Webrev updated in place. build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/ Roger On 6/1/2017 9:46 AM, Magnus Ihse Bursie wrote: On 2017-06-01 15:29, Roger Riggs wrote: Ping on the build change please Just remove the entire "--doclint-format html4&quo

Re: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc

Ping on the build change please On 5/31/2017 10:43 AM, Alan Bateman wrote: On 31/05/2017 15:34, Roger Riggs wrote: Please review javadoc markup change to update to html5 acceptable to doclint. The table formatting is updated to html5 markup. The Docs build is updated to require doclint

RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc

Please review javadoc markup change to update to html5 acceptable to doclint. The table formatting is updated to html5 markup. The Docs build is updated to require doclint html5. Webrev: jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/ build:

Re: RFR: 8179915: Update extLink taglet to allow not linking the description

Hi, I would generalize it just a bit by taking the URL from the system property; if the property was set it would use the URL and if not generate the citation. Then the taglet could be used a bit more broadly without complicating the build or code. $.02, Roger On 5/11/2017 4:51 PM, Kumar

Re: RFR: JDK-8179022 Add serialization spec as markdown

Hi Magnus, Looks good, I checked the previous and new html content and found no significant differences. There are some content improvements that should be made but that's a separate task. Thanks, Roger On 4/20/2017 2:51 PM, Roger Riggs wrote: Hi Magnus, How did you verify

Re: RFR: JDK-8179022 Add serialization spec as markdown

Hi Magnus, How did you verify that the result was the same as the previous specification? It would have been good to separate the content changes from the other parts so they could be properly reviewed. The proposed markdown source does not favorably easily with the spec as I worked on it a

Re: Please review: JDK-8178725: provide way to link to external documentation

Hi, An idea that might make it more flexible would be if the settable property used as the link used one of the familiar formatting substitution mechanisms so the id can be inserted in the link wherever it is needed. For example, the PrintStream formatting like %s. Alternatively, the {0}

Re: RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged

Hi Alan, Looks ok from the core-libs perspective. Roger On 9/6/2016 3:38 AM, Alan Burlison wrote: On 01/09/2016 18:43, Alan Burlison wrote: I posted this originally on build-dev, it was suggested I should also post it to core-libs-dev for review of some of the changes. /usr/ccs /opt/sfw

Re: RFR:

$.02, for testoutput/hotspot so that if other repos do something similar they are all under testoutput/... Roger On 1/13/16 10:11 AM, Erik Helin wrote: On 2016-01-13, Staffan Larsen wrote: Looks good! Thanks! On 2016-01-13, Staffan Larsen wrote: (Although /build//testoutput/hotspot/

Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

Hi, It would be useful to figure out the number of cpus available when in a container. Some comments have added to: 8140793 getAvailableProcessors may incorrectly report the number of cpus in Docker container But so far we haven't dug deep

Re: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version

Hi Alan, Would there be any concerns about backporting to JDK 8? On 6/17/2015 7:32 AM, Alan Bateman wrote: On 15/06/2015 22:58, Roger Riggs wrote: Please review code for Windows 10 that sets the System properties for os.name and os.version from the version of kernel32.dll. The update uses

RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version

Please review code for Windows 10 that sets the System properties for os.name and os.version from the version of kernel32.dll. The update uses the same technique used by Hotspot in src/os/windows/vm/os_windows.cpp. The Windows link of CoreLibraries.gmk includes version.lib/dll. The behavior

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

Hi, Sadly, but not entirely unexpectedly there is an anomaly in the include files: It seems that Windows does not define O_SYNC and O_DSYNC. To make up for the absence jdk/src/java.base/share/native/libjava/io_util.h conditionally defines them. There is no problem if the system include files

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

: On 22/05/2015 01:42, Roger Riggs wrote: Oops, got the wrong host: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ Issues: 8074818: Resolve disabled warnings for libjava 8080007: Stop ignoring warnings for libjava Thanks, Roger In JDK_GetVersionInfo0 then I

RFR 9: 8074818: Resolve disabled warnings for libjava

Please review these native code and build changes to clear compilation warnings. Most are due to mixing unsigned types with signed types or providing the correct type to an invoked function. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-8074818/ Issues:

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

0:09, Roger Riggs wrote: Please review these native code and build changes to clear compilation warnings. Most are due to mixing unsigned types with signed types or providing the correct type to an invoked function. The code changes look good! Webrev: http://bussund0416.us.oracle.com/~rriggs

Re: Excessive rebuilds of modules

Ioi, You can rebuild just the contents of a single module: % make java.base java.base-libs java.base-launchers Roger On 5/20/2015 4:10 PM, joe darcy wrote: On 5/20/2015 11:15 AM, Ioi Lam wrote: If I change a line of code in the java.base module, every Java module is rebuilt. However, my

Re: FW: Windows 7: Running the tests

Hi Mads, The test groups are defined in the TEST.groups files at the top level/test in each repository. The jtreg -dir parameter is the top of a test directory hierarchy. Omitting the argument to jtreg will run all the tests. There is a group :jdk_core that may be a starting point. Roger

Re: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link

Hi, I saw that error message COFF: file invalid or corrupt using VS 2010 before I installed the Visual Studio 2010_x86_sp1. Worked ok after. $.02, Roger On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote: Hi there I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

Hi Staffan, An earlier issue was keeping tests in sync with the code under test, hence the use of test directories within each repository. I think a structure in which the benchmarks for some function and the function itself are in the same repository that is easier to understand and maintain.

RFR 8u40: 8065397: Remove ExtendedPlatformComponent.java from EXFILES list

Please review a cleanup for the 8u40 build. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-build-8065353/ Thanks, Roger

[8u40] Request for approval for CR 8065397 - Remove ExtendedPlatformComponent.java from EXFILES list

With correct subject line, requesting approval for: Please review a cleanup for the 8u40 build. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-build-8065353/ Looks okay to me. Are you also asking for 8u40 putback approval as well? Or maybe you are thinking to send a separate 8u40

Re: RFR: 9/8u40 8062475: Enable hook for custom doc generation

. It's correct that in JDK 8 you will need to use -include. /Erik On 2014-10-30 18:20, roger riggs wrote: Hi Erik, Thanks for the comments and recommendations. Though the new macro is not applicable to 8u40 and I'll need to use the original form of -include. Do I need a separate bug/review

Re: RFR: 9/8u40 8062475: Enable hook for custom doc generation

Hi, Corrected, updated the webrev. http://cr.openjdk.java.net/~rriggs/webrev-custom-javadoc-jdk9/ Thanks, Roger On 10/31/2014 9:47 AM, Erik Joelsson wrote: On 2014-10-31 14:44, roger riggs wrote: Hi, Thanks for the recommendations, updated webrevs: JDK 9 webrev: http://cr.openjdk.java.net

RFR 8u40: 8062635: Enable custom CompileJavaClasses.gmk

Please review a change to include CompileJavaClasses.gmk from the CUSTOM_MAKE_DIR. Please verify the change from := to += at line 61, it was overwriting instead of appending. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-custom-compile-java/ Issue:

Re: RFR: 9/8u40 8062475: Enable hook for custom doc generation

with ifndef OPENJDK. /Erik On 2014-10-29 20:56, roger riggs wrote: To enable generating additional javadoc from the CUSTOM_MAKE_DIR directory please review: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-custom-javadoc/ Issue: 8062475: Enable hook for custom doc generation Thanks, Roger

RFR: 9/8u40 8062475: Enable hook for custom doc generation

To enable generating additional javadoc from the CUSTOM_MAKE_DIR directory please review: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-custom-javadoc/ Issue: 8062475: Enable hook for custom doc generation Thanks, Roger

RFR: 8057751: CompileNativeLibraries for custom build

Please review for 8u40 this improvement to allow delegation of building native libraries to the custom/closed build. Issue: JDK-8057751 https://bugs.openjdk.java.net/browse/JDK-8057751 CompileNativeLibraries for custom build Webrev:

Re: RFR: 8057751: CompileNativeLibraries for custom build

Hi David, Thanks, I will add the comment. Roger On 9/8/2014 8:36 AM, David Holmes wrote: Hi Roger, On 8/09/2014 10:30 PM, roger riggs wrote: Please review for 8u40 this improvement to allow delegation of building native libraries to the custom/closed build. Issue: JDK-8057751 https

How to CompileNativeLibraries (for 8u40) in custom/closed repository

Hi, For 8u40... There should be a hook from the open CompileNativeLibraries to a corresponding makefile in the custom/closed repository to allow build instructions to be in the right place. I think all it takes is to add a conditional include; is there a better way? Webrev @