RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Finally able to revisit this patch: With this patch the security tests will again be runnable on the exploded jdk image. The main changes are: * The security classes are compiled separately to a different output directory. * The security jars are created in the jdk target (instead of images)

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Woops, as some of you pointed out, I missed adding the link to the webrev: http://cr.openjdk.java.net/~erikj/8009280/webrev.02/ /Erik On 2013-08-16 10:46, Erik Joelsson wrote: Finally able to revisit this patch: With this patch the security tests will again be runnable on the exploded jdk im

Re: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

I see no objections to this, and I think it has been through enough review. I'll sponsor this change for Aleksej. -Chris. On 13/08/2013 10:20, Aleksej Efimov wrote: Stuart, Thanks for your comments. New webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.03/

RFR: 8021430: 64 bit JDK build fails on windows 7 due to missing corba source files

Please review this small fix for build failures on windows that were reported a couple of times recently. The abspath function in make sometimes garbles its output. In this case, the function call was a legacy leftover and no longer needed. Solution is to simply remove them. http://cr.openjdk.

Re: make dist-clean should remove javacservers directory

Hello Ivan, Thank you for the patch. It looks good and I will be happy to sponsor it for you. /Erik On 2013-08-01 22:48, Ivan Gerasimov wrote: Hello! When sjavac is enabled, configure creates $OUTPUT_ROOT/javacservers directory. However, make dist-clean doesn't remove it. Please find a s

Re: RFR: 8021430: 64 bit JDK build fails on windows 7 due to missing corba source files

Hi Erik: Please review this small fix for build failures on windows that were reported a couple of times recently. The abspath function in make sometimes garbles its output. In this case, the function call was a legacy leftover and no longer needed. Solution is to simply remove them. http://

hg: jdk8/build: 8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory

Changeset: 4fb877dfe5c4 Author:erikj Date: 2013-08-15 17:14 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/4fb877dfe5c4 8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory Reviewed-by:

Re: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

Chris, Thank you for review and for sponsorship. I have prepared hg changeset patches for root and jdk repositories: root repo patch: http://cr.openjdk.java.net/~aefimov/8021820/jdk8_hg.export jdk repo patch: http://cr.openjdk.java.net/~aefimov/8021820/jdk_jdk8_hg.export I think if there is no

Re: RFR: 8021430: 64 bit JDK build fails on windows 7 due to missing corba source files

On 8/16/2013 3:49 AM, Erik Joelsson wrote: Please review this small fix for build failures on windows that were reported a couple of times recently. The abspath function in make sometimes garbles its output. In this case, the function call was a legacy leftover and no longer needed. Solution is

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Erik: Woops, as some of you pointed out, I missed adding the link to the webrev: http://cr.openjdk.java.net/~erikj/8009280/webrev.02/ Looks good to me, but we should wait to hear from Brad. Tim

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Do the security tests have a particular requirement to run against the exploded jdk? Why not just test against the images? Mike On Aug 16 2013, at 01:46 , Erik Joelsson wrote: > Finally able to revisit this patch: > > With this patch the security tests will again be runnable on the exploded jd

RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

This failure happens when compiling with the VS 2012 compiler. The attach code relies on the order of two methods in the compiled binary and VS 2012 changed that order. The solution used is the linker flag /ORDER [1] which allows us to specify the order in which methods are laid out in the binar

Re: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

Hi, Aleksej, thanks for the update. The latest version looks good. Chris, thanks for sponsoring this change. s'marks On 8/16/13 7:51 AM, Aleksej Efimov wrote: Chris, Thank you for review and for sponsorship. I have prepared hg changeset patches for root and jdk repositories: root repo patch:

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Currently, the only way to get a valid build is to do an images build. Having to do a full image build adds too much time to the think/edit/compile/run environment. The default target build: % make381 will not create a valid JCE environment. The proper JCE signed files and policy files

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Hi Erik, I spent the last week getting familiar with the new build environment, but then got pulled of into something else. I'm glad I got pulled off, it looks like you were quietly working on many of the same issues I was. I would hate to have duplicated that work. Anyway, I'm close to be

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

On Aug 16 2013, at 13:17 , Brad Wetmore wrote: > Currently, the only way to get a valid build is to do an images build. Having > to do a full image build adds too much time to the think/edit/compile/run > environment. Have you looked at either sjavac or the JDK_FILTER features to reduce the o

Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

On 08/16/13 09:51 AM, Staffan Larsen wrote: This failure happens when compiling with the VS 2012 compiler. The attach code relies on the order of two methods in the compiled binary and VS 2012 changed that order. The solution used is the linker flag /ORDER [1] which allows us to specify the or