Re: Code review request: 8004235: Disable native JGSS provider on Mac

From a build point of view, this looks ok. I don't know of an easy way to write 2 ifneqs on the same line either. The way you did it is at least readable and as far as I know the common way of doing it in make. /Erik On 2012-12-07 11:39, Weijun Wang wrote: The native JGSS provider on Mac is

Re: Code review: 8004904: Makefile for ntlm (was Re: com/sun/security/ntlm)

That is correct, the new build will already handle incremental building of any changed java file, so this won't make a difference. Thanks for the heads up anyway! /Erik On 2012-12-12 04:32, Weijun Wang wrote: Hi Chris/Mark I've added a makefile, please take a look

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

. Hopefully one more nail in the old build's coffin. The jdk target should depend upon genclasses. It seems really strange to have this as a dependency for securityjars and not jdk. Mike On Apr 30 2013, at 07:45 , Erik Joelsson wrote: With this patch the security tests will again be runnable

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

, David On 1/05/2013 12:45 AM, Erik Joelsson wrote: 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

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

This patch didn't work with sjavac enabled. Back to the drawing board. /Erik On 2013-04-30 16:45, Erik Joelsson wrote: 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

Re: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

Finally getting back to this. Updated webrevs: http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.02/ http://cr.openjdk.java.net/~erikj/8010785/webrev.root.02/ The javascript part is no longer needed since it has been removed. /Erik On 2013-04-11 12:53, Erik Joelsson wrote: Open part

Re: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

to that of BUILD_CRYPTO to be treated as the same. I moved this to a closed file. /Erik Thanks, David On 31/05/2013 8:14 PM, Erik Joelsson wrote: Finally getting back to this. Updated webrevs: http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.02/ http://cr.openjdk.java.net/~erikj/8010785/webrev.root.02

Re: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

:14 PM, Erik Joelsson wrote: Finally getting back to this. Updated webrevs: http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.02/ http://cr.openjdk.java.net/~erikj/8010785/webrev.root.02/ The javascript part is no longer needed since it has been removed. /Erik On 2013-04-11 12:53, Erik

Re: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

On 2013-06-07 04:08, David Holmes wrote: On 4/06/2013 10:38 PM, David Holmes wrote: On 4/06/2013 9:21 PM, Erik Joelsson wrote: On 2013-06-04 06:56, David Holmes wrote: I think we should add a (configure time?) check to watch for the illegal: BUILD_CRYPTO=no, OPENJDK=true. Not sure

Re: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

On 2013-06-11 09:22, David Holmes wrote: Erik, On 7/06/2013 7:50 PM, Erik Joelsson wrote: On 2013-06-07 04:08, David Holmes wrote: On 4/06/2013 10:38 PM, David Holmes wrote: On 4/06/2013 9:21 PM, Erik Joelsson wrote: On 2013-06-04 06:56, David Holmes wrote: I think we should add

Re: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

On 2013-06-11 10:59, David Holmes wrote: On 11/06/2013 5:47 PM, Erik Joelsson wrote: On 2013-06-11 09:22, David Holmes wrote: Erik, On 7/06/2013 7:50 PM, Erik Joelsson wrote: On 2013-06-07 04:08, David Holmes wrote: On 4/06/2013 10:38 PM, David Holmes wrote: On 4/06/2013 9:21 PM

hg: jdk8/tl/langtools: 8014513: Sjavac doesn't detect 32-bit jvm properly

Changeset: dcc6a52bf363 Author:erikj Date: 2013-06-27 10:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dcc6a52bf363 8014513: Sjavac doesn't detect 32-bit jvm properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java

hg: jdk8/tl/langtools: 8015145: Smartjavac needs more flexibility with linking to sources

Changeset: 71b0089b146f Author:erikj Date: 2013-08-15 17:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71b0089b146f 8015145: Smartjavac needs more flexibility with linking to sources Reviewed-by: jjg, ohrstrom !

