From mark.reinhold at oracle.com Sat Apr 1 18:25:50 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 01 Apr 2017 11:25:50 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: References: Message-ID: <20170401112550.898587932@eggemoggin.niobe.net> 2017/3/30 6:05:43 -0700, magnus.ihse.bursie at oracle.com: > As a part of JEP 299, we should build the Javadoc as a single combined > output, instead of a dozen or so individual javadoc bundles. This bug > fixes this. The selection on what to include is now based on modules > instead of packages. I'm worried that perhaps we've unified a bit too much here. This patch does build all the Javadoc together, as advertised, but that places the `jdk.*` modules together with the `java.*` modules under the heading "Java Platform, Standard Edition 9 API Specification", and of course the `jdk.*` modules aren't part of that spec. JDK 9 is the "Reference Implementation" (in JCP terms) of Java SE 9, so it's important to keep a clear distinction between the SE-standard parts of the spec and those that are JDK-specific. Would it make sense instead to have `docs/api` be just for the SE (i.e., `java.*`) modules, and then place the Javadoc for the `jdk.*` modules under `docs/api/jdk`? There could be a helpful link from the SE API title page to the JDK API title page, but it should make it clear that the JDK APIs aren't part of the SE spec. - Mark From erik.joelsson at oracle.com Mon Apr 3 08:36:46 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Apr 2017 10:36:46 +0200 Subject: JDK10 build on Win64 fails on `make images` In-Reply-To: References: Message-ID: <8508da1d-93d2-f7f2-f597-973e387066bb@oracle.com> (moving to build-dev) Hello Oleksandr Nikitin, It looks like you forgot to clone all the repositories. Please run "sh get_source.sh" in the root of the repository you cloned. You will also need to rerun "sh ./common/bin/hgforest.sh up -r JDK-8174901-epsilon-branch" after the full clone. I would also recommend getting Visual Studio 2013. While configure will accept 2010/SDK 7.1, it's not the compiler we use or recommend for JDK 9 or 10. /Erik On 2017-04-01 18:11, Oleksandr Nikitin wrote: > Hello, > > I am trying to build JDK 10 + Epsilon GC on Windows by this guide: > http://openjdk.java.net/jeps/8174901 > > TLDR: configure seems to run fine, but the `make images` step fails with > the error: > No rule to make target `java.base-libs` > > Full build log: https://gist.github.com/wizzard0/ > ad8406ea1c2aea4bfe9faeda35a76dd0 > > I can build JDK 8 and 9 in this environment, so I assume it is configured > mostly correctly. > Never dabbled with any JDK sources before, so looking for any advice. I can > provide access to the machine if needed. > > Machine: Windows 10 Pro x64, Windows SDK 7.1, Cygwin x64, bootstrap JDK > 1.8u121 x64 > > Thanks in advance! > From magnus.ihse.bursie at oracle.com Mon Apr 3 10:00:30 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Apr 2017 12:00:30 +0200 Subject: RFR: JDK-8177955 Add testing documentation Message-ID: The new run-test framework got a serious documentation effort alongside its creation. Unfortunately, there were at the time no good place to put that documentation. Now that we have common/doc and a framework for handling build documentation, it would be good to put the run-test documentation there. I intend to push this as a documentation bug (noreg-doc) into jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8177955 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8177955-add-testing-docs/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Apr 3 10:24:52 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Apr 2017 12:24:52 +0200 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <20170401112550.898587932@eggemoggin.niobe.net> References: <20170401112550.898587932@eggemoggin.niobe.net> Message-ID: <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> Mark, I think the distinction you ask for is already there. The two separate make targets "docs-javadoc" and "docs-reference" builds two distinct images "docs" and "javase-docs", respectively. The first of these builds the complete Java SE + JDK documentation, the second build just the Java SE documentation. I do not think it's a good idea to go further and actually *remove* the Java SE part from the complete "docs" image. Upholding such a formal difference between different parts of the JDK is likely to be just confusing to common Java developers. I believe that enforcing such a cut would eliminate much of the work that has been put into giving the the Java developer community a unified access to all releveant documentation. With that said, we should change the heading so that only the javase-docs image claims to be the SE specification. (Note that this incorrect claim is not a regression, since this is what the core-docs api has been saying since long time ago, even while containing Oracle-specific classes...) /Magnus On 2017-04-01 20:25, mark.reinhold at oracle.com wrote: > 2017/3/30 6:05:43 -0700, magnus.ihse.bursie at oracle.com: >> As a part of JEP 299, we should build the Javadoc as a single combined >> output, instead of a dozen or so individual javadoc bundles. This bug >> fixes this. The selection on what to include is now based on modules >> instead of packages. > I'm worried that perhaps we've unified a bit too much here. > > This patch does build all the Javadoc together, as advertised, but that > places the `jdk.*` modules together with the `java.*` modules under the > heading "Java Platform, Standard Edition 9 API Specification", and of > course the `jdk.*` modules aren't part of that spec. > > JDK 9 is the "Reference Implementation" (in JCP terms) of Java SE 9, so > it's important to keep a clear distinction between the SE-standard parts > of the spec and those that are JDK-specific. > > Would it make sense instead to have `docs/api` be just for the SE (i.e., > `java.*`) modules, and then place the Javadoc for the `jdk.*` modules > under `docs/api/jdk`? There could be a helpful link from the SE API > title page to the JDK API title page, but it should make it clear that > the JDK APIs aren't part of the SE spec. > > - Mark From erik.joelsson at oracle.com Mon Apr 3 11:52:25 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Apr 2017 13:52:25 +0200 Subject: RFR: JDK-8177955 Add testing documentation In-Reply-To: References: Message-ID: <8c01d0e6-a558-1025-fc4a-a70aa247d2ae@oracle.com> Looks good. A few grammar/spelling corrections: 96: "All tests" 127: "command line" 139: is this still true? I thought you added the default concurrency behavior from the old hotspot test/Makefile. /Erik On 2017-04-03 12:00, Magnus Ihse Bursie wrote: > The new run-test framework got a serious documentation effort > alongside its creation. Unfortunately, there were at the time no good > place to put that documentation. > > Now that we have common/doc and a framework for handling build > documentation, it would be good to put the run-test documentation there. > > I intend to push this as a documentation bug (noreg-doc) into jdk9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177955 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8177955-add-testing-docs/webrev.01 > > /Magnus > From jonathan.gibbons at oracle.com Mon Apr 3 18:01:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 03 Apr 2017 11:01:13 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> Message-ID: <58E28DE9.4050201@oracle.com> Mark, I agree there will need to be some cosmetic cleanup with respect to headings. Given the optionality of whether or not the build is set to import JavaFX, the headings and content of the new overview page will need to be somewhat synthesized. Separately, it has always been a requirement to support the generation of "Java SE"-only docs, which can be produced independently of the consolidated docs. The advantage of being able to generate a single big bundle is that the new "javadoc Search" feature will work as expected. If we partition the docs, then the scope of any search will be restricted to the subset of docs currently being viewed. -- Jon On 04/03/2017 03:24 AM, Magnus Ihse Bursie wrote: > Mark, > > I think the distinction you ask for is already there. The two separate > make targets "docs-javadoc" and "docs-reference" builds two distinct > images "docs" and "javase-docs", respectively. The first of these > builds the complete Java SE + JDK documentation, the second build just > the Java SE documentation. > > I do not think it's a good idea to go further and actually *remove* > the Java SE part from the complete "docs" image. Upholding such a > formal difference between different parts of the JDK is likely to be > just confusing to common Java developers. I believe that enforcing > such a cut would eliminate much of the work that has been put into > giving the the Java developer community a unified access to all > releveant documentation. > > With that said, we should change the heading so that only the > javase-docs image claims to be the SE specification. (Note that this > incorrect claim is not a regression, since this is what the core-docs > api has been saying since long time ago, even while containing > Oracle-specific classes...) > > /Magnus > > On 2017-04-01 20:25, mark.reinhold at oracle.com wrote: >> 2017/3/30 6:05:43 -0700, magnus.ihse.bursie at oracle.com: >>> As a part of JEP 299, we should build the Javadoc as a single combined >>> output, instead of a dozen or so individual javadoc bundles. This bug >>> fixes this. The selection on what to include is now based on modules >>> instead of packages. >> I'm worried that perhaps we've unified a bit too much here. >> >> This patch does build all the Javadoc together, as advertised, but that >> places the `jdk.*` modules together with the `java.*` modules under the >> heading "Java Platform, Standard Edition 9 API Specification", and of >> course the `jdk.*` modules aren't part of that spec. >> >> JDK 9 is the "Reference Implementation" (in JCP terms) of Java SE 9, so >> it's important to keep a clear distinction between the SE-standard parts >> of the spec and those that are JDK-specific. >> >> Would it make sense instead to have `docs/api` be just for the SE (i.e., >> `java.*`) modules, and then place the Javadoc for the `jdk.*` modules >> under `docs/api/jdk`? There could be a helpful link from the SE API >> title page to the JDK API title page, but it should make it clear that >> the JDK APIs aren't part of the SE spec. >> >> - Mark > From mandy.chung at oracle.com Mon Apr 3 18:41:03 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 11:41:03 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name Message-ID: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ This revisits the OS name and arch in packaging JDK modules to extend the module descriptor with ModuleTarget class file attribute. We considered matching with the system properties. Linux x64 JDK can run on a system whose `os.arch` system property value can be `amd64` or `i586` or `x86_x64`. Similiarly, windows x86/x64 JDK can run on a system whose `os.name` system property starts with ?Windows? as the os.name property is set to "Windows XXX" for example "Windows Server 2012 R2?. It might be worth considering multiple OS arch values in ModuleTarget in the future. JDK bundle names are revised in JDK 9. This is a good alternative to be consistent with $OS-$ARCH value in the bundle names. This patch proposes to package JDK modules with OS name and arch to match the values as in JDK bundle names. jlink will generate the `release` file and set OS_NAME and OS_ARCH to those values. This also proposes to drop OS_VERSION to align with the ModuleTarget class file attribute. This shows the old and new value of OS_NAME/OS_ARCH properties in the `release` file: JDK 8 JDK 9 ----- ----- OS_NAME Linux linux SunOS solaris Darwin osx Windows windows OS_ARCH i386,x86 x86 i586,amd64,x86_64 x64 sparcv9 sparcv9 arm arm32 aarch64 arm64 Mandy From mark.reinhold at oracle.com Mon Apr 3 20:15:52 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 13:15:52 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <20170403131552.834209932@eggemoggin.niobe.net> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > ... > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin osx > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 x64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 I suggest we use "amd64" instead of "x64" (or any other variants). "x64" is confusingly close to "x86", and while it's used by some companies (including Oracle), it's not used all that widely. "amd64" is better known, matches the long-standing value of the "os.arch" system property (on Linux and Windows, anyway) and, as a side benefit, honors the originators of the architecture. - Mark From simon at cjnash.com Mon Apr 3 20:35:30 2017 From: simon at cjnash.com (Simon Nash) Date: Mon, 03 Apr 2017 21:35:30 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170403131552.834209932@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> Message-ID: <58E2B212.6080605@cjnash.com> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: > 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> >> ... >> >> This shows the old and new value of OS_NAME/OS_ARCH properties >> in the `release` file: >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin osx >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 x64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 > > I suggest we use "amd64" instead of "x64" (or any other variants). > "x64" is confusingly close to "x86", and while it's used by some > companies (including Oracle), it's not used all that widely. "amd64" is > better known, matches the long-standing value of the "os.arch" system > property (on Linux and Windows, anyway) and, as a side benefit, honors > the originators of the architecture. > > - Mark > I am not sure why we would change to osx for Mac when the Mac developers have recently dropped the Mac OS X terminology and changed it to macOS. Simon From mandy.chung at oracle.com Mon Apr 3 21:07:39 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 14:07:39 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <58E2B212.6080605@cjnash.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> Message-ID: <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> > On Apr 3, 2017, at 1:35 PM, Simon Nash wrote: > > On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: > > I am not sure why we would change to osx for Mac when the Mac developers > have recently dropped the Mac OS X terminology and changed it to macOS. Just to be clear, there is no plan to change the value of the ?os.name? system property and its value is ?Mac OS X?. Changing the value of the system property ?os.name? would break existing applications. In JDK 8, OS_NAME in the release file is ?Darwin? which is what this patch would change. Mandy From simon at cjnash.com Mon Apr 3 21:38:52 2017 From: simon at cjnash.com (Simon Nash) Date: Mon, 03 Apr 2017 22:38:52 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> Message-ID: <58E2C0EC.4000907@cjnash.com> On 03/04/2017 22:07, Mandy Chung wrote: >> On Apr 3, 2017, at 1:35 PM, Simon Nash wrote: >> >> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >> >> I am not sure why we would change to osx for Mac when the Mac developers >> have recently dropped the Mac OS X terminology and changed it to macOS. > > Just to be clear, there is no plan to change the value of the > ?os.name? system property and its value is ?Mac OS X?. > Changing the value of the system property ?os.name? would > break existing applications. > > In JDK 8, OS_NAME in the release file is ?Darwin? which is > what this patch would change. > > Mandy I understand that the os.name property value cannot be changed for compatibility reasons and therefore this name needs to stay as the "historic" Mac OS X. My comment was regarding the change of value for OS_NAME. Given that there is no compatibility issue here, does it make sense for the new value to be something that is no longer current in Apple terminology? Simon From mark.reinhold at oracle.com Mon Apr 3 21:39:25 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 14:39:25 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <58E2B212.6080605@cjnash.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> Message-ID: <20170403143925.120730340@eggemoggin.niobe.net> 2017/4/3 13:35:30 -0700, simon at cjnash.com: > On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>> >>> ... >>> >>> This shows the old and new value of OS_NAME/OS_ARCH properties >>> in the `release` file: >>> >>> JDK 8 JDK 9 >>> ----- ----- >>> OS_NAME Linux linux >>> SunOS solaris >>> Darwin osx >>> Windows windows >>> >>> OS_ARCH i386,x86 x86 >>> i586,amd64,x86_64 x64 >>> sparcv9 sparcv9 >>> arm arm32 >>> aarch64 arm64 > > I am not sure why we would change to osx for Mac when the Mac developers > have recently dropped the Mac OS X terminology and changed it to macOS. Agreed -- we should change OS_NAME from "Darwin" to "macos". - Mark From mandy.chung at oracle.com Mon Apr 3 21:50:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 14:50:52 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170403143925.120730340@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> Message-ID: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> > On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: > > 2017/4/3 13:35:30 -0700, simon at cjnash.com: >> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >>> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>>> >>>> ... >>>> >>>> This shows the old and new value of OS_NAME/OS_ARCH properties >>>> in the `release` file: >>>> >>>> JDK 8 JDK 9 >>>> ----- ----- >>>> OS_NAME Linux linux >>>> SunOS solaris >>>> Darwin osx >>>> Windows windows >>>> >>>> OS_ARCH i386,x86 x86 >>>> i586,amd64,x86_64 x64 >>>> sparcv9 sparcv9 >>>> arm arm32 >>>> aarch64 arm64 >> >> I am not sure why we would change to osx for Mac when the Mac developers >> have recently dropped the Mac OS X terminology and changed it to macOS. > > Agreed -- we should change OS_NAME from "Darwin" to "macos?. OK. Should the bundle names be updated to reflect this change? In any case, it is a separate issue. JDK 8 JDK 9 ----- ----- OS_NAME Linux linux SunOS solaris Darwin macos Windows windows OS_ARCH i386,x86 x86 i586,amd64,x86_64 amd64 sparcv9 sparcv9 arm arm32 aarch64 arm64 Mandy From mark.reinhold at oracle.com Mon Apr 3 23:10:00 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 16:10:00 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> Message-ID: <20170403161000.636247171@eggemoggin.niobe.net> 2017/4/3 14:50:52 -0700, mandy.chung at oracle.com: >> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>> ... >>> >>> I am not sure why we would change to osx for Mac when the Mac developers >>> have recently dropped the Mac OS X terminology and changed it to macOS. >> >> Agreed -- we should change OS_NAME from "Darwin" to "macos?. > > OK. Should the bundle names be updated to reflect this change? Probably not worth doing at this late stage in 9; let's fix these in 10. > In any case, it is a separate issue. Yep. > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 Looks good. Thanks, - Mark From mark.reinhold at oracle.com Mon Apr 3 23:38:36 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 16:38:36 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> Message-ID: <20170403163836.43874389@eggemoggin.niobe.net> 2017/4/3 3:24:52 -0700, magnus.ihse.bursie at oracle.com: > I think the distinction you ask for is already there. The two separate > make targets "docs-javadoc" and "docs-reference" builds two distinct > images "docs" and "javase-docs", respectively. The first of these builds > the complete Java SE + JDK documentation, the second build just the Java > SE documentation. I'm glad that there's an SE-only target, but that's not what I asked for. > I do not think it's a good idea to go further and actually *remove* the > Java SE part from the complete "docs" image. That's not what I asked for, either. I suggested making a stronger distinction between the specifications of the SE APIs and those of the rest of the JDK, by putting the latter in a subdirectory of the same image. Sorry if that wasn't clear. > Upholding such a formal > difference between different parts of the JDK is likely to be just > confusing to common Java developers. I believe that enforcing such a cut > would eliminate much of the work that has been put into giving the the > Java developer community a unified access to all releveant documentation. I see your point, but failing to make a strong distinction could also confuse developers, since it may lead some to use JDK-specific APIs when they really want to write code that's portable to any SE implementation. Still, there may be better ways to make that distinction, as Jon suggests nearby. > With that said, we should change the heading so that only the > javase-docs image claims to be the SE specification. Yes, we must do that, at a bare minimum. - Mark From mark.reinhold at oracle.com Mon Apr 3 23:42:07 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Apr 2017 16:42:07 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <58E28DE9.4050201@oracle.com> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <58E28DE9.4050201@oracle.com> Message-ID: <20170403164207.109533423@eggemoggin.niobe.net> 2017/4/3 11:01:13 -0700, jonathan.gibbons at oracle.com: > I agree there will need to be some cosmetic cleanup with respect to > headings. Given the optionality of whether or not the build is set to > import JavaFX, the headings and content of the new overview page will > need to be somewhat synthesized. Is it possible to have (up to) three sections of modules on the front page, where the first is headed by an orange "Java SE Modules" box, the second is "JavaFX Modules", and the third is "JDK Modules"? That, plus an updated title and some prose to explain that the first section is standard and the rest are not, would probably do the trick. > The advantage of being able to generate a single big bundle is that the > new "javadoc Search" feature will work as expected. If we partition the > docs, then the scope of any search will be restricted to the subset of > docs currently being viewed. I agree that a unified search experience is very useful. - Mark From mandy.chung at oracle.com Mon Apr 3 23:49:41 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 3 Apr 2017 16:49:41 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170403161000.636247171@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <20170403161000.636247171@eggemoggin.niobe.net> Message-ID: > On Apr 3, 2017, at 4:10 PM, mark.reinhold at oracle.com wrote: > > 2017/4/3 14:50:52 -0700, mandy.chung at oracle.com: >>> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >>> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>>> ... >>>> >>>> I am not sure why we would change to osx for Mac when the Mac developers >>>> have recently dropped the Mac OS X terminology and changed it to macOS. >>> >>> Agreed -- we should change OS_NAME from "Darwin" to "macos?. >> >> OK. Should the bundle names be updated to reflect this change? > > Probably not worth doing at this late stage in 9; let's fix these in 10. That's what I was thinking too. I created a JBS issue target for 10: Mandy From jonathan.gibbons at oracle.com Mon Apr 3 23:59:34 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 03 Apr 2017 16:59:34 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <20170403164207.109533423@eggemoggin.niobe.net> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <58E28DE9.4050201@oracle.com> <20170403164207.109533423@eggemoggin.niobe.net> Message-ID: <58E2E1E6.9070708@oracle.com> On 04/03/2017 04:42 PM, mark.reinhold at oracle.com wrote: > 2017/4/3 11:01:13 -0700, jonathan.gibbons at oracle.com: >> I agree there will need to be some cosmetic cleanup with respect to >> headings. Given the optionality of whether or not the build is set to >> import JavaFX, the headings and content of the new overview page will >> need to be somewhat synthesized. > Is it possible to have (up to) three sections of modules on the front > page, where the first is headed by an orange "Java SE Modules" box, the > second is "JavaFX Modules", and the third is "JDK Modules"? > > That, plus an updated title and some prose to explain that the first > section is standard and the rest are not, would probably do the trick. I'm not sure that we can partition the modules table in the remaining time for 9, although I do like the suggestion. My thought had been to focus on the prose, so that the introductory text on the page has 3 paragraphs with appropriate subheadings, for the 3 groups that you mention. I was hoping that the makefiles would then be able to determine which of those 3 sections would be appropriate for the docs bundle being generated. Going forward, I was thinking to repurpose the under-used -group option to give something like the visual grouping you suggest. See: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#group Using the existing technology, it might be reasonably easy to change the existing table, so that the Modules tab can replaced by a series of tabs labelled "All Modules", "Java SE Modules", "JavaFX Modules" and "JDK Modules". I can raise this with the rest of jaavdoc team to see how difficult that would be in the remaining time. > >> The advantage of being able to generate a single big bundle is that the >> new "javadoc Search" feature will work as expected. If we partition the >> docs, then the scope of any search will be restricted to the subset of >> docs currently being viewed. > I agree that a unified search experience is very useful. > > - Mark From Alan.Bateman at oracle.com Tue Apr 4 06:40:31 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Apr 2017 07:40:31 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <58E2C0EC.4000907@cjnash.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <1D342860-93A1-4A04-A1AC-C7C67A9C4E3F@oracle.com> <58E2C0EC.4000907@cjnash.com> Message-ID: <54e37f0b-b5d1-8d74-04a1-58bffa97c867@oracle.com> On 03/04/2017 22:38, Simon Nash wrote: > : > > My comment was regarding the change of value for OS_NAME. Given that > there is > no compatibility issue here, does it make sense for the new value to > be something > that is no longer current in Apple terminology? Just on compatibility then just to say that the `release` file is a supported interface. So changing the value of OS_NAME ("Darwin" -> "macos" and "SunOS" -> "solaris") might mean that scripts or tools that read it will need to be updated. Mandy will get this change documented in the release notes and I wouldn't expect updating scripts to deal with additional or new values should be a major issue. -Alan. From Alan.Bateman at oracle.com Tue Apr 4 07:42:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Apr 2017 08:42:06 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: On 03/04/2017 19:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails. In DefaultImageBuilder.storeFiles then map(ResourcePoolModule::osName).orElse(null) would be cleaner. I'm sure Volker or someone maintaining the AIX port will ask for jdk.tools.jlink.internal.Platform to be extended to handle that platform. -Alan. From magnus.ihse.bursie at oracle.com Tue Apr 4 08:04:22 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 10:04:22 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> Message-ID: <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> On 2017-04-03 23:50, Mandy Chung wrote: >> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >> >> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >>>> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>>>> >>>>> ... >>>>> >>>>> This shows the old and new value of OS_NAME/OS_ARCH properties >>>>> in the `release` file: >>>>> >>>>> JDK 8 JDK 9 >>>>> ----- ----- >>>>> OS_NAME Linux linux >>>>> SunOS solaris >>>>> Darwin osx >>>>> Windows windows >>>>> >>>>> OS_ARCH i386,x86 x86 >>>>> i586,amd64,x86_64 x64 >>>>> sparcv9 sparcv9 >>>>> arm arm32 >>>>> aarch64 arm64 >>> I am not sure why we would change to osx for Mac when the Mac developers >>> have recently dropped the Mac OS X terminology and changed it to macOS. >> Agreed -- we should change OS_NAME from "Darwin" to "macos?. > OK. Should the bundle names be updated to reflect this change? > In any case, it is a separate issue. > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 If we are making changes to the original proposal from JDK-8175819, then I just want to add my few cents: Why change from the well-established "aarch64" to the virtually unused "arm64"? As far as I know, using the name "arm64" for the aarch64 platform is something that has only been done in the (recently opened) closed Oracle port. This change, however, proposes to change the value in the release file even for the open aarch64 port, which has always been known by that name. /Magnus > > Mandy > From magnus.ihse.bursie at oracle.com Tue Apr 4 08:20:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 10:20:23 +0200 Subject: RFR: JDK-8177955 Add testing documentation In-Reply-To: <8c01d0e6-a558-1025-fc4a-a70aa247d2ae@oracle.com> References: <8c01d0e6-a558-1025-fc4a-a70aa247d2ae@oracle.com> Message-ID: <64fa228a-4d43-ba7c-a321-7ff32c5a908e@oracle.com> On 2017-04-03 13:52, Erik Joelsson wrote: > Looks good. A few grammar/spelling corrections: > > 96: "All tests" Fixed. > > 127: "command line" Fixed. > > 139: is this still true? I thought you added the default concurrency > behavior from the old hotspot test/Makefile. Mr Eagle Eye! :-) Updated to: Defaults to TEST_JOBS (if set by `--with-test-jobs=`), otherwise it defaults to JOBS, except for Hotspot, where the default is *number of CPU cores/2*, but never more than 12. /Magnus > > /Erik > > > On 2017-04-03 12:00, Magnus Ihse Bursie wrote: >> The new run-test framework got a serious documentation effort >> alongside its creation. Unfortunately, there were at the time no good >> place to put that documentation. >> >> Now that we have common/doc and a framework for handling build >> documentation, it would be good to put the run-test documentation there. >> >> I intend to push this as a documentation bug (noreg-doc) into jdk9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8177955 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8177955-add-testing-docs/webrev.01 >> >> /Magnus >> > From adinn at redhat.com Tue Apr 4 08:59:56 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Apr 2017 09:59:56 +0100 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <4c1201e8-31a2-2f84-2ef3-1ae838dff353@redhat.com> On 03/04/17 19:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > This revisits the OS name and arch in packaging JDK modules > to extend the module descriptor with ModuleTarget class file > attribute. We considered matching with the system properties. > Linux x64 JDK can run on a system whose `os.arch` system > property value can be `amd64` or `i586` or `x86_x64`. > Similiarly, windows x86/x64 JDK can run on a system whose > `os.name` system property starts with ?Windows? as the > os.name property is set to "Windows XXX" for example > "Windows Server 2012 R2?. It might be worth considering > multiple OS arch values in ModuleTarget in the future. > > JDK bundle names are revised in JDK 9. This is a good > alternative to be consistent with $OS-$ARCH value in > the bundle names. This patch proposes to package JDK modules > with OS name and arch to match the values as in JDK bundle names. > jlink will generate the `release` file and set OS_NAME and > OS_ARCH to those values. This also proposes to drop > OS_VERSION to align with the ModuleTarget class file attribute. > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin osx > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 x64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 arm64 is *not* a correct name for the AArch64 architecture. There is in fact no arm64 architecture. The latter name has been used to identify the Oracle-developed port but that fact does not sanction its use for OS_ARCH. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.joelsson at oracle.com Tue Apr 4 09:57:15 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 11:57:15 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: Hello, I don't quite understand this. In the proposition below it says osx, and x64, but in platform.m4 you generate macos and amd64. Does this then get translated again and why are we introducing yet another name for the operating system on Apple computers? /Erik On 2017-04-03 20:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > This revisits the OS name and arch in packaging JDK modules > to extend the module descriptor with ModuleTarget class file > attribute. We considered matching with the system properties. > Linux x64 JDK can run on a system whose `os.arch` system > property value can be `amd64` or `i586` or `x86_x64`. > Similiarly, windows x86/x64 JDK can run on a system whose > `os.name` system property starts with ?Windows? as the > os.name property is set to "Windows XXX" for example > "Windows Server 2012 R2?. It might be worth considering > multiple OS arch values in ModuleTarget in the future. > > JDK bundle names are revised in JDK 9. This is a good > alternative to be consistent with $OS-$ARCH value in > the bundle names. This patch proposes to package JDK modules > with OS name and arch to match the values as in JDK bundle names. > jlink will generate the `release` file and set OS_NAME and > OS_ARCH to those values. This also proposes to drop > OS_VERSION to align with the ModuleTarget class file attribute. > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin osx > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 x64 > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 > > Mandy > From erik.joelsson at oracle.com Tue Apr 4 10:13:42 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 12:13:42 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <0112fc8f-0e4f-1c16-782c-fde330735453@oracle.com> Oh, I missed the further discussion before I posted this and the webrev was apparently updated in place to reflect that discussion. Please ignore my comment below. /Erik On 2017-04-04 11:57, Erik Joelsson wrote: > Hello, > > I don't quite understand this. In the proposition below it says osx, > and x64, but in platform.m4 you generate macos and amd64. Does this > then get translated again and why are we introducing yet another name > for the operating system on Apple computers? > > /Erik > > > On 2017-04-03 20:41, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> >> This revisits the OS name and arch in packaging JDK modules >> to extend the module descriptor with ModuleTarget class file >> attribute. We considered matching with the system properties. >> Linux x64 JDK can run on a system whose `os.arch` system >> property value can be `amd64` or `i586` or `x86_x64`. >> Similiarly, windows x86/x64 JDK can run on a system whose >> `os.name` system property starts with ?Windows? as the >> os.name property is set to "Windows XXX" for example >> "Windows Server 2012 R2?. It might be worth considering >> multiple OS arch values in ModuleTarget in the future. >> >> JDK bundle names are revised in JDK 9. This is a good >> alternative to be consistent with $OS-$ARCH value in >> the bundle names. This patch proposes to package JDK modules >> with OS name and arch to match the values as in JDK bundle names. >> jlink will generate the `release` file and set OS_NAME and >> OS_ARCH to those values. This also proposes to drop >> OS_VERSION to align with the ModuleTarget class file attribute. >> >> This shows the old and new value of OS_NAME/OS_ARCH properties >> in the `release` file: >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin osx >> Windows windows >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 x64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 >> >> Mandy > From akashche at redhat.com Tue Apr 4 11:26:41 2017 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 4 Apr 2017 12:26:41 +0100 Subject: Number of make jobs for bootcycle-images target Message-ID: Hi, Currently in jdk9 bootcycle-images make target is executed with unlimited number of make jobs. May I ask whether "JOBS=" bit here [1] is intentional or just a typo and should be "JOBS=$(JOBS)" instead? Current variant works on x86_64 but crashes with native arm32 boot cycle builds - compilation tasks are spawned faster than being executed. [1] http://hg.openjdk.java.net/jdk9/jdk9/file/41d9f0545d53/make/Main.gmk#l323 -- -Alex From magnus.ihse.bursie at oracle.com Tue Apr 4 11:47:58 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 13:47:58 +0200 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <20170403163836.43874389@eggemoggin.niobe.net> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <20170403163836.43874389@eggemoggin.niobe.net> Message-ID: Here is an updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03 The only change compared to the previous webrev is that I have updated the title for the JDK javadocs so it does not claim to be Java SE. I have filed the following follow-up bugs to address Mark's concerns, and concerns expressed elsewhere: * JDK-8178043 Group Java SE, JDK and JavaFX modules in unified javadoc [1] * JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java [2] * JDK-8178038 Copy jdwp-protocol.html to proper location [3] * JDK-8178039 Copy jvmti.html to proper location [4] I hope JDK-8178043 captures the intent of the solution I understand that Mark and Jon seemed to agree upon. I also refer to the previously existing: * JDK-8175824 Provide more flexible means for setting the overview text in the generated docs [5] which I have amended with the task of also making sure that the values of the title text snippets gets proper values. Since a lot of the continued work on Javadoc changes in JDK 9 is dependent on this change, I hope it is now clear for pushing. /Magnus [1] https://bugs.openjdk.java.net/browse/JDK-8178043 [2] https://bugs.openjdk.java.net/browse/JDK-8178037 [3] https://bugs.openjdk.java.net/browse/JDK-8178038 [4] https://bugs.openjdk.java.net/browse/JDK-8178039 [5] https://bugs.openjdk.java.net/browse/JDK-8175824 On 2017-04-04 01:38, mark.reinhold at oracle.com wrote: > 2017/4/3 3:24:52 -0700, magnus.ihse.bursie at oracle.com: >> I think the distinction you ask for is already there. The two separate >> make targets "docs-javadoc" and "docs-reference" builds two distinct >> images "docs" and "javase-docs", respectively. The first of these builds >> the complete Java SE + JDK documentation, the second build just the Java >> SE documentation. > I'm glad that there's an SE-only target, but that's not what I asked > for. > >> I do not think it's a good idea to go further and actually *remove* the >> Java SE part from the complete "docs" image. > That's not what I asked for, either. I suggested making a stronger > distinction between the specifications of the SE APIs and those of the > rest of the JDK, by putting the latter in a subdirectory of the same > image. Sorry if that wasn't clear. > >> Upholding such a formal >> difference between different parts of the JDK is likely to be just >> confusing to common Java developers. I believe that enforcing such a cut >> would eliminate much of the work that has been put into giving the the >> Java developer community a unified access to all releveant documentation. > I see your point, but failing to make a strong distinction could also > confuse developers, since it may lead some to use JDK-specific APIs when > they really want to write code that's portable to any SE implementation. > > Still, there may be better ways to make that distinction, as Jon suggests > nearby. > >> With that said, we should change the heading so that only the >> javase-docs image claims to be the SE specification. > Yes, we must do that, at a bare minimum. > > - Mark From erik.joelsson at oracle.com Tue Apr 4 12:19:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 14:19:17 +0200 Subject: Number of make jobs for bootcycle-images target In-Reply-To: References: Message-ID: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> Hello Alex, It wasn't a typo, but it was also not correct, as you are pointing out. Setting JOBS to $(JOBS) would disable the jobserver for the sub make process and also risk flooding a smaller system. What we really need is a way to block the setting of -j in the "Init.gmk main" target. Something like this seems to work for me: diff -r 7810f75d016a make/Init.gmk --- a/make/Init.gmk +++ b/make/Init.gmk @@ -303,7 +303,8 @@ $(call PrepareSmartJavac) ( cd $(TOPDIR) && \ $(NICE) $(MAKE) $(MAKE_ARGS) $(OUTPUT_SYNC_FLAG) \ - -j $(JOBS) -f make/Main.gmk $(USER_MAKE_VARS) \ + $(if $(DISABLE_JOBS),, -j $(JOBS)) \ + -f make/Main.gmk $(USER_MAKE_VARS) \ $(PARALLEL_TARGETS) $(COMPARE_BUILD_MAKE) $(BUILD_LOG_PIPE) || \ ( exitcode=$$? && \ $(PRINTF) "\nERROR: Build failed for $(TARGET_DESCRIPTION) (exit code $$exitcode) \n" \ diff -r 7810f75d016a make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -320,7 +320,7 @@ ifneq ($(COMPILE_TYPE), cross) $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image) +$(MAKE) $(MAKE_ARGS) -f $(SRC_ROOT)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \ - JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main + DISABLE_JOBS=true SPEC=$(dir $(SPEC))bootcycle-spec.gmk main else $(call LogWarn, Boot cycle build disabled when cross compiling) endif /Erik On 2017-04-04 13:26, Alex Kashchenko wrote: > Hi, > > Currently in jdk9 bootcycle-images make target is executed with > unlimited number of make jobs. May I ask whether "JOBS=" bit here [1] > is intentional or just a typo and should be "JOBS=$(JOBS)" instead? > > Current variant works on x86_64 but crashes with native arm32 boot > cycle builds - compilation tasks are spawned faster than being executed. > > > [1] > http://hg.openjdk.java.net/jdk9/jdk9/file/41d9f0545d53/make/Main.gmk#l323 > From erik.joelsson at oracle.com Tue Apr 4 12:22:46 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 14:22:46 +0200 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <20170403163836.43874389@eggemoggin.niobe.net> Message-ID: Looks good to me. /Erik On 2017-04-04 13:47, Magnus Ihse Bursie wrote: > Here is an updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03 > > The only change compared to the previous webrev is that I have updated > the title for the JDK javadocs so it does not claim to be Java SE. > > I have filed the following follow-up bugs to address Mark's concerns, > and concerns expressed elsewhere: > > * JDK-8178043 Group Java SE, JDK and JavaFX modules in unified javadoc > [1] > * JDK-8178037 Move information from jdi-overview.html into jdk.jdi > module-info.java [2] > * JDK-8178038 Copy jdwp-protocol.html to proper location [3] > * JDK-8178039 Copy jvmti.html to proper location [4] > > I hope JDK-8178043 captures the intent of the solution I understand > that Mark and Jon seemed to agree upon. > > I also refer to the previously existing: > > * JDK-8175824 Provide more flexible means for setting the overview > text in the generated docs [5] > > which I have amended with the task of also making sure that the values > of the title text snippets gets proper values. > > Since a lot of the continued work on Javadoc changes in JDK 9 is > dependent on this change, I hope it is now clear for pushing. > > /Magnus > > [1] https://bugs.openjdk.java.net/browse/JDK-8178043 > [2] https://bugs.openjdk.java.net/browse/JDK-8178037 > [3] https://bugs.openjdk.java.net/browse/JDK-8178038 > [4] https://bugs.openjdk.java.net/browse/JDK-8178039 > [5] https://bugs.openjdk.java.net/browse/JDK-8175824 > > > On 2017-04-04 01:38, mark.reinhold at oracle.com wrote: >> 2017/4/3 3:24:52 -0700, magnus.ihse.bursie at oracle.com: >>> I think the distinction you ask for is already there. The two separate >>> make targets "docs-javadoc" and "docs-reference" builds two distinct >>> images "docs" and "javase-docs", respectively. The first of these >>> builds >>> the complete Java SE + JDK documentation, the second build just the >>> Java >>> SE documentation. >> I'm glad that there's an SE-only target, but that's not what I asked >> for. >> >>> I do not think it's a good idea to go further and actually *remove* the >>> Java SE part from the complete "docs" image. >> That's not what I asked for, either. I suggested making a stronger >> distinction between the specifications of the SE APIs and those of the >> rest of the JDK, by putting the latter in a subdirectory of the same >> image. Sorry if that wasn't clear. >> >>> Upholding such a formal >>> difference between different parts of the JDK is likely to be just >>> confusing to common Java developers. I believe that enforcing such a >>> cut >>> would eliminate much of the work that has been put into giving the the >>> Java developer community a unified access to all releveant >>> documentation. >> I see your point, but failing to make a strong distinction could also >> confuse developers, since it may lead some to use JDK-specific APIs when >> they really want to write code that's portable to any SE implementation. >> >> Still, there may be better ways to make that distinction, as Jon >> suggests >> nearby. >> >>> With that said, we should change the heading so that only the >>> javase-docs image claims to be the SE specification. >> Yes, we must do that, at a bare minimum. >> >> - Mark > From magnus.ihse.bursie at oracle.com Tue Apr 4 12:59:44 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 14:59:44 +0200 Subject: Number of make jobs for bootcycle-images target In-Reply-To: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> References: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> Message-ID: What is the intention here? You want build the second part of the boot cycle build without setting -j? Is this because we already have a good value of -j inherited from an earlier make call? The fix looks scary, but that's maybe because all of this make-wrapping logic is scary. What if you keep sending JOBS= and then check if JOBS has a value in Init.gmk, instead of introducing DISABLE_JOBS? /Magnus On 2017-04-04 14:19, Erik Joelsson wrote: > Hello Alex, > > It wasn't a typo, but it was also not correct, as you are pointing > out. Setting JOBS to $(JOBS) would disable the jobserver for the sub > make process and also risk flooding a smaller system. What we really > need is a way to block the setting of -j in the "Init.gmk main" > target. Something like this seems to work for me: > > > diff -r 7810f75d016a make/Init.gmk > --- a/make/Init.gmk > +++ b/make/Init.gmk > @@ -303,7 +303,8 @@ > $(call PrepareSmartJavac) > ( cd $(TOPDIR) && \ > $(NICE) $(MAKE) $(MAKE_ARGS) $(OUTPUT_SYNC_FLAG) \ > - -j $(JOBS) -f make/Main.gmk $(USER_MAKE_VARS) \ > + $(if $(DISABLE_JOBS),, -j $(JOBS)) \ > + -f make/Main.gmk $(USER_MAKE_VARS) \ > $(PARALLEL_TARGETS) $(COMPARE_BUILD_MAKE) > $(BUILD_LOG_PIPE) || \ > ( exitcode=$$? && \ > $(PRINTF) "\nERROR: Build failed for > $(TARGET_DESCRIPTION) (exit code $$exitcode) \n" \ > diff -r 7810f75d016a make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -320,7 +320,7 @@ > ifneq ($(COMPILE_TYPE), cross) > $(call LogWarn, Boot cycle build step 2: Building a new JDK > image using previously built image) > +$(MAKE) $(MAKE_ARGS) -f $(SRC_ROOT)/make/Init.gmk > PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \ > - JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main > + DISABLE_JOBS=true SPEC=$(dir $(SPEC))bootcycle-spec.gmk main > else > $(call LogWarn, Boot cycle build disabled when cross compiling) > endif > > > /Erik > > On 2017-04-04 13:26, Alex Kashchenko wrote: >> Hi, >> >> Currently in jdk9 bootcycle-images make target is executed with >> unlimited number of make jobs. May I ask whether "JOBS=" bit here [1] >> is intentional or just a typo and should be "JOBS=$(JOBS)" instead? >> >> Current variant works on x86_64 but crashes with native arm32 boot >> cycle builds - compilation tasks are spawned faster than being executed. >> >> >> [1] >> http://hg.openjdk.java.net/jdk9/jdk9/file/41d9f0545d53/make/Main.gmk#l323 >> > From erik.joelsson at oracle.com Tue Apr 4 13:10:58 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Apr 2017 15:10:58 +0200 Subject: Number of make jobs for bootcycle-images target In-Reply-To: References: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> Message-ID: <8d034aa2-3728-edfb-253b-a49cb9d58c94@oracle.com> Hello, On 2017-04-04 14:59, Magnus Ihse Bursie wrote: > What is the intention here? You want build the second part of the boot > cycle build without setting -j? Is this because we already have a good > value of -j inherited from an earlier make call? > We only want to set the -j flag once since resetting it in a sub make call causes us to loose the job server. If there was some other way of detecting that we are in a wrapped call, that would certainly help. > The fix looks scary, but that's maybe because all of this > make-wrapping logic is scary. > > What if you keep sending JOBS= and then check if JOBS has a value in > Init.gmk, instead of introducing DISABLE_JOBS? > I considered that, but then we lose the currently valid empty value for JOBS, which today translates to -j without argument. One could argue that it's rarely a good idea to let make just go crazy with processes though and in that case we can choose to interpret JOBS="" as don't set -j at all. /Erik > /Magnus > > On 2017-04-04 14:19, Erik Joelsson wrote: >> Hello Alex, >> >> It wasn't a typo, but it was also not correct, as you are pointing >> out. Setting JOBS to $(JOBS) would disable the jobserver for the sub >> make process and also risk flooding a smaller system. What we really >> need is a way to block the setting of -j in the "Init.gmk main" >> target. Something like this seems to work for me: >> >> >> diff -r 7810f75d016a make/Init.gmk >> --- a/make/Init.gmk >> +++ b/make/Init.gmk >> @@ -303,7 +303,8 @@ >> $(call PrepareSmartJavac) >> ( cd $(TOPDIR) && \ >> $(NICE) $(MAKE) $(MAKE_ARGS) $(OUTPUT_SYNC_FLAG) \ >> - -j $(JOBS) -f make/Main.gmk $(USER_MAKE_VARS) \ >> + $(if $(DISABLE_JOBS),, -j $(JOBS)) \ >> + -f make/Main.gmk $(USER_MAKE_VARS) \ >> $(PARALLEL_TARGETS) $(COMPARE_BUILD_MAKE) >> $(BUILD_LOG_PIPE) || \ >> ( exitcode=$$? && \ >> $(PRINTF) "\nERROR: Build failed for >> $(TARGET_DESCRIPTION) (exit code $$exitcode) \n" \ >> diff -r 7810f75d016a make/Main.gmk >> --- a/make/Main.gmk >> +++ b/make/Main.gmk >> @@ -320,7 +320,7 @@ >> ifneq ($(COMPILE_TYPE), cross) >> $(call LogWarn, Boot cycle build step 2: Building a new JDK >> image using previously built image) >> +$(MAKE) $(MAKE_ARGS) -f $(SRC_ROOT)/make/Init.gmk >> PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \ >> - JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main >> + DISABLE_JOBS=true SPEC=$(dir $(SPEC))bootcycle-spec.gmk main >> else >> $(call LogWarn, Boot cycle build disabled when cross compiling) >> endif >> >> >> /Erik >> >> On 2017-04-04 13:26, Alex Kashchenko wrote: >>> Hi, >>> >>> Currently in jdk9 bootcycle-images make target is executed with >>> unlimited number of make jobs. May I ask whether "JOBS=" bit here >>> [1] is intentional or just a typo and should be "JOBS=$(JOBS)" instead? >>> >>> Current variant works on x86_64 but crashes with native arm32 boot >>> cycle builds - compilation tasks are spawned faster than being >>> executed. >>> >>> >>> [1] >>> http://hg.openjdk.java.net/jdk9/jdk9/file/41d9f0545d53/make/Main.gmk#l323 >>> >> > From magnus.ihse.bursie at oracle.com Tue Apr 4 13:29:28 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 15:29:28 +0200 Subject: Number of make jobs for bootcycle-images target In-Reply-To: <8d034aa2-3728-edfb-253b-a49cb9d58c94@oracle.com> References: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> <8d034aa2-3728-edfb-253b-a49cb9d58c94@oracle.com> Message-ID: On 2017-04-04 15:10, Erik Joelsson wrote: > Hello, > > > On 2017-04-04 14:59, Magnus Ihse Bursie wrote: >> What is the intention here? You want build the second part of the >> boot cycle build without setting -j? Is this because we already have >> a good value of -j inherited from an earlier make call? >> > We only want to set the -j flag once since resetting it in a sub make > call causes us to loose the job server. If there was some other way of > detecting that we are in a wrapped call, that would certainly help. There are ways of detecting if we're in a recursive call, but they too tend to be scary to check. :) >> The fix looks scary, but that's maybe because all of this >> make-wrapping logic is scary. >> >> What if you keep sending JOBS= and then check if JOBS has a value in >> Init.gmk, instead of introducing DISABLE_JOBS? >> > I considered that, but then we lose the currently valid empty value > for JOBS, which today translates to -j without argument. One could > argue that it's rarely a good idea to let make just go crazy with > processes though and in that case we can choose to interpret JOBS="" > as don't set -j at all. I don't think we've really had that as a supported option, have we? We set JOBS in the spec.gmk based on configure's idea of the ideal number of jobs for the machine. This idea here is to more or less take control from make, which we don't trust to make that decision. So unless the user explicitly sets JOBS= on the command line, this is not a situation that would occur otherwise. I thought we even checked that JOBS had a valid number in it, but I couldn't find such a check now so maybe I just dreamed that one. /Magnus > > /Erik > >> /Magnus >> >> On 2017-04-04 14:19, Erik Joelsson wrote: >>> Hello Alex, >>> >>> It wasn't a typo, but it was also not correct, as you are pointing >>> out. Setting JOBS to $(JOBS) would disable the jobserver for the sub >>> make process and also risk flooding a smaller system. What we really >>> need is a way to block the setting of -j in the "Init.gmk main" >>> target. Something like this seems to work for me: >>> >>> >>> diff -r 7810f75d016a make/Init.gmk >>> --- a/make/Init.gmk >>> +++ b/make/Init.gmk >>> @@ -303,7 +303,8 @@ >>> $(call PrepareSmartJavac) >>> ( cd $(TOPDIR) && \ >>> $(NICE) $(MAKE) $(MAKE_ARGS) $(OUTPUT_SYNC_FLAG) \ >>> - -j $(JOBS) -f make/Main.gmk $(USER_MAKE_VARS) \ >>> + $(if $(DISABLE_JOBS),, -j $(JOBS)) \ >>> + -f make/Main.gmk $(USER_MAKE_VARS) \ >>> $(PARALLEL_TARGETS) $(COMPARE_BUILD_MAKE) >>> $(BUILD_LOG_PIPE) || \ >>> ( exitcode=$$? && \ >>> $(PRINTF) "\nERROR: Build failed for >>> $(TARGET_DESCRIPTION) (exit code $$exitcode) \n" \ >>> diff -r 7810f75d016a make/Main.gmk >>> --- a/make/Main.gmk >>> +++ b/make/Main.gmk >>> @@ -320,7 +320,7 @@ >>> ifneq ($(COMPILE_TYPE), cross) >>> $(call LogWarn, Boot cycle build step 2: Building a new JDK >>> image using previously built image) >>> +$(MAKE) $(MAKE_ARGS) -f $(SRC_ROOT)/make/Init.gmk >>> PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \ >>> - JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main >>> + DISABLE_JOBS=true SPEC=$(dir $(SPEC))bootcycle-spec.gmk main >>> else >>> $(call LogWarn, Boot cycle build disabled when cross compiling) >>> endif >>> >>> >>> /Erik >>> >>> On 2017-04-04 13:26, Alex Kashchenko wrote: >>>> Hi, >>>> >>>> Currently in jdk9 bootcycle-images make target is executed with >>>> unlimited number of make jobs. May I ask whether "JOBS=" bit here >>>> [1] is intentional or just a typo and should be "JOBS=$(JOBS)" >>>> instead? >>>> >>>> Current variant works on x86_64 but crashes with native arm32 boot >>>> cycle builds - compilation tasks are spawned faster than being >>>> executed. >>>> >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/jdk9/file/41d9f0545d53/make/Main.gmk#l323 >>>> >>> >> > From mark.reinhold at oracle.com Tue Apr 4 15:12:15 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 08:12:15 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> Message-ID: <20170404081215.364493885@eggemoggin.niobe.net> 2017/4/4 1:04:22 -0700, magnus.ihse.bursie at oracle.com: > On 2017-04-03 23:50, Mandy Chung wrote: >> ... >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 > > If we are making changes to the original proposal from JDK-8175819, then > I just want to add my few cents: > > Why change from the well-established "aarch64" to the virtually unused > "arm64"? As far as I know, using the name "arm64" for the aarch64 > platform is something that has only been done in the (recently opened) > closed Oracle port. This change, however, proposes to change the value > in the release file even for the open aarch64 port, which has always > been known by that name. The trouble here is that "arm64" and "aarch64" are effectively synonyms for the ISA, but in the JDK we've wound up using them as the names of two different ports. A JMOD file built for the 64-bit ARM architecture will (one hopes) run equally well on either port. Which name should we use in JMOD files, "arm64" or "aarch64"? My sense is that "arm64" is more immediately understood by developers at large even if "aarch64" is more correct in the eyes of ARM Holdings plc, but I could be wrong. For what it's worth, the Linux distros aren't consistent: Debian-based distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". - Mark From mark.reinhold at oracle.com Tue Apr 4 15:19:30 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 08:19:30 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <20170403163836.43874389@eggemoggin.niobe.net> Message-ID: <20170404081930.338491073@eggemoggin.niobe.net> 2017/4/4 4:47:58 -0700, magnus.ihse.bursie at oracle.com: > Here is an updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03 > > The only change compared to the previous webrev is that I have updated > the title for the JDK javadocs so it does not claim to be Java SE. > > I have filed the following follow-up bugs to address Mark's concerns, > and concerns expressed elsewhere: > > * JDK-8178043 Group Java SE, JDK and JavaFX modules in unified javadoc [1] > * JDK-8178037 Move information from jdi-overview.html into jdk.jdi > module-info.java [2] > * JDK-8178038 Copy jdwp-protocol.html to proper location [3] > * JDK-8178039 Copy jvmti.html to proper location [4] > > I hope JDK-8178043 captures the intent of the solution I understand that > Mark and Jon seemed to agree upon. Yes, I think it does. Thanks for filing it. - Mark From aph at redhat.com Tue Apr 4 15:22:50 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Apr 2017 16:22:50 +0100 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404081215.364493885@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: On 04/04/17 16:12, mark.reinhold at oracle.com wrote: > The trouble here is that "arm64" and "aarch64" are effectively synonyms > for the ISA, but in the JDK we've wound up using them as the names of > two different ports. > > A JMOD file built for the 64-bit ARM architecture will (one hopes) run > equally well on either port. Which name should we use in JMOD files, > "arm64" or "aarch64"? My sense is that "arm64" is more immediately > understood by developers at large even if "aarch64" is more correct > in the eyes of ARM Holdings plc, but I could be wrong. I think that you are wrong. > For what it's worth, the Linux distros aren't consistent: Debian-based > distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". The name of the processor architecture is "AArch64". The name of the Linux kernel architecture is "arm64"; the name of all of userspace is "aarch64", on all distros. The kernel is out of step here, for no better reason than Linus Torvalds didn't like "aarch64". Andrew. From bob.vandette at oracle.com Tue Apr 4 16:03:41 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 4 Apr 2017 12:03:41 -0400 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404081215.364493885@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: > On Apr 4, 2017, at 11:12 AM, mark.reinhold at oracle.com wrote: > > 2017/4/4 1:04:22 -0700, magnus.ihse.bursie at oracle.com: >> On 2017-04-03 23:50, Mandy Chung wrote: >>> ... >>> >>> JDK 8 JDK 9 >>> ----- ----- >>> OS_NAME Linux linux >>> SunOS solaris >>> Darwin macos >>> Windows windows >>> >>> OS_ARCH i386,x86 x86 >>> i586,amd64,x86_64 amd64 >>> sparcv9 sparcv9 >>> arm arm32 >>> aarch64 arm64 >> >> If we are making changes to the original proposal from JDK-8175819, then >> I just want to add my few cents: >> >> Why change from the well-established "aarch64" to the virtually unused >> "arm64"? As far as I know, using the name "arm64" for the aarch64 >> platform is something that has only been done in the (recently opened) >> closed Oracle port. This change, however, proposes to change the value >> in the release file even for the open aarch64 port, which has always >> been known by that name. > > The trouble here is that "arm64" and "aarch64" are effectively synonyms > for the ISA, but in the JDK we've wound up using them as the names of > two different ports. Well sort of ? We are only using arm64 as a configure option to enable building the unified ARM32/64 port and a label in Jira to identify which port a bug or RFE is related to. Both 64-bit ARM ports have been using aarch64 for the os.name property since day one and I think we should stick to this name in the release file to avoid any confusion. Bob. > > A JMOD file built for the 64-bit ARM architecture will (one hopes) run > equally well on either port. Which name should we use in JMOD files, > "arm64" or "aarch64"? My sense is that "arm64" is more immediately > understood by developers at large even if "aarch64" is more correct > in the eyes of ARM Holdings plc, but I could be wrong. > > For what it's worth, the Linux distros aren't consistent: Debian-based > distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". > > - Mark From mark.reinhold at oracle.com Tue Apr 4 16:35:57 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 09:35:57 -0700 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> Message-ID: <20170404093557.376393610@eggemoggin.niobe.net> 2017/4/4 8:22:50 -0700, aph at redhat.com: > On 04/04/17 16:12, mark.reinhold at oracle.com wrote: >> The trouble here is that "arm64" and "aarch64" are effectively synonyms >> for the ISA, but in the JDK we've wound up using them as the names of >> two different ports. >> >> A JMOD file built for the 64-bit ARM architecture will (one hopes) run >> equally well on either port. Which name should we use in JMOD files, >> "arm64" or "aarch64"? My sense is that "arm64" is more immediately >> understood by developers at large even if "aarch64" is more correct >> in the eyes of ARM Holdings plc, but I could be wrong. > > I think that you are wrong. > >> For what it's worth, the Linux distros aren't consistent: Debian-based >> distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". > > The name of the processor architecture is "AArch64". The name of the > Linux kernel architecture is "arm64"; the name of all of userspace is > "aarch64", on all distros. The kernel is out of step here, for no > better reason than Linus Torvalds didn't like "aarch64". Thanks for the background -- I wasn't aware of that. Given that "os.arch" is "aarch64" for both ports, as Bob points out, then we should use "aarch64" in JMOD files as well. This does raise another question, though: Should we use "aarch32" instead of "arm32" for the 32-bit ARM architecture? - Mark From aph at redhat.com Tue Apr 4 16:39:17 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Apr 2017 17:39:17 +0100 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404093557.376393610@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> <20170404093557.376393610@eggemoggin.niobe.net> Message-ID: <921dba93-4497-55b4-3ac4-dd3c6c559deb@redhat.com> On 04/04/17 17:35, mark.reinhold at oracle.com wrote: > This does raise another question, though: Should we use "aarch32" > instead of "arm32" for the 32-bit ARM architecture? Probably not. I believe that "aarch32" is historical revisionism coming from ARM: it didn't exist as a name before AArch64 came out. AFAICR... Andrew. From bob.vandette at oracle.com Tue Apr 4 16:47:50 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 4 Apr 2017 12:47:50 -0400 Subject: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <20170404093557.376393610@eggemoggin.niobe.net> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <20170404081215.364493885@eggemoggin.niobe.net> <20170404093557.376393610@eggemoggin.niobe.net> Message-ID: <963C74B3-377C-40C4-8D0A-73CF506D035C@oracle.com> > On Apr 4, 2017, at 12:35 PM, mark.reinhold at oracle.com wrote: > > 2017/4/4 8:22:50 -0700, aph at redhat.com: >> On 04/04/17 16:12, mark.reinhold at oracle.com wrote: >>> The trouble here is that "arm64" and "aarch64" are effectively synonyms >>> for the ISA, but in the JDK we've wound up using them as the names of >>> two different ports. >>> >>> A JMOD file built for the 64-bit ARM architecture will (one hopes) run >>> equally well on either port. Which name should we use in JMOD files, >>> "arm64" or "aarch64"? My sense is that "arm64" is more immediately >>> understood by developers at large even if "aarch64" is more correct >>> in the eyes of ARM Holdings plc, but I could be wrong. >> >> I think that you are wrong. >> >>> For what it's worth, the Linux distros aren't consistent: Debian-based >>> distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64". >> >> The name of the processor architecture is "AArch64". The name of the >> Linux kernel architecture is "arm64"; the name of all of userspace is >> "aarch64", on all distros. The kernel is out of step here, for no >> better reason than Linus Torvalds didn't like "aarch64". > > Thanks for the background -- I wasn't aware of that. > > Given that "os.arch" is "aarch64" for both ports, as Bob points out, > then we should use "aarch64" in JMOD files as well. > > This does raise another question, though: Should we use "aarch32" > instead of "arm32" for the 32-bit ARM architecture? 32 bit ARM is a bit more challenging since OS vendors sometime encode the architecture version (armv5, armv6, armv7) and endianess into the uname -p output. aarch32 has special meaning (it?s the arch for running 32-bit arm instructions on an armv8 processor.) and I haven?t seen any use of arm32. I suggest we stick with arm. Bob. > > - Mark From jonathan.gibbons at oracle.com Tue Apr 4 19:28:18 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 Apr 2017 12:28:18 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <20170403163836.43874389@eggemoggin.niobe.net> Message-ID: <58E3F3D2.4010407@oracle.com> Magnus, Mark, Don't we need the JEP to be moved from "Proposed To Target" to "Targetted" before we can push? -- Jon On 04/04/2017 04:47 AM, Magnus Ihse Bursie wrote: > Here is an updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03 > > The only change compared to the previous webrev is that I have updated > the title for the JDK javadocs so it does not claim to be Java SE. > > I have filed the following follow-up bugs to address Mark's concerns, > and concerns expressed elsewhere: > > * JDK-8178043 Group Java SE, JDK and JavaFX modules in unified javadoc > [1] > * JDK-8178037 Move information from jdi-overview.html into jdk.jdi > module-info.java [2] > * JDK-8178038 Copy jdwp-protocol.html to proper location [3] > * JDK-8178039 Copy jvmti.html to proper location [4] > > I hope JDK-8178043 captures the intent of the solution I understand > that Mark and Jon seemed to agree upon. > > I also refer to the previously existing: > > * JDK-8175824 Provide more flexible means for setting the overview > text in the generated docs [5] > > which I have amended with the task of also making sure that the values > of the title text snippets gets proper values. > > Since a lot of the continued work on Javadoc changes in JDK 9 is > dependent on this change, I hope it is now clear for pushing. > > /Magnus > > [1] https://bugs.openjdk.java.net/browse/JDK-8178043 > [2] https://bugs.openjdk.java.net/browse/JDK-8178037 > [3] https://bugs.openjdk.java.net/browse/JDK-8178038 > [4] https://bugs.openjdk.java.net/browse/JDK-8178039 > [5] https://bugs.openjdk.java.net/browse/JDK-8175824 > > > On 2017-04-04 01:38, mark.reinhold at oracle.com wrote: >> 2017/4/3 3:24:52 -0700, magnus.ihse.bursie at oracle.com: >>> I think the distinction you ask for is already there. The two separate >>> make targets "docs-javadoc" and "docs-reference" builds two distinct >>> images "docs" and "javase-docs", respectively. The first of these >>> builds >>> the complete Java SE + JDK documentation, the second build just the >>> Java >>> SE documentation. >> I'm glad that there's an SE-only target, but that's not what I asked >> for. >> >>> I do not think it's a good idea to go further and actually *remove* the >>> Java SE part from the complete "docs" image. >> That's not what I asked for, either. I suggested making a stronger >> distinction between the specifications of the SE APIs and those of the >> rest of the JDK, by putting the latter in a subdirectory of the same >> image. Sorry if that wasn't clear. >> >>> Upholding such a formal >>> difference between different parts of the JDK is likely to be just >>> confusing to common Java developers. I believe that enforcing such a >>> cut >>> would eliminate much of the work that has been put into giving the the >>> Java developer community a unified access to all releveant >>> documentation. >> I see your point, but failing to make a strong distinction could also >> confuse developers, since it may lead some to use JDK-specific APIs when >> they really want to write code that's portable to any SE implementation. >> >> Still, there may be better ways to make that distinction, as Jon >> suggests >> nearby. >> >>> With that said, we should change the heading so that only the >>> javase-docs image claims to be the SE specification. >> Yes, we must do that, at a bare minimum. >> >> - Mark > From magnus.ihse.bursie at oracle.com Tue Apr 4 20:30:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Apr 2017 22:30:37 +0200 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <58E3F3D2.4010407@oracle.com> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <20170403163836.43874389@eggemoggin.niobe.net> <58E3F3D2.4010407@oracle.com> Message-ID: On 2017-04-04 21:28, Jonathan Gibbons wrote: > Magnus, Mark, > > Don't we need the JEP to be moved from "Proposed To Target" to > "Targetted" before we can push? I would have assumed that since the patch itself has been code reviewed, and follows the "noreg-doc" rule, it would be fair game to push, regardless of it's relation to a JEP (that covers many other documentation issues). But then again, I'm no expert in these procedural questions. /Magnus > > -- Jon > > On 04/04/2017 04:47 AM, Magnus Ihse Bursie wrote: >> Here is an updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03 >> >> The only change compared to the previous webrev is that I have >> updated the title for the JDK javadocs so it does not claim to be >> Java SE. >> >> I have filed the following follow-up bugs to address Mark's concerns, >> and concerns expressed elsewhere: >> >> * JDK-8178043 Group Java SE, JDK and JavaFX modules in unified >> javadoc [1] >> * JDK-8178037 Move information from jdi-overview.html into jdk.jdi >> module-info.java [2] >> * JDK-8178038 Copy jdwp-protocol.html to proper location [3] >> * JDK-8178039 Copy jvmti.html to proper location [4] >> >> I hope JDK-8178043 captures the intent of the solution I understand >> that Mark and Jon seemed to agree upon. >> >> I also refer to the previously existing: >> >> * JDK-8175824 Provide more flexible means for setting the overview >> text in the generated docs [5] >> >> which I have amended with the task of also making sure that the >> values of the title text snippets gets proper values. >> >> Since a lot of the continued work on Javadoc changes in JDK 9 is >> dependent on this change, I hope it is now clear for pushing. >> >> /Magnus >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8178043 >> [2] https://bugs.openjdk.java.net/browse/JDK-8178037 >> [3] https://bugs.openjdk.java.net/browse/JDK-8178038 >> [4] https://bugs.openjdk.java.net/browse/JDK-8178039 >> [5] https://bugs.openjdk.java.net/browse/JDK-8175824 >> >> >> On 2017-04-04 01:38, mark.reinhold at oracle.com wrote: >>> 2017/4/3 3:24:52 -0700, magnus.ihse.bursie at oracle.com: >>>> I think the distinction you ask for is already there. The two separate >>>> make targets "docs-javadoc" and "docs-reference" builds two distinct >>>> images "docs" and "javase-docs", respectively. The first of these >>>> builds >>>> the complete Java SE + JDK documentation, the second build just the >>>> Java >>>> SE documentation. >>> I'm glad that there's an SE-only target, but that's not what I asked >>> for. >>> >>>> I do not think it's a good idea to go further and actually *remove* >>>> the >>>> Java SE part from the complete "docs" image. >>> That's not what I asked for, either. I suggested making a stronger >>> distinction between the specifications of the SE APIs and those of the >>> rest of the JDK, by putting the latter in a subdirectory of the same >>> image. Sorry if that wasn't clear. >>> >>>> Upholding such a formal >>>> difference between different parts of the JDK is likely to be just >>>> confusing to common Java developers. I believe that enforcing such >>>> a cut >>>> would eliminate much of the work that has been put into giving the the >>>> Java developer community a unified access to all releveant >>>> documentation. >>> I see your point, but failing to make a strong distinction could also >>> confuse developers, since it may lead some to use JDK-specific APIs >>> when >>> they really want to write code that's portable to any SE >>> implementation. >>> >>> Still, there may be better ways to make that distinction, as Jon >>> suggests >>> nearby. >>> >>>> With that said, we should change the heading so that only the >>>> javase-docs image claims to be the SE specification. >>> Yes, we must do that, at a bare minimum. >>> >>> - Mark >> > From mark.reinhold at oracle.com Tue Apr 4 20:50:13 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Apr 2017 13:50:13 -0700 Subject: RFR: JDK-8172312 Update docs target and image for new combined docs In-Reply-To: <58E3F3D2.4010407@oracle.com> References: <20170401112550.898587932@eggemoggin.niobe.net> <20c73e0e-ab82-2255-2554-20a9f9007403@oracle.com> <20170403163836.43874389@eggemoggin.niobe.net> <58E3F3D2.4010407@oracle.com> Message-ID: <20170404135013.152567411@eggemoggin.niobe.net> 2017/4/4 12:28:18 -0700, jonathan.gibbons at oracle.com: > Don't we need the JEP to be moved from "Proposed To Target" to > "Targetted" before we can push? Yep. Coming right up ... - Mark From mandy.chung at oracle.com Tue Apr 4 21:13:42 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Apr 2017 14:13:42 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: Message-ID: <2DD2517B-4D06-4C29-8EE6-734225507A2D@oracle.com> > On Apr 4, 2017, at 12:42 AM, Alan Bateman wrote: > > On 03/04/2017 19:41, Mandy Chung wrote: > >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> > I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails. > It?s already aligned. I updated webrev.00 in place yesterday. Maybe you need to reload it if you happened opening the old version. > In DefaultImageBuilder.storeFiles then map(ResourcePoolModule::osName).orElse(null) would be cleaner. > OK. > I'm sure Volker or someone maintaining the AIX port will ask for jdk.tools.jlink.internal.Platform to be extended to handle that platform. I was wondering if Volker would ask that. Anyway, I have added Platform::AIX constant. Will send out a new webrev. Mandy From akashche at redhat.com Wed Apr 5 09:44:53 2017 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 5 Apr 2017 10:44:53 +0100 Subject: Number of make jobs for bootcycle-images target In-Reply-To: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> References: <3c34b87d-dad2-47b5-0be3-d331e6e5ce01@oracle.com> Message-ID: <135cfa67-0af1-3857-2ffc-7cf8f195360f@redhat.com> On 04/04/2017 01:19 PM, Erik Joelsson wrote: > Hello Alex, > > It wasn't a typo, but it was also not correct, as you are pointing out. > Setting JOBS to $(JOBS) would disable the jobserver for the sub make > process and also risk flooding a smaller system. What we really need is > a way to block the setting of -j in the "Init.gmk main" target. > Something like this seems to work for me: > > [...] Thanks! This patch worked for me with bootcycle builds on arm32 and other archs. -- -Alex From magnus.ihse.bursie at oracle.com Thu Apr 6 08:09:20 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Apr 2017 10:09:20 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> Message-ID: <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> On 2017-04-04 10:04, Magnus Ihse Bursie wrote: > > On 2017-04-03 23:50, Mandy Chung wrote: >>> On Apr 3, 2017, at 2:39 PM, mark.reinhold at oracle.com wrote: >>> >>> 2017/4/3 13:35:30 -0700, simon at cjnash.com: >>>> On 03/04/2017 21:15, mark.reinhold at oracle.com wrote: >>>>> 2017/4/3 11:41:03 -0700, mandy.chung at oracle.com: >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >>>>>> >>>>>> ... >>>>>> >>>>>> This shows the old and new value of OS_NAME/OS_ARCH properties >>>>>> in the `release` file: >>>>>> >>>>>> JDK 8 JDK 9 >>>>>> ----- ----- >>>>>> OS_NAME Linux linux >>>>>> SunOS solaris >>>>>> Darwin osx >>>>>> Windows windows >>>>>> >>>>>> OS_ARCH i386,x86 x86 >>>>>> i586,amd64,x86_64 x64 >>>>>> sparcv9 sparcv9 >>>>>> arm arm32 >>>>>> aarch64 arm64 >>>> I am not sure why we would change to osx for Mac when the Mac >>>> developers >>>> have recently dropped the Mac OS X terminology and changed it to >>>> macOS. >>> Agreed -- we should change OS_NAME from "Darwin" to "macos?. >> OK. Should the bundle names be updated to reflect this change? >> In any case, it is a separate issue. >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 >> sparcv9 sparcv9 >> arm arm32 >> aarch64 arm64 Having though this over real hard, I'd realized I need to make a plea for sanity and consistency. I thought I should lay low in this discussion, but I can't. Choosing "amd64" as the name for the 64-bit x86 platform is really, really unfortunate and a step backwards in our effort to standardize the name of this platform. We have continuously worked on trying to get "x64" the all-around standard name for this platform. Since we dropped the path "lib/amd64", I believe more or less the only place left that still has "amd64" is os.arch, which is not easy to change due to legacy reasons (although I'd really like to see that changed too, considering that it already is different on different operating systems...) I'd really hate for us to suddenly start introducing changes that once again divert us away. :-( It's hard enough as it is with all this converting of names. Let us not add yet another odd place! /Magnus > If we are making changes to the original proposal from JDK-8175819, > then I just want to add my few cents: > > Why change from the well-established "aarch64" to the virtually unused > "arm64"? As far as I know, using the name "arm64" for the aarch64 > platform is something that has only been done in the (recently opened) > closed Oracle port. This change, however, proposes to change the value > in the release file even for the open aarch64 port, which has always > been known by that name. > > /Magnus > >> >> Mandy >> > From magnus.ihse.bursie at oracle.com Fri Apr 7 08:40:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 7 Apr 2017 10:40:23 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file Message-ID: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> This bug is the continuation of JDK-8173303, in which Mandy added the generation of .dot files for @moduleGraph Javadoc tags. With this patch, the code is taken to it's completion, and the temporarily solutions left in place by JDK-8173303 has been replaced by properly integrated solutions. Summary of changes: * A new option --enable-full-docs determines if module graphs should be created or not. (In the future, even more optional but "difficult" documentation work might be added to depend on this.) This is enabled by default is all prerequisites are present. * It is not impossible to get to a state of the documentation with broken img links. * I have re-introduced SetupJavadocGeneration to stop the code duplication between JDK and Java SE javadoc builds. * I have fixed a bug in how the makefiles determines the dependencies of modules. This only affected a single module in nashorn, and no nashorn build code used these dependencies, so that's why it has gone unnoticed until now. I have verified that no other changes in module dependencies are introduced by this fix. * Javadoc source code dependencies are now correct even for transitive modules * Support added for the creation and use in jib of a "graphviz" module. This code is dependent on JDK-8172312. This webrev is done as a diff against the latest published webrev of JDK-8172312. JDK-8172312 is reviewed, but is currently awaiting the status for JEP 299 to be changed to Targeted before it can be pushed. This code only affects the build system and documentation. I intend to push it to jdk9 using the "noreg-doc" RDP2 exception. Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 From erik.joelsson at oracle.com Fri Apr 7 11:02:08 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 7 Apr 2017 13:02:08 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> Message-ID: <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> Hello, This looks good in general. One thing I don't like about this is that if full docs is enabled, the docs-javadoc target now requires the full exploded image to be built first. I think that's unfortunate. Would it be possible to introduce separate targets for the gengraphs parts so that the main javadoc call can be run independently of most of the rest of the build, using the existing docs-javadoc target (and the newer docs-reference, even though I think that name is bit strange in this context)? /Erik On 2017-04-07 10:40, Magnus Ihse Bursie wrote: > This bug is the continuation of JDK-8173303, in which Mandy added the > generation of .dot files for @moduleGraph Javadoc tags. > > With this patch, the code is taken to it's completion, and the > temporarily solutions left in place by JDK-8173303 has been replaced > by properly integrated solutions. > > Summary of changes: > * A new option --enable-full-docs determines if module graphs should > be created or not. (In the future, even more optional but "difficult" > documentation work might be added to depend on this.) This is enabled > by default is all prerequisites are present. > * It is not impossible to get to a state of the documentation with > broken img links. > * I have re-introduced SetupJavadocGeneration to stop the code > duplication between JDK and Java SE javadoc builds. > * I have fixed a bug in how the makefiles determines the dependencies > of modules. This only affected a single module in nashorn, and no > nashorn build code used these dependencies, so that's why it has gone > unnoticed until now. I have verified that no other changes in module > dependencies are introduced by this fix. > * Javadoc source code dependencies are now correct even for transitive > modules > * Support added for the creation and use in jib of a "graphviz" module. > > This code is dependent on JDK-8172312. This webrev is done as a diff > against the latest published webrev of JDK-8172312. JDK-8172312 is > reviewed, but is currently awaiting the status for JEP 299 to be > changed to Targeted before it can be pushed. > > This code only affects the build system and documentation. I intend to > push it to jdk9 using the "noreg-doc" RDP2 exception. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 > From mandy.chung at oracle.com Fri Apr 7 20:04:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 7 Apr 2017 13:04:40 -0700 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> Message-ID: <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> > On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie wrote: > > > Having though this over real hard, I'd realized I need to make a plea for sanity and consistency. I thought I should lay low in this discussion, but I can't. Choosing "amd64" as the name for the 64-bit x86 platform is really, really unfortunate and a step backwards in our effort to standardize the name of this platform. > I think it may be useful to see the value of `os.arch` system property on all platforms at a glance. 32-bit 64-bit linux i386 amd64 arm aarch64 solaris amd64 sparcv9 windows x86 amd64 macos x86_64 It's late in JDK 9. The best is to revisit OS and architecture names in JDK 10 on the consistency and simplicity issue. In the context of JDK-8175819, these are names to pass to jmod ?-os-name ?-os-arch options. The values are used at resolution time to avoid linking modules for different target platforms into the same image. As Mark suggests, we use the value of `os.arch` system property for JMOD file in JDK 9 and we can change the value in JDK 10. No change to system property and bundle names, as we said previously. We should revisit OS and architecture names in JDK 10. I have updated JDK-8178016 to reflect that. Are you okay with that? Below shows the old and new values in the `release` file and the new values are used in JMOD files. JDK 8 JDK 9 ----- ----- OS_NAME Linux linux SunOS solaris Darwin macos Windows windows OS_ARCH i386,x86 x86 i586,amd64,x86_64 amd64 sparcv9 sparcv9 arm arm aarch64 aarch64 Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html Mandy From alexandre.iline at oracle.com Fri Apr 7 21:05:22 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 7 Apr 2017 14:05:22 -0700 Subject: RFR: 8173801 Remove non-client demos and samples In-Reply-To: <2026f5d2-fe72-f230-8e78-47559ffb64a4@oracle.com> References: <07B67AD3-8B22-4FA1-9581-FA15A05C5D66@oracle.com> <2026f5d2-fe72-f230-8e78-47559ffb64a4@oracle.com> Message-ID: <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> After some back and forth it was decided that the client demos should stay intact for JDK9 and be reworked into tests as a part of another JEP. With that, could you take another look on the suggested changes? http://cr.openjdk.java.net/~shurailine/8173801/webrev.03 Thank you. Shura > On Mar 3, 2017, at 9:39 AM, Phil Race wrote: > > What is the plan for ensuring there is still a way to build the client demos - which are not being removed > but just moved. Doesn't this makefile need to be somewhere still ? > > -phil. > > On 3/3/2017 12:18 AM, Magnus Ihse Bursie wrote: >> On 2017-03-02 20:33, Alexandre (Shura) Iline wrote: >>> Hi, >>> >>> Could you be so kind to review suggested changes for the makefiles to stop producing sales and demos bundle. Pls note that this request only changes the makefiles, it does not remove demos and samples source code, which will be done separately. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173801 >>> Webrev: http://cr.openjdk.java.net/~shurailine/8173801/webrev.02/ >>> >>> Shura >> Looks good to me. >> >> Good riddance! :-) >> >> /Magnus >> > From philip.race at oracle.com Fri Apr 7 21:18:13 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 7 Apr 2017 14:18:13 -0700 Subject: RFR: 8173801 Remove non-client demos and samples In-Reply-To: <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> References: <07B67AD3-8B22-4FA1-9581-FA15A05C5D66@oracle.com> <2026f5d2-fe72-f230-8e78-47559ffb64a4@oracle.com> <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> Message-ID: <4df61e7e-0493-2cf4-53e6-a252c19cc06e@oracle.com> All the parts of that which I understand look fine to me. The netbeans XML I know nothing about .. -phil. On 4/7/2017 2:05 PM, Alexandre (Shura) Iline wrote: > After some back and forth it was decided that the client demos should stay intact for JDK9 and be reworked into tests as a part of another JEP. > > With that, could you take another look on the suggested changes? > http://cr.openjdk.java.net/~shurailine/8173801/webrev.03 > > Thank you. > > Shura > > >> On Mar 3, 2017, at 9:39 AM, Phil Race wrote: >> >> What is the plan for ensuring there is still a way to build the client demos - which are not being removed >> but just moved. Doesn't this makefile need to be somewhere still ? >> >> -phil. >> >> On 3/3/2017 12:18 AM, Magnus Ihse Bursie wrote: >>> On 2017-03-02 20:33, Alexandre (Shura) Iline wrote: >>>> Hi, >>>> >>>> Could you be so kind to review suggested changes for the makefiles to stop producing sales and demos bundle. Pls note that this request only changes the makefiles, it does not remove demos and samples source code, which will be done separately. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173801 >>>> Webrev: http://cr.openjdk.java.net/~shurailine/8173801/webrev.02/ >>>> >>>> Shura >>> Looks good to me. >>> >>> Good riddance! :-) >>> >>> /Magnus >>> From mandy.chung at oracle.com Fri Apr 7 22:14:57 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 7 Apr 2017 15:14:57 -0700 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> Message-ID: <5277C555-F271-4709-A628-F2A2CB27C664@oracle.com> > On Apr 7, 2017, at 4:02 AM, Erik Joelsson wrote: > > Hello, > > This looks good in general. One thing I don't like about this is that if full docs is enabled, the docs-javadoc target now requires the full exploded image to be built first. I think that's unfortunate. Would it be possible to introduce separate targets for the gengraphs parts so that the main javadoc call can be run independently of most of the rest of the build, using the existing docs-javadoc target (and the newer docs-reference, even though I think that name is bit strange in this context)? > I agree with Erik that it?d be nice to separate the module graph generation and enable it to run with javadoc generation in parallel. That?s one reason why docs-module-graphs was a separate target (I have no issue to take that target out from Main.gmk). > On 2017-04-07 10:40, Magnus Ihse Bursie wrote: >> >> Summary of changes: >> * A new option --enable-full-docs determines if module graphs should be created or not. (In the future, even more optional but "difficult" documentation work might be added to depend on this.) This is enabled by default is all prerequisites are present. It might be okay to call this ?full docs? when it includes the module graphs but I am not sure about the new option name. Can I build OpenJDK with the docs with module graphs when I have Graphviz installed? I would think we need a configure option to specify my local path to `dot` that will enable the module graph build. Is it possible? >> >> This code only affects the build system and documentation. I intend to push it to jdk9 using the "noreg-doc" RDP2 exception. >> Yes this is makefile and docs-only change. In addition, FC extension request for JDK-8173303 covers this issue [1]. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 >> common/autoconf/jdk-options.m4 172 if test "x$DTRACE_DEP_MISSING" = "xtrue"; then What is DTRACE_DEP_MISSING? 158 # gengraphs tool. 167 # generated by the gengraphs tool and store it in the target dir. Nit: I prefer to name the tool as `GenGraphs` rather than gengraphs. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8173303?focusedCommentId=14064511&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14064511 From erik.joelsson at oracle.com Mon Apr 10 07:07:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Apr 2017 09:07:17 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <5277C555-F271-4709-A628-F2A2CB27C664@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> <5277C555-F271-4709-A628-F2A2CB27C664@oracle.com> Message-ID: <717c1dab-71a4-7ef4-fe9f-4de066a580b1@oracle.com> On 2017-04-08 00:14, Mandy Chung wrote: > Can I build OpenJDK with the docs with module graphs when I > have Graphviz installed? I would think we need a configure > option to specify my local path to `dot` that will enable > the module graph build. Is it possible? Yes, it is possible. Configure will look for dot on the path by default and if found, "full docs" will be enabled implicitly. For such a simple dependency as this, basically we just need the path to an executable, we don't need to define actual configure arguments. You can simply override the value on the command line like this: bash configure DOT=/path/to/dot /Erik From erik.joelsson at oracle.com Mon Apr 10 07:51:41 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Apr 2017 09:51:41 +0200 Subject: RFR: 8173801 Remove non-client demos and samples In-Reply-To: <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> References: <07B67AD3-8B22-4FA1-9581-FA15A05C5D66@oracle.com> <2026f5d2-fe72-f230-8e78-47559ffb64a4@oracle.com> <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> Message-ID: <3bf8b149-c0bf-633e-7491-4836f82b3c82@oracle.com> Hello, CompileDemos.gmk: 270: The $(call install-file) line shouldn't be removed make/Bundles.gmk: 186: Since the client demos are still in there, they still need to be filtered out of the image when creating the JDK bundle. Otherwise this looks ok. /Erik On 2017-04-07 23:05, Alexandre (Shura) Iline wrote: > After some back and forth it was decided that the client demos should stay intact for JDK9 and be reworked into tests as a part of another JEP. > > With that, could you take another look on the suggested changes? > http://cr.openjdk.java.net/~shurailine/8173801/webrev.03 > > Thank you. > > Shura > > >> On Mar 3, 2017, at 9:39 AM, Phil Race wrote: >> >> What is the plan for ensuring there is still a way to build the client demos - which are not being removed >> but just moved. Doesn't this makefile need to be somewhere still ? >> >> -phil. >> >> On 3/3/2017 12:18 AM, Magnus Ihse Bursie wrote: >>> On 2017-03-02 20:33, Alexandre (Shura) Iline wrote: >>>> Hi, >>>> >>>> Could you be so kind to review suggested changes for the makefiles to stop producing sales and demos bundle. Pls note that this request only changes the makefiles, it does not remove demos and samples source code, which will be done separately. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173801 >>>> Webrev: http://cr.openjdk.java.net/~shurailine/8173801/webrev.02/ >>>> >>>> Shura >>> Looks good to me. >>> >>> Good riddance! :-) >>> >>> /Magnus >>> From mandy.chung at oracle.com Mon Apr 10 15:02:57 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Apr 2017 08:02:57 -0700 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <717c1dab-71a4-7ef4-fe9f-4de066a580b1@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> <5277C555-F271-4709-A628-F2A2CB27C664@oracle.com> <717c1dab-71a4-7ef4-fe9f-4de066a580b1@oracle.com> Message-ID: <9E07607B-7CBC-4F71-9F36-0D041FCC37AF@oracle.com> > On Apr 10, 2017, at 12:07 AM, Erik Joelsson wrote: > > > On 2017-04-08 00:14, Mandy Chung wrote: >> Can I build OpenJDK with the docs with module graphs when I >> have Graphviz installed? I would think we need a configure >> option to specify my local path to `dot` that will enable >> the module graph build. Is it possible? > Yes, it is possible. Configure will look for dot on the path by default and if found, "full docs" will be enabled implicitly. > > For such a simple dependency as this, basically we just need the path to an executable, we don't need to define actual configure arguments. You can simply override the value on the command line like this: > > bash configure DOT=/path/to/dot Thanks. That would do it. Mandy From magnus.ihse.bursie at oracle.com Tue Apr 11 07:40:07 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Apr 2017 09:40:07 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> Message-ID: On 2017-04-07 22:04, Mandy Chung wrote: > >> On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie >> > > wrote: >> >> >> Having though this over real hard, I'd realized I need to make a plea >> for sanity and consistency. I thought I should lay low in this >> discussion, but I can't. Choosing "amd64" as the name for the 64-bit >> x86 platform is really, really unfortunate and a step backwards in >> our effort to standardize the name of this platform. >> > > I think it may be useful to see the value of `os.arch` system property > on all platforms > at a glance. > > 32-bit64-bit > > linux i386amd64 > arm aarch64 > solaris amd64 > sparcv9 > windows x86 amd64 > macos x86_64 > > It's late in JDK 9. The best is to revisit OS and architecture names > in JDK 10 on the > consistency and simplicity issue. In the context of JDK-8175819, > these are names to > pass tojmod ?-os-name ?-os-arch options. The values are used at > resolution time > to avoid linking modules for different target platforms into the same > image. > > As Mark suggests, we use the value of `os.arch` system property for > JMOD file in > JDK 9 and we can change the value in JDK 10. No change to system > property and > bundle names, as we said previously. I agree. It's late in JDK 9. I'm OK with the proposal of using os.arch for JDK 9, as long as when we're revisiting the issue in JDK 10, we do not use the fact that it was used in JDK 9 as an argument for not changing it... /Magnus > > We should revisit OS and architecture names in JDK 10. I have updated > JDK-8178016 to reflect that. Are you okay with that? > > Below shows the old and new values in the `release` file and the new > values > are used in JMOD files. > > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 > sparcv9 sparcv9 > arm arm > aarch64 aarch64 > > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html > > > Mandy From magnus.ihse.bursie at oracle.com Tue Apr 11 08:19:29 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Apr 2017 10:19:29 +0200 Subject: RFR: 8173801 Remove non-client demos and samples In-Reply-To: <3bf8b149-c0bf-633e-7491-4836f82b3c82@oracle.com> References: <07B67AD3-8B22-4FA1-9581-FA15A05C5D66@oracle.com> <2026f5d2-fe72-f230-8e78-47559ffb64a4@oracle.com> <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> <3bf8b149-c0bf-633e-7491-4836f82b3c82@oracle.com> Message-ID: <84459b58-bb78-fc69-9774-3b2a67158904@oracle.com> On 2017-04-10 09:51, Erik Joelsson wrote: > Hello, > > CompileDemos.gmk: 270: The $(call install-file) line shouldn't be removed > > make/Bundles.gmk: 186: Since the client demos are still in there, they > still need to be filtered out of the image when creating the JDK bundle. > > Otherwise this looks ok. Agree, with these things fixed it looks good. /Magnus > > /Erik > > > On 2017-04-07 23:05, Alexandre (Shura) Iline wrote: >> After some back and forth it was decided that the client demos should >> stay intact for JDK9 and be reworked into tests as a part of another >> JEP. >> >> With that, could you take another look on the suggested changes? >> http://cr.openjdk.java.net/~shurailine/8173801/webrev.03 >> >> Thank you. >> >> Shura >> >> >>> On Mar 3, 2017, at 9:39 AM, Phil Race wrote: >>> >>> What is the plan for ensuring there is still a way to build the >>> client demos - which are not being removed >>> but just moved. Doesn't this makefile need to be somewhere still ? >>> >>> -phil. >>> >>> On 3/3/2017 12:18 AM, Magnus Ihse Bursie wrote: >>>> On 2017-03-02 20:33, Alexandre (Shura) Iline wrote: >>>>> Hi, >>>>> >>>>> Could you be so kind to review suggested changes for the makefiles >>>>> to stop producing sales and demos bundle. Pls note that this >>>>> request only changes the makefiles, it does not remove demos and >>>>> samples source code, which will be done separately. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173801 >>>>> Webrev: http://cr.openjdk.java.net/~shurailine/8173801/webrev.02/ >>>>> >>>>> Shura >>>> Looks good to me. >>>> >>>> Good riddance! :-) >>>> >>>> /Magnus >>>> > From erik.joelsson at oracle.com Tue Apr 11 10:05:56 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Apr 2017 12:05:56 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <35c8724e-f371-b213-1582-027bcafe3af4@oracle.com> <811871c4-25e1-e89e-73ea-fee5a0bf8624@oracle.com> <67C9091D-76CA-4F01-BAC2-0053129FE0A4@oracle.com> Message-ID: On 2017-04-11 09:40, Magnus Ihse Bursie wrote: > > > On 2017-04-07 22:04, Mandy Chung wrote: >> >>> On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie >>> >> > wrote: >>> >>> >>> Having though this over real hard, I'd realized I need to make a >>> plea for sanity and consistency. I thought I should lay low in this >>> discussion, but I can't. Choosing "amd64" as the name for the 64-bit >>> x86 platform is really, really unfortunate and a step backwards in >>> our effort to standardize the name of this platform. >>> >> >> I think it may be useful to see the value of `os.arch` system >> property on all platforms >> at a glance. >> >> 32-bit64-bit >> >> linux i386amd64 >> arm aarch64 >> solaris amd64 >> sparcv9 >> windows x86 amd64 >> macos x86_64 >> >> It's late in JDK 9. The best is to revisit OS and architecture names >> in JDK 10 on the >> consistency and simplicity issue. In the context of JDK-8175819, >> these are names to >> pass tojmod ?-os-name ?-os-arch options. The values are used at >> resolution time >> to avoid linking modules for different target platforms into the same >> image. >> >> As Mark suggests, we use the value of `os.arch` system property for >> JMOD file in >> JDK 9 and we can change the value in JDK 10. No change to system >> property and >> bundle names, as we said previously. > > I agree. It's late in JDK 9. > > I'm OK with the proposal of using os.arch for JDK 9, as long as when > we're revisiting the issue in JDK 10, we do not use the fact that it > was used in JDK 9 as an argument for not changing it... > +1 /Erik > /Magnus > >> >> We should revisit OS and architecture names in JDK 10. I have updated >> JDK-8178016 to reflect that. Are you okay with that? >> >> Below shows the old and new values in the `release` file and the new >> values >> are used in JMOD files. >> >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 >> sparcv9 sparcv9 >> arm arm >> aarch64 aarch64 >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html >> >> >> >> Mandy > From peter.levart at gmail.com Tue Apr 11 11:45:20 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Apr 2017 13:45:20 +0200 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> Message-ID: <313362c6-9624-f07b-8301-e58f0b2dd877@gmail.com> Hi Mandy, On 04/03/2017 11:50 PM, Mandy Chung wrote: > JDK 8 JDK 9 > ----- ----- > OS_NAME Linux linux > SunOS solaris > Darwin macos > Windows windows > > OS_ARCH i386,x86 x86 > i586,amd64,x86_64 amd64 i586 (i.e. 32 bit Pentium) should map to x86, not amd64 !!! Regards, Peter > sparcv9 sparcv9 > arm arm32 > aarch64 arm64 From erik.joelsson at oracle.com Tue Apr 11 13:11:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Apr 2017 15:11:13 +0200 Subject: RFR: JDK-8177822: Move closed jib configuration for arm platforms to open Message-ID: <67a9dfda-2e9e-e284-8b96-247690156d56@oracle.com> When the closed arm port was moved into OpenJDK, we forgot to also include the jib profiles configuration for the internal arm builds. This patch corrects that. The profiles are still exactly the same as they were in closed, which means they build the Oracle ports. Bug: https://bugs.openjdk.java.net/browse/JDK-8177822 Webrev: http://cr.openjdk.java.net/~erikj/8177822/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Tue Apr 11 14:03:12 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Apr 2017 16:03:12 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> Message-ID: <541a30f4-f5be-0482-a4f3-9f48cb88db6a@oracle.com> Here is an updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.04/ This change does not stop requiring the full exploded image to be built first when building full docs. However, full-docs will no longer be automatically enabled, even when all prerequisites are present, so for normal uses (where the user does not give --enable-full-docs), this dependency will not be present. The problem here is that if we do that, we will end up with broken Javadoc in the image/docs directory, since the generated HTML will contain an "" tag, but the png file itself will not exist. During an offline discussion, this was deemed acceptable. I have changed the names of the targets to be more clear. Now we have "docs-jdk" and "docs-javase" as the "top level" javadoc targets. For these, we (currently) have the sub-targets "docs-jdk-javadoc" and "docs-javase-javadoc", but as part of JEP 299, more will soon follow. I have kept "docs-javadoc" as a legacy alias for "docs-jdk-javadoc". I have also incorporated the fixes from Mandy's comment. /Magnus On 2017-04-07 13:02, Erik Joelsson wrote: > Hello, > > This looks good in general. One thing I don't like about this is that > if full docs is enabled, the docs-javadoc target now requires the full > exploded image to be built first. I think that's unfortunate. Would it > be possible to introduce separate targets for the gengraphs parts so > that the main javadoc call can be run independently of most of the > rest of the build, using the existing docs-javadoc target (and the > newer docs-reference, even though I think that name is bit strange in > this context)? > > /Erik > > > On 2017-04-07 10:40, Magnus Ihse Bursie wrote: >> This bug is the continuation of JDK-8173303, in which Mandy added the >> generation of .dot files for @moduleGraph Javadoc tags. >> >> With this patch, the code is taken to it's completion, and the >> temporarily solutions left in place by JDK-8173303 has been replaced >> by properly integrated solutions. >> >> Summary of changes: >> * A new option --enable-full-docs determines if module graphs should >> be created or not. (In the future, even more optional but "difficult" >> documentation work might be added to depend on this.) This is enabled >> by default is all prerequisites are present. >> * It is not impossible to get to a state of the documentation with >> broken img links. >> * I have re-introduced SetupJavadocGeneration to stop the code >> duplication between JDK and Java SE javadoc builds. >> * I have fixed a bug in how the makefiles determines the dependencies >> of modules. This only affected a single module in nashorn, and no >> nashorn build code used these dependencies, so that's why it has gone >> unnoticed until now. I have verified that no other changes in module >> dependencies are introduced by this fix. >> * Javadoc source code dependencies are now correct even for >> transitive modules >> * Support added for the creation and use in jib of a "graphviz" module. >> >> This code is dependent on JDK-8172312. This webrev is done as a diff >> against the latest published webrev of JDK-8172312. JDK-8172312 is >> reviewed, but is currently awaiting the status for JEP 299 to be >> changed to Targeted before it can be pushed. >> >> This code only affects the build system and documentation. I intend >> to push it to jdk9 using the "noreg-doc" RDP2 exception. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 >> > From magnus.ihse.bursie at oracle.com Tue Apr 11 14:04:06 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Apr 2017 16:04:06 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <5277C555-F271-4709-A628-F2A2CB27C664@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> <5277C555-F271-4709-A628-F2A2CB27C664@oracle.com> Message-ID: <6a28c9da-31cd-a13f-314d-f586e84de945@oracle.com> On 2017-04-08 00:14, Mandy Chung wrote: >> On Apr 7, 2017, at 4:02 AM, Erik Joelsson wrote: >> >> Hello, >> >> This looks good in general. One thing I don't like about this is that if full docs is enabled, the docs-javadoc target now requires the full exploded image to be built first. I think that's unfortunate. Would it be possible to introduce separate targets for the gengraphs parts so that the main javadoc call can be run independently of most of the rest of the build, using the existing docs-javadoc target (and the newer docs-reference, even though I think that name is bit strange in this context)? >> > I agree with Erik that it?d be nice to separate the module graph generation > and enable it to run with javadoc generation in parallel. That?s one reason > why docs-module-graphs was a separate target (I have no issue to take that > target out from Main.gmk). > > >> On 2017-04-07 10:40, Magnus Ihse Bursie wrote: >>> Summary of changes: >>> * A new option --enable-full-docs determines if module graphs should be created or not. (In the future, even more optional but "difficult" documentation work might be added to depend on this.) This is enabled by default is all prerequisites are present. > > It might be okay to call this ?full docs? when it includes the > module graphs but I am not sure about the new option name. > > Can I build OpenJDK with the docs with module graphs when I > have Graphviz installed? I would think we need a configure > option to specify my local path to `dot` that will enable > the module graph build. Is it possible? > >>> This code only affects the build system and documentation. I intend to push it to jdk9 using the "noreg-doc" RDP2 exception. >>> > Yes this is makefile and docs-only change. In addition, FC extension > request for JDK-8173303 covers this issue [1]. > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 >>> > common/autoconf/jdk-options.m4 > 172 if test "x$DTRACE_DEP_MISSING" = "xtrue"; then > > What is DTRACE_DEP_MISSING? Oops! A copy/paste error. Thanks for catching it! > > 158 # gengraphs tool. > 167 # generated by the gengraphs tool and store it in the target dir. > > Nit: I prefer to name the tool as `GenGraphs` rather than gengraphs. Fixed. /Magnus > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8173303?focusedCommentId=14064511&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14064511 From tim.bell at oracle.com Tue Apr 11 18:05:36 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 11 Apr 2017 11:05:36 -0700 Subject: RFR: JDK-8177822: Move closed jib configuration for arm platforms to open In-Reply-To: <67a9dfda-2e9e-e284-8b96-247690156d56@oracle.com> References: <67a9dfda-2e9e-e284-8b96-247690156d56@oracle.com> Message-ID: <5a0e22b4-9c16-d7a9-63c3-c6ed92825c2f@oracle.com> Erik: > When the closed arm port was moved into OpenJDK, we forgot to also > include the jib profiles configuration for the internal arm builds. This > patch corrects that. The profiles are still exactly the same as they > were in closed, which means they build the Oracle ports. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177822 > > Webrev: http://cr.openjdk.java.net/~erikj/8177822/webrev.01/ Looks good. /Tim From alexandre.iline at oracle.com Tue Apr 11 21:41:14 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 11 Apr 2017 14:41:14 -0700 Subject: RFR: 8173801 Remove non-client demos and samples In-Reply-To: <84459b58-bb78-fc69-9774-3b2a67158904@oracle.com> References: <07B67AD3-8B22-4FA1-9581-FA15A05C5D66@oracle.com> <2026f5d2-fe72-f230-8e78-47559ffb64a4@oracle.com> <9A739BE0-E980-4FF2-A19C-D5DBA3E5387B@oracle.com> <3bf8b149-c0bf-633e-7491-4836f82b3c82@oracle.com> <84459b58-bb78-fc69-9774-3b2a67158904@oracle.com> Message-ID: <02B45F81-BDEC-4F79-A5B3-7C1A87458FAA@oracle.com> Thank you for review! I have fixed and tested - all good. Will push tomorrow morning. Shura > On Apr 11, 2017, at 1:19 AM, Magnus Ihse Bursie wrote: > > On 2017-04-10 09:51, Erik Joelsson wrote: >> Hello, >> >> CompileDemos.gmk: 270: The $(call install-file) line shouldn't be removed >> >> make/Bundles.gmk: 186: Since the client demos are still in there, they still need to be filtered out of the image when creating the JDK bundle. >> >> Otherwise this looks ok. > > Agree, with these things fixed it looks good. > > /Magnus > >> >> /Erik >> >> >> On 2017-04-07 23:05, Alexandre (Shura) Iline wrote: >>> After some back and forth it was decided that the client demos should stay intact for JDK9 and be reworked into tests as a part of another JEP. >>> >>> With that, could you take another look on the suggested changes? >>> http://cr.openjdk.java.net/~shurailine/8173801/webrev.03 >>> >>> Thank you. >>> >>> Shura >>> >>> >>>> On Mar 3, 2017, at 9:39 AM, Phil Race wrote: >>>> >>>> What is the plan for ensuring there is still a way to build the client demos - which are not being removed >>>> but just moved. Doesn't this makefile need to be somewhere still ? >>>> >>>> -phil. >>>> >>>> On 3/3/2017 12:18 AM, Magnus Ihse Bursie wrote: >>>>> On 2017-03-02 20:33, Alexandre (Shura) Iline wrote: >>>>>> Hi, >>>>>> >>>>>> Could you be so kind to review suggested changes for the makefiles to stop producing sales and demos bundle. Pls note that this request only changes the makefiles, it does not remove demos and samples source code, which will be done separately. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173801 >>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/8173801/webrev.02/ >>>>>> >>>>>> Shura >>>>> Looks good to me. >>>>> >>>>> Good riddance! :-) >>>>> >>>>> /Magnus >>>>> >> > From mandy.chung at oracle.com Wed Apr 12 00:33:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Apr 2017 19:33:48 -0500 Subject: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name In-Reply-To: <313362c6-9624-f07b-8301-e58f0b2dd877@gmail.com> References: <20170403131552.834209932@eggemoggin.niobe.net> <58E2B212.6080605@cjnash.com> <20170403143925.120730340@eggemoggin.niobe.net> <5AD5D871-1673-4D4C-89CC-CEB1B76FDA75@oracle.com> <313362c6-9624-f07b-8301-e58f0b2dd877@gmail.com> Message-ID: <042EE4F5-2120-4707-9660-CBA9546B1837@oracle.com> > On Apr 11, 2017, at 6:45 AM, Peter Levart wrote: > > Hi Mandy, > > On 04/03/2017 11:50 PM, Mandy Chung wrote: >> JDK 8 JDK 9 >> ----- ----- >> OS_NAME Linux linux >> SunOS solaris >> Darwin macos >> Windows windows >> >> OS_ARCH i386,x86 x86 >> i586,amd64,x86_64 amd64 > > i586 (i.e. 32 bit Pentium) should map to x86, not amd64 !!! Oops? a typo of course (should be removed). ?i586? is only used as bundle name. os.arch does not have ?i586? value. Mandy From magnus.ihse.bursie at oracle.com Wed Apr 12 13:14:15 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Apr 2017 15:14:15 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <541a30f4-f5be-0482-a4f3-9f48cb88db6a@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> <541a30f4-f5be-0482-a4f3-9f48cb88db6a@oracle.com> Message-ID: <4dc79fb6-d031-7b9a-4153-4b737faad0f7@oracle.com> On 2017-04-11 16:03, Magnus Ihse Bursie wrote: > Here is an updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.04/ > > > This change does not stop requiring the full exploded image to be > built first when building full docs. However, full-docs will no longer > be automatically enabled, even when all prerequisites are present, so > for normal uses (where the user does not give --enable-full-docs), > this dependency will not be present. > > The problem here is that if we do that, we will end up with broken > Javadoc in the image/docs directory, since the generated HTML will > contain an "" tag, but the png file itself > will not exist. During an offline discussion, this was deemed acceptable. Obviously, miscommunication can arise even outside this mailing list. :-) I misunderstood Erik. Here's yet another (hopefully final) version of the patch, which does split the generation in two separate steps. This change introduces target names which will hopefully make it harder to accidentally build broken documentation, even though it will be possible if you try really hard. :) The idea behind the new name schema is that the docs image after JEP 299 will end up with two directories, "api" and "specs", and we'll have a docs image for jdk (the "normal" docs image) and a special image containing the Java SE documentation only, to serve as reference for the Java SE specification ("javase-docs"). So we get docs-jdk and docs-javase for the two respective top-level targets. Then we break them down in docs-jdk-api and docs-jdk-specs (will be created in a separate change). And finally, docs-jdk-api consists of docs-jdk-api-javadocs and, if running with full docs, docs-jdk-api-modulegraph. Running any of the two latter targets individually will result in a non-consistent api directory, but running any of docs-jdk-api or docs-jdk will ensure it's consistent. http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.05 /Magnus > I have changed the names of the targets to be more clear. Now we have > "docs-jdk" and "docs-javase" as the "top level" javadoc targets. For > these, we (currently) have the sub-targets "docs-jdk-javadoc" and > "docs-javase-javadoc", but as part of JEP 299, more will soon follow. > I have kept "docs-javadoc" as a legacy alias for "docs-jdk-javadoc". > > I have also incorporated the fixes from Mandy's comment. > > /Magnus > > > On 2017-04-07 13:02, Erik Joelsson wrote: >> Hello, >> >> This looks good in general. One thing I don't like about this is that >> if full docs is enabled, the docs-javadoc target now requires the >> full exploded image to be built first. I think that's unfortunate. >> Would it be possible to introduce separate targets for the gengraphs >> parts so that the main javadoc call can be run independently of most >> of the rest of the build, using the existing docs-javadoc target (and >> the newer docs-reference, even though I think that name is bit >> strange in this context)? >> >> /Erik >> >> >> On 2017-04-07 10:40, Magnus Ihse Bursie wrote: >>> This bug is the continuation of JDK-8173303, in which Mandy added >>> the generation of .dot files for @moduleGraph Javadoc tags. >>> >>> With this patch, the code is taken to it's completion, and the >>> temporarily solutions left in place by JDK-8173303 has been replaced >>> by properly integrated solutions. >>> >>> Summary of changes: >>> * A new option --enable-full-docs determines if module graphs should >>> be created or not. (In the future, even more optional but >>> "difficult" documentation work might be added to depend on this.) >>> This is enabled by default is all prerequisites are present. >>> * It is not impossible to get to a state of the documentation with >>> broken img links. >>> * I have re-introduced SetupJavadocGeneration to stop the code >>> duplication between JDK and Java SE javadoc builds. >>> * I have fixed a bug in how the makefiles determines the >>> dependencies of modules. This only affected a single module in >>> nashorn, and no nashorn build code used these dependencies, so >>> that's why it has gone unnoticed until now. I have verified that no >>> other changes in module dependencies are introduced by this fix. >>> * Javadoc source code dependencies are now correct even for >>> transitive modules >>> * Support added for the creation and use in jib of a "graphviz" module. >>> >>> This code is dependent on JDK-8172312. This webrev is done as a diff >>> against the latest published webrev of JDK-8172312. JDK-8172312 is >>> reviewed, but is currently awaiting the status for JEP 299 to be >>> changed to Targeted before it can be pushed. >>> >>> This code only affects the build system and documentation. I intend >>> to push it to jdk9 using the "noreg-doc" RDP2 exception. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 >>> >> > From erik.joelsson at oracle.com Wed Apr 12 14:06:04 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Apr 2017 16:06:04 +0200 Subject: RFR: JDK-8176785 Add build support to generate PNG file from .dot file In-Reply-To: <4dc79fb6-d031-7b9a-4153-4b737faad0f7@oracle.com> References: <0aeaaa04-83bf-6677-67a2-1ce7482c114a@oracle.com> <88446ef5-93eb-5572-8216-8b56399ea51c@oracle.com> <541a30f4-f5be-0482-a4f3-9f48cb88db6a@oracle.com> <4dc79fb6-d031-7b9a-4153-4b737faad0f7@oracle.com> Message-ID: <7fc546e5-aedc-da11-40cb-56e4cb04e49d@oracle.com> Looks good, thanks! /Erik On 2017-04-12 15:14, Magnus Ihse Bursie wrote: > On 2017-04-11 16:03, Magnus Ihse Bursie wrote: >> Here is an updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.04/ >> >> >> This change does not stop requiring the full exploded image to be >> built first when building full docs. However, full-docs will no >> longer be automatically enabled, even when all prerequisites are >> present, so for normal uses (where the user does not give >> --enable-full-docs), this dependency will not be present. >> >> The problem here is that if we do that, we will end up with broken >> Javadoc in the image/docs directory, since the generated HTML will >> contain an "" tag, but the png file itself >> will not exist. During an offline discussion, this was deemed >> acceptable. > > Obviously, miscommunication can arise even outside this mailing list. > :-) I misunderstood Erik. Here's yet another (hopefully final) version > of the patch, which does split the generation in two separate steps. > This change introduces target names which will hopefully make it > harder to accidentally build broken documentation, even though it will > be possible if you try really hard. :) > > The idea behind the new name schema is that the docs image after JEP > 299 will end up with two directories, "api" and "specs", and we'll > have a docs image for jdk (the "normal" docs image) and a special > image containing the Java SE documentation only, to serve as reference > for the Java SE specification ("javase-docs"). > > So we get docs-jdk and docs-javase for the two respective top-level > targets. Then we break them down in docs-jdk-api and docs-jdk-specs > (will be created in a separate change). And finally, docs-jdk-api > consists of docs-jdk-api-javadocs and, if running with full docs, > docs-jdk-api-modulegraph. Running any of the two latter targets > individually will result in a non-consistent api directory, but > running any of docs-jdk-api or docs-jdk will ensure it's consistent. > > http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.05 > > /Magnus > >> I have changed the names of the targets to be more clear. Now we have >> "docs-jdk" and "docs-javase" as the "top level" javadoc targets. For >> these, we (currently) have the sub-targets "docs-jdk-javadoc" and >> "docs-javase-javadoc", but as part of JEP 299, more will soon follow. >> I have kept "docs-javadoc" as a legacy alias for "docs-jdk-javadoc". >> >> I have also incorporated the fixes from Mandy's comment. >> >> /Magnus >> >> >> On 2017-04-07 13:02, Erik Joelsson wrote: >>> Hello, >>> >>> This looks good in general. One thing I don't like about this is >>> that if full docs is enabled, the docs-javadoc target now requires >>> the full exploded image to be built first. I think that's >>> unfortunate. Would it be possible to introduce separate targets for >>> the gengraphs parts so that the main javadoc call can be run >>> independently of most of the rest of the build, using the existing >>> docs-javadoc target (and the newer docs-reference, even though I >>> think that name is bit strange in this context)? >>> >>> /Erik >>> >>> >>> On 2017-04-07 10:40, Magnus Ihse Bursie wrote: >>>> This bug is the continuation of JDK-8173303, in which Mandy added >>>> the generation of .dot files for @moduleGraph Javadoc tags. >>>> >>>> With this patch, the code is taken to it's completion, and the >>>> temporarily solutions left in place by JDK-8173303 has been >>>> replaced by properly integrated solutions. >>>> >>>> Summary of changes: >>>> * A new option --enable-full-docs determines if module graphs >>>> should be created or not. (In the future, even more optional but >>>> "difficult" documentation work might be added to depend on this.) >>>> This is enabled by default is all prerequisites are present. >>>> * It is not impossible to get to a state of the documentation with >>>> broken img links. >>>> * I have re-introduced SetupJavadocGeneration to stop the code >>>> duplication between JDK and Java SE javadoc builds. >>>> * I have fixed a bug in how the makefiles determines the >>>> dependencies of modules. This only affected a single module in >>>> nashorn, and no nashorn build code used these dependencies, so >>>> that's why it has gone unnoticed until now. I have verified that no >>>> other changes in module dependencies are introduced by this fix. >>>> * Javadoc source code dependencies are now correct even for >>>> transitive modules >>>> * Support added for the creation and use in jib of a "graphviz" >>>> module. >>>> >>>> This code is dependent on JDK-8172312. This webrev is done as a >>>> diff against the latest published webrev of JDK-8172312. >>>> JDK-8172312 is reviewed, but is currently awaiting the status for >>>> JEP 299 to be changed to Targeted before it can be pushed. >>>> >>>> This code only affects the build system and documentation. I intend >>>> to push it to jdk9 using the "noreg-doc" RDP2 exception. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176785 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8176785-full-build-support-for-module-graphs/webrev.01 >>>> >>> >> > From kumar.x.srinivasan at oracle.com Tue Apr 18 17:44:16 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 18 Apr 2017 10:44:16 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation Message-ID: <58F65070.6000508@oracle.com> Hello, As explained in the JBS issue [1], this new taglet enables API documents to contain the extLink tag to link external sources. Please review the webrev [2]. Thanks Kumar [1] https://bugs.openjdk.java.net/browse/JDK-8178725 [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ From erik.joelsson at oracle.com Tue Apr 18 17:51:16 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Apr 2017 19:51:16 +0200 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F65070.6000508@oracle.com> References: <58F65070.6000508@oracle.com> Message-ID: <3e448d61-e3ef-1ea8-4b60-2d3a0cc5a92e@oracle.com> The build change looks ok to me, but Magnus should definitely look at this since he is so heavily involved in the Javadoc build right now. /Erik On 2017-04-18 19:44, Kumar Srinivasan wrote: > Hello, > > As explained in the JBS issue [1], this new taglet enables API documents > to contain the extLink tag to link external sources. > > Please review the webrev [2]. > > Thanks > Kumar > > [1] https://bugs.openjdk.java.net/browse/JDK-8178725 > [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ From kumar.x.srinivasan at oracle.com Tue Apr 18 18:26:37 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 18 Apr 2017 11:26:37 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <3e448d61-e3ef-1ea8-4b60-2d3a0cc5a92e@oracle.com> References: <58F65070.6000508@oracle.com> <3e448d61-e3ef-1ea8-4b60-2d3a0cc5a92e@oracle.com> Message-ID: <58F65A5D.1000701@oracle.com> Thanks Erik, yes will wait for Magnus' and Jon's comments. Kumar > The build change looks ok to me, but Magnus should definitely look at > this since he is so heavily involved in the Javadoc build right now. > > /Erik > > > On 2017-04-18 19:44, Kumar Srinivasan wrote: >> Hello, >> >> As explained in the JBS issue [1], this new taglet enables API documents >> to contain the extLink tag to link external sources. >> >> Please review the webrev [2]. >> >> Thanks >> Kumar >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ > From jonathan.gibbons at oracle.com Tue Apr 18 22:27:57 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 18 Apr 2017 15:27:57 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F65A5D.1000701@oracle.com> References: <58F65070.6000508@oracle.com> <3e448d61-e3ef-1ea8-4b60-2d3a0cc5a92e@oracle.com> <58F65A5D.1000701@oracle.com> Message-ID: <58F692ED.9040003@oracle.com> The use of double quotes in the example might lead one to incorrectly believe that they are required. The example should work without the quotes: 43 /** 44 * An inline tag to conveniently insert an external link. 45 * The tag can be used as follows: 46 * {@extLink name description}, for example 47 *

