Re: RFR 8046002: Move Ucrypto to the open jdk repo
Hello Valierie, In Copy-java.base.gmk, you could change the findstring construct to a simple ifeq ($(OPENJDK_TARGET_OS), windows), perhaps even fold the whole ifndef OPENJDK into the previous ifeq since they are now the same. Otherwise it looks good to me. /Erik On 2014-10-15 20:46, Valerie Peng wrote: Hi, build experts, Could you please review the build-related changes for 8046002: Move Ucrypto to the open jdk repo? The rest (src/test) has been reviewed by my peers in security team. Bug: https://bugs.openjdk.java.net/browse/JDK-8046002 Webrev: http://cr.openjdk.java.net/~valeriep/8046002/webrev.01/ Thanks, Valerie
Re: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK
Hi, Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/ ./02/jdk9-open/ has 2 more deleted files than in ./01/jdk9-jdk-src/ test/com/sun/jmx/snmp/ SnmpOidHashCode.java, TimeTicksWrapping.java ./02/jdk9-make/ has one more modified: make/common/Modules.gmk Thanks, Shanliang Mandy Chung wrote: On 10/15/2014 9:04 AM, Mandy Chung wrote: Hi Shanliang, On 10/15/2014 8:19 AM, shanliang wrote: Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ Thanks for taking this on. The fix looks okay. I think you should also take out: make/common/Modules.gmk line 45: JAVA_MODULES_FILTER := jdk.snmp Also jdk/test/com/sun/jmx/snmp should be removed too. Mandy
RFR: Fix typo when translating characters in $USER.
Hi, I've noticed that when I do a build of OpenJDK 9 hs-comp forest then the generated build ID eats the w from my local username. Reproducer bash snippet: (USER=xwwwx; a=$(echo $USER | tr -d -c 'abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'); if [ $a == xx ]; then echo BAD; else echo GOOD; fi) It should print GOOD, but prints BAD. As it turns out there is a typo in common/autoconf/jdk-options.m4 webrev is here: https://jerboaa.fedorapeople.org/bugs/openjdk/JDK-UNKNOWN-build-dev/webrev.00/ Could someone please sponsor this change for me? Since I work for Red Hat the OCA has been signed. Thanks, Severin
Re: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK
Looks good now. /Erik On 2014-10-16 12:20, shanliang wrote: Hi, Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/ ./02/jdk9-open/ has 2 more deleted files than in ./01/jdk9-jdk-src/ test/com/sun/jmx/snmp/ SnmpOidHashCode.java, TimeTicksWrapping.java ./02/jdk9-make/ has one more modified: make/common/Modules.gmk Thanks, Shanliang Mandy Chung wrote: On 10/15/2014 9:04 AM, Mandy Chung wrote: Hi Shanliang, On 10/15/2014 8:19 AM, shanliang wrote: Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ Thanks for taking this on. The fix looks okay. I think you should also take out: make/common/Modules.gmk line 45: JAVA_MODULES_FILTER := jdk.snmp Also jdk/test/com/sun/jmx/snmp should be removed too. Mandy
Re: Build support for JDK-8044627
Erik, Pavel has already pushed the JNDI changes, and will follow up with the service configuration files later, so this issue is less pressing. If you like lets defer addressing the general problem of concatenating service configuration files until jigsaw/m2 is in the JDK 9 mainline. There is no urgency on this, and no point adding unnecessary merge complication ( which I think it what you are suggesting ). -Chris. On 15 Oct 2014, at 11:40, Erik Joelsson erik.joels...@oracle.com wrote: Hello, I have managed to come up with this solution for jdk9/dev. http://cr.openjdk.java.net/~erikj/8044627/webrev.01/ I added a gensrc step for each of the affected modules that simply concatenates the files into the gensrc output dir. The version found there will automatically override the one in the jdk/src. There is an extra complication at the top level as java.corba already had a gensrc step in the corba repo. The proper solution for that part will have to be done in Jigsaw M2, the merge will be hairy. I also had come up with a way to only include one of the files in resources.jar, since the jar command doesn't like duplicate entries. This is a bit of a hack, explicitly excluding 3 of the files, but since resource.jar is going away in M2 anyway, I think it's fine for now. /Erik On 2014-10-14 15:37, Erik Joelsson wrote: Hello Pavel, This will be a bit tricky. Give me a day or two and I will try to come up with something. /Erik On 2014-10-14 15:27, Pavel Rappo wrote: Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Re: RFR: Fix typo when translating characters in $USER.
Hello Severin, Thank you for the bugfix. It does indeed look like a typo. I can sponsor the change for you. However, to satisfy legal requirements, you will need to send the patch directly to us. Since it's small, you can just paste it in a mail to the mailing list and it will be fine. /Erik On 2014-10-16 12:58, Severin Gehwolf wrote: Hi, I've noticed that when I do a build of OpenJDK 9 hs-comp forest then the generated build ID eats the w from my local username. Reproducer bash snippet: (USER=xwwwx; a=$(echo $USER | tr -d -c 'abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'); if [ $a == xx ]; then echo BAD; else echo GOOD; fi) It should print GOOD, but prints BAD. As it turns out there is a typo in common/autoconf/jdk-options.m4 webrev is here: https://jerboaa.fedorapeople.org/bugs/openjdk/JDK-UNKNOWN-build-dev/webrev.00/ Could someone please sponsor this change for me? Since I work for Red Hat the OCA has been signed. Thanks, Severin
Re: Build support for JDK-8044627
Hello, The main problem is that we now will have Gensrc-$m.gmk for the same module in multiple repos. Now, that just happened again with my patch to split GensrcProperties.gmk (jdk.dev has gensrc in both langtools and jdk), so I took the time to solve it in M2. What I mean by this is that M2 is prepared to handle it and the merge will not be that complicated anymore. I would rather have it done and dealt with early. /Erik On 2014-10-16 14:49, Chris Hegarty wrote: Erik, Pavel has already pushed the JNDI changes, and will follow up with the service configuration files later, so this issue is less pressing. If you like lets defer addressing the general problem of concatenating service configuration files until jigsaw/m2 is in the JDK 9 mainline. There is no urgency on this, and no point adding unnecessary merge complication ( which I think it what you are suggesting ). -Chris. On 15 Oct 2014, at 11:40, Erik Joelsson erik.joels...@oracle.com wrote: Hello, I have managed to come up with this solution for jdk9/dev. http://cr.openjdk.java.net/~erikj/8044627/webrev.01/ I added a gensrc step for each of the affected modules that simply concatenates the files into the gensrc output dir. The version found there will automatically override the one in the jdk/src. There is an extra complication at the top level as java.corba already had a gensrc step in the corba repo. The proper solution for that part will have to be done in Jigsaw M2, the merge will be hairy. I also had come up with a way to only include one of the files in resources.jar, since the jar command doesn't like duplicate entries. This is a bit of a hack, explicitly excluding 3 of the files, but since resource.jar is going away in M2 anyway, I think it's fine for now. /Erik On 2014-10-14 15:37, Erik Joelsson wrote: Hello Pavel, This will be a bit tricky. Give me a day or two and I will try to come up with something. /Erik On 2014-10-14 15:27, Pavel Rappo wrote: Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Re: RFR: Fix typo when translating characters in $USER.
Hi Erik,
On Thu, 2014-10-16 at 16:52 +0200, Erik Joelsson wrote:
Hello Severin,
Thank you for the bugfix. It does indeed look like a typo. I can sponsor
the change for you. However, to satisfy legal requirements, you will
need to send the patch directly to us. Since it's small, you can just
paste it in a mail to the mailing list and it will be fine.
Sure, patch is attached and in the email body for reference:
diff --git a/common/autoconf/jdk-options.m4 b/common/autoconf/jdk-options.m4
--- a/common/autoconf/jdk-options.m4
+++ b/common/autoconf/jdk-options.m4
@@ -528,7 +528,7 @@
if test x$USER_RELEASE_SUFFIX = x; then
BUILD_DATE=`date '+%Y_%m_%d_%H_%M'`
# Avoid [:alnum:] since it depends on the locale.
- CLEAN_USERNAME=`echo $USER | $TR -d -c
'abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'`
+ CLEAN_USERNAME=`echo $USER | $TR -d -c
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'`
USER_RELEASE_SUFFIX=`echo ${CLEAN_USERNAME}_${BUILD_DATE} | $TR
'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
fi
fi
Thanks,
Severin
/Erik
On 2014-10-16 12:58, Severin Gehwolf wrote:
Hi,
I've noticed that when I do a build of OpenJDK 9 hs-comp forest then the
generated build ID eats the w from my local username. Reproducer bash
snippet:
(USER=xwwwx; a=$(echo $USER | tr -d -c
'abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'); if [
$a == xx ]; then echo BAD; else echo GOOD; fi)
It should print GOOD, but prints BAD.
As it turns out there is a typo in common/autoconf/jdk-options.m4
webrev is here:
https://jerboaa.fedorapeople.org/bugs/openjdk/JDK-UNKNOWN-build-dev/webrev.00/
Could someone please sponsor this change for me?
Since I work for Red Hat the OCA has been signed.
Thanks,
Severin
diff --git a/common/autoconf/jdk-options.m4 b/common/autoconf/jdk-options.m4
--- a/common/autoconf/jdk-options.m4
+++ b/common/autoconf/jdk-options.m4
@@ -528,7 +528,7 @@
if test x$USER_RELEASE_SUFFIX = x; then
BUILD_DATE=`date '+%Y_%m_%d_%H_%M'`
# Avoid [:alnum:] since it depends on the locale.
- CLEAN_USERNAME=`echo $USER | $TR -d -c 'abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'`
+ CLEAN_USERNAME=`echo $USER | $TR -d -c 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'`
USER_RELEASE_SUFFIX=`echo ${CLEAN_USERNAME}_${BUILD_DATE} | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
fi
fi
Re: Build support for JDK-8044627
On 16 Oct 2014, at 15:58, Erik Joelsson erik.joels...@oracle.com wrote: Hello, The main problem is that we now will have Gensrc-$m.gmk for the same module in multiple repos. Now, that just happened again with my patch to split GensrcProperties.gmk (jdk.dev has gensrc in both langtools and jdk), so I took the time to solve it in M2. What I mean by this is that M2 is prepared to handle it and the merge will not be that complicated anymore. I would rather have it done and dealt with early. Ok. I’m happy to defer the decision on this to you. -Chris. /Erik On 2014-10-16 14:49, Chris Hegarty wrote: Erik, Pavel has already pushed the JNDI changes, and will follow up with the service configuration files later, so this issue is less pressing. If you like lets defer addressing the general problem of concatenating service configuration files until jigsaw/m2 is in the JDK 9 mainline. There is no urgency on this, and no point adding unnecessary merge complication ( which I think it what you are suggesting ). -Chris. On 15 Oct 2014, at 11:40, Erik Joelsson erik.joels...@oracle.com wrote: Hello, I have managed to come up with this solution for jdk9/dev. http://cr.openjdk.java.net/~erikj/8044627/webrev.01/ I added a gensrc step for each of the affected modules that simply concatenates the files into the gensrc output dir. The version found there will automatically override the one in the jdk/src. There is an extra complication at the top level as java.corba already had a gensrc step in the corba repo. The proper solution for that part will have to be done in Jigsaw M2, the merge will be hairy. I also had come up with a way to only include one of the files in resources.jar, since the jar command doesn't like duplicate entries. This is a bit of a hack, explicitly excluding 3 of the files, but since resource.jar is going away in M2 anyway, I think it's fine for now. /Erik On 2014-10-14 15:37, Erik Joelsson wrote: Hello Pavel, This will be a bit tricky. Give me a day or two and I will try to come up with something. /Erik On 2014-10-14 15:27, Pavel Rappo wrote: Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Re: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK
On 10/16/14 3:20 AM, shanliang wrote: Hi, Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/ Looks fine to me. thanks Mandy
Did someone enable warnings=errors for more files?
Rhetorical question, actually — someone clearly did. Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or Clang.current on Mavericks. One of the offending directories is fdlibm, and I have experience with that, so since I can’t get anything else done, I will see about cleaning up that code. David
Re: Did someone enable warnings=errors for more files?
David, I think it is more appropriate to look to compile fdlibm with a different set of flags, as has been done in at least previous iterations of the build system. Thanks, -Joe On 10/16/2014 2:37 PM, David Chase wrote: Rhetorical question, actually — someone clearly did. Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or Clang.current on Mavericks. One of the offending directories is fdlibm, and I have experience with that, so since I can’t get anything else done, I will see about cleaning up that code. David
Re: Did someone enable warnings=errors for more files?
I am more competent at modifying FP source code than I am at tinkering with flags in our build system. If someone else is solving the problem, they might choose what works best for them, I am glad if that happens. But till something happens, I am (very) build-impaired, or I can just make all my changes to a downrev version of the source and hope that the patches apply. David On 2014-10-16, at 6:20 PM, Joe Darcy joe.da...@oracle.com wrote: David, I think it is more appropriate to look to compile fdlibm with a different set of flags, as has been done in at least previous iterations of the build system. Thanks, -Joe On 10/16/2014 2:37 PM, David Chase wrote: Rhetorical question, actually — someone clearly did. Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or Clang.current on Mavericks. One of the offending directories is fdlibm, and I have experience with that, so since I can’t get anything else done, I will see about cleaning up that code. David
Re: Did someone enable warnings=errors for more files?
Changes to fdlibm code should be review on core-libs-dev rather than build-dev. However, given the nature of the code, I am not inclined to approach changes to fdlibm to work around new C compiler warnings. -Joe On 10/16/2014 6:08 PM, David Chase wrote: I am more competent at modifying FP source code than I am at tinkering with flags in our build system. If someone else is solving the problem, they might choose what works best for them, I am glad if that happens. But till something happens, I am (very) build-impaired, or I can just make all my changes to a downrev version of the source and hope that the patches apply. David On 2014-10-16, at 6:20 PM, Joe Darcy joe.da...@oracle.com wrote: David, I think it is more appropriate to look to compile fdlibm with a different set of flags, as has been done in at least previous iterations of the build system. Thanks, -Joe On 10/16/2014 2:37 PM, David Chase wrote: Rhetorical question, actually — someone clearly did. Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or Clang.current on Mavericks. One of the offending directories is fdlibm, and I have experience with that, so since I can’t get anything else done, I will see about cleaning up that code. David