Re: Code review request: 8011402: Move blacklisting certificate logic from hard code to data

Hello Max, I couldn't find the link to the review but I'm guessing this is the one: http://cr.openjdk.java.net/~weijun/8011402/webrev.00/ On 2013-09-06 15:30, Weijun Wang wrote: Hi Sean Please review the code changes at 8011402: Move blacklisting certificate logic from hard code to data

Re: Code review request: 8011402: Move blacklisting certificate logic from hard code to data

On 2013-09-06 16:25, Weijun Wang wrote: On 9/6/13 10:07 PM, Erik Joelsson wrote: Hello Max, I couldn't find the link to the review but I'm guessing this is the one: http://cr.openjdk.java.net/~weijun/8011402/webrev.00/ Correct, sorry about that. 3. Most important: it only works if both

Re: webrev.01 of 8011402: Move blacklisting certificate logic from hard code to data

On 2013-09-11 15:32, Weijun Wang wrote: Slightly updated at the same location. Added different algorithm check in the 2 makefiles. I should have noticed this earlier, but in CopyFiles.gmk, the whole thing is enclosed in ifndef OPENJDK. I would expect lines 403 to 415 to be moved outside of

Re: webrev.01 of 8011402: Move blacklisting certificate logic from hard code to data

Build change looks ok. /Erik On 2013-09-17 13:07, Weijun Wang wrote: Webrev updated to version 02 at http://cr.openjdk.java.net/~weijun/8011402/webrev.02/ Changes since webrev.01: 1. Makefiles: - new build logic outside ifndef OPENJDK - Add a sed check to make sure open and close

Re: [8] Review Request for 8007292 : Add JavaFX internal packages to package.access

Hello Sean, On 2013-10-09 06:33, David Holmes wrote: Hi Sean, Not a full review. On 9/10/2013 5:52 AM, Sean Mullan wrote: Please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8007292 This bug requires build changes and a new build tool to add additional

Re: [8] Review Request for 8007292 : Add JavaFX internal packages to package.access

: On 10/09/2013 05:14 AM, Erik Joelsson wrote: Hello Sean, On 2013-10-09 06:33, David Holmes wrote: Hi Sean, Not a full review. On 9/10/2013 5:52 AM, Sean Mullan wrote: Please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8007292 This bug requires build changes

Re: [8] Review Request for 8007292 : Add JavaFX internal packages to package.access

On 2013-10-10 19:45, Sean Mullan wrote: On 10/10/2013 05:57 AM, Erik Joelsson wrote: Adding makefiles to make/tools is not needed for the new build. Either remove those changes or make a complete port to the old build. I'm not pushing for porting this to the old build at this point since

hg: jdk8/tl: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

Changeset: af81988013b5 Author:erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af81988013b5 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! common/makefiles/JavaCompilation.gmk !

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 76a7c0bc74fd Author:erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76a7c0bc74fd 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/GendataBreakIterator.gmk !

hg: jdk8/tl: 8027963: Create unlimited policy jars.

Changeset: c009462c1e92 Author:erikj Date: 2013-12-04 12:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c009462c1e92 8027963: Create unlimited policy jars. Reviewed-by: wetmore, ihse ! common/autoconf/spec.gmk.in

hg: jdk8/tl/jdk: 8027963: Create unlimited policy jars.

Changeset: 427c78c88229 Author:erikj Date: 2013-12-05 09:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/427c78c88229 8027963: Create unlimited policy jars. Reviewed-by: wetmore, ihse ! make/CreateSecurityJars.gmk ! make/SignJars.gmk -

hg: jdk8/tl/jdk: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 2437ccbf3504 Author:erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java

hg: jdk8/tl/jdk: 8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx; ...

Changeset: 6f3a3bd78c57 Author:erikj Date: 2014-01-10 10:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f3a3bd78c57 8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx 8030946: No jmc.1 for man page of JMC Reviewed-by:

hg: jdk8/tl/jdk: 8032217: failure in man page processing

Changeset: ff56039c4870 Author:erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk

hg: jdk8/tl: 8032632: Wrong version for the first jdk8 fcs build

Changeset: 7238a870ddb7 Author:erikj Date: 2014-01-24 10:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7238a870ddb7 8032632: Wrong version for the first jdk8 fcs build Reviewed-by: katleman ! common/autoconf/spec.gmk.in

Re: Review request: 8040059 Change default policy for extensions to no permission

Hello Mandy, The logic looks fine. Just some style issues. I would like indentation for the conditionals to be 2 spaces as is currently the standard in the makefiles. I would also like to have POLICY_SRC_LIST to be declared empty with := instead of just =. We only use = assignment when

Re: RFR 6997010: Consolidate java.security files into one file with modifications

Hello Max, Shouldn't the rule for $(GENDATA_JAVA_SECURITY) depend on $(RESTRICTED_PKGS_SRC) so that updates to the pkgs file triggers a rebuild? For that to work, the variable $(RESTRICTED_PKGS_SRC) needs to be empty for the OPENJDK case rather than have a dummy name and

Re: RFR 6997010: Consolidate java.security files into one file with modifications

Build change looks good to me now. /Erik On 2014-07-28 15:53, Wang Weijun wrote: Yes, you are right. Webrev updated at http://cr.openjdk.java.net/~weijun/6997010/webrev.02. GendataJavaSecurity.gmk and MakeJavaSecurity.java updated. Thanks Max On Jul 28, 2014, at 19:43, Erik Joelsson

Re: RFR 6997010: Consolidate java.security files into one file with modifications

this provider if testing an OpenJDK build. --Sean Thanks Max On Jul 28, 2014, at 19:43, Erik Joelsson erik.joels...@oracle.com wrote: Hello Max, Shouldn't the rule for $(GENDATA_JAVA_SECURITY) depend on $(RESTRICTED_PKGS_SRC) so that updates to the pkgs file triggers a rebuild? For that to work

Re: RFR 6997010: Consolidate java.security files into one file with modifications

On 2014-08-06 11:14, Weijun Wang wrote: On 8/6/2014 17:04, Erik Joelsson wrote: Speaking of indentation, please also change the ifdef bodies to 2 spaces. Sure. Whenever I edit a Makefile, I dare not use spaces and always use TABs. Obviously an ifdef does not need it. The tab character

Re: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory

Change looks good to me. /Erik On 2014-09-10 18:28, Valerie Peng wrote: Could someone please review this build related change for moving sunpkcs11-solaris.cfg file to the pkcs11 module? Webrev: http://cr.openjdk.java.net/~valeriep/8039898/webrev.00/ Thanks, Valerie

RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is causing compilation errors building jdk9 source code

Hello, Please review the open part of this patch, which changes the building of policy jars to happen even if BUILD_CRYPTO is false. Previously these weren't built as there were signed versions of these jars, but since we no longer sign them, there is no need to not build them. Bug:

Re: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5

Looks good to me. Thanks for fixing warnings! /Erik On 2015-03-16 04:12, Wang Weijun wrote: Hi All Please review the change at http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ Thanks Max

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

Thanks, looks good! /Erik On 2015-03-06 17:14, Magnus Ihse Bursie wrote: On 2015-03-04 14:31, Erik Joelsson wrote: Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line options to grep so that the command line could be copied to the shell for debugging in the future? Also, how hard

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

Hello Mandy, The build changes look ok to me. /Erik On 2015-03-05 02:13, Mandy Chung wrote: As listed in an open issue in JEP 200: The jdk.dev and jdk.runtime modules contain miscellaneous tools that do not obviously belong to any other module; these modules will eventually be either renamed

Re: RFR: JDK-8074859 Turn on warnings as error