48 * {@code 49 * Please see {@extLink Borealis a spectacular} sight. 50 * } 51 *

52 * will produce the following html 53 *

54 * {@code 55 * Please see a spectacular sight. 56 * } 57 * } 58 */ The indentation in both the comment and the source code is a bit inconsistent. Is that an extra } on line 57? The regex will fail if there are too many spaces between "{@extLink" and the name. [1] -- Jon [1]: https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/ On 04/18/2017 11:26 AM, Kumar Srinivasan wrote: > > Thanks Erik, yes will wait for Magnus' and Jon's comments. > > Kumar > >> The build change looks ok to me, but Magnus should definitely look at >> this since he is so heavily involved in the Javadoc build right now. >> >> /Erik >> >> >> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>> Hello, >>> >>> As explained in the JBS issue [1], this new taglet enables API >>> documents >>> to contain the extLink tag to link external sources. >>> >>> Please review the webrev [2]. >>> >>> Thanks >>> Kumar >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >> > From sadhak001 at gmail.com Wed Apr 19 07:42:28 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 19 Apr 2017 07:42:28 +0000 Subject: OpenJDK ARM build not using all the CPU cores Message-ID: Hi all, Whilst build OpenJDK (latest version from http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the build system does not make use of all the CPU cores available on the machine even though it detects them all. (see snippets from the build log below) Detects *4 cores* checking for number of cores... 4 But scales down to *1 core* only Build performance summary: * Cores to use: 1 * Memory limit: 2021 MB * ccache status: installed and in use We have use the --with-num-cores flag with configure but to no avail. Has anyone else has noticed this, is this a known issue or expected behaviour or any config that needs applying in order for this to make use of all the cores. Let me know if you need to see other aspects of the build log. Thanks. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From sadhak001 at gmail.com Wed Apr 19 07:44:11 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 19 Apr 2017 07:44:11 +0000 Subject: Fwd: OpenJDK ARM build not using all the CPU cores In-Reply-To: References: Message-ID: +adoption-discuss at openjdk.java.net to the discussion ---------- Forwarded message --------- From: Mani Sarkar Date: Wed, 19 Apr 2017 at 08:42 Subject: OpenJDK ARM build not using all the CPU cores To: build-dev at openjdk.java.net , build-infra-dev at openjdk.java.net Hi all, Whilst build OpenJDK (latest version from http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the build system does not make use of all the CPU cores available on the machine even though it detects them all. (see snippets from the build log below) Detects *4 cores* checking for number of cores... 4 But scales down to *1 core* only Build performance summary: * Cores to use: 1 * Memory limit: 2021 MB * ccache status: installed and in use We have use the --with-num-cores flag with configure but to no avail. Has anyone else has noticed this, is this a known issue or expected behaviour or any config that needs applying in order for this to make use of all the cores. Let me know if you need to see other aspects of the build log. Thanks. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From aph at redhat.com Wed Apr 19 07:56:09 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Apr 2017 08:56:09 +0100 Subject: OpenJDK ARM build not using all the CPU cores In-Reply-To: References: Message-ID: On 19/04/17 08:42, Mani Sarkar wrote: > Whilst build OpenJDK (latest version from > http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the build > system does not make use of all the CPU cores available on the machine even > though it detects them all. It's because you have almost no memory installed. If you want to override the number of cores to use you can do so manually, but the idea is to prevent you from running out of memory during the build. It's deliberate, not a bug. Andrew. From sadhak001 at gmail.com Wed Apr 19 08:07:48 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 19 Apr 2017 08:07:48 +0000 Subject: OpenJDK ARM build not using all the CPU cores In-Reply-To: References: Message-ID: Thanks Andrew for clarifying. On Wed, 19 Apr 2017 at 08:56 Andrew Haley wrote: > On 19/04/17 08:42, Mani Sarkar wrote: > > Whilst build OpenJDK (latest version from > > http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the > build > > system does not make use of all the CPU cores available on the machine > even > > though it detects them all. > > It's because you have almost no memory installed. If you want to > override the number of cores to use you can do so manually, but the > idea is to prevent you from running out of memory during the build. > It's deliberate, not a bug. > > Andrew. > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From ioi.lam at oracle.com Wed Apr 19 09:07:31 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 19 Apr 2017 17:07:31 +0800 Subject: OpenJDK ARM build not using all the CPU cores In-Reply-To: References: Message-ID: <8AE7C8DA-8E55-4E62-83E3-FAEC67415063@oracle.com> If you really want, you can override the settings with make JOBS=4 images Of course, YMMV due to the low amount of memory. Ioi > Mani Sarkar ? 2017?4?19? ??4:07 ??? > > Thanks Andrew for clarifying. > >> On Wed, 19 Apr 2017 at 08:56 Andrew Haley wrote: >> >>> On 19/04/17 08:42, Mani Sarkar wrote: >>> Whilst build OpenJDK (latest version from >>> http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the >> build >>> system does not make use of all the CPU cores available on the machine >> even >>> though it detects them all. >> >> It's because you have almost no memory installed. If you want to >> override the number of cores to use you can do so manually, but the >> idea is to prevent you from running out of memory during the build. >> It's deliberate, not a bug. >> >> Andrew. >> >> -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* From erik.joelsson at oracle.com Wed Apr 19 09:26:46 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Apr 2017 11:26:46 +0200 Subject: OpenJDK ARM build not using all the CPU cores In-Reply-To: <8AE7C8DA-8E55-4E62-83E3-FAEC67415063@oracle.com> References: <8AE7C8DA-8E55-4E62-83E3-FAEC67415063@oracle.com> Message-ID: <1b0405d4-de42-589d-d79d-6c1f94539e3a@oracle.com> If you want to do the override at configure time, the correct configure parameter is --with-jobs=4. The --with-num-cores isn't all that useful except for easier testing of the logic for calculating the default number of jobs (which is why I left it there). The default limitation of jobs based on memory is rather conservative (1 job per 1024MB IIRC). We don't like to assume that building is the only thing the system ever does. Also most of the build tasks aren't that memory hungry, but some are. I recommend you try manually increasing jobs until you find your optimal level of concurrency for the types of builds you do. /Erik On 2017-04-19 11:07, Ioi Lam wrote: > If you really want, you can override the settings with > > make JOBS=4 images > > Of course, YMMV due to the low amount of memory. > > Ioi > >> Mani Sarkar ? 2017?4?19? ??4:07 ??? >> >> Thanks Andrew for clarifying. >> >>> On Wed, 19 Apr 2017 at 08:56 Andrew Haley wrote: >>> >>>> On 19/04/17 08:42, Mani Sarkar wrote: >>>> Whilst build OpenJDK (latest version from >>>> http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the >>> build >>>> system does not make use of all the CPU cores available on the machine >>> even >>>> though it detects them all. >>> It's because you have almost no memory installed. If you want to >>> override the number of cores to use you can do so manually, but the >>> idea is to prevent you from running out of memory during the build. >>> It's deliberate, not a bug. >>> >>> Andrew. >>> >>> -- >> @theNeomatrix369 * | **Blog >> ** | *LJC Associate & LJC Advocate >> (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project - *MutabilityDetector >> * | **Bitbucket >> * * | **Github >> * * | **LinkedIn >> * >> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >> >> *Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!* From sadhak001 at gmail.com Wed Apr 19 10:09:43 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 19 Apr 2017 10:09:43 +0000 Subject: OpenJDK ARM build not using all the CPU cores In-Reply-To: <1b0405d4-de42-589d-d79d-6c1f94539e3a@oracle.com> References: <8AE7C8DA-8E55-4E62-83E3-FAEC67415063@oracle.com> <1b0405d4-de42-589d-d79d-6c1f94539e3a@oracle.com> Message-ID: Thanks Erik, I have updated our scripts with this flag. Cheers, Mani On Wed, 19 Apr 2017 at 10:29 Erik Joelsson wrote: > If you want to do the override at configure time, the correct configure > parameter is --with-jobs=4. The --with-num-cores isn't all that useful > except for easier testing of the logic for calculating the default > number of jobs (which is why I left it there). > > The default limitation of jobs based on memory is rather conservative (1 > job per 1024MB IIRC). We don't like to assume that building is the only > thing the system ever does. Also most of the build tasks aren't that > memory hungry, but some are. I recommend you try manually increasing > jobs until you find your optimal level of concurrency for the types of > builds you do. > > /Erik > > > On 2017-04-19 11:07, Ioi Lam wrote: > > If you really want, you can override the settings with > > > > make JOBS=4 images > > > > Of course, YMMV due to the low amount of memory. > > > > Ioi > > > >> Mani Sarkar ? 2017?4?19? ??4:07 ??? > >> > >> Thanks Andrew for clarifying. > >> > >>> On Wed, 19 Apr 2017 at 08:56 Andrew Haley wrote: > >>> > >>>> On 19/04/17 08:42, Mani Sarkar wrote: > >>>> Whilst build OpenJDK (latest version from > >>>> http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the > >>> build > >>>> system does not make use of all the CPU cores available on the machine > >>> even > >>>> though it detects them all. > >>> It's because you have almost no memory installed. If you want to > >>> override the number of cores to use you can do so manually, but the > >>> idea is to prevent you from running out of memory during the build. > >>> It's deliberate, not a bug. > >>> > >>> Andrew. > >>> > >>> -- > >> @theNeomatrix369 * | **Blog > >> ** | *LJC Associate & LJC > Advocate > >> (@adoptopenjdk & @adoptajsr programs) > >> *Meet-a-Project - *MutabilityDetector > >> * | **Bitbucket > >> * * | **Github > >> * * | **LinkedIn > >> * > >> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ > >> > >> *Don't chase success, rather aim for "Excellence", and success will come > >> chasing after you!* > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From magnus.ihse.bursie at oracle.com Wed Apr 19 11:26:03 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Apr 2017 13:26:03 +0200 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F65070.6000508@oracle.com> References: <58F65070.6000508@oracle.com> Message-ID: <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> On 2017-04-18 19:44, Kumar Srinivasan wrote: > Hello, > > As explained in the JBS issue [1], this new taglet enables API documents > to contain the extLink tag to link external sources. > > Please review the webrev [2]. Changes looks good. Just a reflection: This is heavily biased to Oracle documentation. Even if it's possible to override the URL via a system property, it assumes the Oracle URL format and id name. Just wondering a bit how that fits with the OpenJDK philosophy. /Magnus > > Thanks > Kumar > > [1] https://bugs.openjdk.java.net/browse/JDK-8178725 > [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ From magnus.ihse.bursie at oracle.com Wed Apr 19 11:42:47 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Apr 2017 13:42:47 +0200 Subject: RFR: JDK-8178438 Info-privileged.plist claims launchers to be "OpenJDK 7 Command" Message-ID: The file src/java.base/macosx/native/launcher/Info-privileged.plist, which is used when building signed macos launcher binaries, contains this snippet: CFBundleName OpenJDK 7 Command I assume this has not been updated since JDK 7. I suggest removing the version number from the file completely. Approved for fixing in JDK 9. Bug: https://bugs.openjdk.java.net/browse/JDK-8178438 Patch inline: diff --git a/src/java.base/macosx/native/launcher/Info-privileged.plist b/src/java.base/macosx/native/launcher/Info-privileged.plist --- a/src/java.base/macosx/native/launcher/Info-privileged.plist +++ b/src/java.base/macosx/native/launcher/Info-privileged.plist @@ -7,7 +7,7 @@ CFBundleInfoDictionaryVersion 6.0 CFBundleName - OpenJDK 7 Command + OpenJDK Command CFBundleShortVersionString 1.0 CFBundleVersion /Magnus From erik.joelsson at oracle.com Wed Apr 19 11:46:50 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Apr 2017 13:46:50 +0200 Subject: RFR: JDK-8178438 Info-privileged.plist claims launchers to be "OpenJDK 7 Command" In-Reply-To: References: Message-ID: <1b489830-db51-5e90-7e56-5fdfef1d9348@oracle.com> Looks good. /Erik On 2017-04-19 13:42, Magnus Ihse Bursie wrote: > The file src/java.base/macosx/native/launcher/Info-privileged.plist, > which is used when building signed macos launcher binaries, contains > this snippet: > > CFBundleName > OpenJDK 7 Command > > I assume this has not been updated since JDK 7. I suggest removing the > version number from the file completely. > > Approved for fixing in JDK 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178438 > Patch inline: > diff --git > a/src/java.base/macosx/native/launcher/Info-privileged.plist > b/src/java.base/macosx/native/launcher/Info-privileged.plist > --- a/src/java.base/macosx/native/launcher/Info-privileged.plist > +++ b/src/java.base/macosx/native/launcher/Info-privileged.plist > @@ -7,7 +7,7 @@ > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > - OpenJDK 7 Command > + OpenJDK Command > CFBundleShortVersionString > 1.0 > CFBundleVersion > > /Magnus From magnus.ihse.bursie at oracle.com Wed Apr 19 11:57:16 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Apr 2017 13:57:16 +0200 Subject: RFR: JDK-8178042 Allow custom taglets Message-ID: <2cb1d3db-9d6f-e5ea-4da4-79426d697e21@oracle.com> Please review this simple change to allow custom to add specialized javadoc taglets. Bug: https://bugs.openjdk.java.net/browse/JDK-8178042 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.01 /Magnus From david.holmes at oracle.com Wed Apr 19 12:07:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Apr 2017 22:07:58 +1000 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> Message-ID: <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: > On 2017-04-18 19:44, Kumar Srinivasan wrote: >> Hello, >> >> As explained in the JBS issue [1], this new taglet enables API documents >> to contain the extLink tag to link external sources. >> >> Please review the webrev [2]. > Changes looks good. > > Just a reflection: This is heavily biased to Oracle documentation. Even > if it's possible to override the URL via a system property, it assumes > the Oracle URL format and id name. Just wondering a bit how that fits > with the OpenJDK philosophy. I have to agree, this is not at all general purpose but totally Oracle documentation centric. David ----- > /Magnus > >> >> Thanks >> Kumar >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ > From magnus.ihse.bursie at oracle.com Wed Apr 19 12:36:09 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Apr 2017 14:36:09 +0200 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory Message-ID: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> This patch will solve three issues that I (unfortunately) filed as separate issues, but that shares a common solution. The three issues are: JDK-8178038 Copy jdwp-protocol.html to proper location JDK-8178039 Copy jvmti.html to proper location JDK-8178316 Add JVM-MANAGEMENT-MIB.mib to jdk/src/java.management/share/specs/ This patch will also solve this in a general way, to start preparing for JDK-8177434 (Copy specifications from module specs directory to docs image). Bug descriptions: https://bugs.openjdk.java.net/browse/JDK-8178038 Copy jdwp-protocol.html to proper location After JDK-8172312, the copy of jvmti.html into docs/platform/jvmti will stick out like a sore thumb. It should be moved to the new location designed by JEP 299, in docs/specs. https://bugs.openjdk.java.net/browse/JDK-8178039 Copy jvmti.html to proper location After JDK-8172312, the copy of jvmti.html into docs/platform/jvmti will stick out like a sore thumb. It should be moved to the new location designed by JEP 299, in docs/specs. https://bugs.openjdk.java.net/browse/JDK-8178316 Add JVM-MANAGEMENT-MIB.mib to jdk/src/java.management/share/specs/ The file JVM-MANAGEMENT-MIB.mib have unfortunately been stored in the closed sources. This was an oversight, and it should be moved to open sources. The file will follow the new structure of JEP 299 and be put in java.management/share/specs/, and copied to docs/specs during build. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Apr 19 12:54:44 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Apr 2017 14:54:44 +0200 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java Message-ID: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html is no longer included in the generated documentation. The information provided by that file should move to src/jdk.jdi/share/classes/module-info.java instead. I also took the liberty of removing a bunch of other overview.html files that are not included in the Javadoc anymore. They provided no real informational value, and what text they contained is already expressed similarly or better in the corresponding module-info.java files instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Apr 19 12:57:00 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Apr 2017 14:57:00 +0200 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> Message-ID: <19f743ad-3635-acbf-004b-63573f397ecf@oracle.com> Looks good. Nit: Javadoc.gmk:358-360 only indented 2 spaces for continuation. Same goes for 390-393, but you didn't actually touch those lines. /Erik On 2017-04-19 14:36, Magnus Ihse Bursie wrote: > This patch will solve three issues that I (unfortunately) filed as > separate issues, but that shares a common solution. The three issues are: > JDK-8178038 Copy jdwp-protocol.html to proper location > JDK-8178039 Copy jvmti.html to proper location > JDK-8178316 Add JVM-MANAGEMENT-MIB.mib to > jdk/src/java.management/share/specs/ > > This patch will also solve this in a general way, to start preparing > for JDK-8177434 (Copy specifications from module specs directory to > docs image). > > Bug descriptions: > > https://bugs.openjdk.java.net/browse/JDK-8178038 Copy > jdwp-protocol.html to proper location > After JDK-8172312, the copy of jvmti.html into docs/platform/jvmti > will stick out like a sore thumb. It should be moved to the new > location designed by JEP 299, in docs/specs. > > https://bugs.openjdk.java.net/browse/JDK-8178039 Copy jvmti.html to > proper location > After JDK-8172312, the copy of jvmti.html into docs/platform/jvmti > will stick out like a sore thumb. It should be moved to the new > location designed by JEP 299, in docs/specs. > > https://bugs.openjdk.java.net/browse/JDK-8178316 Add > JVM-MANAGEMENT-MIB.mib to jdk/src/java.management/share/specs/ > The file JVM-MANAGEMENT-MIB.mib have unfortunately been stored in the > closed sources. This was an oversight, and it should be moved to open > sources. > > The file will follow the new structure of JEP 299 and be put in > java.management/share/specs/, and copied to docs/specs during build. > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Apr 19 12:58:09 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Apr 2017 14:58:09 +0200 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: <3d150f84-aa75-0ddd-c445-15fdaf2eb970@oracle.com> Looks good to me. /Erik On 2017-04-19 14:54, Magnus Ihse Bursie wrote: > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html > is no longer included in the generated documentation. The information > provided by that file should move to > src/jdk.jdi/share/classes/module-info.java instead. > > I also took the liberty of removing a bunch of other overview.html > files that are not included in the Javadoc anymore. They provided no > real informational value, and what text they contained is already > expressed similarly or better in the corresponding module-info.java > files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 > > /Magnus > From Alan.Bateman at oracle.com Wed Apr 19 13:01:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Apr 2017 14:01:23 +0100 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: On 19/04/2017 13:54, Magnus Ihse Bursie wrote: > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html > is no longer included in the generated documentation. The information > provided by that file should move to > src/jdk.jdi/share/classes/module-info.java instead. > > I also took the liberty of removing a bunch of other overview.html > files that are not included in the Javadoc anymore. They provided no > real informational value, and what text they contained is already > expressed similarly or better in the corresponding module-info.java > files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 The serviceability-dev mailing list is the best place to discuss the debugger API. However, what you have looks okay. I think I would use the opportunity to replace "The JDI" with just "JDI" in the second and third paragraphs. -Alan From tim.bell at oracle.com Wed Apr 19 13:30:19 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 19 Apr 2017 06:30:19 -0700 Subject: RFR: JDK-8178438 Info-privileged.plist claims launchers to be "OpenJDK 7 Command" In-Reply-To: <1b489830-db51-5e90-7e56-5fdfef1d9348@oracle.com> References: <1b489830-db51-5e90-7e56-5fdfef1d9348@oracle.com> Message-ID: <39ea0fe8-38b3-ae69-0d86-6c2f5866636d@oracle.com> Looks good to me as well. Tim On 04/19/17 04:46, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-04-19 13:42, Magnus Ihse Bursie wrote: >> The file src/java.base/macosx/native/launcher/Info-privileged.plist, >> which is used when building signed macos launcher binaries, contains >> this snippet: >> >> CFBundleName >> OpenJDK 7 Command >> >> I assume this has not been updated since JDK 7. I suggest removing the >> version number from the file completely. >> >> Approved for fixing in JDK 9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178438 >> Patch inline: >> diff --git >> a/src/java.base/macosx/native/launcher/Info-privileged.plist >> b/src/java.base/macosx/native/launcher/Info-privileged.plist >> --- a/src/java.base/macosx/native/launcher/Info-privileged.plist >> +++ b/src/java.base/macosx/native/launcher/Info-privileged.plist >> @@ -7,7 +7,7 @@ >> CFBundleInfoDictionaryVersion >> 6.0 >> CFBundleName >> - OpenJDK 7 Command >> + OpenJDK Command >> CFBundleShortVersionString >> 1.0 >> CFBundleVersion >> >> /Magnus > From mandy.chung at oracle.com Wed Apr 19 16:40:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 09:40:32 -0700 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: <38E8D569-C58F-4573-A630-A175EEABE240@oracle.com> > On Apr 19, 2017, at 5:54 AM, Magnus Ihse Bursie wrote: > > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html is no longer included in the generated documentation. The information provided by that file should move to src/jdk.jdi/share/classes/module-info.java instead. > > I also took the liberty of removing a bunch of other overview.html files that are not included in the Javadoc anymore. They provided no real informational value, and what text they contained is already expressed similarly or better in the corresponding module-info.java files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 Moving the content from jdi-overview.html to module-info.java is the right choice. Nit: if you don?t mind, can you replace ? with {@code ?} Otherwise, looks fine. The following sentence reads a little strange to me that contains a couple of ???. I just want to point it out and we should leave it as is. 36 * The JDI also provides explicit control over a virtual machine's execution. 37 * The ability to suspend and resume threads, and to set breakpoints, 38 * watchpoints, ... Notification of exceptions, class loading, thread 39 * creation... The ability to inspect a suspended thread's state, local 40 * variables, stack backtrace? Mandy From mandy.chung at oracle.com Wed Apr 19 16:41:38 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 09:41:38 -0700 Subject: RFR: JDK-8178042 Allow custom taglets In-Reply-To: <2cb1d3db-9d6f-e5ea-4da4-79426d697e21@oracle.com> References: <2cb1d3db-9d6f-e5ea-4da4-79426d697e21@oracle.com> Message-ID: > On Apr 19, 2017, at 4:57 AM, Magnus Ihse Bursie wrote: > > Please review this simple change to allow custom to add specialized javadoc taglets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178042 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.01 Looks fine to me. Mandy From kumar.x.srinivasan at oracle.com Wed Apr 19 17:46:33 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 19 Apr 2017 10:46:33 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F692ED.9040003@oracle.com> References: <58F65070.6000508@oracle.com> <3e448d61-e3ef-1ea8-4b60-2d3a0cc5a92e@oracle.com> <58F65A5D.1000701@oracle.com> <58F692ED.9040003@oracle.com> Message-ID: <58F7A279.2020707@oracle.com> Have made the following changes: * fixed the indentations, basically pointed the IDE and asked it to reformat the whole file * fixed regex, to be defensive against leading WS, though the DocCommentParser whacks the WS. Please see updated webrev: http://cr.openjdk.java.net/~ksrini/8178725/webrev.01/ Thanks Kumar On 4/18/2017 3:27 PM, Jonathan Gibbons wrote: > The use of double quotes in the example might lead one to incorrectly > believe that they are required. > > The example should work without the quotes: > > 43 /** > 44 * An inline tag to conveniently insert an external link. > 45 * The tag can be used as follows: > 46 * {@extLink name description}, for example > 47 *

> 48 * {@code > 49 * Please see {@extLink Borealis a spectacular} sight. > 50 * } > 51 *

> 52 * will produce the following html > 53 *

> 54 * {@code > 55 * Please see href="https://www.oracle.com/pls/topic/lookup?ctx=javase9&id=Borealis">a > spectacular sight. > 56 * } > 57 * } > 58 */ > > > The indentation in both the comment and the source code is a bit > inconsistent. Is that an extra } on line 57? > > The regex will fail if there are too many spaces between "{@extLink" > and the name. [1] > > -- Jon > > > [1]: > https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/ > > > On 04/18/2017 11:26 AM, Kumar Srinivasan wrote: >> >> Thanks Erik, yes will wait for Magnus' and Jon's comments. >> >> Kumar >> >>> The build change looks ok to me, but Magnus should definitely look >>> at this since he is so heavily involved in the Javadoc build right now. >>> >>> /Erik >>> >>> >>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> As explained in the JBS issue [1], this new taglet enables API >>>> documents >>>> to contain the extLink tag to link external sources. >>>> >>>> Please review the webrev [2]. >>>> >>>> Thanks >>>> Kumar >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>> >> > From kumar.x.srinivasan at oracle.com Wed Apr 19 17:50:21 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 19 Apr 2017 10:50:21 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> Message-ID: <58F7A35D.7000303@oracle.com> We could potentially make the default URL to be "some" cgi url, and have the build system specify the URL all the time, in our case it would be the Oracle documentation URL. Would this be an acceptable approach ? Kumar > On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>> Hello, >>> >>> As explained in the JBS issue [1], this new taglet enables API >>> documents >>> to contain the extLink tag to link external sources. >>> >>> Please review the webrev [2]. >> Changes looks good. >> >> Just a reflection: This is heavily biased to Oracle documentation. Even >> if it's possible to override the URL via a system property, it assumes >> the Oracle URL format and id name. Just wondering a bit how that fits >> with the OpenJDK philosophy. > > I have to agree, this is not at all general purpose but totally Oracle > documentation centric. > > David > ----- > > >> /Magnus >> >>> >>> Thanks >>> Kumar >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >> From sadhak001 at gmail.com Wed Apr 19 20:20:41 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 19 Apr 2017 20:20:41 +0000 Subject: OpenJDK ARM build not using all the CPU cores In-Reply-To: References: <8AE7C8DA-8E55-4E62-83E3-FAEC67415063@oracle.com> <1b0405d4-de42-589d-d79d-6c1f94539e3a@oracle.com> Message-ID: Thanks Erik we applied that flag and it has picked up the cores, we wll see when the build finishes how much or how long it took to finish compared to our previous 1-3 hour builds. On Wed, 19 Apr 2017 at 11:09 Mani Sarkar wrote: > Thanks Erik, I have updated our scripts with this flag. > > Cheers, > Mani > > On Wed, 19 Apr 2017 at 10:29 Erik Joelsson > wrote: > >> If you want to do the override at configure time, the correct configure >> parameter is --with-jobs=4. The --with-num-cores isn't all that useful >> except for easier testing of the logic for calculating the default >> number of jobs (which is why I left it there). >> >> The default limitation of jobs based on memory is rather conservative (1 >> job per 1024MB IIRC). We don't like to assume that building is the only >> thing the system ever does. Also most of the build tasks aren't that >> memory hungry, but some are. I recommend you try manually increasing >> jobs until you find your optimal level of concurrency for the types of >> builds you do. >> >> /Erik >> >> >> On 2017-04-19 11:07, Ioi Lam wrote: >> > If you really want, you can override the settings with >> > >> > make JOBS=4 images >> > >> > Of course, YMMV due to the low amount of memory. >> > >> > Ioi >> > >> >> Mani Sarkar ? 2017?4?19? ??4:07 ??? >> >> >> >> Thanks Andrew for clarifying. >> >> >> >>> On Wed, 19 Apr 2017 at 08:56 Andrew Haley wrote: >> >>> >> >>>> On 19/04/17 08:42, Mani Sarkar wrote: >> >>>> Whilst build OpenJDK (latest version from >> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the >> >>> build >> >>>> system does not make use of all the CPU cores available on the >> machine >> >>> even >> >>>> though it detects them all. >> >>> It's because you have almost no memory installed. If you want to >> >>> override the number of cores to use you can do so manually, but the >> >>> idea is to prevent you from running out of memory during the build. >> >>> It's deliberate, not a bug. >> >>> >> >>> Andrew. >> >>> >> >>> -- >> >> @theNeomatrix369 * | **Blog >> >> ** | *LJC Associate & LJC >> Advocate >> >> (@adoptopenjdk & @adoptajsr programs) >> >> *Meet-a-Project - *MutabilityDetector >> >> * | **Bitbucket >> >> * * | **Github >> >> * * | **LinkedIn >> >> * >> >> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >> >> >> >> *Don't chase success, rather aim for "Excellence", and success will >> come >> >> chasing after you!* >> >> -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From david.holmes at oracle.com Wed Apr 19 20:37:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 06:37:34 +1000 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F7A35D.7000303@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> Message-ID: <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: > > We could potentially make the default URL to be "some" cgi url, > and have the build system specify the URL all the time, in our > case it would be the Oracle documentation URL. > > Would this be an acceptable approach ? I'm not sure what you mean. I have a hard time seeing how a simple identifier (that will be fixed in the file using the taglet) can be attached to an arbitrary URL to yield a valid result. As Magnus said, being able to change the URL is good, but it still requires the same "kind" of URL where the identifier is used as a key. Imagine you have all the documentation locally on your machine then try to figure out how you could link to other local documentation using this scheme. David > Kumar > >> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> As explained in the JBS issue [1], this new taglet enables API >>>> documents >>>> to contain the extLink tag to link external sources. >>>> >>>> Please review the webrev [2]. >>> Changes looks good. >>> >>> Just a reflection: This is heavily biased to Oracle documentation. Even >>> if it's possible to override the URL via a system property, it assumes >>> the Oracle URL format and id name. Just wondering a bit how that fits >>> with the OpenJDK philosophy. >> >> I have to agree, this is not at all general purpose but totally Oracle >> documentation centric. >> >> David >> ----- >> >> >>> /Magnus >>> >>>> >>>> Thanks >>>> Kumar >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>> > From kumar.x.srinivasan at oracle.com Wed Apr 19 20:47:54 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 19 Apr 2017 13:47:54 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> Message-ID: <58F7CCFA.7050604@oracle.com> On 4/19/2017 1:37 PM, David Holmes wrote: > On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >> >> We could potentially make the default URL to be "some" cgi url, >> and have the build system specify the URL all the time, in our >> case it would be the Oracle documentation URL. >> >> Would this be an acceptable approach ? > > I'm not sure what you mean. I have a hard time seeing how a simple > identifier (that will be fixed in the file using the taglet) can be > attached to an arbitrary URL to yield a valid result. As Magnus said, > being able to change the URL is good, but it still requires the same > "kind" of URL where the identifier is used as a key. > > Imagine you have all the documentation locally on your machine then > try to figure out how you could link to other local documentation > using this scheme. Ok I see, I am going to defer this to Jon Gibbons. Kumar > > David > >> Kumar >> >>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>> Hello, >>>>> >>>>> As explained in the JBS issue [1], this new taglet enables API >>>>> documents >>>>> to contain the extLink tag to link external sources. >>>>> >>>>> Please review the webrev [2]. >>>> Changes looks good. >>>> >>>> Just a reflection: This is heavily biased to Oracle documentation. >>>> Even >>>> if it's possible to override the URL via a system property, it assumes >>>> the Oracle URL format and id name. Just wondering a bit how that fits >>>> with the OpenJDK philosophy. >>> >>> I have to agree, this is not at all general purpose but totally Oracle >>> documentation centric. >>> >>> David >>> ----- >>> >>> >>>> /Magnus >>>> >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>> >> From mandy.chung at oracle.com Wed Apr 19 22:54:29 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 15:54:29 -0700 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> Message-ID: <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> > On Apr 19, 2017, at 5:36 AM, Magnus Ihse Bursie wrote: > > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 368 JDWP_PROTOCOL := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html 369 $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ 370 FILES := $(JDWP_PROTOCOL), \ 371 DEST := $(JAVADOC_OUTPUTDIR)/specs/jdwp, \ 372 )) Is there any reason why jdwp-protocol.html is not copied to the ?specs? directory? docs-docs-specs copies specs to jdk docs. I would expect there will be docs-javase-specs to copy specs from Java SE modules to javase-docs/specs but missing. Mandy From mandy.chung at oracle.com Wed Apr 19 23:11:34 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 16:11:34 -0700 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> Message-ID: <4D5EE0BD-16A0-4976-9EF0-32FBA0CA56EB@oracle.com> > On Apr 19, 2017, at 3:54 PM, Mandy Chung wrote: > > >> On Apr 19, 2017, at 5:36 AM, Magnus Ihse Bursie wrote: >> >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 > > 368 JDWP_PROTOCOL := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html One more thing: jdwp-protocol belongs to jdk.jdwp.agent module. It would be nice if Gensrc-jdk.jdi.gmk can be cleaned up. Mandy > 369 $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ > 370 FILES := $(JDWP_PROTOCOL), \ > 371 DEST := $(JAVADOC_OUTPUTDIR)/specs/jdwp, \ > 372 )) > > Is there any reason why jdwp-protocol.html is not copied to the ?specs? directory? > > docs-docs-specs copies specs to jdk docs. I would expect there will be docs-javase-specs to copy specs from Java SE modules to javase-docs/specs but missing. > > Mandy From david.holmes at oracle.com Thu Apr 20 02:21:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 12:21:21 +1000 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html > is no longer included in the generated documentation. The information > provided by that file should move to > src/jdk.jdi/share/classes/module-info.java instead. Looks good, but highlighted an error with the existing text: /** * Defines the Java Debugger Interface. + *

+ * The Java™ Debug Interface (JDI) is a high level Java API providing The first line should read "Debug" not "Debugger". Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" should be replaced by "The JDI". Thanks, David > I also took the liberty of removing a bunch of other overview.html files > that are not included in the Javadoc anymore. They provided no real > informational value, and what text they contained is already expressed > similarly or better in the corresponding module-info.java files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 > > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Apr 20 07:21:59 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 09:21:59 +0200 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> Message-ID: <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> On 2017-04-20 00:54, Mandy Chung wrote: >> On Apr 19, 2017, at 5:36 AM, Magnus Ihse Bursie wrote: >> >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 > 368 JDWP_PROTOCOL := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html > 369 $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ > 370 FILES := $(JDWP_PROTOCOL), \ > 371 DEST := $(JAVADOC_OUTPUTDIR)/specs/jdwp, \ > 372 )) > > Is there any reason why jdwp-protocol.html is not copied to the ?specs? directory? Yes, there is. This document is only part of the jdwp specification. This is dynamically generated. The rest of the jdwp specification is static. I have a prototype that, in light of JEP 299, copies the rest of the specification to "specs/jdwp", but at the moment it's unclear if that's going to get into JDK 9. Nevertheless, I think it is prudent to prepare for this structure. > docs-docs-specs copies specs to jdk docs. I would expect there will be docs-javase-specs to copy specs from Java SE modules to javase-docs/specs but missing. You mean docs-jdk-specs? While there is a superficial similarity between "docs-jdk" and "docs-javase", there's a difference in purpose. The latter is only created for a special-purpose formal API verification, and is not supposed to be shipped. This means that it's not built by e.g. "docs-image". I assumed that only the API would be needed for that. /Magnus > > Mandy From magnus.ihse.bursie at oracle.com Thu Apr 20 07:37:40 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 09:37:40 +0200 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <4D5EE0BD-16A0-4976-9EF0-32FBA0CA56EB@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <4D5EE0BD-16A0-4976-9EF0-32FBA0CA56EB@oracle.com> Message-ID: <87e47dff-f680-adab-c7d0-8117217f69db@oracle.com> On 2017-04-20 01:11, Mandy Chung wrote: >> On Apr 19, 2017, at 3:54 PM, Mandy Chung wrote: >> >> >>> On Apr 19, 2017, at 5:36 AM, Magnus Ihse Bursie wrote: >>> >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 >> 368 JDWP_PROTOCOL := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html > One more thing: jdwp-protocol belongs to jdk.jdwp.agent module. > It would be nice if Gensrc-jdk.jdi.gmk can be cleaned up. I agree that it would be nice if Gensrc-jdk.jdi.gmk can be cleaned up. Unfortunately it's a bit tangled up right now, and a proper solution might be too radical for this change. But let's see if we can sort this out, perhaps with your module expertise a solution is possible. We need to gensrc three files: 1) $(SUPPORT_OUTPUTDIR)/headers/jdk.jdwp.agent/JDWPCommands.h 2) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/com/sun/tools/jdi/JDWP.java 3) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html 1 and 2 are being created by the same call to the build tool, and 3 is created by a separate call. I'm not sure if this is possible to change. It looks like it might. 1 already belongs to jdk.jdwp.agent, and 3 could easily be moved there. The problem is 2, which is needed when compiling the jdk.jdi module. I have two suggestions, but I don't know if either of them is possible: 1) Move the JDWP.java file to jdk.jdwp.agent, and make sure it's properly exported from jdk.jdwp.agent to jdk.jdi. (From my point of view, this seems like the logical thing to do.) In this case, the entire gensrc:ing could move to jdk.jdwp.agent, and possibly even into a single call to the build tool to generate all three files. 2) Split the gensrc into one for jdk.jdwp.agent that generated 1 and 3, and one for jdk.jdi that generates 2. It might require us to generate a dummy 2 and 1 that are just thrown away, if the tool cannot be told not to generate both 1 and 2 at the same time. /Magnus > > Mandy > >> 369 $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ >> 370 FILES := $(JDWP_PROTOCOL), \ >> 371 DEST := $(JAVADOC_OUTPUTDIR)/specs/jdwp, \ >> 372 )) >> >> Is there any reason why jdwp-protocol.html is not copied to the ?specs? directory? >> >> docs-docs-specs copies specs to jdk docs. I would expect there will be docs-javase-specs to copy specs from Java SE modules to javase-docs/specs but missing. >> >> Mandy From magnus.ihse.bursie at oracle.com Thu Apr 20 07:57:54 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 09:57:54 +0200 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> Message-ID: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> On 2017-04-20 04:21, David Holmes wrote: > On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: >> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html >> is no longer included in the generated documentation. The information >> provided by that file should move to >> src/jdk.jdi/share/classes/module-info.java instead. > > Looks good, but highlighted an error with the existing text: > > /** > * Defines the Java Debugger Interface. > + *

> + * The Java™ Debug Interface (JDI) is a high level Java API > providing > > The first line should read "Debug" not "Debugger". Good catch. I really didn't plan to make any editorial changes in this review, only to move the contents to a place were it was once again included. However, the text was apparently in need of some freshing up, so I tried to fix what was pointed out. > > Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" > should be replaced by "The JDI". I love it when I get conflicting reviews! ;-) I'm sorry Dave, I'm afraid I can't do that. :-) "The JDI" just sounds weird, and that's not how acronyms are typically referred to. So I've sided with Alan here. If you don't agree, I'll back out that change and you can fight it out by yourselves. :) And Mandy: I agree with the weird ellipses. I changed that to "etc.", which I think captures the intent that the list was not exhaustive. Here is an updated review. It fixes the "Debugger" in the title, "The JDI" -> "JDI" in two places, "..." -> "etc." and -> {@code}. http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/ /Magnus > > Thanks, > David > >> I also took the liberty of removing a bunch of other overview.html files >> that are not included in the Javadoc anymore. They provided no real >> informational value, and what text they contained is already expressed >> similarly or better in the corresponding module-info.java files instead. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 >> >> >> >> /Magnus >> From Alan.Bateman at oracle.com Thu Apr 20 07:58:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Apr 2017 08:58:11 +0100 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <87e47dff-f680-adab-c7d0-8117217f69db@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <4D5EE0BD-16A0-4976-9EF0-32FBA0CA56EB@oracle.com> <87e47dff-f680-adab-c7d0-8117217f69db@oracle.com> Message-ID: <7993dd63-dcba-3e88-d9bb-a7f185a4e507@oracle.com> On 20/04/2017 08:37, Magnus Ihse Bursie wrote: > : > > I have two suggestions, but I don't know if either of them is possible: > 1) Move the JDWP.java file to jdk.jdwp.agent, and make sure it's > properly exported from jdk.jdwp.agent to jdk.jdi. (From my point of > view, this seems like the logical thing to do.) In this case, the > entire gensrc:ing could move to jdk.jdwp.agent, and possibly even into > a single call to the build tool to generate all three files. JDWP.java is the debugger side of the wire protocol and so jdk.jdi is the right module for this class. I haven't been following this thread closely but are you planning to move make/data/jdwp/jdwp.spec or the jdwpgen tool? If not then would it help if this tool were updated with an option to to just generate the source files for debugger or debuggee side rather than both? That seems to be your option #2 which I assume would mean running the tool twice. -Alan From david.holmes at oracle.com Thu Apr 20 08:25:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 18:25:53 +1000 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> Message-ID: On 20/04/2017 5:57 PM, Magnus Ihse Bursie wrote: > On 2017-04-20 04:21, David Holmes wrote: >> On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: >>> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html >>> is no longer included in the generated documentation. The information >>> provided by that file should move to >>> src/jdk.jdi/share/classes/module-info.java instead. >> >> Looks good, but highlighted an error with the existing text: >> >> /** >> * Defines the Java Debugger Interface. >> + *

>> + * The Java™ Debug Interface (JDI) is a high level Java API >> providing >> >> The first line should read "Debug" not "Debugger". > > Good catch. > > I really didn't plan to make any editorial changes in this review, only > to move the contents to a place were it was once again included. > However, the text was apparently in need of some freshing up, so I tried > to fix what was pointed out. > >> >> Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" >> should be replaced by "The JDI". > > I love it when I get conflicting reviews! ;-) > > I'm sorry Dave, I'm afraid I can't do that. :-) "The JDI" just sounds > weird, and that's not how acronyms are typically referred to. So I've > sided with Alan here. If you don't agree, I'll back out that change and > you can fight it out by yourselves. :) It depends on the exact nature of the acronym. If you wrote this out you would say "The Java Debug Interface .." hence you should say "The JDI ...". :) Cheers, David ----- > And Mandy: I agree with the weird ellipses. I changed that to "etc.", > which I think captures the intent that the list was not exhaustive. > > Here is an updated review. It fixes the "Debugger" in the title, "The > JDI" -> "JDI" in two places, "..." -> "etc." and -> {@code}. > > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/ > > > /Magnus > >> >> Thanks, >> David >> >>> I also took the liberty of removing a bunch of other overview.html files >>> that are not included in the Javadoc anymore. They provided no real >>> informational value, and what text they contained is already expressed >>> similarly or better in the corresponding module-info.java files instead. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 >>> >>> >>> >>> /Magnus >>> > From martijnverburg at gmail.com Thu Apr 20 11:16:36 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 20 Apr 2017 12:16:36 +0100 Subject: Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported) Message-ID: Hi all, We've been putting together a community build farm and have wrangled from ARM machines. We are building from jdk8u and have the following configuration: ----- A new configuration has been successfully created in /home/jenkins/workspace/george_arm_test/openjdk/build/linux-aarch64-normal-server-release using configure arguments '--with-boot-jdk=/usr/lib/jvm/java-1.7.0-openjdk-arm64 --enable-ccache --with-jvm-variants=server --with-cacerts-file=/home/jenkins/workspace/george_arm_test/cacerts_area/security/cacerts --with-alsa=/home/jenkins/workspace/george_arm_test/alsa-lib-1.0.27.2 --with-freetype=/home/jenkins/workspace/george_arm_test/openjdk/installedfreetype --with-x=/usr/include/X11 --with-debug-level=release'. Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 Tools summary: * Boot JDK: java version "1.7.0_95" OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-3) OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode) (at /usr/lib/jvm/java-1.7.0-openjdk-arm64) * C Compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 version 5.4.0 (at /usr/bin/gcc-5) * C++ Compiler: g++-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 version 5.4.0 (at /usr/bin/g++-5) Build performance summary: * Cores to use: 16 * Memory limit: 128878 MB * ccache status: installed and in use Configured the JDK ------ We notice that the configure output states: checking if the C compiler supports "-m64"... no checking if the C++ compiler supports "-m64"... no checking if both compilers support "-m64"... no checking if the C compiler supports "-m64"... no checking if the C++ compiler supports "-m64"... no checking if both compilers support "-m64"... no ----- The hotspot build then fails (predictably enough) at: CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache /usr/bin/g++-5 -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/prims -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/cpu/x86/vm -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os_cpu/linux_x86/vm -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/linux/vm -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jenkins\"" -DHOTSPOT_LIB_ARCH=\"aarch64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header /home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled/precompiled.hpp -o precompiled.hpp.gch *g++-5: error: unrecognized command line option '-m64'* ----- We're inexperienced at build on this architecture, I assuming that we either need a compiler that supports -m64 or that -m64 should not be passed through in this case? Cheers, Martijn From erik.joelsson at oracle.com Thu Apr 20 11:33:46 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Apr 2017 13:33:46 +0200 Subject: Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported) In-Reply-To: References: Message-ID: <830055ef-504b-1dca-0ca8-4f4405f94454@oracle.com> I'm not familiar with building for arm/aarch64 on the native platform (i.e. not cross compiling) in jdk8u. It definitely looks like the configuration is confused. The command line for hotspot seems to think that it's supposed to produce an x86_64 binary using your aarch64 compiler. I suspect you will need to set more environment variables manually to trick the hotspot makefiles into doing the right thing. We fixed a lot of things in this area in JDK 9, where I'm pretty sure this would just work. /Erik On 2017-04-20 13:16, Martijn Verburg wrote: > Hi all, > > We've been putting together a community build farm and have wrangled from > ARM machines. We are building from jdk8u and have the following > configuration: > > ----- > > A new configuration has been successfully created in > /home/jenkins/workspace/george_arm_test/openjdk/build/linux-aarch64-normal-server-release > using configure arguments > '--with-boot-jdk=/usr/lib/jvm/java-1.7.0-openjdk-arm64 --enable-ccache > --with-jvm-variants=server > --with-cacerts-file=/home/jenkins/workspace/george_arm_test/cacerts_area/security/cacerts > --with-alsa=/home/jenkins/workspace/george_arm_test/alsa-lib-1.0.27.2 > --with-freetype=/home/jenkins/workspace/george_arm_test/openjdk/installedfreetype > --with-x=/usr/include/X11 --with-debug-level=release'. > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 > > Tools summary: > * Boot JDK: java version "1.7.0_95" OpenJDK Runtime Environment > (IcedTea 2.6.4) (7u95-2.6.4-3) OpenJDK 64-Bit Server VM (build 24.95-b01, > mixed mode) (at /usr/lib/jvm/java-1.7.0-openjdk-arm64) > * C Compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 > version 5.4.0 (at /usr/bin/gcc-5) > * C++ Compiler: g++-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 > version 5.4.0 (at /usr/bin/g++-5) > > Build performance summary: > * Cores to use: 16 > * Memory limit: 128878 MB > * ccache status: installed and in use > > Configured the JDK > > ------ > > We notice that the configure output states: > > checking if the C compiler supports "-m64"... no > checking if the C++ compiler supports "-m64"... no > checking if both compilers support "-m64"... no > checking if the C compiler supports "-m64"... no > checking if the C++ compiler supports "-m64"... no > checking if both compilers support "-m64"... no > > ----- > > The hotspot build then fails (predictably enough) at: > > CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache > /usr/bin/g++-5 -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/prims > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/cpu/x86/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os_cpu/linux_x86/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/linux/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\"" > -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jenkins\"" > -DHOTSPOT_LIB_ARCH=\"aarch64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 > -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 > -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe > -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -DVM_LITTLE_ENDIAN > -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -std=gnu++98 -c -MMD -MP -MF > ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header > /home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled/precompiled.hpp > -o precompiled.hpp.gch > *g++-5: error: unrecognized command line option '-m64'* > > ----- > > We're inexperienced at build on this architecture, I assuming that we > either need a compiler that supports -m64 or that -m64 should not be passed > through in this case? > > Cheers, > Martijn From aph at redhat.com Thu Apr 20 11:49:36 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Apr 2017 12:49:36 +0100 Subject: Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported) In-Reply-To: References: Message-ID: <7b93b926-3006-10af-034e-40def214d434@redhat.com> On 20/04/17 12:16, Martijn Verburg wrote: > We're inexperienced at build on this architecture, I assuming that we > either need a compiler that supports -m64 or that -m64 should not be passed > through in this case? You shouldn't have any great problem building JDK8: we do it all of the time. Exactly what is the URL that you checked out? It should be ssh://hg.openjdk.java.net/aarch64-port/jdk8u Andrew. From dalibor.topic at oracle.com Thu Apr 20 12:17:44 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 20 Apr 2017 14:17:44 +0200 Subject: Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported) In-Reply-To: References: Message-ID: If this is related to yesterday's similar query [0], then I assume you're using http://hg.openjdk.java.net/jdk8u/jdk8u/ for the build. There is no dedicated ARM port in JDK 8u. You would need to build the Zero interpreter instead, if you are building from the forest above, or, as Andrew suggested, use a different forest from the AArch64 Port Project. cheers, dalibor topic [0] http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018974.html On 20.04.2017 13:16, Martijn Verburg wrote: > Hi all, > > We've been putting together a community build farm and have wrangled from > ARM machines. We are building from jdk8u and have the following > configuration: > > ----- > > A new configuration has been successfully created in > /home/jenkins/workspace/george_arm_test/openjdk/build/linux-aarch64-normal-server-release > using configure arguments > '--with-boot-jdk=/usr/lib/jvm/java-1.7.0-openjdk-arm64 --enable-ccache > --with-jvm-variants=server > --with-cacerts-file=/home/jenkins/workspace/george_arm_test/cacerts_area/security/cacerts > --with-alsa=/home/jenkins/workspace/george_arm_test/alsa-lib-1.0.27.2 > --with-freetype=/home/jenkins/workspace/george_arm_test/openjdk/installedfreetype > --with-x=/usr/include/X11 --with-debug-level=release'. > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 > > Tools summary: > * Boot JDK: java version "1.7.0_95" OpenJDK Runtime Environment > (IcedTea 2.6.4) (7u95-2.6.4-3) OpenJDK 64-Bit Server VM (build 24.95-b01, > mixed mode) (at /usr/lib/jvm/java-1.7.0-openjdk-arm64) > * C Compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 > version 5.4.0 (at /usr/bin/gcc-5) > * C++ Compiler: g++-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 > version 5.4.0 (at /usr/bin/g++-5) > > Build performance summary: > * Cores to use: 16 > * Memory limit: 128878 MB > * ccache status: installed and in use > > Configured the JDK > > ------ > > We notice that the configure output states: > > checking if the C compiler supports "-m64"... no > checking if the C++ compiler supports "-m64"... no > checking if both compilers support "-m64"... no > checking if the C compiler supports "-m64"... no > checking if the C++ compiler supports "-m64"... no > checking if both compilers support "-m64"... no > > ----- > > The hotspot build then fails (predictably enough) at: > > CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache > /usr/bin/g++-5 -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/prims > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/cpu/x86/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os_cpu/linux_x86/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/linux/vm > -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\"" > -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jenkins\"" > -DHOTSPOT_LIB_ARCH=\"aarch64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 > -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 > -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe > -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -DVM_LITTLE_ENDIAN > -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -std=gnu++98 -c -MMD -MP -MF > ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header > /home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled/precompiled.hpp > -o precompiled.hpp.gch > *g++-5: error: unrecognized command line option '-m64'* > > ----- > > We're inexperienced at build on this architecture, I assuming that we > either need a compiler that supports -m64 or that -m64 should not be passed > through in this case? > > Cheers, > Martijn > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From martijnverburg at gmail.com Thu Apr 20 12:21:39 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 20 Apr 2017 13:21:39 +0100 Subject: Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported) In-Reply-To: References: Message-ID: Hi Erik/Andrew/Dalibor, Ah that clears it up - we were getting confused with what port was in mainstream or not. OK, we'll pick the ssh://hg.openjdk.java.net/ aarch64-port/jdk8u for our Java 8 build (Zero is interesting, but of less use to the wider community) and then we'll see what happens for 9 and 10 a little down the line. Thanks all again for the speedy assistance! Cheers, Martijn On 20 April 2017 at 13:17, dalibor topic wrote: > If this is related to yesterday's similar query [0], then I assume you're > using http://hg.openjdk.java.net/jdk8u/jdk8u/ for the build. > > There is no dedicated ARM port in JDK 8u. You would need to build the Zero > interpreter instead, if you are building from the forest above, or, as > Andrew suggested, use a different forest from the AArch64 Port Project. > > cheers, > dalibor topic > > [0] http://mail.openjdk.java.net/pipermail/build-dev/2017-April/ > 018974.html > > > On 20.04.2017 13:16, Martijn Verburg wrote: > >> Hi all, >> >> We've been putting together a community build farm and have wrangled from >> ARM machines. We are building from jdk8u and have the following >> configuration: >> >> ----- >> >> A new configuration has been successfully created in >> /home/jenkins/workspace/george_arm_test/openjdk/build/linux- >> aarch64-normal-server-release >> using configure arguments >> '--with-boot-jdk=/usr/lib/jvm/java-1.7.0-openjdk-arm64 --enable-ccache >> --with-jvm-variants=server >> --with-cacerts-file=/home/jenkins/workspace/george_arm_test/ >> cacerts_area/security/cacerts >> --with-alsa=/home/jenkins/workspace/george_arm_test/alsa-lib-1.0.27.2 >> --with-freetype=/home/jenkins/workspace/george_arm_test/open >> jdk/installedfreetype >> --with-x=/usr/include/X11 --with-debug-level=release'. >> >> Configuration summary: >> * Debug level: release >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.7.0_95" OpenJDK Runtime Environment >> (IcedTea 2.6.4) (7u95-2.6.4-3) OpenJDK 64-Bit Server VM (build 24.95-b01, >> mixed mode) (at /usr/lib/jvm/java-1.7.0-openjdk-arm64) >> * C Compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 >> version 5.4.0 (at /usr/bin/gcc-5) >> * C++ Compiler: g++-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 >> version 5.4.0 (at /usr/bin/g++-5) >> >> Build performance summary: >> * Cores to use: 16 >> * Memory limit: 128878 MB >> * ccache status: installed and in use >> >> Configured the JDK >> >> ------ >> >> We notice that the configure output states: >> >> checking if the C compiler supports "-m64"... no >> checking if the C++ compiler supports "-m64"... no >> checking if both compilers support "-m64"... no >> checking if the C compiler supports "-m64"... no >> checking if the C++ compiler supports "-m64"... no >> checking if both compilers support "-m64"... no >> >> ----- >> >> The hotspot build then fails (predictably enough) at: >> >> CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache >> /usr/bin/g++-5 -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/ >> src/share/vm/prims >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/ >> src/share/vm/precompiled >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/cpu/x86/vm >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/ >> src/os_cpu/linux_x86/vm >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/linux/vm >> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\"" >> -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jenkins\"" >> -DHOTSPOT_LIB_ARCH=\"aarch64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" >> -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 >> -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 >> -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti >> -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe >> -fno-strict-aliasing -g -fno-omit-frame-pointer -O3 -DVM_LITTLE_ENDIAN >> -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function >> -Wunused-value -std=gnu++98 -c -MMD -MP -MF >> ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header >> /home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/ >> share/vm/precompiled/precompiled.hpp >> -o precompiled.hpp.gch >> *g++-5: error: unrecognized command line option '-m64'* >> >> ----- >> >> We're inexperienced at build on this architecture, I assuming that we >> either need a compiler that supports -m64 or that -m64 should not be >> passed >> through in this case? >> >> Cheers, >> Martijn >> >> > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From magnus.ihse.bursie at oracle.com Thu Apr 20 13:49:14 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 15:49:14 +0200 Subject: RFR: JDK-8179022 Add serialization spec as markdown Message-ID: Here's the first step towards fixing JDK-8177434 . A framework is added for converting markdown specs to html using pandoc. The Java serialization spec is added in markdown format as a proof of concept. I also reintroduced the functionality to enable full docs if all prerequisites are present. Note that this fix is dependent on the patch for JDK-8178038 et al that is currently out for review. The webrev is created with that patch as baseline. This fix is part of JEP 299. I intend to push it to jdk9. Here's an example of the generated output: http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ Bug: https://bugs.openjdk.java.net/browse/JDK-8179022 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01 /Magnus From Alan.Bateman at oracle.com Thu Apr 20 13:59:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Apr 2017 14:59:06 +0100 Subject: RFR: JDK-8179022 Add serialization spec as markdown In-Reply-To: References: Message-ID: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com> On 20/04/2017 14:49, Magnus Ihse Bursie wrote: > Here's the first step towards fixing JDK-8177434 > . A framework is > added for converting markdown specs to html using pandoc. The Java > serialization spec is added in markdown format as a proof of concept. > I also reintroduced the functionality to enable full docs if all > prerequisites are present. > > Note that this fix is dependent on the patch for JDK-8178038 et al > that is currently out for review. The webrev is created with that > patch as baseline. > > This fix is part of JEP 299. I intend to push it to jdk9. > > Here's an example of the generated output: > http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179022 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01 I just skimmed this and notice this adds class.gif with output that I think is serialver. This tool has been changed in JDK 9 to drop the GUI and so this image and the reference to the "Show" button are now obsolete. I'm sure you don't want want to get into issues like this but we will need to submit a few bugs to ensure that some of the dusty documents are updated. -Alan From erik.joelsson at oracle.com Thu Apr 20 14:40:40 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Apr 2017 16:40:40 +0200 Subject: RFR: JDK-8179022 Add serialization spec as markdown In-Reply-To: References: Message-ID: The build changes look good to me. I can't comment on the actual .md files. /Erik On 2017-04-20 15:49, Magnus Ihse Bursie wrote: > Here's the first step towards fixing JDK-8177434 > . A framework is > added for converting markdown specs to html using pandoc. The Java > serialization spec is added in markdown format as a proof of concept. > I also reintroduced the functionality to enable full docs if all > prerequisites are present. > > Note that this fix is dependent on the patch for JDK-8178038 et al > that is currently out for review. The webrev is created with that > patch as baseline. > > This fix is part of JEP 299. I intend to push it to jdk9. > > Here's an example of the generated output: > http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179022 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01 > > /Magnus From mandy.chung at oracle.com Thu Apr 20 14:56:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 07:56:18 -0700 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> Message-ID: <55B9D093-687F-428E-8DD1-DFA9D1F2A8C2@oracle.com> > On Apr 20, 2017, at 12:57 AM, Magnus Ihse Bursie wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/ Looks good. Mandy From mandy.chung at oracle.com Thu Apr 20 16:26:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 09:26:58 -0700 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> Message-ID: > On Apr 20, 2017, at 12:21 AM, Magnus Ihse Bursie wrote: > > > > On 2017-04-20 00:54, Mandy Chung wrote: >>> On Apr 19, 2017, at 5:36 AM, Magnus Ihse Bursie wrote: >>> >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 >> 368 JDWP_PROTOCOL := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html >> 369 $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ >> 370 FILES := $(JDWP_PROTOCOL), \ >> 371 DEST := $(JAVADOC_OUTPUTDIR)/specs/jdwp, \ >> 372 )) >> >> Is there any reason why jdwp-protocol.html is not copied to the ?specs? directory? > Yes, there is. This document is only part of the jdwp specification. This is dynamically generated. The rest of the jdwp specification is static. I have a prototype that, in light of JEP 299, copies the rest of the specification to "specs/jdwp", but at the moment it's unclear if that's going to get into JDK 9. Nevertheless, I think it is prudent to prepare for this structure. > Should the specs be organized with modular layout? e.g. docs/specs/$MODULE. In this case, it would be docs/specs/jdk.jdwp.agent. Jon - have you considered the specs be organized with modular layout? >> docs-docs-specs copies specs to jdk docs. I would expect there will be docs-javase-specs to copy specs from Java SE modules to javase-docs/specs but missing. > You mean docs-jdk-specs? Oops.. typo. > > While there is a superficial similarity between "docs-jdk" and "docs-javase", there's a difference in purpose. The latter is only created for a special-purpose formal API verification, and is not supposed to be shipped. This means that it's not built by e.g. "docs-image". I assumed that only the API would be needed for that. Some spec are Java SE such as JNI, JVM TI, JAR file spec that should be included when building "docs-javase" target. So copying of $MODULE/share/specs to $JAVADOC_OUTPUTDIR/specs should also be done for docs-javase but only the selected Java SE modules. JDI and JDWP are not Java SE and no need to handle that. I?m okay if you prefer separating ?copying of Java SE specs" for ?docs-javase? from this issue. Mandy From Alan.Bateman at oracle.com Thu Apr 20 16:32:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Apr 2017 17:32:01 +0100 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> Message-ID: On 20/04/2017 17:26, Mandy Chung wrote: > JDI and JDWP are not Java SE and no need to handle that. > Just a small correction to this. The JDWP spec is Java SE. JDI is course JDK-specific, as is the JDWP transport interface. -Alan From mandy.chung at oracle.com Thu Apr 20 16:44:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 09:44:58 -0700 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <87e47dff-f680-adab-c7d0-8117217f69db@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <4D5EE0BD-16A0-4976-9EF0-32FBA0CA56EB@oracle.com> <87e47dff-f680-adab-c7d0-8117217f69db@oracle.com> Message-ID: <28E68563-111A-4885-9DFF-FE490AD2D475@oracle.com> > On Apr 20, 2017, at 12:37 AM, Magnus Ihse Bursie wrote: > > On 2017-04-20 01:11, Mandy Chung wrote: >>> On Apr 19, 2017, at 3:54 PM, Mandy Chung wrote: >>> >>> >>>> On Apr 19, 2017, at 5:36 AM, Magnus Ihse Bursie wrote: >>>> >>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178038-javadoc-specs/webrev.01 >>> 368 JDWP_PROTOCOL := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html >> One more thing: jdwp-protocol belongs to jdk.jdwp.agent module. >> It would be nice if Gensrc-jdk.jdi.gmk can be cleaned up. > I agree that it would be nice if Gensrc-jdk.jdi.gmk can be cleaned up. Unfortunately it's a bit tangled up right now, and a proper solution might be too radical for this change. But let's see if we can sort this out, perhaps with your module expertise a solution is possible. > > We need to gensrc three files: > 1) $(SUPPORT_OUTPUTDIR)/headers/jdk.jdwp.agent/JDWPCommands.h > 2) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/com/sun/tools/jdi/JDWP.java > 3) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/jdwp-protocol.html > > 1 and 2 are being created by the same call to the build tool, and 3 is created by a separate call. I'm not sure if this is possible to change. It looks like it might. > > 1 already belongs to jdk.jdwp.agent, and 3 could easily be moved there. The problem is 2, which is needed when compiling the jdk.jdi module. > > I have two suggestions, but I don't know if either of them is possible: > 1) Move the JDWP.java file to jdk.jdwp.agent, and make sure it's properly exported from jdk.jdwp.agent to jdk.jdi. (From my point of view, this seems like the logical thing to do.) In this case, the entire gensrc:ing could move to jdk.jdwp.agent, and possibly even into a single call to the build tool to generate all three files. > As Alan said, JDWP.java is part of jdk.jdi. No need to be moved. > 2) Split the gensrc into one for jdk.jdwp.agent that generated 1 and 3, and one for jdk.jdi that generates 2. It might require us to generate a dummy 2 and 1 that are just thrown away, if the tool cannot be told not to generate both 1 and 2 at the same time. I checked that build.tool.jdwpgen.Main can be invoked with -doc option only to generate 2 and it can be invoked separately with -include option to generate 1. Moving 1 and 3 to Gensrc-jdk.jdwp.agent.gmk seems like would work without change to the jdwpgen tool. Mandy From mandy.chung at oracle.com Thu Apr 20 16:47:34 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 09:47:34 -0700 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> Message-ID: > On Apr 20, 2017, at 9:32 AM, Alan Bateman wrote: > > > > On 20/04/2017 17:26, Mandy Chung wrote: >> JDI and JDWP are not Java SE and no need to handle that. >> > Just a small correction to this. The JDWP spec is Java SE. JDI is course JDK-specific, as is the JDWP transport interface. Thanks for the correction. In this case, which module should jdwp-protocol.html spec belong to? Not jdk.jdwp.agent then. The suggestion of the modular specs layout in the docs bundle may not apply. Mandy From Alan.Bateman at oracle.com Thu Apr 20 16:55:31 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Apr 2017 17:55:31 +0100 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> Message-ID: <6ef1d4dc-a28b-d615-88d1-a4d666d131ff@oracle.com> On 20/04/2017 17:47, Mandy Chung wrote: > In this case, which module should jdwp-protocol.html spec belong to? Not jdk.jdwp.agent then. > The suggestion of the modular specs layout in the docs bundle may not apply. > jdwp-protocol.html is the JDWP protocol so it's implemented by both the debugger and debugee. Typically the debugger sends a command and the debuggee responds with a reply. There are also event messages that the target VM/debuggee sends to the debugger. If there is place for Java SE documentation then it might be best to put it there rather than trying to put it in jdk.jdi or jdk.jdwp.agent. -Alan From jonathan.gibbons at oracle.com Thu Apr 20 18:02:05 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Apr 2017 11:02:05 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> Message-ID: <58F8F79D.8080305@oracle.com> David, Magnus, Yes, this is somewhat Oracle-specific (more accurately it is JDK-specific, which is why this is a proposed to be a JDK build-time taglet, and not a standard tag in the standard doclet), but it is no worse than the explicit Oracle-specific URLs that have been used up to now, or the relative links using {@docRoot}/../stuff which assume that "stuff " is available nearby somehow. I would also go further and say this is better that the existing methodology because it abstracts all the linking to a single taglet, removing it from inline in the doc comments. Yes, the currently proposed taglet may assume the existence of single "base URL", but anyone with an alternate implementation of OpenJDK could change the impl of the taglet to use any other mechanism to establish the link. Doing a "strings in switch" on the identifier to select a URL comes to mind, and avoids anyone having to edit the main source doc comments. -- Jon On 04/19/2017 01:37 PM, David Holmes wrote: > On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >> >> We could potentially make the default URL to be "some" cgi url, >> and have the build system specify the URL all the time, in our >> case it would be the Oracle documentation URL. >> >> Would this be an acceptable approach ? > > I'm not sure what you mean. I have a hard time seeing how a simple > identifier (that will be fixed in the file using the taglet) can be > attached to an arbitrary URL to yield a valid result. As Magnus said, > being able to change the URL is good, but it still requires the same > "kind" of URL where the identifier is used as a key. > > Imagine you have all the documentation locally on your machine then > try to figure out how you could link to other local documentation > using this scheme. > > David > >> Kumar >> >>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>> Hello, >>>>> >>>>> As explained in the JBS issue [1], this new taglet enables API >>>>> documents >>>>> to contain the extLink tag to link external sources. >>>>> >>>>> Please review the webrev [2]. >>>> Changes looks good. >>>> >>>> Just a reflection: This is heavily biased to Oracle documentation. >>>> Even >>>> if it's possible to override the URL via a system property, it assumes >>>> the Oracle URL format and id name. Just wondering a bit how that fits >>>> with the OpenJDK philosophy. >>> >>> I have to agree, this is not at all general purpose but totally Oracle >>> documentation centric. >>> >>> David >>> ----- >>> >>> >>>> /Magnus >>>> >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>> >> From Roger.Riggs at Oracle.com Thu Apr 20 18:08:43 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 20 Apr 2017 14:08:43 -0400 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F7CCFA.7050604@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> <58F7CCFA.7050604@oracle.com> Message-ID: <6953e1d7-338a-e03b-0590-4e2e8c0cb880@Oracle.com> 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} form of MessageFormat might clash less with the URL encoding syntax. $.02, Roger On 4/19/2017 4:47 PM, Kumar Srinivasan wrote: > > On 4/19/2017 1:37 PM, David Holmes wrote: >> On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >>> >>> We could potentially make the default URL to be "some" cgi url, >>> and have the build system specify the URL all the time, in our >>> case it would be the Oracle documentation URL. >>> >>> Would this be an acceptable approach ? >> >> I'm not sure what you mean. I have a hard time seeing how a simple >> identifier (that will be fixed in the file using the taglet) can be >> attached to an arbitrary URL to yield a valid result. As Magnus said, >> being able to change the URL is good, but it still requires the same >> "kind" of URL where the identifier is used as a key. >> >> Imagine you have all the documentation locally on your machine then >> try to figure out how you could link to other local documentation >> using this scheme. > > > Ok I see, I am going to defer this to Jon Gibbons. > > Kumar > >> >> David >> >>> Kumar >>> >>>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>>> Hello, >>>>>> >>>>>> As explained in the JBS issue [1], this new taglet enables API >>>>>> documents >>>>>> to contain the extLink tag to link external sources. >>>>>> >>>>>> Please review the webrev [2]. >>>>> Changes looks good. >>>>> >>>>> Just a reflection: This is heavily biased to Oracle documentation. >>>>> Even >>>>> if it's possible to override the URL via a system property, it >>>>> assumes >>>>> the Oracle URL format and id name. Just wondering a bit how that fits >>>>> with the OpenJDK philosophy. >>>> >>>> I have to agree, this is not at all general purpose but totally Oracle >>>> documentation centric. >>>> >>>> David >>>> ----- >>>> >>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Thanks >>>>>> Kumar >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>>> >>> > From mandy.chung at oracle.com Thu Apr 20 18:37:19 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 11:37:19 -0700 Subject: Review Request: JDK-8179035: Include tool modules in unified docs Message-ID: <32E5AC49-DE5E-4E0B-A2F8-D69EB53A757C@oracle.com> A few modules are missing in the unified docs such as jdk.jcmd, jdk.jdwp.agent, jdk.jstatd, etc. Some tool modules are providers and they were in the initial set. The modules that are neither a provider nor exporting any API package are missed in the initial patch. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179035/webrev.00/ Mandy From magnus.ihse.bursie at oracle.com Thu Apr 20 18:47:13 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 20:47:13 +0200 Subject: RFR: JDK-8179022 Add serialization spec as markdown In-Reply-To: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com> References: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com> Message-ID: On 2017-04-20 15:59, Alan Bateman wrote: > On 20/04/2017 14:49, Magnus Ihse Bursie wrote: > >> Here's the first step towards fixing JDK-8177434 >> . A framework is >> added for converting markdown specs to html using pandoc. The Java >> serialization spec is added in markdown format as a proof of concept. >> I also reintroduced the functionality to enable full docs if all >> prerequisites are present. >> >> Note that this fix is dependent on the patch for JDK-8178038 et al >> that is currently out for review. The webrev is created with that >> patch as baseline. >> >> This fix is part of JEP 299. I intend to push it to jdk9. >> >> Here's an example of the generated output: >> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01 > I just skimmed this and notice this adds class.gif with output that I > think is serialver. This tool has been changed in JDK 9 to drop the > GUI and so this image and the reference to the "Show" button are now > obsolete. I'm sure you don't want want to get into issues like this > but we will need to submit a few bugs to ensure that some of the dusty > documents are updated. You are right that I do not want to make any substantial changes to the documentation. I have made an effort to make sure the markdown is of a high quality (like any other source code), so that it should be easy to read and update. In this process I noticed a few minor issues (like syntactic errors in the examples, or incorrect/inconsistent formatting) which I have fixed. I have also noticed some things that sound like they need to be updated, like the serialver stuff. I'm no expert on serialization, but perhaps I can have an offline chat with someone who are, and come with a couple of suggestions on things to improve with the documentation. --- I just noticed that I had missed to do "hg add" so webrev did not pick up my new script that creates the pandoc bundle. Here's an updated webrev that added this: http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02 /Magnus > > -Alan From Roger.Riggs at Oracle.com Thu Apr 20 18:51:43 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 20 Apr 2017 14:51:43 -0400 Subject: RFR: JDK-8179022 Add serialization spec as markdown In-Reply-To: References: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com> Message-ID: <9c7e600e-002c-4423-630b-796c54d206b1@Oracle.com> 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 couple of months ago. That's going to take more work to verify. Thanks, Roger On 4/20/2017 2:47 PM, Magnus Ihse Bursie wrote: > On 2017-04-20 15:59, Alan Bateman wrote: >> On 20/04/2017 14:49, Magnus Ihse Bursie wrote: >> >>> Here's the first step towards fixing JDK-8177434 >>> . A framework is >>> added for converting markdown specs to html using pandoc. The Java >>> serialization spec is added in markdown format as a proof of >>> concept. I also reintroduced the functionality to enable full docs >>> if all prerequisites are present. >>> >>> Note that this fix is dependent on the patch for JDK-8178038 et al >>> that is currently out for review. The webrev is created with that >>> patch as baseline. >>> >>> This fix is part of JEP 299. I intend to push it to jdk9. >>> >>> Here's an example of the generated output: >>> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01 >> I just skimmed this and notice this adds class.gif with output that I >> think is serialver. This tool has been changed in JDK 9 to drop the >> GUI and so this image and the reference to the "Show" button are now >> obsolete. I'm sure you don't want want to get into issues like this >> but we will need to submit a few bugs to ensure that some of the >> dusty documents are updated. > > You are right that I do not want to make any substantial changes to > the documentation. I have made an effort to make sure the markdown is > of a high quality (like any other source code), so that it should be > easy to read and update. In this process I noticed a few minor issues > (like syntactic errors in the examples, or incorrect/inconsistent > formatting) which I have fixed. > > I have also noticed some things that sound like they need to be > updated, like the serialver stuff. I'm no expert on serialization, but > perhaps I can have an offline chat with someone who are, and come with > a couple of suggestions on things to improve with the documentation. > > --- > > I just noticed that I had missed to do "hg add" so webrev did not pick > up my new script that creates the pandoc bundle. Here's an updated > webrev that added this: > > http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02 > > > /Magnus > >> >> -Alan > From mandy.chung at oracle.com Thu Apr 20 19:10:03 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 12:10:03 -0700 Subject: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory In-Reply-To: <6ef1d4dc-a28b-d615-88d1-a4d666d131ff@oracle.com> References: <14fabc20-9ad1-1622-2b52-805123e14764@oracle.com> <1D2B6568-65BB-4CF4-B981-E001EF7CDE10@oracle.com> <76f29e54-dfd9-636a-2e68-216f5b2a32fd@oracle.com> <6ef1d4dc-a28b-d615-88d1-a4d666d131ff@oracle.com> Message-ID: > On Apr 20, 2017, at 9:55 AM, Alan Bateman wrote: > > On 20/04/2017 17:47, Mandy Chung wrote: > >> In this case, which module should jdwp-protocol.html spec belong to? Not jdk.jdwp.agent then. >> The suggestion of the modular specs layout in the docs bundle may not apply. >> > jdwp-protocol.html is the JDWP protocol so it's implemented by both the debugger and debugee. Typically the debugger sends a command and the debuggee responds with a reply. There are also event messages that the target VM/debuggee sends to the debugger. If there is place for Java SE documentation then it might be best to put it there rather than trying to put it in jdk.jdi or jdk.jdwp.agent. Agree. Magnus?s proposed patch to put jdwp-protocol.html in the spec/jdwp directory is fine. Mandy From lance.andersen at oracle.com Thu Apr 20 19:16:57 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 20 Apr 2017 15:16:57 -0400 Subject: Review Request: JDK-8179035: Include tool modules in unified docs In-Reply-To: <32E5AC49-DE5E-4E0B-A2F8-D69EB53A757C@oracle.com> References: <32E5AC49-DE5E-4E0B-A2F8-D69EB53A757C@oracle.com> Message-ID: The javadocs read fine. Probably need to update the copyright date for the module-info.java files Best Lance > On Apr 20, 2017, at 2:37 PM, Mandy Chung wrote: > > A few modules are missing in the unified docs such as jdk.jcmd, > jdk.jdwp.agent, jdk.jstatd, etc. Some tool modules are providers > and they were in the initial set. The modules that are neither > a provider nor exporting any API package are missed in the initial > patch. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179035/webrev.00/ > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Thu Apr 20 19:28:10 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 12:28:10 -0700 Subject: RFR: JDK-8179022 Add serialization spec as markdown In-Reply-To: References: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com> Message-ID: <5ED77D59-502A-421F-9445-885B8E2616C5@oracle.com> > On Apr 20, 2017, at 11:47 AM, Magnus Ihse Bursie wrote: > > http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02 A passing comment. Copyright header is missing in make/devkit/createPandocBundle.sh Mandy From jonathan.gibbons at oracle.com Thu Apr 20 21:41:45 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Apr 2017 14:41:45 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F7A279.2020707@oracle.com> References: <58F65070.6000508@oracle.com> <3e448d61-e3ef-1ea8-4b60-2d3a0cc5a92e@oracle.com> <58F65A5D.1000701@oracle.com> <58F692ED.9040003@oracle.com> <58F7A279.2020707@oracle.com> Message-ID: <58F92B19.5040304@oracle.com> OK by me. -- Jon On 04/19/2017 10:46 AM, Kumar Srinivasan wrote: > Have made the following changes: > * fixed the indentations, basically pointed the IDE and asked it to > reformat the whole file > * fixed regex, to be defensive against leading WS, though the > DocCommentParser > whacks the WS. > > Please see updated webrev: > http://cr.openjdk.java.net/~ksrini/8178725/webrev.01/ > > Thanks > Kumar > > > On 4/18/2017 3:27 PM, Jonathan Gibbons wrote: >> The use of double quotes in the example might lead one to incorrectly >> believe that they are required. >> >> The example should work without the quotes: >> >> 43 /** >> 44 * An inline tag to conveniently insert an external link. >> 45 * The tag can be used as follows: >> 46 * {@extLink name description}, for example >> 47 *

