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

Magnus, I agree with this, and agree with closing it WNF. -- Jon On 05/12/2017 12:16 AM, Magnus Ihse Bursie wrote: Kumar, This was not an improvement. This will require additional changes in the build system to avoid a regression. I see no reason for that. In fact, I propose we close the bu

Re: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64 flags

Erik: Looks good to me as well. Tim On 05/12/17 11:36, Kumar Srinivasan wrote: Looks good, and thanks for fixing this quickly!. Kumar With the removal of the -d64 flag, bootcycle builds started failing. This patch stops trying to use -d64 completely for the boot jdk since it shouldn't be n

Re: Review Request: JDK-8180208 Provide a new docs bundle page

> On May 12, 2017, at 11:17 AM, Magnus Ihse Bursie > wrote: > > > Maybe skip the three-bullet item list and rephrase it somewhat. > > "The complete API specification is available from [this > overview](api/index.html). The following table guides to to some important > entry points". > > Or

Re: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64 flags

Looks good, and thanks for fixing this quickly!. Kumar With the removal of the -d64 flag, bootcycle builds started failing. This patch stops trying to use -d64 completely for the boot jdk since it shouldn't be needed for either JDK 8 or 9. The checks that used this parameter to see if the JV

Re: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64 flags

> On May 12, 2017, at 11:30 AM, Erik Joelsson wrote: > > With the removal of the -d64 flag, bootcycle builds started failing. This > patch stops trying to use -d64 completely for the boot jdk since it shouldn't > be needed for either JDK 8 or 9. The checks that used this parameter to see > if

RFR: JDK-8180198: make bootcycle-images fail with uses of -d64 flags

With the removal of the -d64 flag, bootcycle builds started failing. This patch stops trying to use -d64 completely for the boot jdk since it shouldn't be needed for either JDK 8 or 9. The checks that used this parameter to see if the JVM was 64 bit has been rewritten to instead look at the ver

Re: Review Request: JDK-8180208 Provide a new docs bundle page

On 2017-05-12 20:09, Mandy Chung wrote: Thanks Magnus for the review and feedback. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.02 - Merged with the recent changesets in jdk9/dev. - Renamed docs-jdk-index-html target to docs-jdk-index. - Keep the “Java SE”

Re: Review Request: JDK-8180208 Provide a new docs bundle page

Thanks Magnus for the review and feedback. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.02 - Merged with the recent changesets in jdk9/dev. - Renamed docs-jdk-index-html target to docs-jdk-index. - Keep the “Java SE” column header. Add a new table header to s

Re: RFR: JDK-8180178 Restructure existing man pages according to JEP 299

1a - do nothing in JDK 9 as I mentioned in my reply that answered your part 2 question for Option 1. Do 1d in JDK 10 (along with modularizing the man pages) Mandy > On May 12, 2017, at 9:44 AM, Magnus Ihse Bursie > wrote: > > I realize I was not very clear in my mail, despite my intentions.

Re: Review Request: JDK-8180208 Provide a new docs bundle page

On 2017-05-12 17:04, Mandy Chung wrote: On May 12, 2017, at 5:31 AM, Magnus Ihse Bursie > wrote: Mandy, Build changes mostly look good. I have a few requests: 1) Please rename the target docs-jdk-index instead of docs-jdk-index-html. Will fix.

Re: RFR: JDK-8180178 Restructure existing man pages according to JEP 299

I realize I was not very clear in my mail, despite my intentions. :-) What I meant was, given option 1, there are some more choices to be made. 1a) do not do anything, ignore this patch, and ship things just as they are in JDK 8. 1b) apply this patch, move the files in the src tree and the ou

Re: RFR: JDK-8180178 Restructure existing man pages according to JEP 299

I suggest do nothing in JDK 9 (i.e. option 1) and do the man pages cleanup effort in JDK 10. This patch together with conversion to markdown can be pushed to jdk10 repo (probably best after the jdk9 build/docs changes are completed to avoid any merge conflict). There will probably be some fo

Re: RFR: JDK-8180281 --with-jtreg is broken for many use cases

Looks good. /Erik On 2017-05-12 04:59, Magnus Ihse Bursie wrote: It turned out that run-test behaved badly when JT_HOME was not set. Here's an updated version with a more helpful failure mode. http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.02 /Magnus On 2017-05

Re: RFR: JDK-8180178 Restructure existing man pages according to JEP 299

Thanks Magnus, I agree completely with the below. Option 1 seems most logical to me, especially since the work to conform to JEP 299 has already been done. /Erik On 2017-05-11 23:51, Magnus Ihse Bursie wrote: (Sorry if this is a bit TL, please don't DR though...) Good we started clearing t

Re: Review Request: JDK-8180208 Provide a new docs bundle page

> On May 12, 2017, at 5:31 AM, Magnus Ihse Bursie > wrote: > > Mandy, > > Build changes mostly look good. I have a few requests: > > 1) Please rename the target docs-jdk-index instead of docs-jdk-index-html. > Will fix. > 2) I'm glad you added a LogInfo line, however > +$(call Lo

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