Looks good to me. /Erik On 2015-04-17 14:52, Magnus Ihse Bursie wrote: With JDK-8074096, the number of warnings in the product was reduced to a minimum. This enables the next step, which is turning on the respective compiler flags that turns warnings into errors. In the long run, this is the

Re: RFR 7191662: JCE providers should be located via ServiceLoader

Hello Valerie, The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile

Re: RFR 7191662: JCE providers should be located via ServiceLoader,

On 2015-05-22 02:46, Mandy Chung wrote: I’m including build-dev and we need to ask for Erik and Magnus advice what’s the best way to work around this. Erik, Magnus, Security providers now become service providers. They are provided from 11 different modules, 3 of them are os-specific.

Re: RFR 7191662: JCE providers should be located via ServiceLoader,

On 2015-05-22 18:53, Mandy Chung wrote: On 05/22/2015 08:09 AM, Alan Bateman wrote: On 22/05/2015 13:55, Chris Hegarty wrote: : I think it could be done either way. Valerie - have you considered not pushing the services configuration files with this change? With the change then the

Re: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module

Build changes still look good. /Erik On 2015-08-15 01:30, Valerie Peng wrote: Updated the webrev in place to use osxsecurity given peer feedbacks. Thanks, Valerie On 8/13/2015 7:31 PM, Valerie Peng wrote: Can someone please help reviewing this change? This is to move Apple provider from

Re: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module

One is enough. /Erik On 2015-08-18 02:21, Valerie Peng wrote: Thanks for the review. Is one more reviewer from build team needed? Valerie On 8/14/2015 4:58 PM, Mandy Chung wrote: Looks good. Mandy On Aug 14, 2015, at 4:30 PM, Valerie Pengvalerie.p...@oracle.com wrote: Updated the

Re: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module

Build changes look good. /Erik On 2015-08-14 04:31, Valerie Peng wrote: Can someone please help reviewing this change? This is to move Apple provider from jdk.deploy.osx module to java.base module. The native library for Apple provider is separated out from the osx one generated in

Re: [9] RFR 8130665 java/lang/SecurityManager/CheckSecurityProvider.java failing in jake on OS X

Hello Valerie, To reduce duplication, I think something like this would be preferable. Remove the windows and macosx checks and just always run this line: POLICY_SRC_LIST += \ $(wildcard $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/conf/security/java.policy) That way, I platform

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

Much better, and thank you for fixing the existing mkdir/echo lines too. Just one nit, for this continuation: $(TOOL_CACERTSHASHER) -i $(GENDATA_CACERTSHASHER_IN) \ -o $(GENDATA_CACERTSHASHER) please use tab+4spaces for the second line. No need to resend webrev for that. See

Re: RFR 8162739: Create new keytool option to access cacerts file

Build change looks fine. /Erik On 2016-08-08 15:46, Weijun Wang wrote: Please review the code changes at http://cr.openjdk.java.net/~weijun/8162739/webrev.00/ A new -cacerts option is added to keytool so there is no need to provide the full cacerts path on the command line.

Re: RFR: 8164071: Default.policy file missing content for solaris

On 2016-08-17 18:43, Sean Mullan wrote: On 8/17/2016 12:33 PM, Erik Joelsson wrote: Hello Sean, The change looks ok, but it could also be expressed like this to avoid duplication: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) DEF_POLICY_SRC_LIST += $(JDK_TOPDIR)/src

Re: RFR: 8164071: Default.policy file missing content for solaris

Hello Sean, The change looks ok, but it could also be expressed like this to avoid duplication: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) DEF_POLICY_SRC_LIST += $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy endif /Erik On 2016-08-17 18:18,

Re: RFR 8074838: Resolve disabled warnings for libj2pkcs11

Looks ok to me. /Erik On 2016-08-25 23:20, Anthony Scarpino wrote: Hi, Can I get a review of this change to remove the warning suppression and fix the minor compiler issues that it was hiding in the pkcs11 wrapper library. http://cr.openjdk.java.net/~ascarpino/8074838/webrev/ thanks