>> 48 * {@code >> 49 * Please see {@extLink Borealis a spectacular} sight. >> 50 * } >> 51 *

>> 52 * will produce the following html >> 53 *

>> 54 * {@code >> 55 * Please see > href="https://www.oracle.com/pls/topic/lookup?ctx=javase9&id=Borealis">a >> spectacular sight. >> 56 * } >> 57 * } >> 58 */ >> >> >> The indentation in both the comment and the source code is a bit >> inconsistent. Is that an extra } on line 57? >> >> The regex will fail if there are too many spaces between "{@extLink" >> and the name. [1] >> >> -- Jon >> >> >> [1]: >> https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/ >> >> >> On 04/18/2017 11:26 AM, Kumar Srinivasan wrote: >>> >>> Thanks Erik, yes will wait for Magnus' and Jon's comments. >>> >>> Kumar >>> >>>> The build change looks ok to me, but Magnus should definitely look >>>> at this since he is so heavily involved in the Javadoc build right >>>> now. >>>> >>>> /Erik >>>> >>>> >>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>> Hello, >>>>> >>>>> As explained in the JBS issue [1], this new taglet enables API >>>>> documents >>>>> to contain the extLink tag to link external sources. >>>>> >>>>> Please review the webrev [2]. >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Apr 20 21:53:03 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 23:53:03 +0200 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <58F8F79D.8080305@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> <58F8F79D.8080305@oracle.com> Message-ID: <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> On 2017-04-20 20:02, Jonathan Gibbons wrote: > David, Magnus, > > Yes, this is somewhat Oracle-specific (more accurately it is > JDK-specific, which is why this is a proposed to be a JDK build-time > taglet, and not a standard tag in the standard doclet), but it is no > worse than the explicit Oracle-specific URLs that have been used up to > now, or the relative links using {@docRoot}/../stuff which assume > that "stuff " is available nearby somehow. I would also go further > and say this is better that the existing methodology because it > abstracts all the linking to a single taglet, removing it from inline > in the doc comments. I agree, it's in no way worse than what already existed. But it shed light on the somewhat unclear division between online Oracle documentation and OpenJDK documentation. Just to be clear: I do not oppose the fix. It looks good to me. If anything, there was a bit of a clash between on the one hand providing a means for overriding the URL, but on the other hand not really making it as general as it could be. Either removing the possibility to override it (and, as you say, let an alternative implementation change the code of the taglet itself), or as Roger suggest, using a more general mechanism like MessageFormat would have the code make slightly more sense. The simplest way is probably to skip the property override, which doesn't get used anyhow right now (and therefore suspect according to "if you don't test it, it is (or will become) broken"). /Magnus > Yes, the currently proposed taglet may assume the existence of single > "base URL", but anyone with an alternate implementation of OpenJDK > could change the impl of the taglet to use any other mechanism to > establish the link. Doing a "strings in switch" on the identifier to > select a URL comes to mind, and avoids anyone having to edit the main > source doc comments. > > -- Jon > > > > On 04/19/2017 01:37 PM, David Holmes wrote: >> On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >>> >>> We could potentially make the default URL to be "some" cgi url, >>> and have the build system specify the URL all the time, in our >>> case it would be the Oracle documentation URL. >>> >>> Would this be an acceptable approach ? >> >> I'm not sure what you mean. I have a hard time seeing how a simple >> identifier (that will be fixed in the file using the taglet) can be >> attached to an arbitrary URL to yield a valid result. As Magnus said, >> being able to change the URL is good, but it still requires the same >> "kind" of URL where the identifier is used as a key. >> >> Imagine you have all the documentation locally on your machine then >> try to figure out how you could link to other local documentation >> using this scheme. >> >> David >> >>> Kumar >>> >>>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>>> Hello, >>>>>> >>>>>> As explained in the JBS issue [1], this new taglet enables API >>>>>> documents >>>>>> to contain the extLink tag to link external sources. >>>>>> >>>>>> Please review the webrev [2]. >>>>> Changes looks good. >>>>> >>>>> Just a reflection: This is heavily biased to Oracle documentation. >>>>> Even >>>>> if it's possible to override the URL via a system property, it >>>>> assumes >>>>> the Oracle URL format and id name. Just wondering a bit how that fits >>>>> with the OpenJDK philosophy. >>>> >>>> I have to agree, this is not at all general purpose but totally Oracle >>>> documentation centric. >>>> >>>> David >>>> ----- >>>> >>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Thanks >>>>>> Kumar >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>>> >>> > From jonathan.gibbons at oracle.com Thu Apr 20 22:02:24 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Apr 2017 15:02:24 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> <58F8F79D.8080305@oracle.com> <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> Message-ID: <07bdf639-615f-8a10-6009-9c5e43ed6439@oracle.com> On 4/20/17 2:53 PM, Magnus Ihse Bursie wrote: > On 2017-04-20 20:02, Jonathan Gibbons wrote: >> David, Magnus, >> >> Yes, this is somewhat Oracle-specific (more accurately it is >> JDK-specific, which is why this is a proposed to be a JDK build-time >> taglet, and not a standard tag in the standard doclet), but it is no >> worse than the explicit Oracle-specific URLs that have been used up >> to now, or the relative links using {@docRoot}/../stuff which assume >> that "stuff " is available nearby somehow. I would also go further >> and say this is better that the existing methodology because it >> abstracts all the linking to a single taglet, removing it from inline >> in the doc comments. > I agree, it's in no way worse than what already existed. But it shed > light on the somewhat unclear division between online Oracle > documentation and OpenJDK documentation. > > Just to be clear: I do not oppose the fix. It looks good to me. > > If anything, there was a bit of a clash between on the one hand > providing a means for overriding the URL, but on the other hand not > really making it as general as it could be. Either removing the > possibility to override it (and, as you say, let an alternative > implementation change the code of the taglet itself), or as Roger > suggest, using a more general mechanism like MessageFormat would have > the code make slightly more sense. The simplest way is probably to > skip the property override, which doesn't get used anyhow right now > (and therefore suspect according to "if you don't test it, it is (or > will become) broken"). > I'd be OK with removing the ability to override the URL. -- Jon > /Magnus > >> Yes, the currently proposed taglet may assume the existence of >> single "base URL", but anyone with an alternate implementation of >> OpenJDK could change the impl of the taglet to use any other >> mechanism to establish the link. Doing a "strings in switch" on the >> identifier to select a URL comes to mind, and avoids anyone having to >> edit the main source doc comments. >> >> -- Jon >> >> >> >> On 04/19/2017 01:37 PM, David Holmes wrote: >>> On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >>>> >>>> We could potentially make the default URL to be "some" cgi url, >>>> and have the build system specify the URL all the time, in our >>>> case it would be the Oracle documentation URL. >>>> >>>> Would this be an acceptable approach ? >>> >>> I'm not sure what you mean. I have a hard time seeing how a simple >>> identifier (that will be fixed in the file using the taglet) can be >>> attached to an arbitrary URL to yield a valid result. As Magnus >>> said, being able to change the URL is good, but it still requires >>> the same "kind" of URL where the identifier is used as a key. >>> >>> Imagine you have all the documentation locally on your machine then >>> try to figure out how you could link to other local documentation >>> using this scheme. >>> >>> David >>> >>>> Kumar >>>> >>>>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>>>> Hello, >>>>>>> >>>>>>> As explained in the JBS issue [1], this new taglet enables API >>>>>>> documents >>>>>>> to contain the extLink tag to link external sources. >>>>>>> >>>>>>> Please review the webrev [2]. >>>>>> Changes looks good. >>>>>> >>>>>> Just a reflection: This is heavily biased to Oracle >>>>>> documentation. Even >>>>>> if it's possible to override the URL via a system property, it >>>>>> assumes >>>>>> the Oracle URL format and id name. Just wondering a bit how that >>>>>> fits >>>>>> with the OpenJDK philosophy. >>>>> >>>>> I have to agree, this is not at all general purpose but totally >>>>> Oracle >>>>> documentation centric. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Kumar >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>>>> >>>> >> > From magnus.ihse.bursie at oracle.com Thu Apr 20 22:20:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Apr 2017 00:20:37 +0200 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 Message-ID: We should switch all uses of the javadoc tool to generate documentation in HTML 5, using the -html5 option. Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 Patch inline: diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk --- a/make/Javadoc.gmk +++ b/make/Javadoc.gmk @@ -84,7 +84,7 @@ # The initial set of options for javadoc JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords -notimestamp \ -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex --system none \ - --expand-requires transitive + -html5 --expand-requires transitive # Should we add DRAFT stamps to the generated javadoc? ifeq ($(VERSION_IS_GA), true) /Magnus From kumar.x.srinivasan at oracle.com Thu Apr 20 22:36:19 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 20 Apr 2017 15:36:19 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> <58F8F79D.8080305@oracle.com> <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> Message-ID: <58F937E3.2030309@oracle.com> Thanks for all the comments and feed back, I will go with what we have, for now, likely its not the last time we will be touching this before jdk9 is done. Kumar > On 2017-04-20 20:02, Jonathan Gibbons wrote: >> David, Magnus, >> >> Yes, this is somewhat Oracle-specific (more accurately it is >> JDK-specific, which is why this is a proposed to be a JDK build-time >> taglet, and not a standard tag in the standard doclet), but it is no >> worse than the explicit Oracle-specific URLs that have been used up >> to now, or the relative links using {@docRoot}/../stuff which assume >> that "stuff " is available nearby somehow. I would also go further >> and say this is better that the existing methodology because it >> abstracts all the linking to a single taglet, removing it from inline >> in the doc comments. > I agree, it's in no way worse than what already existed. But it shed > light on the somewhat unclear division between online Oracle > documentation and OpenJDK documentation. > > Just to be clear: I do not oppose the fix. It looks good to me. > > If anything, there was a bit of a clash between on the one hand > providing a means for overriding the URL, but on the other hand not > really making it as general as it could be. Either removing the > possibility to override it (and, as you say, let an alternative > implementation change the code of the taglet itself), or as Roger > suggest, using a more general mechanism like MessageFormat would have > the code make slightly more sense. The simplest way is probably to > skip the property override, which doesn't get used anyhow right now > (and therefore suspect according to "if you don't test it, it is (or > will become) broken"). > > /Magnus > >> Yes, the currently proposed taglet may assume the existence of >> single "base URL", but anyone with an alternate implementation of >> OpenJDK could change the impl of the taglet to use any other >> mechanism to establish the link. Doing a "strings in switch" on the >> identifier to select a URL comes to mind, and avoids anyone having to >> edit the main source doc comments. >> >> -- Jon >> >> >> >> On 04/19/2017 01:37 PM, David Holmes wrote: >>> On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >>>> >>>> We could potentially make the default URL to be "some" cgi url, >>>> and have the build system specify the URL all the time, in our >>>> case it would be the Oracle documentation URL. >>>> >>>> Would this be an acceptable approach ? >>> >>> I'm not sure what you mean. I have a hard time seeing how a simple >>> identifier (that will be fixed in the file using the taglet) can be >>> attached to an arbitrary URL to yield a valid result. As Magnus >>> said, being able to change the URL is good, but it still requires >>> the same "kind" of URL where the identifier is used as a key. >>> >>> Imagine you have all the documentation locally on your machine then >>> try to figure out how you could link to other local documentation >>> using this scheme. >>> >>> David >>> >>>> Kumar >>>> >>>>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>>>> Hello, >>>>>>> >>>>>>> As explained in the JBS issue [1], this new taglet enables API >>>>>>> documents >>>>>>> to contain the extLink tag to link external sources. >>>>>>> >>>>>>> Please review the webrev [2]. >>>>>> Changes looks good. >>>>>> >>>>>> Just a reflection: This is heavily biased to Oracle >>>>>> documentation. Even >>>>>> if it's possible to override the URL via a system property, it >>>>>> assumes >>>>>> the Oracle URL format and id name. Just wondering a bit how that >>>>>> fits >>>>>> with the OpenJDK philosophy. >>>>> >>>>> I have to agree, this is not at all general purpose but totally >>>>> Oracle >>>>> documentation centric. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Kumar >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>>>> >>>> >> > From jonathan.gibbons at oracle.com Thu Apr 20 22:42:21 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Apr 2017 15:42:21 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: References: Message-ID: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> We probably want to set --doclint-format html5 for javac as well, for the benefit of compilations that run doclint. -- Jon On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: > We should switch all uses of the javadoc tool to generate > documentation in HTML 5, using the -html5 option. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 > Patch inline: > diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk > --- a/make/Javadoc.gmk > +++ b/make/Javadoc.gmk > @@ -84,7 +84,7 @@ > # The initial set of options for javadoc > JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords > -notimestamp \ > -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex > --system none \ > - --expand-requires transitive > + -html5 --expand-requires transitive > > # Should we add DRAFT stamps to the generated javadoc? > ifeq ($(VERSION_IS_GA), true) > > /Magnus From martinrb at google.com Fri Apr 21 01:08:59 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 20 Apr 2017 18:08:59 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> Message-ID: There would be a global cleanup involved for --doclint-format html5 A CSS expert can probably suggest replacements. [javac] ... src/main/java/util/Deque.java:30: error: attribute border for table only accepts "" or "1", use CSS instead: BORDER [javac] * On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > We probably want to set > > --doclint-format html5 > > for javac as well, for the benefit of compilations that run doclint. > > -- Jon > > > > On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: > >> We should switch all uses of the javadoc tool to generate documentation >> in HTML 5, using the -html5 option. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 >> Patch inline: >> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >> --- a/make/Javadoc.gmk >> +++ b/make/Javadoc.gmk >> @@ -84,7 +84,7 @@ >> # The initial set of options for javadoc >> JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords >> -notimestamp \ >> -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex --system >> none \ >> - --expand-requires transitive >> + -html5 --expand-requires transitive >> >> # Should we add DRAFT stamps to the generated javadoc? >> ifeq ($(VERSION_IS_GA), true) >> >> /Magnus >> > > From Alan.Bateman at oracle.com Fri Apr 21 07:33:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Apr 2017 08:33:37 +0100 Subject: Review Request: JDK-8179035: Include tool modules in unified docs In-Reply-To: <32E5AC49-DE5E-4E0B-A2F8-D69EB53A757C@oracle.com> References: <32E5AC49-DE5E-4E0B-A2F8-D69EB53A757C@oracle.com> Message-ID: <5295504e-2184-621e-7a02-4a7f6e243e8d@oracle.com> On 20/04/2017 19:37, Mandy Chung wrote: > A few modules are missing in the unified docs such as jdk.jcmd, > jdk.jdwp.agent, jdk.jstatd, etc. Some tool modules are providers > and they were in the initial set. The modules that are neither > a provider nor exporting any API package are missed in the initial > patch. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179035/webrev.00/ For jdk.rmic then it might be better to take the wording from the man page so that it reads: "... to generate stub and skeleton class files (JRMP protocol) and stub and tie class files (IIOP protocol) for remote objects." The proposed javadoc for jdk.pack looks okay to me. -Alan From erik.joelsson at oracle.com Fri Apr 21 08:03:05 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 21 Apr 2017 10:03:05 +0200 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: References: Message-ID: Looks good to me. /Erik On 2017-04-21 00:20, Magnus Ihse Bursie wrote: > We should switch all uses of the javadoc tool to generate > documentation in HTML 5, using the -html5 option. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 > Patch inline: > diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk > --- a/make/Javadoc.gmk > +++ b/make/Javadoc.gmk > @@ -84,7 +84,7 @@ > # The initial set of options for javadoc > JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords > -notimestamp \ > -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex > --system none \ > - --expand-requires transitive > + -html5 --expand-requires transitive > > # Should we add DRAFT stamps to the generated javadoc? > ifeq ($(VERSION_IS_GA), true) > > /Magnus From magnus.ihse.bursie at oracle.com Fri Apr 21 09:30:11 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Apr 2017 11:30:11 +0200 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> Message-ID: <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> Jon, Can you please open a separate bug for this? Just adding --doclint-format html5 generates a lot of failures, as Martin points out, so it's not feasible to do as part of this fix. /Magnus On 2017-04-21 03:08, Martin Buchholz wrote: > There would be a global cleanup involved for --doclint-format html5 > A CSS expert can probably suggest replacements. > > [javac] ... src/main/java/util/Deque.java:30: error: attribute border > for table only accepts "" or "1", use CSS instead: BORDER > [javac] *
> > > On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> We probably want to set >> >> --doclint-format html5 >> >> for javac as well, for the benefit of compilations that run doclint. >> >> -- Jon >> >> >> >> On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: >> >>> We should switch all uses of the javadoc tool to generate documentation >>> in HTML 5, using the -html5 option. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 >>> Patch inline: >>> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >>> --- a/make/Javadoc.gmk >>> +++ b/make/Javadoc.gmk >>> @@ -84,7 +84,7 @@ >>> # The initial set of options for javadoc >>> JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords >>> -notimestamp \ >>> -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex --system >>> none \ >>> - --expand-requires transitive >>> + -html5 --expand-requires transitive >>> >>> # Should we add DRAFT stamps to the generated javadoc? >>> ifeq ($(VERSION_IS_GA), true) >>> >>> /Magnus >>> >> From erik.joelsson at oracle.com Fri Apr 21 14:37:35 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 21 Apr 2017 16:37:35 +0200 Subject: RFR: JDK-8179078: Jib run-test-prebuilt profile missing dependency on bootjdk Message-ID: <1caf7e6e-e810-adab-896e-b5f80d3cd1c8@oracle.com> Hello, When using the run-test-prebuilt Jib profile to run tests, we need to set JT_JAVA to point to the boot jdk for jtreg. The configuration to set JT_JAVA is there, but I forgot to also add boot_jdk as a dependency on that profile. Bug: https://bugs.openjdk.java.net/browse/JDK-8179078 Patch: diff -r 111e2e7d00f4 common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js +++ b/common/conf/jib-profiles.js @@ -584,7 +584,7 @@ var testOnlyProfilesPrebuilt = { "run-test-prebuilt": { src: "src.conf", - dependencies: [ "jtreg", "gnumake", testedProfile + ".jdk", + dependencies: [ "jtreg", "gnumake", "boot_jdk", testedProfile + ".jdk", testedProfile + ".test", "src.full" ], work_dir: input.get("src.full", "install_path") + "/test", /Erik From Roger.Riggs at Oracle.com Fri Apr 21 14:46:01 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 21 Apr 2017 10:46:01 -0400 Subject: RFR: JDK-8179022 Add serialization spec as markdown In-Reply-To: <9c7e600e-002c-4423-630b-796c54d206b1@Oracle.com> References: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com> <9c7e600e-002c-4423-630b-796c54d206b1@Oracle.com> Message-ID: <0a1d5bd0-77a8-4fff-1479-d293bcf8ccf6@Oracle.com> 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 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 couple of months ago. > That's going to take more work to verify. > > Thanks, Roger > > > On 4/20/2017 2:47 PM, Magnus Ihse Bursie wrote: >> On 2017-04-20 15:59, Alan Bateman wrote: >>> On 20/04/2017 14:49, Magnus Ihse Bursie wrote: >>> >>>> Here's the first step towards fixing JDK-8177434 >>>> . A framework is >>>> added for converting markdown specs to html using pandoc. The Java >>>> serialization spec is added in markdown format as a proof of >>>> concept. I also reintroduced the functionality to enable full docs >>>> if all prerequisites are present. >>>> >>>> Note that this fix is dependent on the patch for JDK-8178038 et al >>>> that is currently out for review. The webrev is created with that >>>> patch as baseline. >>>> >>>> This fix is part of JEP 299. I intend to push it to jdk9. >>>> >>>> Here's an example of the generated output: >>>> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01 >>> I just skimmed this and notice this adds class.gif with output that >>> I think is serialver. This tool has been changed in JDK 9 to drop >>> the GUI and so this image and the reference to the "Show" button are >>> now obsolete. I'm sure you don't want want to get into issues like >>> this but we will need to submit a few bugs to ensure that some of >>> the dusty documents are updated. >> >> You are right that I do not want to make any substantial changes to >> the documentation. I have made an effort to make sure the markdown is >> of a high quality (like any other source code), so that it should be >> easy to read and update. In this process I noticed a few minor issues >> (like syntactic errors in the examples, or incorrect/inconsistent >> formatting) which I have fixed. >> >> I have also noticed some things that sound like they need to be >> updated, like the serialver stuff. I'm no expert on serialization, >> but perhaps I can have an offline chat with someone who are, and come >> with a couple of suggestions on things to improve with the >> documentation. >> >> --- >> >> I just noticed that I had missed to do "hg add" so webrev did not >> pick up my new script that creates the pandoc bundle. Here's an >> updated webrev that added this: >> >> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02 >> >> >> /Magnus >> >>> >>> -Alan >> > From erik.joelsson at oracle.com Fri Apr 21 14:43:37 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 21 Apr 2017 16:43:37 +0200 Subject: RFR: JDK-8179078: Jib run-test-prebuilt profile missing dependency on bootjdk In-Reply-To: <1caf7e6e-e810-adab-896e-b5f80d3cd1c8@oracle.com> References: <1caf7e6e-e810-adab-896e-b5f80d3cd1c8@oracle.com> Message-ID: <03f78b2c-8a2f-50e4-9f81-04f7db458b4a@oracle.com> (resending to include Christian) On 2017-04-21 16:37, Erik Joelsson wrote: > Hello, > > When using the run-test-prebuilt Jib profile to run tests, we need to > set JT_JAVA to point to the boot jdk for jtreg. The configuration to > set JT_JAVA is there, but I forgot to also add boot_jdk as a > dependency on that profile. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179078 > > Patch: > > diff -r 111e2e7d00f4 common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -584,7 +584,7 @@ > var testOnlyProfilesPrebuilt = { > "run-test-prebuilt": { > src: "src.conf", > - dependencies: [ "jtreg", "gnumake", testedProfile + ".jdk", > + dependencies: [ "jtreg", "gnumake", "boot_jdk", > testedProfile + ".jdk", > testedProfile + ".test", "src.full" > ], > work_dir: input.get("src.full", "install_path") + "/test", > > > /Erik > From christian.tornqvist at oracle.com Fri Apr 21 14:48:08 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 21 Apr 2017 10:48:08 -0400 Subject: RFR: JDK-8179078: Jib run-test-prebuilt profile missing dependency on bootjdk In-Reply-To: <03f78b2c-8a2f-50e4-9f81-04f7db458b4a@oracle.com> References: <1caf7e6e-e810-adab-896e-b5f80d3cd1c8@oracle.com> <03f78b2c-8a2f-50e4-9f81-04f7db458b4a@oracle.com> Message-ID: <27EE88B9-2BAB-4B91-94EB-9AAB28BCFBB2@oracle.com> Hi Erik, This looks good, I?ve verified that the fix works. Thanks for fixing this! Thanks, Christian > On Apr 21, 2017, at 10:43 AM, Erik Joelsson wrote: > > (resending to include Christian) > > > On 2017-04-21 16:37, Erik Joelsson wrote: >> Hello, >> >> When using the run-test-prebuilt Jib profile to run tests, we need to set JT_JAVA to point to the boot jdk for jtreg. The configuration to set JT_JAVA is there, but I forgot to also add boot_jdk as a dependency on that profile. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8179078 >> >> Patch: >> >> diff -r 111e2e7d00f4 common/conf/jib-profiles.js >> --- a/common/conf/jib-profiles.js >> +++ b/common/conf/jib-profiles.js >> @@ -584,7 +584,7 @@ >> var testOnlyProfilesPrebuilt = { >> "run-test-prebuilt": { >> src: "src.conf", >> - dependencies: [ "jtreg", "gnumake", testedProfile + ".jdk", >> + dependencies: [ "jtreg", "gnumake", "boot_jdk", testedProfile + ".jdk", >> testedProfile + ".test", "src.full" >> ], >> work_dir: input.get("src.full", "install_path") + "/test", >> >> >> /Erik >> > From mandy.chung at oracle.com Fri Apr 21 14:48:29 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 21 Apr 2017 07:48:29 -0700 Subject: Review Request: JDK-8179035: Include tool modules in unified docs In-Reply-To: <5295504e-2184-621e-7a02-4a7f6e243e8d@oracle.com> References: <32E5AC49-DE5E-4E0B-A2F8-D69EB53A757C@oracle.com> <5295504e-2184-621e-7a02-4a7f6e243e8d@oracle.com> Message-ID: > On Apr 21, 2017, at 12:33 AM, Alan Bateman wrote: > > On 20/04/2017 19:37, Mandy Chung wrote: > >> A few modules are missing in the unified docs such as jdk.jcmd, >> jdk.jdwp.agent, jdk.jstatd, etc. Some tool modules are providers >> and they were in the initial set. The modules that are neither >> a provider nor exporting any API package are missed in the initial >> patch. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179035/webrev.00/ > > For jdk.rmic then it might be better to take the wording from the man page so that it reads: > > "... to generate stub and skeleton class files (JRMP protocol) and stub and tie class files (IIOP protocol) for remote objects." I have pushed the fix. We can rev it in the next pass. Now that we have unified docs which will make it easier to do a review on the first sentence of module summary page. Mandy From tim.bell at oracle.com Fri Apr 21 14:52:53 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 21 Apr 2017 07:52:53 -0700 Subject: RFR: JDK-8179078: Jib run-test-prebuilt profile missing dependency on bootjdk In-Reply-To: <27EE88B9-2BAB-4B91-94EB-9AAB28BCFBB2@oracle.com> References: <1caf7e6e-e810-adab-896e-b5f80d3cd1c8@oracle.com> <03f78b2c-8a2f-50e4-9f81-04f7db458b4a@oracle.com> <27EE88B9-2BAB-4B91-94EB-9AAB28BCFBB2@oracle.com> Message-ID: <5e316cc4-49e1-db1e-690d-0d42af6c464d@oracle.com> Erik- Looks good to me as well. /Iim On 04/21/17 07:48, Christian Tornqvist wrote: > Hi Erik, > > This looks good, I?ve verified that the fix works. Thanks for fixing this! > > Thanks, > Christian > >> On Apr 21, 2017, at 10:43 AM, Erik Joelsson wrote: >> >> (resending to include Christian) >> >> >> On 2017-04-21 16:37, Erik Joelsson wrote: >>> Hello, >>> >>> When using the run-test-prebuilt Jib profile to run tests, we need to set JT_JAVA to point to the boot jdk for jtreg. The configuration to set JT_JAVA is there, but I forgot to also add boot_jdk as a dependency on that profile. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179078 >>> >>> Patch: >>> >>> diff -r 111e2e7d00f4 common/conf/jib-profiles.js >>> --- a/common/conf/jib-profiles.js >>> +++ b/common/conf/jib-profiles.js >>> @@ -584,7 +584,7 @@ >>> var testOnlyProfilesPrebuilt = { >>> "run-test-prebuilt": { >>> src: "src.conf", >>> - dependencies: [ "jtreg", "gnumake", testedProfile + ".jdk", >>> + dependencies: [ "jtreg", "gnumake", "boot_jdk", testedProfile + ".jdk", >>> testedProfile + ".test", "src.full" >>> ], >>> work_dir: input.get("src.full", "install_path") + "/test", >>> >>> >>> /Erik >>> >> > From erik.joelsson at oracle.com Fri Apr 21 14:50:35 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 21 Apr 2017 16:50:35 +0200 Subject: RFR: JDK-8179079: Incremental HotSpot builds broken on Windows Message-ID: <0eb8fdbe-d37a-1a0e-f7b6-1fdd3aa2a166@oracle.com> We have hit another issue related to the new Cygwin behavior regarding \r line endings. The incremental native build on Windows breaks because we get ^M characters in the *.d files. Output from "make --debug=b" typically looks like this: Prerequisite '/cygdrive/c/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp^M' of target '/cygdrive/c/erik/jdk9-dev/build/windows-x64/hotspot/variant-server/tools/adlc/objs/adlparse.obj' does not exist. It's annoying to be fixing these one at a time like this, but I can't really see a general solution to the problem. Here is the simplest fix I could come up with for this particular problem: diff -r 6832b2d9d1ae make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk Fri Apr 21 11:31:09 2017 +0200 +++ b/make/common/NativeCompilation.gmk Fri Apr 21 16:48:11 2017 +0200 @@ -165,6 +165,7 @@ WINDOWS_SHOWINCLUDE_SED_PATTERN := \ -e '/^Note: including file:/!d' \ -e 's|Note: including file: *||' \ + -e 's|\r||g' \ -e 's|\\|/|g' \ -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \ -e '\|$(TOPDIR)|I !d' \ This sed expression is used to rewrite the output of CL's -showIncludes into a list of header files with absolute unix paths. /Erik From tim.bell at oracle.com Sat Apr 22 16:30:48 2017 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 22 Apr 2017 09:30:48 -0700 Subject: RFR: JDK-8179079: Incremental HotSpot builds broken on Windows In-Reply-To: <0eb8fdbe-d37a-1a0e-f7b6-1fdd3aa2a166@oracle.com> References: <0eb8fdbe-d37a-1a0e-f7b6-1fdd3aa2a166@oracle.com> Message-ID: <10ac2640-4e7f-c457-3192-0892070e8685@oracle.com> Hi Erik: Looks good. /Tim > We have hit another issue related to the new Cygwin behavior regarding > \r line endings. The incremental native build on Windows breaks because > we get ^M characters in the *.d files. Output from "make --debug=b" > typically looks like this: > > Prerequisite > '/cygdrive/c/erik/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp^M' of > target > '/cygdrive/c/erik/jdk9-dev/build/windows-x64/hotspot/variant-server/tools/adlc/objs/adlparse.obj' > does not exist. > > It's annoying to be fixing these one at a time like this, but I can't > really see a general solution to the problem. Here is the simplest fix I > could come up with for this particular problem: > > diff -r 6832b2d9d1ae make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk Fri Apr 21 11:31:09 2017 +0200 > +++ b/make/common/NativeCompilation.gmk Fri Apr 21 16:48:11 2017 +0200 > @@ -165,6 +165,7 @@ > WINDOWS_SHOWINCLUDE_SED_PATTERN := \ > -e '/^Note: including file:/!d' \ > -e 's|Note: including file: *||' \ > + -e 's|\r||g' \ > -e 's|\\|/|g' \ > -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \ > -e '\|$(TOPDIR)|I !d' \ > > > This sed expression is used to rewrite the output of CL's -showIncludes > into a list of header files with absolute unix paths. > > /Erik > From martinrb at google.com Sat Apr 22 17:11:21 2017 From: martinrb at google.com (Martin Buchholz) Date: Sat, 22 Apr 2017 10:11:21 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> Message-ID: It seems our javadoc is using html constructs that are not valid html5. If so, we should convert all of those before we start generating html5 output. That should not be too much work for someone who actually understands css and html5. On Fri, Apr 21, 2017 at 2:30 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Jon, > > Can you please open a separate bug for this? Just adding --doclint-format > html5 generates a lot of failures, as Martin points out, so it's not > feasible to do as part of this fix. > > /Magnus > > > On 2017-04-21 03:08, Martin Buchholz wrote: > >> There would be a global cleanup involved for --doclint-format html5 >> A CSS expert can probably suggest replacements. >> >> [javac] ... src/main/java/util/Deque.java:30: error: attribute >> border >> for table only accepts "" or "1", use CSS instead: BORDER >> [javac] *
>> >> >> On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >> We probably want to set >>> >>> --doclint-format html5 >>> >>> for javac as well, for the benefit of compilations that run doclint. >>> >>> -- Jon >>> >>> >>> >>> On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: >>> >>> We should switch all uses of the javadoc tool to generate documentation >>>> in HTML 5, using the -html5 option. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 >>>> Patch inline: >>>> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >>>> --- a/make/Javadoc.gmk >>>> +++ b/make/Javadoc.gmk >>>> @@ -84,7 +84,7 @@ >>>> # The initial set of options for javadoc >>>> JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords >>>> -notimestamp \ >>>> -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex >>>> --system >>>> none \ >>>> - --expand-requires transitive >>>> + -html5 --expand-requires transitive >>>> >>>> # Should we add DRAFT stamps to the generated javadoc? >>>> ifeq ($(VERSION_IS_GA), true) >>>> >>>> /Magnus >>>> >>>> >>> > From magnus.ihse.bursie at oracle.com Sun Apr 23 17:11:28 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 23 Apr 2017 19:11:28 +0200 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> Message-ID: <2730115E-B7E4-42CD-AFF7-00235C8CA821@oracle.com> Martin, Does this mean you oppose this change until all Javadoc compiles cleanly with doclint html5? /Magnus > 22 apr. 2017 kl. 19:11 skrev Martin Buchholz : > > It seems our javadoc is using html constructs that are not valid html5. If so, we should convert all of those before we start generating html5 output. That should not be too much work for someone who actually understands css and html5. > >> On Fri, Apr 21, 2017 at 2:30 AM, Magnus Ihse Bursie wrote: >> Jon, >> >> Can you please open a separate bug for this? Just adding --doclint-format html5 generates a lot of failures, as Martin points out, so it's not feasible to do as part of this fix. >> >> /Magnus >> >> >>> On 2017-04-21 03:08, Martin Buchholz wrote: >>> There would be a global cleanup involved for --doclint-format html5 >>> A CSS expert can probably suggest replacements. >>> >>> [javac] ... src/main/java/util/Deque.java:30: error: attribute border >>> for table only accepts "" or "1", use CSS instead: BORDER >>> [javac] *
>>> >>> >>> On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < >>> jonathan.gibbons at oracle.com> wrote: >>> >>>> We probably want to set >>>> >>>> --doclint-format html5 >>>> >>>> for javac as well, for the benefit of compilations that run doclint. >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: >>>> >>>>> We should switch all uses of the javadoc tool to generate documentation >>>>> in HTML 5, using the -html5 option. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 >>>>> Patch inline: >>>>> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >>>>> --- a/make/Javadoc.gmk >>>>> +++ b/make/Javadoc.gmk >>>>> @@ -84,7 +84,7 @@ >>>>> # The initial set of options for javadoc >>>>> JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords >>>>> -notimestamp \ >>>>> -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex --system >>>>> none \ >>>>> - --expand-requires transitive >>>>> + -html5 --expand-requires transitive >>>>> >>>>> # Should we add DRAFT stamps to the generated javadoc? >>>>> ifeq ($(VERSION_IS_GA), true) >>>>> >>>>> /Magnus > From magnus.ihse.bursie at oracle.com Sun Apr 23 19:21:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 23 Apr 2017 21:21:38 +0200 Subject: RFR: JDK-8178042 Allow custom taglets In-Reply-To: References: <2cb1d3db-9d6f-e5ea-4da4-79426d697e21@oracle.com> Message-ID: <366bc2b7-e1c0-4181-674a-2907e12edaff@oracle.com> On 2017-04-19 18:41, Mandy Chung wrote: >> On Apr 19, 2017, at 4:57 AM, Magnus Ihse Bursie wrote: >> >> Please review this simple change to allow custom to add specialized javadoc taglets. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178042 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.01 > Looks fine to me. Thanks for the review. In an off-list discussion, Erik asked me to rewrite the hook mechanism slightly. Here's an improved version: http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.02 /Magnus > > Mandy > From erik.joelsson at oracle.com Mon Apr 24 08:02:07 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Apr 2017 10:02:07 +0200 Subject: RFR: JDK-8178042 Allow custom taglets In-Reply-To: <366bc2b7-e1c0-4181-674a-2907e12edaff@oracle.com> References: <2cb1d3db-9d6f-e5ea-4da4-79426d697e21@oracle.com> <366bc2b7-e1c0-4181-674a-2907e12edaff@oracle.com> Message-ID: Looks ok to me. /Erik On 2017-04-23 21:21, Magnus Ihse Bursie wrote: > > On 2017-04-19 18:41, Mandy Chung wrote: >>> On Apr 19, 2017, at 4:57 AM, Magnus Ihse Bursie >>> wrote: >>> >>> Please review this simple change to allow custom to add specialized >>> javadoc taglets. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178042 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.01 >> Looks fine to me. > > Thanks for the review. > > In an off-list discussion, Erik asked me to rewrite the hook mechanism > slightly. Here's an improved version: > > http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.02 > > > /Magnus > >> >> Mandy >> > From ted at tedneward.com Mon Apr 24 08:41:53 2017 From: ted at tedneward.com (Ted Neward) Date: Mon, 24 Apr 2017 01:41:53 -0700 Subject: Error in "exploded-image-optimize' on Ubuntu Message-ID: Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From erik.joelsson at oracle.com Mon Apr 24 12:10:23 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Apr 2017 14:10:23 +0200 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: References: Message-ID: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> Hello Ted, I do not recognize the error, but I suspect that the failing command is the first time the build is running the newly built jdk to generate something. Can you try this and see if that works? $ build/linux-x64/jdk/bin/java The build should work on Ubuntu 16.04 (it's what I use personally most of the time). The ubuntu shell on Win10 however is not going to work. It's certainly something we would like to leverage in the future, but so far, it's lacking vital features to be feasible. /Erik On 2017-04-24 10:41, Ted Neward wrote: > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From erik.joelsson at oracle.com Mon Apr 24 13:04:28 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Apr 2017 15:04:28 +0200 Subject: RFR: JDK-8179225: Update graphviz bundle script with up to date build instructions Message-ID: The make/devkit/createGraphvizBundle.sh script documents how we create a more or less standalone bundle with the dot command. It was discovered that this bundle wasn't as standalone as it could be and this was fixed by adding some more libraries to the bundle. This change updates the script the reflect these updated build instructions. Bug: https://bugs.openjdk.java.net/browse/JDK-8179225 Patch: diff -r 35017c286513 make/devkit/createGraphvizBundle.sh --- a/make/devkit/createGraphvizBundle.sh +++ b/make/devkit/createGraphvizBundle.sh @@ -39,6 +39,7 @@ wget http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-libs-$GRAPHVIZ_VERSION.el6.x86_64.rpm wget http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-plugins-core-$GRAPHVIZ_VERSION.el6.x86_64.rpm wget http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-plugins-x-$GRAPHVIZ_VERSION.el6.x86_64.rpm +wget http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/getPackage/libtool-ltdl-2.2.6-15.5.el6.x86_64.rpm mkdir graphviz cd graphviz /Erik From tim.bell at oracle.com Mon Apr 24 13:24:35 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 24 Apr 2017 06:24:35 -0700 Subject: RFR: JDK-8179225: Update graphviz bundle script with up to date build instructions In-Reply-To: References: Message-ID: <5fec5601-df75-1fc0-43a2-a66b8887cd12@oracle.com> Erik: > The make/devkit/createGraphvizBundle.sh script documents how we create a > more or less standalone bundle with the dot command. It was discovered > that this bundle wasn't as standalone as it could be and this was fixed > by adding some more libraries to the bundle. This change updates the > script the reflect these updated build instructions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179225 Looks good to me. Tim > Patch: > > diff -r 35017c286513 make/devkit/createGraphvizBundle.sh > --- a/make/devkit/createGraphvizBundle.sh > +++ b/make/devkit/createGraphvizBundle.sh > @@ -39,6 +39,7 @@ > wget > http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-libs-$GRAPHVIZ_VERSION.el6.x86_64.rpm > > wget > http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-plugins-core-$GRAPHVIZ_VERSION.el6.x86_64.rpm > > wget > http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-plugins-x-$GRAPHVIZ_VERSION.el6.x86_64.rpm > > +wget > http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/getPackage/libtool-ltdl-2.2.6-15.5.el6.x86_64.rpm > > > mkdir graphviz > cd graphviz From kumar.x.srinivasan at oracle.com Mon Apr 24 14:19:53 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 24 Apr 2017 07:19:53 -0700 Subject: Please review: JDK-8178725: provide way to link to external documentation In-Reply-To: <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> References: <58F65070.6000508@oracle.com> <381d5156-ddb0-dcb6-f069-0c3727e5a8e2@oracle.com> <5cc6d962-bd12-25af-389d-f5b611b6ee1b@oracle.com> <58F7A35D.7000303@oracle.com> <747b4b46-73da-2203-81c7-bd438062fd0c@oracle.com> <58F8F79D.8080305@oracle.com> <5cdc93b3-4e41-8c6f-7309-37099dc19ab5@oracle.com> Message-ID: <58FE0989.9080902@oracle.com> Ok updated http://cr.openjdk.java.net/~ksrini/8178725/webrev.02/ In this changeset removed the override as Magnus suggested. Thanks Kumar > On 2017-04-20 20:02, Jonathan Gibbons wrote: >> David, Magnus, >> >> Yes, this is somewhat Oracle-specific (more accurately it is >> JDK-specific, which is why this is a proposed to be a JDK build-time >> taglet, and not a standard tag in the standard doclet), but it is no >> worse than the explicit Oracle-specific URLs that have been used up >> to now, or the relative links using {@docRoot}/../stuff which assume >> that "stuff " is available nearby somehow. I would also go further >> and say this is better that the existing methodology because it >> abstracts all the linking to a single taglet, removing it from inline >> in the doc comments. > I agree, it's in no way worse than what already existed. But it shed > light on the somewhat unclear division between online Oracle > documentation and OpenJDK documentation. > > Just to be clear: I do not oppose the fix. It looks good to me. > > If anything, there was a bit of a clash between on the one hand > providing a means for overriding the URL, but on the other hand not > really making it as general as it could be. Either removing the > possibility to override it (and, as you say, let an alternative > implementation change the code of the taglet itself), or as Roger > suggest, using a more general mechanism like MessageFormat would have > the code make slightly more sense. The simplest way is probably to > skip the property override, which doesn't get used anyhow right now > (and therefore suspect according to "if you don't test it, it is (or > will become) broken"). > > /Magnus > >> Yes, the currently proposed taglet may assume the existence of >> single "base URL", but anyone with an alternate implementation of >> OpenJDK could change the impl of the taglet to use any other >> mechanism to establish the link. Doing a "strings in switch" on the >> identifier to select a URL comes to mind, and avoids anyone having to >> edit the main source doc comments. >> >> -- Jon >> >> >> >> On 04/19/2017 01:37 PM, David Holmes wrote: >>> On 20/04/2017 3:50 AM, Kumar Srinivasan wrote: >>>> >>>> We could potentially make the default URL to be "some" cgi url, >>>> and have the build system specify the URL all the time, in our >>>> case it would be the Oracle documentation URL. >>>> >>>> Would this be an acceptable approach ? >>> >>> I'm not sure what you mean. I have a hard time seeing how a simple >>> identifier (that will be fixed in the file using the taglet) can be >>> attached to an arbitrary URL to yield a valid result. As Magnus >>> said, being able to change the URL is good, but it still requires >>> the same "kind" of URL where the identifier is used as a key. >>> >>> Imagine you have all the documentation locally on your machine then >>> try to figure out how you could link to other local documentation >>> using this scheme. >>> >>> David >>> >>>> Kumar >>>> >>>>> On 19/04/2017 9:26 PM, Magnus Ihse Bursie wrote: >>>>>> On 2017-04-18 19:44, Kumar Srinivasan wrote: >>>>>>> Hello, >>>>>>> >>>>>>> As explained in the JBS issue [1], this new taglet enables API >>>>>>> documents >>>>>>> to contain the extLink tag to link external sources. >>>>>>> >>>>>>> Please review the webrev [2]. >>>>>> Changes looks good. >>>>>> >>>>>> Just a reflection: This is heavily biased to Oracle >>>>>> documentation. Even >>>>>> if it's possible to override the URL via a system property, it >>>>>> assumes >>>>>> the Oracle URL format and id name. Just wondering a bit how that >>>>>> fits >>>>>> with the OpenJDK philosophy. >>>>> >>>>> I have to agree, this is not at all general purpose but totally >>>>> Oracle >>>>> documentation centric. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Kumar >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178725 >>>>>>> [2] http://cr.openjdk.java.net/~ksrini/8178725/webrev.00/ >>>>>> >>>> >> > From ted at tedneward.com Mon Apr 24 17:35:34 2017 From: ted at tedneward.com (Ted Neward) Date: Mon, 24 Apr 2017 10:35:34 -0700 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> Message-ID: Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: Hello Ted, I do not recognize the error, but I suspect that the failing command is the first time the build is running the newly built jdk to generate something. Can you try this and see if that works? $ build/linux-x64/jdk/bin/java The build should work on Ubuntu 16.04 (it's what I use personally most of the time). The ubuntu shell on Win10 however is not going to work. It's certainly something we would like to leverage in the future, but so far, it's lacking vital features to be feasible. /Erik On 2017-04-24 10:41, Ted Neward wrote: > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From jonathan.gibbons at oracle.com Mon Apr 24 22:27:55 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Apr 2017 15:27:55 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> Message-ID: <58FE7BEB.2020108@oracle.com> I'll open a separate bug, but we'll have to decide how we sequence this. It's already the case that we've mostly disabled doclint in javadoc, so it is not significantly worse to disable it in javac for the time being as well, until we get everything sorted out and consistent. -- Jon On 04/21/2017 02:30 AM, Magnus Ihse Bursie wrote: > Jon, > > Can you please open a separate bug for this? Just adding > --doclint-format html5 generates a lot of failures, as Martin points > out, so it's not feasible to do as part of this fix. > > /Magnus > > On 2017-04-21 03:08, Martin Buchholz wrote: >> There would be a global cleanup involved for --doclint-format html5 >> A CSS expert can probably suggest replacements. >> >> [javac] ... src/main/java/util/Deque.java:30: error: attribute >> border >> for table only accepts "" or "1", use CSS instead: BORDER >> [javac] *
>> >> >> On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> We probably want to set >>> >>> --doclint-format html5 >>> >>> for javac as well, for the benefit of compilations that run doclint. >>> >>> -- Jon >>> >>> >>> >>> On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: >>> >>>> We should switch all uses of the javadoc tool to generate >>>> documentation >>>> in HTML 5, using the -html5 option. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 >>>> Patch inline: >>>> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >>>> --- a/make/Javadoc.gmk >>>> +++ b/make/Javadoc.gmk >>>> @@ -84,7 +84,7 @@ >>>> # The initial set of options for javadoc >>>> JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords >>>> -notimestamp \ >>>> -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex >>>> --system >>>> none \ >>>> - --expand-requires transitive >>>> + -html5 --expand-requires transitive >>>> >>>> # Should we add DRAFT stamps to the generated javadoc? >>>> ifeq ($(VERSION_IS_GA), true) >>>> >>>> /Magnus >>>> >>> > From martinrb at google.com Tue Apr 25 00:00:12 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 24 Apr 2017 17:00:12 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: <2730115E-B7E4-42CD-AFF7-00235C8CA821@oracle.com> References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> <2730115E-B7E4-42CD-AFF7-00235C8CA821@oracle.com> Message-ID: [+javadoc-dev] I'm no html expert, so don't trust anything I say, but: jdk9 javadoc contains constructs that are clearly invalid html5, so generating html5 output creates invalid web pages; they must be cleaned up first. Someone around here must have the expertise to know how best to write modern html tables with borders. The existing tables have mostly been cargo-culted from file to file (including in java.util.concurrent). Even if we can generate clean html5, I suspect it's too early to switch; web standards change more slowly than anything else in the universe except IPv6. Whenever we're tempted to switch to a "modern" standard, we should listen to How Many More Years? until the feeling goes away. On Sun, Apr 23, 2017 at 10:11 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Martin, > > Does this mean you oppose this change until all Javadoc compiles cleanly > with doclint html5? > > /Magnus > > 22 apr. 2017 kl. 19:11 skrev Martin Buchholz : > > It seems our javadoc is using html constructs that are not valid html5. > If so, we should convert all of those before we start generating html5 > output. That should not be too much work for someone who actually > understands css and html5. > > On Fri, Apr 21, 2017 at 2:30 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> Jon, >> >> Can you please open a separate bug for this? Just adding --doclint-format >> html5 generates a lot of failures, as Martin points out, so it's not >> feasible to do as part of this fix. >> >> /Magnus >> >> >> On 2017-04-21 03:08, Martin Buchholz wrote: >> >>> There would be a global cleanup involved for --doclint-format html5 >>> A CSS expert can probably suggest replacements. >>> >>> [javac] ... src/main/java/util/Deque.java:30: error: attribute >>> border >>> for table only accepts "" or "1", use CSS instead: BORDER >>> [javac] *
>>> >>> >>> On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < >>> jonathan.gibbons at oracle.com> wrote: >>> >>> We probably want to set >>>> >>>> --doclint-format html5 >>>> >>>> for javac as well, for the benefit of compilations that run doclint. >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: >>>> >>>> We should switch all uses of the javadoc tool to generate documentation >>>>> in HTML 5, using the -html5 option. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175036 >>>>> Patch inline: >>>>> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >>>>> --- a/make/Javadoc.gmk >>>>> +++ b/make/Javadoc.gmk >>>>> @@ -84,7 +84,7 @@ >>>>> # The initial set of options for javadoc >>>>> JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords >>>>> -notimestamp \ >>>>> -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex >>>>> --system >>>>> none \ >>>>> - --expand-requires transitive >>>>> + -html5 --expand-requires transitive >>>>> >>>>> # Should we add DRAFT stamps to the generated javadoc? >>>>> ifeq ($(VERSION_IS_GA), true) >>>>> >>>>> /Magnus >>>>> >>>>> >>>> >> > From jonathan.gibbons at oracle.com Tue Apr 25 00:06:32 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Apr 2017 17:06:32 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> <2730115E-B7E4-42CD-AFF7-00235C8CA821@oracle.com> Message-ID: <5ef24ed2-1875-2d56-5c64-b350faa02b14@oracle.com> Martin No one disputes that we need to clean up the HTML in our doc comments. There is also a very strong desire to move to HTML 5 for the JDK documentation to be able to make use of the accessibility features that are available. The only issue is how to get there from here and how quickly can we do it? Now that Unified docs are in place, we should be able to start doing experiments to determine the magnitude of the problem. -- Jon On 4/24/17 5:00 PM, Martin Buchholz wrote: > [+javadoc-dev] > > I'm no html expert, so don't trust anything I say, but: > > jdk9 javadoc contains constructs that are clearly invalid html5, so > generating html5 output creates invalid web pages; they must be > cleaned up first. Someone around here must have the expertise to know > how best to write modern html tables with borders. The existing > tables have mostly been cargo-culted from file to file (including in > java.util.concurrent). > > Even if we can generate clean html5, I suspect it's too early to > switch; web standards change more slowly than anything else in the > universe except IPv6. Whenever we're tempted to switch to a "modern" > standard, we should listen to How Many More Years? > until the feeling goes away. > > > > On Sun, Apr 23, 2017 at 10:11 AM, Magnus Ihse Bursie > > > wrote: > > Martin, > > Does this mean you oppose this change until all Javadoc compiles > cleanly with doclint html5? > > /Magnus > > 22 apr. 2017 kl. 19:11 skrev Martin Buchholz >: > >> It seems our javadoc is using html constructs that are not valid >> html5. If so, we should convert all of those before we start >> generating html5 output. That should not be too much work for >> someone who actually understands css and html5. >> >> On Fri, Apr 21, 2017 at 2:30 AM, Magnus Ihse Bursie >> > > wrote: >> >> Jon, >> >> Can you please open a separate bug for this? Just adding >> --doclint-format html5 generates a lot of failures, as Martin >> points out, so it's not feasible to do as part of this fix. >> >> /Magnus >> >> >> On 2017-04-21 03:08, Martin Buchholz wrote: >> >> There would be a global cleanup involved for >> --doclint-format html5 >> A CSS expert can probably suggest replacements. >> >> [javac] ... src/main/java/util/Deque.java:30: error: >> attribute border >> for table only accepts "" or "1", use CSS instead: BORDER >> [javac] *
>> >> >> On Thu, Apr 20, 2017 at 3:42 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com >> > wrote: >> >> We probably want to set >> >> --doclint-format html5 >> >> for javac as well, for the benefit of compilations >> that run doclint. >> >> -- Jon >> >> >> >> On 4/20/17 3:20 PM, Magnus Ihse Bursie wrote: >> >> We should switch all uses of the javadoc tool to >> generate documentation >> in HTML 5, using the -html5 option. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8175036 >> >> Patch inline: >> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk >> --- a/make/Javadoc.gmk >> +++ b/make/Javadoc.gmk >> @@ -84,7 +84,7 @@ >> # The initial set of options for javadoc >> JAVADOC_OPTIONS := -XDignore.symbol.file=true >> -use -keywords >> -notimestamp \ >> -serialwarn -encoding ISO-8859-1 >> -breakiterator -splitIndex --system >> none \ >> - --expand-requires transitive >> + -html5 --expand-requires transitive >> >> # Should we add DRAFT stamps to the generated >> javadoc? >> ifeq ($(VERSION_IS_GA), true) >> >> /Magnus >> >> >> >> > From martinrb at google.com Tue Apr 25 00:23:22 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 24 Apr 2017 17:23:22 -0700 Subject: RFR: JDK-8175036 All API docs should be built for HTML 5 In-Reply-To: <5ef24ed2-1875-2d56-5c64-b350faa02b14@oracle.com> References: <38e95e7c-f1fa-c2d0-f67e-d7a2e17f175f@oracle.com> <14713fe1-74b6-b33e-a72f-1d1346c9982c@oracle.com> <2730115E-B7E4-42CD-AFF7-00235C8CA821@oracle.com> <5ef24ed2-1875-2d56-5c64-b350faa02b14@oracle.com> Message-ID: On Mon, Apr 24, 2017 at 5:06 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > There is also a very strong desire to move to HTML 5 for the JDK > documentation to be able to make use of the accessibility features that are > available. > OK, that's a good reason to do it sooner rather than later! From mandy.chung at oracle.com Tue Apr 25 02:03:07 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 24 Apr 2017 19:03:07 -0700 Subject: RFR: JDK-8178042 Allow custom taglets In-Reply-To: <366bc2b7-e1c0-4181-674a-2907e12edaff@oracle.com> References: <2cb1d3db-9d6f-e5ea-4da4-79426d697e21@oracle.com> <366bc2b7-e1c0-4181-674a-2907e12edaff@oracle.com> Message-ID: <6E5ECA81-AEE5-45DA-84FA-DFC5936F2D76@oracle.com> > On Apr 23, 2017, at 12:21 PM, Magnus Ihse Bursie wrote: > > > Thanks for the review. > > In an off-list discussion, Erik asked me to rewrite the hook mechanism slightly. Here's an improved version: > > http://cr.openjdk.java.net/~ihse/JDK-8178042-allow-custom-taglets/webrev.02 +1 Mandy From erik.joelsson at oracle.com Tue Apr 25 10:29:10 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Apr 2017 12:29:10 +0200 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> Message-ID: <1b0a5294-33d7-d735-18e3-5dc4488a4f5a@oracle.com> Hello, First of all, are you expecting to build linux or windows binaries in the ubuntu subsystem? Our interest is to use it to replace cygwin when producing windows binaries. In theory it should be possible to build linux binaries, but AFAIK, current OpenJDK linux binaries crash on startup when trying to run there, which prevents building since we need a bootjdk to run the build (a JDK 8 boot to build JDK 9). I have not investigated this any further, just a college's first impression when it was first released. If you got this to work, we would likely be able to build linux binaries at least. Though, while amusing, that wouldn't be particularly useful for me at least. The next hurdle is crossing the linux/windows barrier again when running native windows applications from the linux subsystem. This was not possible at all in the current release, but I know it's being worked on. Perhaps it even works in some kind of beta at this point. From what I've read about it there are some limitations which would require some trickery from us to get around. For example environment variables are not shared between the environments. All in all this looks like very interesting for the future. /Erik On 2017-04-24 19:35, Ted Neward wrote: > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > Hello Ted, > > I do not recognize the error, but I suspect that the failing command is > the first time the build is running the newly built jdk to generate > something. Can you try this and see if that works? > > $ build/linux-x64/jdk/bin/java > > The build should work on Ubuntu 16.04 (it's what I use personally most > of the time). The ubuntu shell on Win10 however is not going to work. > It's certainly something we would like to leverage in the future, but so > far, it's lacking vital features to be feasible. > > /Erik > > On 2017-04-24 10:41, Ted Neward wrote: > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > From dalibor.topic at oracle.com Tue Apr 25 10:44:11 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 25 Apr 2017 12:44:11 +0200 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> Message-ID: <6b2253b3-4f00-cac4-592e-0ea9514e9e09@oracle.com> Looking at the issue tracker, there is a few dozen of open issues related to Java support, such as https://github.com/Microsoft/BashOnWindows/issues/541 which seem to indicate that the Linux subsystem for Windows may still have a few low-level issues to shake out first. There apparently were some futex problems, some signal handling issues, etc. Some of the workarounds for some of the issues I've heard of involve running the JVM in interpreter mode, but that wouldn't be much fun for building the JDK, which needs to run javac on the JVM to compile the class library. cheers, dalibor topic On 24.04.2017 19:35, Ted Neward wrote: > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > Hello Ted, > > I do not recognize the error, but I suspect that the failing command is > the first time the build is running the newly built jdk to generate > something. Can you try this and see if that works? > > $ build/linux-x64/jdk/bin/java > > The build should work on Ubuntu 16.04 (it's what I use personally most > of the time). The ubuntu shell on Win10 however is not going to work. > It's certainly something we would like to leverage in the future, but so > far, it's lacking vital features to be feasible. > > /Erik > > On 2017-04-24 10:41, Ted Neward wrote: > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ted at tedneward.com Wed Apr 26 07:45:51 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 26 Apr 2017 00:45:51 -0700 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: <1b0a5294-33d7-d735-18e3-5dc4488a4f5a@oracle.com> References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> <1b0a5294-33d7-d735-18e3-5dc4488a4f5a@oracle.com> Message-ID: <9B22BAC1-381E-45EA-905D-7938285BDE61@tedneward.com> Honestly, it?s not like I?m ?expecting? much, period?this is more of a ?Hmmm, this should be possible, so let?s see?.? kind of quest. ;-) However, I?m not under the illusion that something built using the Linux subsystem is technically a Windows application?AFAIK, anything built using the gcc chain under the Linux subsystem can only run under the Linux subsystem. I think. (That?s part of the reason to do some of this?to experiment and find out where the boundaries lie.) So step 1 is to figure out if I can get a JDK build going, and if there?s simple fixes here to unblock the process. If/when it?s not an easy fix here, then I can start talking to friends over in DevDiv inside Microsoft and try to track down who owns the Linux chain there and what, if anything, can be done to unblock without requiring massive engineering effort on Microsoft?s or Oracle?s part. Bear in mind, too, that this is a part-time project, so I may end up going about a half-dozen hours into this thing and go, ?Damn, I?m outta time? and have to drop it. Hence, the search for an easy fix. :-) (By the way, for the remainder of this email, everything is implicitly referring to the Linux subsystem running in Windows 10.) I can say that from a Windows bash shell, I did get Java 8 working, so long as it was installed via the apt manager inside the Linux subsystem; ?sudo apt install openjdk-8? (IIRC) worked fine, and I have a Java environment that, as far as I can tell, runs Java just fine. (sdkman.io also works, by the way, which I think was what I ended up doing instead of apt-get just for easier maintenance on my end.) Getting the bootstrap JDK in place was definitely not a hard thing to do. As for running native Windows apps from the Linux subsystem, again, this isn?t a problem so long as the right binaries are found. Here?s what I mean: By nature, it seems that the bash shell implicitly combines both a Linux PATH (?/usr/local/bin:/usr/bin:??) with the surrounding Windows machine?s PATH (?C:\Windows;C:\Windows\System32;??) to create one long PATH with Unix-ified paths. (The Windows file paths are transformed into Linux subsystem paths by ?mounting? drives C (and D, and E, and whatever else) under a ?/mnt? directory and proceeding as normal from there.) If I?m in a bash shell, and I type ?notepad?, Linux suggests installing WINE. If I?m in the same shell and I type ?/mnt/c/Windows/notepad.exe?, then it fires up Notepad without a hitch. I think the key thing here is that the ?.exe? part of the name is always assumed in a Windows (CMD.EXE) shell, whereas in *nix by default you need the full name. (Just trying this out, when I type ?notepad.exe? without the path prefix in a bash shell, it works fine as well, assuming /mnt/c/Windows is on the PATH, which it is in my bash shell by default.) So I will assert that crossing the Linux/Windows boundary may be a lot easier than originally assumed. FWIW, in a CMD.exe shell, running ?ver? tells me I?m running Windows 10.0.15063, which I believe corresponds with the ?Creators Update? build of Win 10, if that makes a difference in your own testing. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 4/25/17, 3:29 AM, "Erik Joelsson" wrote: Hello, First of all, are you expecting to build linux or windows binaries in the ubuntu subsystem? Our interest is to use it to replace cygwin when producing windows binaries. In theory it should be possible to build linux binaries, but AFAIK, current OpenJDK linux binaries crash on startup when trying to run there, which prevents building since we need a bootjdk to run the build (a JDK 8 boot to build JDK 9). I have not investigated this any further, just a college's first impression when it was first released. If you got this to work, we would likely be able to build linux binaries at least. Though, while amusing, that wouldn't be particularly useful for me at least. The next hurdle is crossing the linux/windows barrier again when running native windows applications from the linux subsystem. This was not possible at all in the current release, but I know it's being worked on. Perhaps it even works in some kind of beta at this point. From what I've read about it there are some limitations which would require some trickery from us to get around. For example environment variables are not shared between the environments. All in all this looks like very interesting for the future. /Erik On 2017-04-24 19:35, Ted Neward wrote: > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > Hello Ted, > > I do not recognize the error, but I suspect that the failing command is > the first time the build is running the newly built jdk to generate > something. Can you try this and see if that works? > > $ build/linux-x64/jdk/bin/java > > The build should work on Ubuntu 16.04 (it's what I use personally most > of the time). The ubuntu shell on Win10 however is not going to work. > It's certainly something we would like to leverage in the future, but so > far, it's lacking vital features to be feasible. > > /Erik > > On 2017-04-24 10:41, Ted Neward wrote: > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > From ted at tedneward.com Wed Apr 26 08:00:43 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 26 Apr 2017 01:00:43 -0700 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: <6b2253b3-4f00-cac4-592e-0ea9514e9e09@oracle.com> References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> <6b2253b3-4f00-cac4-592e-0ea9514e9e09@oracle.com> Message-ID: <8CB33C64-0802-45A7-A64E-D8C1DBDC340C@tedneward.com> I?ll have a look and see if they still hold with the most recent update. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 4/25/17, 3:44 AM, "build-dev on behalf of dalibor topic" wrote: Looking at the issue tracker, there is a few dozen of open issues related to Java support, such as https://github.com/Microsoft/BashOnWindows/issues/541 which seem to indicate that the Linux subsystem for Windows may still have a few low-level issues to shake out first. There apparently were some futex problems, some signal handling issues, etc. Some of the workarounds for some of the issues I've heard of involve running the JVM in interpreter mode, but that wouldn't be much fun for building the JDK, which needs to run javac on the JVM to compile the class library. cheers, dalibor topic On 24.04.2017 19:35, Ted Neward wrote: > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > Hello Ted, > > I do not recognize the error, but I suspect that the failing command is > the first time the build is running the newly built jdk to generate > something. Can you try this and see if that works? > > $ build/linux-x64/jdk/bin/java > > The build should work on Ubuntu 16.04 (it's what I use personally most > of the time). The ubuntu shell on Win10 however is not going to work. > It's certainly something we would like to leverage in the future, but so > far, it's lacking vital features to be feasible. > > /Erik > > On 2017-04-24 10:41, Ted Neward wrote: > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From erik.joelsson at oracle.com Wed Apr 26 08:24:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Apr 2017 10:24:48 +0200 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: <9B22BAC1-381E-45EA-905D-7938285BDE61@tedneward.com> References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> <1b0a5294-33d7-d735-18e3-5dc4488a4f5a@oracle.com> <9B22BAC1-381E-45EA-905D-7938285BDE61@tedneward.com> Message-ID: Hello, Most of my previous mail reflected experiences with the old version of the linux subsystem from the anniversary edition of windows 10. I knew they were working on improving it and it seems the Creators Update is now live with those improvements, which is very interesting news to me! That explains why running a boot jdk now works for you and why you can run windows applications. My comment about the limitations with environment variables was based on last time I read the developers blog about the improvements they were working on some months back: https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/ I'm not sure if that part has been fixed but it's quite possible. My previous assumptions are clearly outdated. If using the subsystem Ubuntu gcc toolchain, you would naturally build linux applications. To build Windows applications, we would run the Visual Studio toolchain like we do today. From what I can see, you should be able to build linux binaries fine now. The challenge is adjusting the build system to use the linux subsystem instead of cygwin when producing windows binaries. I don't expect you to solve that for us though. :) /Erik On 2017-04-26 09:45, Ted Neward wrote: > Honestly, it?s not like I?m ?expecting? much, period?this is more of a ?Hmmm, this should be possible, so let?s see?.? kind of quest. ;-) > > However, I?m not under the illusion that something built using the Linux subsystem is technically a Windows application?AFAIK, anything built using the gcc chain under the Linux subsystem can only run under the Linux subsystem. I think. (That?s part of the reason to do some of this?to experiment and find out where the boundaries lie.) > > So step 1 is to figure out if I can get a JDK build going, and if there?s simple fixes here to unblock the process. If/when it?s not an easy fix here, then I can start talking to friends over in DevDiv inside Microsoft and try to track down who owns the Linux chain there and what, if anything, can be done to unblock without requiring massive engineering effort on Microsoft?s or Oracle?s part. > > Bear in mind, too, that this is a part-time project, so I may end up going about a half-dozen hours into this thing and go, ?Damn, I?m outta time? and have to drop it. Hence, the search for an easy fix. :-) > > (By the way, for the remainder of this email, everything is implicitly referring to the Linux subsystem running in Windows 10.) > > I can say that from a Windows bash shell, I did get Java 8 working, so long as it was installed via the apt manager inside the Linux subsystem; ?sudo apt install openjdk-8? (IIRC) worked fine, and I have a Java environment that, as far as I can tell, runs Java just fine. (sdkman.io also works, by the way, which I think was what I ended up doing instead of apt-get just for easier maintenance on my end.) Getting the bootstrap JDK in place was definitely not a hard thing to do. > > As for running native Windows apps from the Linux subsystem, again, this isn?t a problem so long as the right binaries are found. Here?s what I mean: By nature, it seems that the bash shell implicitly combines both a Linux PATH (?/usr/local/bin:/usr/bin:??) with the surrounding Windows machine?s PATH (?C:\Windows;C:\Windows\System32;??) to create one long PATH with Unix-ified paths. (The Windows file paths are transformed into Linux subsystem paths by ?mounting? drives C (and D, and E, and whatever else) under a ?/mnt? directory and proceeding as normal from there.) > > If I?m in a bash shell, and I type ?notepad?, Linux suggests installing WINE. If I?m in the same shell and I type ?/mnt/c/Windows/notepad.exe?, then it fires up Notepad without a hitch. I think the key thing here is that the ?.exe? part of the name is always assumed in a Windows (CMD.EXE) shell, whereas in *nix by default you need the full name. (Just trying this out, when I type ?notepad.exe? without the path prefix in a bash shell, it works fine as well, assuming /mnt/c/Windows is on the PATH, which it is in my bash shell by default.) > > So I will assert that crossing the Linux/Windows boundary may be a lot easier than originally assumed. FWIW, in a CMD.exe shell, running ?ver? tells me I?m running Windows 10.0.15063, which I believe corresponds with the ?Creators Update? build of Win 10, if that makes a difference in your own testing. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/25/17, 3:29 AM, "Erik Joelsson" wrote: > > Hello, > > First of all, are you expecting to build linux or windows binaries in > the ubuntu subsystem? Our interest is to use it to replace cygwin when > producing windows binaries. > > In theory it should be possible to build linux binaries, but AFAIK, > current OpenJDK linux binaries crash on startup when trying to run > there, which prevents building since we need a bootjdk to run the build > (a JDK 8 boot to build JDK 9). I have not investigated this any further, > just a college's first impression when it was first released. If you got > this to work, we would likely be able to build linux binaries at least. > Though, while amusing, that wouldn't be particularly useful for me at least. > > The next hurdle is crossing the linux/windows barrier again when running > native windows applications from the linux subsystem. This was not > possible at all in the current release, but I know it's being worked on. > Perhaps it even works in some kind of beta at this point. From what I've > read about it there are some limitations which would require some > trickery from us to get around. For example environment variables are > not shared between the environments. > > All in all this looks like very interesting for the future. > > /Erik > > > On 2017-04-24 19:35, Ted Neward wrote: > > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > > > Hello Ted, > > > > I do not recognize the error, but I suspect that the failing command is > > the first time the build is running the newly built jdk to generate > > something. Can you try this and see if that works? > > > > $ build/linux-x64/jdk/bin/java > > > > The build should work on Ubuntu 16.04 (it's what I use personally most > > of the time). The ubuntu shell on Win10 however is not going to work. > > It's certainly something we would like to leverage in the future, but so > > far, it's lacking vital features to be feasible. > > > > /Erik > > > > On 2017-04-24 10:41, Ted Neward wrote: > > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > > > > > Ted Neward > > > > > > Author, Speaker, Mentor > > > > > > http://www.newardassociates.com > > > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > > > > > > > > From ted at tedneward.com Wed Apr 26 08:32:11 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 26 Apr 2017 01:32:11 -0700 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> <1b0a5294-33d7-d735-18e3-5dc4488a4f5a@oracle.com> <9B22BAC1-381E-45EA-905D-7938285BDE61@tedneward.com> Message-ID: <278B68D5-905F-4A17-A084-17B421E89E35@tedneward.com> Oh, yeah, I wasn?t trying to be all ?I?m right, you?re wrong, YOU SUX? or anything like that. :-) I had a feeling you were working with the earlier version, and the Creators Update solved several of those problems, as you point out. Hopefully my reaction wasn?t taken the wrong way. If it was, I apologize. All that up-front stated, I did get stuck with the exploded-image-optimize error, but I haven?t had time to run the build again and see what parts got constructed, so as soon as I find some free time (!), I?ll give that a spin. I?m happy to act as the guinea pig and/or canary in the coal mine on this one if it helps. :-) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 4/26/17, 1:24 AM, "Erik Joelsson" wrote: Hello, Most of my previous mail reflected experiences with the old version of the linux subsystem from the anniversary edition of windows 10. I knew they were working on improving it and it seems the Creators Update is now live with those improvements, which is very interesting news to me! That explains why running a boot jdk now works for you and why you can run windows applications. My comment about the limitations with environment variables was based on last time I read the developers blog about the improvements they were working on some months back: https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/ I'm not sure if that part has been fixed but it's quite possible. My previous assumptions are clearly outdated. If using the subsystem Ubuntu gcc toolchain, you would naturally build linux applications. To build Windows applications, we would run the Visual Studio toolchain like we do today. From what I can see, you should be able to build linux binaries fine now. The challenge is adjusting the build system to use the linux subsystem instead of cygwin when producing windows binaries. I don't expect you to solve that for us though. :) /Erik On 2017-04-26 09:45, Ted Neward wrote: > Honestly, it?s not like I?m ?expecting? much, period?this is more of a ?Hmmm, this should be possible, so let?s see?.? kind of quest. ;-) > > However, I?m not under the illusion that something built using the Linux subsystem is technically a Windows application?AFAIK, anything built using the gcc chain under the Linux subsystem can only run under the Linux subsystem. I think. (That?s part of the reason to do some of this?to experiment and find out where the boundaries lie.) > > So step 1 is to figure out if I can get a JDK build going, and if there?s simple fixes here to unblock the process. If/when it?s not an easy fix here, then I can start talking to friends over in DevDiv inside Microsoft and try to track down who owns the Linux chain there and what, if anything, can be done to unblock without requiring massive engineering effort on Microsoft?s or Oracle?s part. > > Bear in mind, too, that this is a part-time project, so I may end up going about a half-dozen hours into this thing and go, ?Damn, I?m outta time? and have to drop it. Hence, the search for an easy fix. :-) > > (By the way, for the remainder of this email, everything is implicitly referring to the Linux subsystem running in Windows 10.) > > I can say that from a Windows bash shell, I did get Java 8 working, so long as it was installed via the apt manager inside the Linux subsystem; ?sudo apt install openjdk-8? (IIRC) worked fine, and I have a Java environment that, as far as I can tell, runs Java just fine. (sdkman.io also works, by the way, which I think was what I ended up doing instead of apt-get just for easier maintenance on my end.) Getting the bootstrap JDK in place was definitely not a hard thing to do. > > As for running native Windows apps from the Linux subsystem, again, this isn?t a problem so long as the right binaries are found. Here?s what I mean: By nature, it seems that the bash shell implicitly combines both a Linux PATH (?/usr/local/bin:/usr/bin:??) with the surrounding Windows machine?s PATH (?C:\Windows;C:\Windows\System32;??) to create one long PATH with Unix-ified paths. (The Windows file paths are transformed into Linux subsystem paths by ?mounting? drives C (and D, and E, and whatever else) under a ?/mnt? directory and proceeding as normal from there.) > > If I?m in a bash shell, and I type ?notepad?, Linux suggests installing WINE. If I?m in the same shell and I type ?/mnt/c/Windows/notepad.exe?, then it fires up Notepad without a hitch. I think the key thing here is that the ?.exe? part of the name is always assumed in a Windows (CMD.EXE) shell, whereas in *nix by default you need the full name. (Just trying this out, when I type ?notepad.exe? without the path prefix in a bash shell, it works fine as well, assuming /mnt/c/Windows is on the PATH, which it is in my bash shell by default.) > > So I will assert that crossing the Linux/Windows boundary may be a lot easier than originally assumed. FWIW, in a CMD.exe shell, running ?ver? tells me I?m running Windows 10.0.15063, which I believe corresponds with the ?Creators Update? build of Win 10, if that makes a difference in your own testing. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/25/17, 3:29 AM, "Erik Joelsson" wrote: > > Hello, > > First of all, are you expecting to build linux or windows binaries in > the ubuntu subsystem? Our interest is to use it to replace cygwin when > producing windows binaries. > > In theory it should be possible to build linux binaries, but AFAIK, > current OpenJDK linux binaries crash on startup when trying to run > there, which prevents building since we need a bootjdk to run the build > (a JDK 8 boot to build JDK 9). I have not investigated this any further, > just a college's first impression when it was first released. If you got > this to work, we would likely be able to build linux binaries at least. > Though, while amusing, that wouldn't be particularly useful for me at least. > > The next hurdle is crossing the linux/windows barrier again when running > native windows applications from the linux subsystem. This was not > possible at all in the current release, but I know it's being worked on. > Perhaps it even works in some kind of beta at this point. From what I've > read about it there are some limitations which would require some > trickery from us to get around. For example environment variables are > not shared between the environments. > > All in all this looks like very interesting for the future. > > /Erik > > > On 2017-04-24 19:35, Ted Neward wrote: > > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > > > Hello Ted, > > > > I do not recognize the error, but I suspect that the failing command is > > the first time the build is running the newly built jdk to generate > > something. Can you try this and see if that works? > > > > $ build/linux-x64/jdk/bin/java > > > > The build should work on Ubuntu 16.04 (it's what I use personally most > > of the time). The ubuntu shell on Win10 however is not going to work. > > It's certainly something we would like to leverage in the future, but so > > far, it's lacking vital features to be feasible. > > > > /Erik > > > > On 2017-04-24 10:41, Ted Neward wrote: > > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > > > > > Ted Neward > > > > > > Author, Speaker, Mentor > > > > > > http://www.newardassociates.com > > > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > > > > > > > > From magnus.ihse.bursie at oracle.com Wed Apr 26 12:41:05 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Apr 2017 14:41:05 +0200 Subject: RFR: JDK-8179225: Update graphviz bundle script with up to date build instructions In-Reply-To: References: Message-ID: <32568ba0-7fdd-378a-f3f1-7e4b87b8cf7d@oracle.com> Looks good to me. /Magnus On 2017-04-24 15:04, Erik Joelsson wrote: > The make/devkit/createGraphvizBundle.sh script documents how we create > a more or less standalone bundle with the dot command. It was > discovered that this bundle wasn't as standalone as it could be and > this was fixed by adding some more libraries to the bundle. This > change updates the script the reflect these updated build instructions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179225 > > Patch: > > diff -r 35017c286513 make/devkit/createGraphvizBundle.sh > --- a/make/devkit/createGraphvizBundle.sh > +++ b/make/devkit/createGraphvizBundle.sh > @@ -39,6 +39,7 @@ > wget > http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-libs-$GRAPHVIZ_VERSION.el6.x86_64.rpm > wget > http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-plugins-core-$GRAPHVIZ_VERSION.el6.x86_64.rpm > wget > http://www.graphviz.org/pub/graphviz/stable/redhat/el6/x86_64/os/graphviz-plugins-x-$GRAPHVIZ_VERSION.el6.x86_64.rpm > +wget > http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/getPackage/libtool-ltdl-2.2.6-15.5.el6.x86_64.rpm > > mkdir graphviz > cd graphviz > > > /Erik > From erik.joelsson at oracle.com Thu Apr 27 09:38:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Apr 2017 11:38:22 +0200 Subject: Error in "exploded-image-optimize' on Ubuntu In-Reply-To: <278B68D5-905F-4A17-A084-17B421E89E35@tedneward.com> References: <579516d5-197d-fc30-8bce-9609cc8a77e7@oracle.com> <1b0a5294-33d7-d735-18e3-5dc4488a4f5a@oracle.com> <9B22BAC1-381E-45EA-905D-7938285BDE61@tedneward.com> <278B68D5-905F-4A17-A084-17B421E89E35@tedneward.com> Message-ID: On 2017-04-26 10:32, Ted Neward wrote: > Oh, yeah, I wasn?t trying to be all ?I?m right, you?re wrong, YOU SUX? or anything like that. :-) I had a feeling you were working with the earlier version, and the Creators Update solved several of those problems, as you point out. Hopefully my reaction wasn?t taken the wrong way. If it was, I apologize. No reason to. > All that up-front stated, I did get stuck with the exploded-image-optimize error, but I haven?t had time to run the build again and see what parts got constructed, so as soon as I find some free time (!), I?ll give that a spin. I?m happy to act as the guinea pig and/or canary in the coal mine on this one if it helps. :-) I installed a Windows 10 VM yesterday to try this out. I was able to build a JDK 10 forest without problems, producing linux-x64 binaries that seem to work fine. The build wasn't particularly fast though. It takes about the same time to build linux binaries in WSL as it takes to build windows binaries in Cygwin on that machine. Just running configure takes longer in WSL compared to Cygwin. I had hoped for speed improvements over Cygwin. /Erik > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 4/26/17, 1:24 AM, "Erik Joelsson" wrote: > > Hello, > > Most of my previous mail reflected experiences with the old version of > the linux subsystem from the anniversary edition of windows 10. I knew > they were working on improving it and it seems the Creators Update is > now live with those improvements, which is very interesting news to me! > That explains why running a boot jdk now works for you and why you can > run windows applications. > > My comment about the limitations with environment variables was based on > last time I read the developers blog about the improvements they were > working on some months back: > > https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/ > > I'm not sure if that part has been fixed but it's quite possible. My > previous assumptions are clearly outdated. > > If using the subsystem Ubuntu gcc toolchain, you would naturally build > linux applications. To build Windows applications, we would run the > Visual Studio toolchain like we do today. From what I can see, you > should be able to build linux binaries fine now. The challenge is > adjusting the build system to use the linux subsystem instead of cygwin > when producing windows binaries. I don't expect you to solve that for us > though. :) > > /Erik > > On 2017-04-26 09:45, Ted Neward wrote: > > Honestly, it?s not like I?m ?expecting? much, period?this is more of a ?Hmmm, this should be possible, so let?s see?.? kind of quest. ;-) > > > > However, I?m not under the illusion that something built using the Linux subsystem is technically a Windows application?AFAIK, anything built using the gcc chain under the Linux subsystem can only run under the Linux subsystem. I think. (That?s part of the reason to do some of this?to experiment and find out where the boundaries lie.) > > > > So step 1 is to figure out if I can get a JDK build going, and if there?s simple fixes here to unblock the process. If/when it?s not an easy fix here, then I can start talking to friends over in DevDiv inside Microsoft and try to track down who owns the Linux chain there and what, if anything, can be done to unblock without requiring massive engineering effort on Microsoft?s or Oracle?s part. > > > > Bear in mind, too, that this is a part-time project, so I may end up going about a half-dozen hours into this thing and go, ?Damn, I?m outta time? and have to drop it. Hence, the search for an easy fix. :-) > > > > (By the way, for the remainder of this email, everything is implicitly referring to the Linux subsystem running in Windows 10.) > > > > I can say that from a Windows bash shell, I did get Java 8 working, so long as it was installed via the apt manager inside the Linux subsystem; ?sudo apt install openjdk-8? (IIRC) worked fine, and I have a Java environment that, as far as I can tell, runs Java just fine. (sdkman.io also works, by the way, which I think was what I ended up doing instead of apt-get just for easier maintenance on my end.) Getting the bootstrap JDK in place was definitely not a hard thing to do. > > > > As for running native Windows apps from the Linux subsystem, again, this isn?t a problem so long as the right binaries are found. Here?s what I mean: By nature, it seems that the bash shell implicitly combines both a Linux PATH (?/usr/local/bin:/usr/bin:??) with the surrounding Windows machine?s PATH (?C:\Windows;C:\Windows\System32;??) to create one long PATH with Unix-ified paths. (The Windows file paths are transformed into Linux subsystem paths by ?mounting? drives C (and D, and E, and whatever else) under a ?/mnt? directory and proceeding as normal from there.) > > > > If I?m in a bash shell, and I type ?notepad?, Linux suggests installing WINE. If I?m in the same shell and I type ?/mnt/c/Windows/notepad.exe?, then it fires up Notepad without a hitch. I think the key thing here is that the ?.exe? part of the name is always assumed in a Windows (CMD.EXE) shell, whereas in *nix by default you need the full name. (Just trying this out, when I type ?notepad.exe? without the path prefix in a bash shell, it works fine as well, assuming /mnt/c/Windows is on the PATH, which it is in my bash shell by default.) > > > > So I will assert that crossing the Linux/Windows boundary may be a lot easier than originally assumed. FWIW, in a CMD.exe shell, running ?ver? tells me I?m running Windows 10.0.15063, which I believe corresponds with the ?Creators Update? build of Win 10, if that makes a difference in your own testing. > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 4/25/17, 3:29 AM, "Erik Joelsson" wrote: > > > > Hello, > > > > First of all, are you expecting to build linux or windows binaries in > > the ubuntu subsystem? Our interest is to use it to replace cygwin when > > producing windows binaries. > > > > In theory it should be possible to build linux binaries, but AFAIK, > > current OpenJDK linux binaries crash on startup when trying to run > > there, which prevents building since we need a bootjdk to run the build > > (a JDK 8 boot to build JDK 9). I have not investigated this any further, > > just a college's first impression when it was first released. If you got > > this to work, we would likely be able to build linux binaries at least. > > Though, while amusing, that wouldn't be particularly useful for me at least. > > > > The next hurdle is crossing the linux/windows barrier again when running > > native windows applications from the linux subsystem. This was not > > possible at all in the current release, but I know it's being worked on. > > Perhaps it even works in some kind of beta at this point. From what I've > > read about it there are some limitations which would require some > > trickery from us to get around. For example environment variables are > > not shared between the environments. > > > > All in all this looks like very interesting for the future. > > > > /Erik > > > > > > On 2017-04-24 19:35, Ted Neward wrote: > > > Can you be more specific as to which features it?s lacking? (Having spent a fair amount of time on Windows in my career, I might be able to suggest some ways to work with/around it, though I?ll be the first to admit the Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I have several friends who work on DotNetCore, and can maybe ask them for some ideas on how to work around whatever issues that are coming up.) > > > > > > Meanwhile, I?ll see if the build works. (I?m not in front of that machine as I write this.) > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 4/24/17, 5:10 AM, "Erik Joelsson" wrote: > > > > > > Hello Ted, > > > > > > I do not recognize the error, but I suspect that the failing command is > > > the first time the build is running the newly built jdk to generate > > > something. Can you try this and see if that works? > > > > > > $ build/linux-x64/jdk/bin/java > > > > > > The build should work on Ubuntu 16.04 (it's what I use personally most > > > of the time). The ubuntu shell on Win10 however is not going to work. > > > It's certainly something we would like to leverage in the future, but so > > > far, it's lacking vital features to be feasible. > > > > > > /Erik > > > > > > On 2017-04-24 10:41, Ted Neward wrote: > > > > Tried using Ubuntu 16 (in a Virtual Box image, if that makes a difference) and the Ubuntu shell in Win10, and keep getting the same error: > > > > > > > > > > > > > > > > ExplodedImageOptimize.gmk:40: recipe for target ??/jdk_packages_attribute.done? failed > > > > > > > > > > > > > > > > Happens for any kind of configured build (fastdebug, slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that somebody has seen this before and has a quick one-line fix. > > > > > > > > > > > > > > > > Error messages suggest checking the build log; where is that? (I?m guessing build//build.log, but just checking to make sure there isn?t another one I should be looking at?) > > > > > > > > > > > > > > > > Ted Neward > > > > > > > > Author, Speaker, Mentor > > > > > > > > http://www.newardassociates.com > > > > > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > > > > > > > > > > > > > > > > > > > > > From magnus.ihse.bursie at oracle.com Thu Apr 27 12:17:04 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Apr 2017 14:17:04 +0200 Subject: RFR: JDK-8179361 specify -javafx option for javadoc command Message-ID: <2a6e6ebd-f041-2083-aac0-4f89cb263044@oracle.com> If doclint is enabled for the javadoc command, it shows a bunch of 119 errors for "unknown tag @defaultValue". This means that javadoc is not correctly processing the tag to generate the correct documentation. This tag is currently enabled by the -javafx option. Eventually, we should review JavaFX support in javadoc, but for now the best solution to these errors is to use the -javafx option in the javadoc command. Bug: https://bugs.openjdk.java.net/browse/JDK-8179361 Patch inline: diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk --- a/make/Javadoc.gmk +++ b/make/Javadoc.gmk @@ -91,7 +91,7 @@ # The initial set of options for javadoc JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords -notimestamp \ -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex --system none \ - -html5 --expand-requires transitive + -html5 -javafx --expand-requires transitive # Should we add DRAFT stamps to the generated javadoc? ifeq ($(VERSION_IS_GA), true) /Magnus From erik.joelsson at oracle.com Thu Apr 27 14:14:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Apr 2017 16:14:13 +0200 Subject: RFR: JDK-8179361 specify -javafx option for javadoc command In-Reply-To: <2a6e6ebd-f041-2083-aac0-4f89cb263044@oracle.com> References: <2a6e6ebd-f041-2083-aac0-4f89cb263044@oracle.com> Message-ID: <786d9cf7-0177-1055-5bf3-65e5c3249fd0@oracle.com> Looks good to me. /Erik On 2017-04-27 14:17, Magnus Ihse Bursie wrote: > If doclint is enabled for the javadoc command, it shows a bunch of 119 > errors for "unknown tag @defaultValue". This means that javadoc is not > correctly processing the tag to generate the correct documentation. > > This tag is currently enabled by the -javafx option. > > Eventually, we should review JavaFX support in javadoc, but for now > the best solution to these errors is to use the -javafx option in the > javadoc command. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179361 > Patch inline: > diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk > --- a/make/Javadoc.gmk > +++ b/make/Javadoc.gmk > @@ -91,7 +91,7 @@ > # The initial set of options for javadoc > JAVADOC_OPTIONS := -XDignore.symbol.file=true -use -keywords > -notimestamp \ > -serialwarn -encoding ISO-8859-1 -breakiterator -splitIndex > --system none \ > - -html5 --expand-requires transitive > + -html5 -javafx --expand-requires transitive > > # Should we add DRAFT stamps to the generated javadoc? > ifeq ($(VERSION_IS_GA), true) > > /Magnus From matthias.baesken at sap.com Fri Apr 28 09:21:45 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Apr 2017 09:21:45 +0000 Subject: objcopy issues on Solaris Message-ID: Hello, we are facing problems with gobjcopy on Solaris 10 x86_64. When processing libjvm.so (product build) with FDS and separated debug-infos we are getting : objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N It looks like we are running into this (or a similar) problems : https://bugs.openjdk.java.net/browse/JDK-7165598 As recommended in those bugs : x86 https://bugs.openjdk.java.net/browse/JDK-8034005 (and similar Sparc issue) https://bugs.openjdk.java.net/browse/JDK-8033602 We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page) and still get the mentioned error. In the OpenJDK version checks, 2.21 seems to be needed minimum, the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.". Could you tell us the exact version of objcopy / gobjcopy you are using in 8 and 9 on Solaris to process the debuginfo ? And where do you get the gobjcopy from? Thanks, Richard and Matthias From david.holmes at oracle.com Fri Apr 28 11:23:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Apr 2017 21:23:56 +1000 Subject: objcopy issues on Solaris In-Reply-To: References: Message-ID: <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com> Hi Matthias, On 28/04/2017 7:21 PM, Baesken, Matthias wrote: > > Hello, we are facing problems with gobjcopy on Solaris 10 x86_64. > When processing libjvm.so (product build) with FDS and separated debug-infos we are getting : > > objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N > > It looks like we are running into this (or a similar) problems : > > https://bugs.openjdk.java.net/browse/JDK-7165598 > > As recommended in those bugs : > > x86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > (and similar Sparc issue) > https://bugs.openjdk.java.net/browse/JDK-8033602 > > We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page) > and still get the mentioned error. > > In the OpenJDK version checks, 2.21 seems to be needed minimum, > the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.". > > Could you tell us the exact version of objcopy / gobjcopy you are using in 8 and 9 on Solaris to > process the debuginfo ? > And where do you get the gobjcopy from? GNU objcopy (GNU Binutils) 2.21.1 developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 This is a Solaris 11u1 package. David ----- > Thanks, Richard and Matthias > From matthias.baesken at sap.com Fri Apr 28 12:20:44 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Apr 2017 12:20:44 +0000 Subject: objcopy issues on Solaris In-Reply-To: <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com> References: <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com> Message-ID: <390fa253c3854c51b1a930d66c54ecf4@sap.com> > GNU objcopy (GNU Binutils) 2.21.1 > developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 > This is a Solaris 11u1 package. Hi David, thanks for the info. But what about Solaris 10 ? https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms mentions 10u6 supported for JDK8 . And does the 11u1 package developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 Contain special objcopy patches ? Best regards, Matthias -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 28. April 2017 13:24 To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; Erik Joelsson (erik.joelsson at oracle.com) ; 'magnus.ihse.bursie at oracle.com' Cc: Simonis, Volker ; Reingruber, Richard Subject: Re: objcopy issues on Solaris Hi Matthias, On 28/04/2017 7:21 PM, Baesken, Matthias wrote: > > Hello, we are facing problems with gobjcopy on Solaris 10 x86_64. > When processing libjvm.so (product build) with FDS and separated debug-infos we are getting : > > objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N > > It looks like we are running into this (or a similar) problems : > > https://bugs.openjdk.java.net/browse/JDK-7165598 > > As recommended in those bugs : > > x86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > (and similar Sparc issue) > https://bugs.openjdk.java.net/browse/JDK-8033602 > > We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page) > and still get the mentioned error. > > In the OpenJDK version checks, 2.21 seems to be needed minimum, > the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.". > > Could you tell us the exact version of objcopy / gobjcopy you are using in 8 and 9 on Solaris to > process the debuginfo ? > And where do you get the gobjcopy from? GNU objcopy (GNU Binutils) 2.21.1 developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 This is a Solaris 11u1 package. David ----- > Thanks, Richard and Matthias > From erik.joelsson at oracle.com Fri Apr 28 13:33:43 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Apr 2017 15:33:43 +0200 Subject: objcopy issues on Solaris In-Reply-To: <390fa253c3854c51b1a930d66c54ecf4@sap.com> References: <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com> <390fa253c3854c51b1a930d66c54ecf4@sap.com> Message-ID: Hello, In jdk8u we still have this workaround for broken gobjcopy in NativeCompilation.gmk: # gobjcopy crashes on "empty" section headers with the SHF_ALLOC flag set. # Use $(FIX_EMPTY_SEC_HDR_FLAGS) to clear the SHF_ALLOC flag (if set) from # empty section headers until a fixed $(OBJCOPY) is available. # An empty section header has sh_addr == 0 and sh_size == 0. # This problem has only been seen on Solaris X64, but we call this tool # on all Solaris builds just in case. # # $(OBJCOPY) --add-gnu-debuglink=... corrupts SUNW_* sections. # Use $(ADD_GNU_DEBUGLINK) until a fixed $(OBJCOPY) is available. $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).debuginfo : $$($1_TARGET) \ $(FIX_EMPTY_SEC_HDR_FLAGS) $(ADD_GNU_DEBUGLINK) $(RM) $$@ $(FIX_EMPTY_SEC_HDR_FLAGS) $(LOG_INFO) $$< $(OBJCOPY) --only-keep-debug $$< $$@ $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$< I don't know if this is related to your problem. We were able to remove the above in JDK 9 because gobjcopy in Solaris 11 is not exhibiting this problem for us. The introduction of this workaround is from before my time so I don't know the details. The tools FIX_EMPTY_SEC_HDR_FLAGS and ADD_GNU_DEBUGLINK are in the jdk8u src. I checked a build machine for jdk8u and it reports "GNU objcopy 2.15" and this seems to be from the default OS package (Solaris 10). We have had problems with bugs in gobjcopy in the past though. (Example https://bugs.openjdk.java.net/browse/JDK-8034021) So try to get all the latest patches for it. /Erik On 2017-04-28 14:20, Baesken, Matthias wrote: >> GNU objcopy (GNU Binutils) 2.21.1 >> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 >> This is a Solaris 11u1 package. > > Hi David, thanks for the info. > But what about Solaris 10 ? > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > mentions 10u6 supported for JDK8 . > > And does the 11u1 package developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 > Contain special objcopy patches ? > > Best regards, Matthias > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 28. April 2017 13:24 > To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; Erik Joelsson (erik.joelsson at oracle.com) ; 'magnus.ihse.bursie at oracle.com' > Cc: Simonis, Volker ; Reingruber, Richard > Subject: Re: objcopy issues on Solaris > > Hi Matthias, > > On 28/04/2017 7:21 PM, Baesken, Matthias wrote: >> Hello, we are facing problems with gobjcopy on Solaris 10 x86_64. >> When processing libjvm.so (product build) with FDS and separated debug-infos we are getting : >> >> objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N >> >> It looks like we are running into this (or a similar) problems : >> >> https://bugs.openjdk.java.net/browse/JDK-7165598 >> >> As recommended in those bugs : >> >> x86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> (and similar Sparc issue) >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page) >> and still get the mentioned error. >> >> In the OpenJDK version checks, 2.21 seems to be needed minimum, >> the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.". >> >> Could you tell us the exact version of objcopy / gobjcopy you are using in 8 and 9 on Solaris to >> process the debuginfo ? >> And where do you get the gobjcopy from? > GNU objcopy (GNU Binutils) 2.21.1 > > developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 > > This is a Solaris 11u1 package. > > David > ----- > >> Thanks, Richard and Matthias >> From richard.reingruber at sap.com Fri Apr 28 16:00:37 2017 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 28 Apr 2017 16:00:37 +0000 Subject: objcopy issues on Solaris In-Reply-To: References: <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com> <390fa253c3854c51b1a930d66c54ecf4@sap.com> Message-ID: <22929188ecbf43c8b4a15cfeaa22a582@sap.com> Hi Erik, I noticed this workaround, but apparently it was removed again from the hotspot build with http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/8c76e844a7f9. This confused me, nevertheless I tried it. fix_empty_sec_hdr_flags libjvm.so objcopy --only-keep-debug libjvm.so libjvm.debuginfo # here I got the "Not enough room for program headers, try linking with -N" add_gnu_debuglink libjvm.debuginfo libjvm.so Succeeds: now I got a libjvm.debuginfo, but it seems to be corrupted: $ elfdump libjvm.debuginfo > dump.txt Segmentation Fault (core dumped) I assume the workaround was removed because of this corruption(that's what the bugs JDK-8034005 and JDK-8033602 suggest), but why was it kept for the jdk build then? Do you know? I was hoping that Oracle's binutils 2.21.1 contains fixes for the issues which are not yet pushed upstream. This would explain my problems with binutils 2.28 from gnu.org Cheers, Richard. -----Original Message----- From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Freitag, 28. April 2017 15:34 To: Baesken, Matthias ; David Holmes ; 'build-dev at openjdk.java.net' ; 'magnus.ihse.bursie at oracle.com' Cc: Simonis, Volker ; Reingruber, Richard Subject: Re: objcopy issues on Solaris Hello, In jdk8u we still have this workaround for broken gobjcopy in NativeCompilation.gmk: # gobjcopy crashes on "empty" section headers with the SHF_ALLOC flag set. # Use $(FIX_EMPTY_SEC_HDR_FLAGS) to clear the SHF_ALLOC flag (if set) from # empty section headers until a fixed $(OBJCOPY) is available. # An empty section header has sh_addr == 0 and sh_size == 0. # This problem has only been seen on Solaris X64, but we call this tool # on all Solaris builds just in case. # # $(OBJCOPY) --add-gnu-debuglink=... corrupts SUNW_* sections. # Use $(ADD_GNU_DEBUGLINK) until a fixed $(OBJCOPY) is available. $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).debuginfo : $$($1_TARGET) \ $(FIX_EMPTY_SEC_HDR_FLAGS) $(ADD_GNU_DEBUGLINK) $(RM) $$@ $(FIX_EMPTY_SEC_HDR_FLAGS) $(LOG_INFO) $$< $(OBJCOPY) --only-keep-debug $$< $$@ $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$< I don't know if this is related to your problem. We were able to remove the above in JDK 9 because gobjcopy in Solaris 11 is not exhibiting this problem for us. The introduction of this workaround is from before my time so I don't know the details. The tools FIX_EMPTY_SEC_HDR_FLAGS and ADD_GNU_DEBUGLINK are in the jdk8u src. I checked a build machine for jdk8u and it reports "GNU objcopy 2.15" and this seems to be from the default OS package (Solaris 10). We have had problems with bugs in gobjcopy in the past though. (Example https://bugs.openjdk.java.net/browse/JDK-8034021) So try to get all the latest patches for it. /Erik On 2017-04-28 14:20, Baesken, Matthias wrote: >> GNU objcopy (GNU Binutils) 2.21.1 >> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 >> This is a Solaris 11u1 package. > > Hi David, thanks for the info. > But what about Solaris 10 ? > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > mentions 10u6 supported for JDK8 . > > And does the 11u1 package developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 > Contain special objcopy patches ? > > Best regards, Matthias > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 28. April 2017 13:24 > To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; Erik Joelsson (erik.joelsson at oracle.com) ; 'magnus.ihse.bursie at oracle.com' > Cc: Simonis, Volker ; Reingruber, Richard > Subject: Re: objcopy issues on Solaris > > Hi Matthias, > > On 28/04/2017 7:21 PM, Baesken, Matthias wrote: >> Hello, we are facing problems with gobjcopy on Solaris 10 x86_64. >> When processing libjvm.so (product build) with FDS and separated debug-infos we are getting : >> >> objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N >> >> It looks like we are running into this (or a similar) problems : >> >> https://bugs.openjdk.java.net/browse/JDK-7165598 >> >> As recommended in those bugs : >> >> x86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> (and similar Sparc issue) >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page) >> and still get the mentioned error. >> >> In the OpenJDK version checks, 2.21 seems to be needed minimum, >> the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.". >> >> Could you tell us the exact version of objcopy / gobjcopy you are using in 8 and 9 on Solaris to >> process the debuginfo ? >> And where do you get the gobjcopy from? > GNU objcopy (GNU Binutils) 2.21.1 > > developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0 > > This is a Solaris 11u1 package. > > David > ----- > >> Thanks, Richard and Matthias >> From magnus.ihse.bursie at oracle.com Fri Apr 28 19:52:24 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Apr 2017 21:52:24 +0200 Subject: RFR: JDK-8179453 Add a proper SetupProcessMarkdown Message-ID: <04db6bd8-3141-5b06-3391-b4e90641c013@oracle.com> To cover the coming needs of the added markdown specifications, a more proper function for setting up markdown processing is needed. The CSS file is intented as a first approach/placeholder. It needs to be updated later on. Bug: https://bugs.openjdk.java.net/browse/JDK-8179453 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179453-add-process-markdown/webrev.01 /Magnus From javalists at cbfiddle.com Sun Apr 30 03:40:35 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 29 Apr 2017 20:40:35 -0700 Subject: problem building JDK 9 on macOS 10.12.4 Message-ID: <7E753602-49B5-474D-BD78-D9645A87F18C@cbfiddle.com> I just updated from http://hg.openjdk.java.net/jdk9/jdk9 and ran into the following build problem on macOS 10.12.4: configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. /Volumes/A/JDK/jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor configure exiting with result code 1 Note that freetype was already installed using brew. The following output suggests that configure is only looking in the SDK and not in /usr/local... +++ FREETYPE_BASE_NAME=freetype +++ FREETYPE_CFLAGS= +++ FREETYPE_LIBS= +++ FREETYPE_BUNDLE_LIB_PATH= +++ test xtrue = xfalse +++ BUNDLE_FREETYPE= +++ test x '!=' x +++ test x '!=' x +++ test x '!=' x +++ test x '!=' x +++ test x = x +++ test xmacosx = xwindows +++ BUNDLE_FREETYPE=no +++ test x/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk = x +++ test x '!=' xyes +++ test xmacosx = xwindows +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib +++ METHOD='well-known location' +++ FOUND_FREETYPE=yes +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ft2build.h +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2 +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2/ft2build.h +++ FOUND_FREETYPE=no +++ test xno = xyes +++ test xno = xyes +++ test xno '!=' xyes +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11 +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/lib +++ METHOD='well-known location' +++ FOUND_FREETYPE=yes +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/ft2build.h +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/freetype2 +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/freetype2/ft2build.h +++ FOUND_FREETYPE=no +++ test xno = xyes +++ test xno = xyes +++ test xno '!=' xyes +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/lib +++ METHOD='well-known location' +++ FOUND_FREETYPE=yes +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/ft2build.h +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/freetype2 +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/freetype2/ft2build.h +++ FOUND_FREETYPE=no +++ test xno = xyes +++ test xno = xyes +++ test xmacosx = xmacosx +++ test xno '!=' xyes +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11 +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/lib +++ METHOD='well-known location' +++ FOUND_FREETYPE=yes +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/ft2build.h +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/freetype2 +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/freetype2/ft2build.h +++ FOUND_FREETYPE=no +++ test xno = xyes +++ test xno = xyes +++ test xno '!=' xyes +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr +++ test x64 = x64 +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/x86_64-linux-gnu +++ METHOD='well-known location' +++ FOUND_FREETYPE=yes +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ft2build.h +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2 +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2/ft2build.h +++ FOUND_FREETYPE=no +++ test xno = xyes +++ test xno = xyes +++ test xno '!=' xyes +++ MISSING_DEPENDENCY=freetype +++ test xmacosx = xwindows.cygwin +++ test xmacosx = xwindows.msys +++ PKGHANDLER_COMMAND= +++ case $PKGHANDLER in +++ brew_help freetype +++ case $1 in +++ PKGHANDLER_COMMAND='brew install freetype' +++ test 'xbrew install freetype' '!=' x +++ HELP_MSG='You might be able to fix this by running '\''brew install freetype'\''.' +++ as_fn_error 0 'Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' 62636 5 +++ as_status=0 +++ test 0 -eq 0 +++ as_status=1 +++ test 5 +++ as_lineno=62636 +++ as_lineno_stack=as_lineno_stack= +++ printf '%s\n' 'configure:62636: error: Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' +++ printf '%s\n' 'configure: error: Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. +++ as_fn_exit 1 +++ set +e +++ as_fn_set_status 1 +++ return 1 +++ exit 1 + exit_status=1 /Volumes/A/JDK/jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor + rm -f core '*.core' 'core.conftest.*' + rm -f -r 'conftest*' confdefs.h 'conf29603*' + exit 1 ++ echo 1 ++ exec +++ cat /var/folders/kr/m7872s7x5t3f8twyftzrj0zm0000gn/T/jdk-build-configure.tmp.XXXXXX.YV3rVGeJ/rc ++ conf_result_code=1 ++ test 1 -eq 0 ++ echo configure exiting with result code 1 configure exiting with result code 1 ++ exit 1 + rm -rf /var/folders/kr/m7872s7x5t3f8twyftzrj0zm0000gn/T/jdk-build-configure.tmp.XXXXXX.YV3rVGeJ From neugens.limasoftware at gmail.com Sun Apr 30 12:36:24 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 30 Apr 2017 14:36:24 +0200 Subject: problem building JDK 9 on macOS 10.12.4 In-Reply-To: <7E753602-49B5-474D-BD78-D9645A87F18C@cbfiddle.com> References: <7E753602-49B5-474D-BD78-D9645A87F18C@cbfiddle.com> Message-ID: Did you pass the --with-freetype explicitly to configure? Cheers, Mario 2017-04-30 5:40 GMT+02:00 Alan Snyder : > I just updated from http://hg.openjdk.java.net/jdk9/jdk9 and ran into the following build problem on macOS 10.12.4: > > configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. > > /Volumes/A/JDK/jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor > > configure exiting with result code 1 > > > Note that freetype was already installed using brew. > The following output suggests that configure is only looking in the SDK and not in /usr/local... > > +++ FREETYPE_BASE_NAME=freetype > +++ FREETYPE_CFLAGS= > +++ FREETYPE_LIBS= > +++ FREETYPE_BUNDLE_LIB_PATH= > +++ test xtrue = xfalse > +++ BUNDLE_FREETYPE= > +++ test x '!=' x > +++ test x '!=' x > +++ test x '!=' x > +++ test x '!=' x > +++ test x = x > +++ test xmacosx = xwindows > +++ BUNDLE_FREETYPE=no > +++ test x/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk = x > +++ test x '!=' xyes > +++ test xmacosx = xwindows > +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include > +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib > +++ METHOD='well-known location' > +++ FOUND_FREETYPE=yes > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ft2build.h > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2 > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2/ft2build.h > +++ FOUND_FREETYPE=no > +++ test xno = xyes > +++ test xno = xyes > +++ test xno '!=' xyes > +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11 > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include > +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/lib > +++ METHOD='well-known location' > +++ FOUND_FREETYPE=yes > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/ft2build.h > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/freetype2 > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/freetype2/ft2build.h > +++ FOUND_FREETYPE=no > +++ test xno = xyes > +++ test xno = xyes > +++ test xno '!=' xyes > +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include > +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/lib > +++ METHOD='well-known location' > +++ FOUND_FREETYPE=yes > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/ft2build.h > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/freetype2 > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/freetype2/ft2build.h > +++ FOUND_FREETYPE=no > +++ test xno = xyes > +++ test xno = xyes > +++ test xmacosx = xmacosx > +++ test xno '!=' xyes > +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11 > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include > +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/lib > +++ METHOD='well-known location' > +++ FOUND_FREETYPE=yes > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/ft2build.h > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/freetype2 > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/freetype2/ft2build.h > +++ FOUND_FREETYPE=no > +++ test xno = xyes > +++ test xno = xyes > +++ test xno '!=' xyes > +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr > +++ test x64 = x64 > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include > +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/x86_64-linux-gnu > +++ METHOD='well-known location' > +++ FOUND_FREETYPE=yes > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ft2build.h > +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2 > +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2/ft2build.h > +++ FOUND_FREETYPE=no > +++ test xno = xyes > +++ test xno = xyes > +++ test xno '!=' xyes > +++ MISSING_DEPENDENCY=freetype > +++ test xmacosx = xwindows.cygwin > +++ test xmacosx = xwindows.msys > +++ PKGHANDLER_COMMAND= > +++ case $PKGHANDLER in > +++ brew_help freetype > +++ case $1 in > +++ PKGHANDLER_COMMAND='brew install freetype' > +++ test 'xbrew install freetype' '!=' x > +++ HELP_MSG='You might be able to fix this by running '\''brew install freetype'\''.' > +++ as_fn_error 0 'Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' 62636 5 > +++ as_status=0 > +++ test 0 -eq 0 > +++ as_status=1 > +++ test 5 > +++ as_lineno=62636 > +++ as_lineno_stack=as_lineno_stack= > +++ printf '%s\n' 'configure:62636: error: Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' > +++ printf '%s\n' 'configure: error: Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' > configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. > +++ as_fn_exit 1 > +++ set +e > +++ as_fn_set_status 1 > +++ return 1 > +++ exit 1 > + exit_status=1 > /Volumes/A/JDK/jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor > + rm -f core '*.core' 'core.conftest.*' > + rm -f -r 'conftest*' confdefs.h 'conf29603*' > + exit 1 > ++ echo 1 > ++ exec > +++ cat /var/folders/kr/m7872s7x5t3f8twyftzrj0zm0000gn/T/jdk-build-configure.tmp.XXXXXX.YV3rVGeJ/rc > ++ conf_result_code=1 > ++ test 1 -eq 0 > ++ echo configure exiting with result code 1 > configure exiting with result code 1 > ++ exit 1 > + rm -rf /var/folders/kr/m7872s7x5t3f8twyftzrj0zm0000gn/T/jdk-build-configure.tmp.XXXXXX.YV3rVGeJ > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From javalists at cbfiddle.com Sun Apr 30 13:33:19 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 30 Apr 2017 06:33:19 -0700 Subject: problem building JDK 9 on macOS 10.12.4 In-Reply-To: References: <7E753602-49B5-474D-BD78-D9645A87F18C@cbfiddle.com> Message-ID: <637A0C4D-6482-462E-8AE4-3797343B9BE9@cbfiddle.com> No. > On Apr 30, 2017, at 5:36 AM, Mario Torre wrote: > > Did you pass the --with-freetype explicitly to configure? > > Cheers, > Mario > > 2017-04-30 5:40 GMT+02:00 Alan Snyder >: >> I just updated from http://hg.openjdk.java.net/jdk9/jdk9 >and ran into the following build problem on macOS 10.12.4: >> >> configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. >> >> /Volumes/A/JDK/jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor >> >> configure exiting with result code 1 >> >> >> Note that freetype was already installed using brew. >> The following output suggests that configure is only looking in the SDK and not in /usr/local... >> >> +++ FREETYPE_BASE_NAME=freetype >> +++ FREETYPE_CFLAGS= >> +++ FREETYPE_LIBS= >> +++ FREETYPE_BUNDLE_LIB_PATH= >> +++ test xtrue = xfalse >> +++ BUNDLE_FREETYPE= >> +++ test x '!=' x >> +++ test x '!=' x >> +++ test x '!=' x >> +++ test x '!=' x >> +++ test x = x >> +++ test xmacosx = xwindows >> +++ BUNDLE_FREETYPE=no >> +++ test x/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk = x >> +++ test x '!=' xyes >> +++ test xmacosx = xwindows >> +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include >> +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib >> +++ METHOD='well-known location' >> +++ FOUND_FREETYPE=yes >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ft2build.h >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2 >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2/ft2build.h >> +++ FOUND_FREETYPE=no >> +++ test xno = xyes >> +++ test xno = xyes >> +++ test xno '!=' xyes >> +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11 >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include >> +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/lib >> +++ METHOD='well-known location' >> +++ FOUND_FREETYPE=yes >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/ft2build.h >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/freetype2 >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/X11/include/freetype2/ft2build.h >> +++ FOUND_FREETYPE=no >> +++ test xno = xyes >> +++ test xno = xyes >> +++ test xno '!=' xyes >> +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include >> +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/lib >> +++ METHOD='well-known location' >> +++ FOUND_FREETYPE=yes >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/ft2build.h >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/freetype2 >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/local/include/freetype2/ft2build.h >> +++ FOUND_FREETYPE=no >> +++ test xno = xyes >> +++ test xno = xyes >> +++ test xmacosx = xmacosx >> +++ test xno '!=' xyes >> +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11 >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include >> +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/lib >> +++ METHOD='well-known location' >> +++ FOUND_FREETYPE=yes >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/ft2build.h >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/freetype2 >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/opt/X11/include/freetype2/ft2build.h >> +++ FOUND_FREETYPE=no >> +++ test xno = xyes >> +++ test xno = xyes >> +++ test xno '!=' xyes >> +++ FREETYPE_BASE_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr >> +++ test x64 = x64 >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include >> +++ POTENTIAL_FREETYPE_LIB_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/x86_64-linux-gnu >> +++ METHOD='well-known location' >> +++ FOUND_FREETYPE=yes >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ft2build.h >> +++ POTENTIAL_FREETYPE_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2 >> +++ test -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/freetype2/ft2build.h >> +++ FOUND_FREETYPE=no >> +++ test xno = xyes >> +++ test xno = xyes >> +++ test xno '!=' xyes >> +++ MISSING_DEPENDENCY=freetype >> +++ test xmacosx = xwindows.cygwin >> +++ test xmacosx = xwindows.msys >> +++ PKGHANDLER_COMMAND= >> +++ case $PKGHANDLER in >> +++ brew_help freetype >> +++ case $1 in >> +++ PKGHANDLER_COMMAND='brew install freetype' >> +++ test 'xbrew install freetype' '!=' x >> +++ HELP_MSG='You might be able to fix this by running '\''brew install freetype'\''.' >> +++ as_fn_error 0 'Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' 62636 5 >> +++ as_status=0 >> +++ test 0 -eq 0 >> +++ as_status=1 >> +++ test 5 >> +++ as_lineno=62636 >> +++ as_lineno_stack=as_lineno_stack= >> +++ printf '%s\n' 'configure:62636: error: Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' >> +++ printf '%s\n' 'configure: error: Could not find freetype! You might be able to fix this by running '\''brew install freetype'\''. ' >> configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. >> +++ as_fn_exit 1 >> +++ set +e >> +++ as_fn_set_status 1 >> +++ return 1 >> +++ exit 1 >> + exit_status=1 >> /Volumes/A/JDK/jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor >> + rm -f core '*.core' 'core.conftest.*' >> + rm -f -r 'conftest*' confdefs.h 'conf29603*' >> + exit 1 >> ++ echo 1 >> ++ exec >> +++ cat /var/folders/kr/m7872s7x5t3f8twyftzrj0zm0000gn/T/jdk-build-configure.tmp.XXXXXX.YV3rVGeJ/rc >> ++ conf_result_code=1 >> ++ test 1 -eq 0 >> ++ echo configure exiting with result code 1 >> configure exiting with result code 1 >> ++ exit 1 >> + rm -rf /var/folders/kr/m7872s7x5t3f8twyftzrj0zm0000gn/T/jdk-build-configure.tmp.XXXXXX.YV3rVGeJ >> >> > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/