:D great! It worked perfectly! Thanks a lot Tommaso Pasini 2017-05-12 14:17 GMT+02:00 Magnus Ihse Bursie : > "bash configure --disable-warnings-as-errors" > > /Magnus > > > On 2017-05-12 14:11, Tommaso Pasini wrote: > > ok, i suspected that Lennart, could you tell me how to set that flag? > Than

Re: Review Request: JDK-8180208 Provide a new docs bundle page

Mandy, Build changes mostly look good. I have a few requests: 1) Please rename the target docs-jdk-index instead of docs-jdk-index-html. 2) I'm glad you added a LogInfo line, however +$(call LogInfo, Generating docs bundle page at $@) will print the full path to the output file, and we

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

"bash configure --disable-warnings-as-errors" /Magnus On 2017-05-12 14:11, Tommaso Pasini wrote: ok, i suspected that Lennart, could you tell me how to set that flag? Thanks a lot! Tommaso Pasini 2017-05-12 13:09 GMT+02:00 Lennart Börjeson >: I’ve had that err

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

I check the make sources and they do not seam to use CFLAGS anywhere Tommaso Pasini 2017-05-12 14:11 GMT+02:00 Tommaso Pasini : > ok, i suspected that Lennart, could you tell me how to set that flag? > Thanks a lot! > > Tommaso Pasini > > 2017-05-12 13:09 GMT+02:00 Lennart Börjeson : > >> I’ve h

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

ok, i suspected that Lennart, could you tell me how to set that flag? Thanks a lot! Tommaso Pasini 2017-05-12 13:09 GMT+02:00 Lennart Börjeson : > I’ve had that error on my Mac since forever. :-/ > > You need to configure with "--disable-warnings-as-errors”. > > You’ll then get that warning quit

Re: RFR: JDK-8180281 --with-jtreg is broken for many use cases

It turned out that run-test behaved badly when JT_HOME was not set. Here's an updated version with a more helpful failure mode. http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.02 /Magnus On 2017-05-12 12:08, Magnus Ihse Bursie wrote: JDK-8179537 was opened with a reque

Re: Graal missing from MacOS Java 9 EA download b167

Thank you for the response. As I believe Graal is the most important new thing in jdk9, I’d then just want to state my opinion: Even if AOT is available only for x86_64 (and I have absolutely no problems with that), I still believe Graal should be included on all platforms. After all, Graal i

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

I’ve had that error on my Mac since forever. :-/ You need to configure with "--disable-warnings-as-errors”. You’ll then get that warning quite a few times during the build, bit it will work. (At least it does for me.) /Lennart > 12 maj 2017 kl. 12:44 skrev Tommaso Pasini : > > thanks for th

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

I have clang-802.0.42 installed. But I'm not 100% sure that this is what make is using. How can I check? Tommaso Pasini 2017-05-12 12:56 GMT+02:00 David Holmes : > What compiler (name and version) are you trying to use? > > David > > > On 12/05/2017 8:44 PM, Tommaso Pasini wrote: > >> thanks for

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

What compiler (name and version) are you trying to use? David On 12/05/2017 8:44 PM, Tommaso Pasini wrote: thanks for the answer, I tried to remove and reconfigure. Unfortunately I still have the same issue. This is very strange because the static variable _min_tree_chunk_size, seams declared c

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

thanks for the answer, I tried to remove and reconfigure. Unfortunately I still have the same issue. This is very strange because the static variable _min_tree_chunk_size, seams declared correctly in the class. Tommaso Pasini 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie : > My recommendation is

Re: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

My recommendation is that you remove the entire output directory ("rm -rf build"), re-do the configuration and try again. Before removing, you can do "make print-configuration" to get the command line you used to configure. /Magnus On 2017-05-12 12:12, Tommaso Pasini wrote: Hi guys, its the

Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation

Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X Sierra. I was able to configure but when I run the command make clean install, it stops with this error: hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error: > instantiation of variable 'TreeChunk > >::_min_tre

RFR: JDK-8180281 --with-jtreg is broken for many use cases

JDK-8179537 was opened with a request to document the brokenness of --with-jtreg. Better to fix it than to document how it's broken. Now --with-jtreg works like this: * --without-jtreg will explicitly disable jtreg. * --with-jtreg= will use the specified directory, and will do sanity checks t

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

Kumar, This was not an improvement. This will require additional changes in the build system to avoid a regression. I see no reason for that. In fact, I propose we close the bug as WNF. Let me elaborate. The problem here is that Oracle has dual roles: partly as a contributor to OpenJDK, and