Re: RFR: 8157561 :Ship the unlimited policy files in JDK Updates

Build changes look ok to me. /Erik On 2016-11-04 14:42, Seán Coffey wrote: Looking to push this enhancement to jdk8u. The change introduces the new Security property which was brought into JDK 9 via JDK-8061842. The code differs in that jar files continue to be used and backwards

Re: RFR: 8170157/8169335: Unlimited Cryptography Policy Changes

Looks good. /Erik On 2016-12-03 00:50, Bradford Wetmore wrote: Hi, I need reviewers for these related bugs: https://bugs.openjdk.java.net/browse/JDK-8170157 Enable unlimited cryptographic policy by default in OracleJDK https://bugs.openjdk.java.net/browse/JDK-8169335 Add a crypto policy

Re: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory

Nah, it's fine. /Erik On 2017-05-09 04:37, Magnus Ihse Bursie wrote: On 2017-05-05 17:52, Erik Joelsson wrote: What's the reason for adding the conditional around SetupCopyFiles in Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an empty FILES list. It should evaluate

Re: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory

What's the reason for adding the conditional around SetupCopyFiles in Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an empty FILES list. It should evaluate to basically nothing in that case. /Erik On 2017-05-05 06:17, Magnus Ihse Bursie wrote: The Security Standard Names

Re: RFR 8148371: Remove policytool

From a build point of view this looks good. /Erik On 2017-09-06 06:17, Weijun Wang wrote: Hi All Please review the change, which spans to root, jdk and langtools repos. http://cr.openjdk.java.net/~weijun/8148371/ I've searched for the "policytool" word in the whole jdk10/jdk10 forests,

Re: RFR 8201815: Use Mozilla Public Suffix List

Build changes look ok. /Erik On 2018-05-22 08:25, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL

Re: RFR 8201815: Use Mozilla Public Suffix List

below cases, CHMOD is called after MV/CP. gendata/Gendata-java.base.gmk 59-$(MV) $@.tmp $@ 60:$(CHMOD) 444 $@ 61- common/JavaCompilation.gmk 80-$(CP) $$< $$@ 81:$(CHMOD) -f ug+w $$@ Thanks Max /Magnus 22 maj 2018 kl. 17:44 skrev Erik Joelsson <erik.joels...@oracle.com>:

Re: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically

Looks good. /Erik On 2018-06-08 01:50, Magnus Ihse Bursie wrote: On 2018-06-07 23:20, Erik Joelsson wrote: Hello Magnus, Very nice refactoring! Thanks! JdkNativeCompilation.gmk line 126-127 looks a bit long. There is an extra space on 126. Also, why not addprefix for adding -I instead

Re: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI

Build change looks good. /Erik On 2018-06-21 04:12, Weijun Wang wrote: Please take a review on this change http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ and the release note at https://bugs.openjdk.java.net/browse/JDK-8205471 The code change adds RSASSA-PSS signature

Re: RFR: JDK-8199640 Split up BUILD_LIBKRB5 into the two, unrelated compilations it consists of

Looks good. /Erik On 2018-03-14 16:18, Magnus Ihse Bursie wrote: BUILD_LIBKRB5 is currently a strange chimera between compiling w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share source code, name or compilation options. This patch separates them into two separate

Re: RFR: JDK-8199636 Unify naming for jaas_unix and jaas_nt

Looks good. /Erik On 2018-03-14 14:50, Magnus Ihse Bursie wrote: For some odd reason, the native library compiled for jdk.security.auth is called jaas_unix on unix and jaas_nt on windows. There's no good reason for this, and it breaks with the common practice in OpenJDK. This patch renames

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

Build changes still look good to me. /Erik On 2018-03-28 03:31, Magnus Ihse Bursie wrote: On 2018-03-28 01:52, Weijun Wang wrote: On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: https://bugs.openjdk.java.net/browse/JDK-8200193 -- for

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

