hg: jdk8/build/jdk: 8026909: Retire Some Rarely Used GC Combintations
Changeset: 2a3afe1ec514 Author:rgallard Date: 2014-01-09 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2a3afe1ec514 8026909: Retire Some Rarely Used GC Combintations Summary: Fix only affects java command, nroff page, OpenJDK Reviewed-by: maxelsso ! src/bsd/doc/man/java.1 ! src/linux/doc/man/java.1 ! src/solaris/doc/sun/man/man1/java.1
Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
P.S. Forgot to mention, this looks good to me. Thanks for jumping in on this one. ;) Brad On 1/9/2014 12:07 AM, Anthony Scarpino wrote: Hi, I have a change that needs a review to the manifest.mf file for the Specification-Version from 1.8 to 1.9. This is needed as part of the build & signing of crypto signed jar files. Being from the security side and not the build side of the openjdk world, if there is a better way to address this, please let me know. http://cr.openjdk.java.net/~ascarpino/8031372/webrev.00/ thanks Tony
Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
On 1/9/2014 12:34 AM, Alan Bateman wrote: On 09/01/2014 08:07, Anthony Scarpino wrote: As an aside, I think we should strike while the iron is hot and get the changes required to move major versions written down somewhere (maybe checked into the forest). I see Joe has updated the JDK_MINOR_VERSION, there was change required to jtreg, and probably a few other changes that. Having these tasks captured somewhere might make it easier the next time. Agreed. See below. And Erik/Mark wrote: >> For the future, is there a reason for not automatically generating the >> "specification-version" based on the version numbers we have, or at >> least move the definition of it to the version numbers file? > Excellent question. We should try to minimize the number of places > where version numbers need to be changed. Just in case this suggestion gets forgotten, earlier this week, I added a few notes/links to JDK-8029942, the JDK 10 equivalent for JDK-8000962. JDK-8029942: Update JDK_MINOR_VERSION for JDK 10 JDK-8000962: Update JDK_MINOR_VERSION for JDK 9 If someone feels like including the bugid for JTREG changes, feel free to add it. If so, then we might want to change the synopsis to a more general "Update build version values to JDK 10" instead of "Update JDK_MINOR_VERSION for JDK 10". Brad
Unexpected Mac X11 dependency
I'm trying to do a vanilla build on Mac OS X Mavericks. (Using an old copy of Xcode 4.) Configure succeeds as follows, while acknowledging that X11 is not found: sh configure --with-boot-jdk=$JAVA7_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin ... checking what is not needed on MacOSX?... alsa pulse x11 checking for Mac OS X Java Framework... /System/Library/Frameworks/JavaVM.framework checking for X... no checking for X11/extensions/shape.h... no ... Building jdk gets a compiler error, complaining about a missing X11 header: make all ... In file included from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/pipe/Region.h:34, from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/loops/Blit.c:27: /Users/dan/Dev/jdk/jdk8/jdk/src/solaris/native/sun/awt/utility/rect.h:31:22: warning: X11/Xlib.h: No such file or directory In file included from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/pipe/Region.h:34, from /Users/dan/Dev/jdk/jdk8/jdk/src/share/native/sun/java2d/loops/Blit.c:27: /Users/dan/Dev/jdk/jdk8/jdk/src/solaris/native/sun/awt/utility/rect.h:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘RECT_T’ ... As I understand it, all dependencies on X11 were supposed to have been removed at the end of October. (Attempts to run configure on earlier versions fail, telling me I need X11.) I'm no expert on how these things are structured, but I find it odd that a file in src/solaris needs to be compiled by a Mac build (shouldn't it only depend on src/share and src/macosx?)... For now, my workaround is to add a compiler flag at configure time: sh configure \ --with-boot-jdk=$JAVA7_HOME \ --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin \ --with-extra-cflags=-I/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/X11/include But it would be helpful if this inconsistency could be addressed, either by i) removing the dependency (I think this is what is intended), or ii) enforcing the dependency at configure time. —Dan
Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
2014/1/8 16:47 -0800, erik.joels...@oracle.com: > ... > > For the future, is there a reason for not automatically generating the > "specification-version" based on the version numbers we have, or at > least move the definition of it to the version numbers file? Excellent question. We should try to minimize the number of places where version numbers need to be changed. - Mark
Re: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
On Jan 9 2014, at 04:30 , Magnus Ihse Bursie wrote: > On 2014-01-08 22:11, Mike Duigou wrote: >> You are correct. Sorry (wrong -r option and use of a file list misled me >> into thinking it was generating the right content). >> >> I have added >> >> http://cr.openjdk.java.net/~mduigou/JDK-8030350/3/webrev/ >> >> and checked to make sure it has the right content. > > Thanks! > > A question regarding the changes in toolchain.m4: > >> + CCXXFLAGS_JDK="$CCXXFLAGS $CCXXFLAGS_JDK -Wall -Wextra -Wformat=2 >> -Wno-unused-parameter -Wno-unused -Wno-parentheses \ > > Isn't -Wno-unused-parameter redundant if you have -Wno-unused? I have not > tested compiling code provoking that warning, but my understanding from > reading http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html is that > -Wno-unused will turn off all "unused" warnings. While unused-parameter is > usually only just annoying, some of the other are more intelligent and > useful, and could just as well be turned on -- but I understand if that is > not part of your current fix. For unknown reasons both seemed to be required. I am not sure why. Despite the -Wno-unused I still see many unused local warnings. Mike
Re: RFR: JDK-8030946, JDK-8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx
Hi Erik On 01/ 9/14 04:23 AM, Magnus Ihse Bursie wrote: On 2014-01-09 12:20, Erik Joelsson wrote: Hello, Please review the open part of this change for jdk8. New man pages have been added in jdk8, but the makefiles were never updated to include these man pages in the build. There are two separate bugs covering this: https://bugs.openjdk.java.net/browse/JDK-8031300 https://bugs.openjdk.java.net/browse/JDK-8030946 This change adds the new man pages to Images.gmk. It also adds new (empty) Japanese translations for the new pages for Macosx. We apparently do not have real translations for Macosx, but all the old man pages have empty dummys, and the build would fail without them. I also identified three such old dummy pages that aren't needed (and only existed for ja on macosx), klist, ktab and kinit, and removed them. http://cr.openjdk.java.net/~erikj/8031300/webrev.jdk.01/ /Erik Looks good to me. /Magnus Looks good to me as well. Tim
Re: RFR: JDK-8025936: Windows .pdb and .map files does not have proper dependencies setup
On 2014-01-08 15:38, Erik Joelsson wrote: Please review this fix for dependencies on windows pdb and map files. While in the area, I took the liberty of cleaning up a bit and removing some duplication. Webrev: http://cr.openjdk.java.net/~erikj/8025936/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025936 Thank you for cleaning this up! It looks much better now! I have a minor nit: 432 $1_EXTRA_LDFLAGS += "-pdb:$$($1_OBJECT_DIR)/$$($1_NOSUFFIX).pdb" \ 433 "-map:$$($1_OBJECT_DIR)/$$($1_NOSUFFIX).map" 434 $1_DEBUGINFO_FILES := $$($1_OBJECT_DIR)/$$($1_NOSUFFIX).map \ 435 $$($1_OBJECT_DIR)/$$($1_NOSUFFIX).pdb The change of order between map and pdb files does not really matter, but got me confused at first look. But it's no big deal, if you don't want to update the patch I will not blame you. :) /Magnus
Re: RFR: JDK-8030946, JDK-8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx
On 2014-01-09 12:20, Erik Joelsson wrote: Hello, Please review the open part of this change for jdk8. New man pages have been added in jdk8, but the makefiles were never updated to include these man pages in the build. There are two separate bugs covering this: https://bugs.openjdk.java.net/browse/JDK-8031300 https://bugs.openjdk.java.net/browse/JDK-8030946 This change adds the new man pages to Images.gmk. It also adds new (empty) Japanese translations for the new pages for Macosx. We apparently do not have real translations for Macosx, but all the old man pages have empty dummys, and the build would fail without them. I also identified three such old dummy pages that aren't needed (and only existed for ja on macosx), klist, ktab and kinit, and removed them. http://cr.openjdk.java.net/~erikj/8031300/webrev.jdk.01/ /Erik Looks good to me. /Magnus
Re: RFR: 8030350 : (s) Enable additional compiler warnings for GCC
On 2014-01-08 22:11, Mike Duigou wrote: You are correct. Sorry (wrong -r option and use of a file list misled me into thinking it was generating the right content). I have added http://cr.openjdk.java.net/~mduigou/JDK-8030350/3/webrev/ and checked to make sure it has the right content. Thanks! A question regarding the changes in toolchain.m4: + CCXXFLAGS_JDK="$CCXXFLAGS $CCXXFLAGS_JDK -Wall -Wextra -Wformat=2 -Wno-unused-parameter -Wno-unused -Wno-parentheses \ Isn't -Wno-unused-parameter redundant if you have -Wno-unused? I have not tested compiling code provoking that warning, but my understanding from reading http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html is that -Wno-unused will turn off all "unused" warnings. While unused-parameter is usually only just annoying, some of the other are more intelligent and useful, and could just as well be turned on -- but I understand if that is not part of your current fix. Other than that, it looks good. /Magnus
RFR: JDK-8030946, JDK-8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx
Hello, Please review the open part of this change for jdk8. New man pages have been added in jdk8, but the makefiles were never updated to include these man pages in the build. There are two separate bugs covering this: https://bugs.openjdk.java.net/browse/JDK-8031300 https://bugs.openjdk.java.net/browse/JDK-8030946 This change adds the new man pages to Images.gmk. It also adds new (empty) Japanese translations for the new pages for Macosx. We apparently do not have real translations for Macosx, but all the old man pages have empty dummys, and the build would fail without them. I also identified three such old dummy pages that aren't needed (and only existed for ja on macosx), klist, ktab and kinit, and removed them. http://cr.openjdk.java.net/~erikj/8031300/webrev.jdk.01/ /Erik
Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
On 2014-01-09 09:34, Alan Bateman wrote: On 09/01/2014 08:07, Anthony Scarpino wrote: Hi, I have a change that needs a review to the manifest.mf file for the Specification-Version from 1.8 to 1.9. This is needed as part of the build & signing of crypto signed jar files. Being from the security side and not the build side of the openjdk world, if there is a better way to address this, please let me know. http://cr.openjdk.java.net/~ascarpino/8031372/webrev.00/ This looks right to me. As an aside, I think we should strike while the iron is hot and get the changes required to move major versions written down somewhere (maybe checked into the forest). I see Joe has updated the JDK_MINOR_VERSION, there was change required to jtreg, and probably a few other changes that. Having these tasks captured somewhere might make it easier the next time. The patch looks good to me. For the future, is there a reason for not automatically generating the "specification-version" based on the version numbers we have, or at least move the definition of it to the version numbers file? /Erik
Re: Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
On 09/01/2014 08:07, Anthony Scarpino wrote: Hi, I have a change that needs a review to the manifest.mf file for the Specification-Version from 1.8 to 1.9. This is needed as part of the build & signing of crypto signed jar files. Being from the security side and not the build side of the openjdk world, if there is a better way to address this, please let me know. http://cr.openjdk.java.net/~ascarpino/8031372/webrev.00/ This looks right to me. As an aside, I think we should strike while the iron is hot and get the changes required to move major versions written down somewhere (maybe checked into the forest). I see Joe has updated the JDK_MINOR_VERSION, there was change required to jtreg, and probably a few other changes that. Having these tasks captured somewhere might make it easier the next time. -Alan
Code review request: 8031372 JDK 9 Specification-Version in jar files is still 1.8
Hi, I have a change that needs a review to the manifest.mf file for the Specification-Version from 1.8 to 1.9. This is needed as part of the build & signing of crypto signed jar files. Being from the security side and not the build side of the openjdk world, if there is a better way to address this, please let me know. http://cr.openjdk.java.net/~ascarpino/8031372/webrev.00/ thanks Tony