I have looked at the build changes and they look good. Will you file followups for each component team to look over their exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt laying around here. /Erik On 2018-03-23 06:56,

Re: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir Thanks, Max On May 31, 2019, at 1:34 AM, Erik Joelsson wrote: On 2019-05-30 08:32, Weijun Wang wrote: On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: In my experience, using directories for dependencies in make does not work well. Since all

Re: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

Hello Max, Looking in ToolsJdk.gmk, I realize that the BUILD_TOOLS variable was renamed back when we unified the repositories and is now called BUILD_TOOLS_JDK. It seems like I missed updating the references to this variable in the gendata dir. If you use the new variable name in the

Re: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

On 2019-05-30 08:32, Weijun Wang wrote: On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites

Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file

I'm happy with this. /Erik On 2019-06-14 08:33, Weijun Wang wrote: Here is the updated webrev http://cr.openjdk.java.net/~weijun/8225392/webrev.01/ The only change is ordering in 'keytool -list' and its test. Thanks, Max On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote: On 6/14/19 1:49

Re: RFR: JDK-8225392: Comparison builds are failing due to cacerts file

. On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson wrote: Since JDK-8193255, when we started generating the cacerts file in the build, the build compare baseline builds have started failing. It seems the cacerts binary file has some non determinism built in so it doesn't get generated exactly

Re: RFR: JDK-8225392: Comparison builds are failing due to cacerts file

not integrated into the JDK until after they were created by the CA. Can we somehow extract the last revision time of each PEM file instead? That is more aligned with the previous creation date that we used. --Sean On 6/12/19 12:38 PM, Erik Joelsson wrote: Hello Max, Much appreciated! I

Re: RFR 6722928: Support SSPI as a native GSS-API provider

Hello Max, I believe $(call FindSrcDirsForLib, $(MODULE), sspi_bridge) for SRC is the default so you shouldn't need to specify it explicitly, or did you experience some problems with the default that I'm missing? /Erik On 2019-06-09 19:30, Weijun Wang wrote: Updated webrev at

Re: RFR: 8231351: Add notes for PKCS11 tests in the test doc

I think this type of comment fits well in the top level test doc. It just provides basic instructions for setting up these tests so that they pass without going into too much detail. Perhaps a reference to the pkcs11 README for more details would be a good idea. Looks good to me. /Erik On

Re: RFR: 8231351: Add notes for PKCS11 tests in the test doc

in the patch. Hope you wouldn't mind it. Thanks. Could you please sponsor it? Thanks a lot. Best regards, Jia 在 2019年09月23日 23:18, Erik Joelsson 写道: I think this type of comment fits well in the top level test doc. It just provides basic instructions for setting up these tests so that they pass without

Re: RFR 8234697: Generate sun.security.util.math.intpoly classes during build

On 2019-11-25 16:42, Weijun Wang wrote: On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: Build change looks good. Thanks. One question: I see the output to stdout from FieldGen.java shown in build. Is it possible to hide it but still store the output in the log file? No, we

Re: RFR 8234697: Generate sun.security.util.math.intpoly classes during build

On 2019-11-26 16:39, Weijun Wang wrote: On Nov 27, 2019, at 12:14 AM, Erik Joelsson wrote: On 2019-11-25 16:42, Weijun Wang wrote: On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: Build change looks good. Thanks. One question: I see the output to stdout from FieldGen.java shown

Re: RFR 8234697: Generate sun.security.util.math.intpoly classes during build

Build change looks good. /Erik On 2019-11-22 18:59, Weijun Wang wrote: Please review the change at http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. I changed the BigInteger

Re: RFR 8240261: Use make/templates/gpl-cp-header in FieldGen.java

Build changes look ok. /Erik On 2020-02-29 05:02, Weijun Wang wrote: Please take a review at https://cr.openjdk.java.net/~weijun/8240261/webrev.00 Thanks, Max

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v2]

On Thu, 8 Oct 2020 10:29:24 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the third incubation round >> of the foreign memory access API incubation >> (see JEP 393 [1]). This iteration focus on improving the usability of the >> API in 3 main ways: >> *

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v3]

On Thu, 8 Oct 2020 13:59:20 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the third incubation round >> of the foreign memory access API incubation >> (see JEP 393 [1]). This iteration focus on improving the usability of the >> API in 3 main ways: >> *

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)

On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore wrote: > This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation > (see JEP 393 [1]). This iteration focus on improving the usability of the API > in 3 main ways: > * first,

Re: RFR: 8235710: Remove the legacy elliptic curves

On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and > calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove > from all source builds of the ec

Re: RFR: 8235710: Remove the legacy elliptic curves [v2]

On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and >> calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove >> from all source builds of the ec

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a >> separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional >

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On 2020-12-08 00:30, Magnus Ihse Bursie wrote: On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote: I have reviewed all lines in the patch file with or near instances of `jdk.compiler` Hi Magnus, I see the motivation of moving these build files for better identification of ownership.

Re: RFR: 8257733: Move module-specific data from make to respective module

On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson wrote: >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably the >> most suitable home because Java SE specifies JDWP as an optiona

Re: RFR: 8257733: Move module-specific data from make to respective module

On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >> And I can certainly move jdwp.spec to java.base instead. That's the reason I >> need input on this: All I know is that is definitely not the responsibility >> of the Build Group to maintain that document, and I made my best guess at >>

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . It looks like you have

Re: RFR: 8253866: Security Libs Terminology Refresh

On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace > archaic/non-inclusive words with more neutral terms (see JDK-8253315 for > details). > > Here are the changes covering core libraries code and tests. Terms were > changed as

Re: RFR: 8257733: Move module-specific data from make to respective module [v4]

On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8259886 : Improve SSL session cache performance and scalability

On Mon, 1 Feb 2021 18:30:14 GMT, Erik Joelsson wrote: >> I'm trying to benchmark a class that is in a non-exported package >> `sun.security.util`. Without this line the benchmark doesn't compile. I >> couldn't find any other benchmarks that access non-exported classes, so I

Re: RFR: 8259886 : Improve SSL session cache performance and scalability

On Mon, 1 Feb 2021 18:24:46 GMT, djelinski wrote: >> make/test/BuildMicrobenchmark.gmk line 97: >> >>> 95: SRC := $(MICROBENCHMARK_SRC), \ >>> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 97: JAVAC_FLAGS := $(JAVAC_FLAGS) --add-exports >>> java.base/sun.security.util=ALL-UNNAMED, \

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7]

On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from >> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from >>

Re: RFR: 8259886 : Improve SSL session cache performance and scalability [v2]

On Mon, 1 Feb 2021 18:49:04 GMT, djelinski wrote: >> Under certain load, MemoryCache operations take a substantial fraction of >> the time needed to complete SSL handshakes. This series of patches improves >> performance characteristics of MemoryCache, at the cost of a functional >> change:

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

On 2021-01-26 04:44, Magnus Ihse Bursie wrote: On 2021-01-26 13:09, Vladimir Kempik wrote: On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward wrote: AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework ie: `--with-extra-ldflags='-F

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. >

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v6]

On Thu, 3 Jun 2021 16:43:51 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign >> Linker API. We realized that, while handy, the *default* lookup abstraction >> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >>

Re: RFR: 8267123: Remove RMI Activation

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m

On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from >

Re: RFR: 8259886 : Improve SSL session cache performance and scalability

On Wed, 27 Jan 2021 11:32:08 GMT, djelinski wrote: > Under certain load, MemoryCache operations take a substantial fraction of the > time needed to complete SSL handshakes. This series of patches improves > performance characteristics of MemoryCache, at the cost of a functional > change:

  1   2   >