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)
and put in the jdk/lib/... directorie
s resolved. 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
,
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
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 diff
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 of
actually similar enough 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.jav
New webrev:
http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.04/
On 2013-06-04 06:56, David Holmes wrote:
Hi Erik,
On 4/06/2013 12:21 AM, Erik Joelsson wrote:
Hi David,
Thanks for the comments, new webrev for jdk:
http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.03/
Thanks
/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/
The javascript part is no longer needed since it has been removed
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
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 a
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
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
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
! src/share/classes/com/sun/tools/sjavac/JavacState.jav
Changeset: 4300c2f5fb1b
Author:erikj
Date: 2013-08-16 16:00 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4300c2f5fb1b
8023146: Sjavac test failes in langtools nightly
Reviewed-by: mcimadamore, jfranck
! test/tools/sjavac/SJavac.java
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
Ha
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 wor
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 t
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 l
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
r
:
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 ch
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
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
! common/makefiles/RM
Changeset: 438c54c148a6
Author:erikj
Date: 2013-10-16 13:49 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/438c54c148a6
6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar
Reviewed-by: dholmes, chegar
! makefiles/BuildCorba.gmk
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
! makefiles/Generat
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
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
- make/data/cryptopolicy/limited/LIMITE
Changeset: 53d74b77ee53
Author:erikj
Date: 2014-01-08 14:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/rev/53d74b77ee53
8030781: System.setProperties(null) drops all system properties (RELEASE not
set)
Reviewed-by: alanb, ihse, tbell
! common/autoconf/generated-configure.sh
! c
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
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:
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
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
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
explic
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
MakeJavaSecurity.java
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 wrote
this
provider if testing an OpenJDK build.
--Sean
Thanks
Max
On Jul 28, 2014, at 19:43, Erik Joelsson
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, th
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
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
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: https://
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 would
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
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
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
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
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. T
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 java.
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
l
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 spe
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 jdk.dep
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 j
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 Peng
wrote:
Updated the webrev in place to use "osxse
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
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
http://cr.openjdk.java.
On 2013-03-14 20:37, Omair Majid wrote:
Andrew Hughes wrote the original changeset in the old build system [1]
and I believe this is exactly what he wanted out of the changeset. I am
CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant.
I didn't actually create that comment in
The build changes look ok.
/Erik
On 2013-03-18 12:00, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8010192/webrev.00/
The Mac native JGSS provider is back. Besides reverting changes made
in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106, there are:
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
prerequi
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 as
, 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
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
http://cr
timestamp.
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 genera
e 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
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
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 20
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 wi
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 par
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 are not
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 in
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
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
> comm
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 code.
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 c
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, by
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:
>> * firs
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:
>> * firs
Makefile change looks ok.
/Erik
On 2015-10-02 19:08, Anthony Scarpino wrote:
Hi all,
I'm need a review of the last developement piece to JEP 246, the
configuration changes.
I've copied the build-dev in case there were any comments on the minor
changes in the make directory related to the j
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 [
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.
lib/security
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, S
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
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
Tony
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
compatibil
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 fa
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 d
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 e
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,
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
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 compilations
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, M
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
jdk.security.auth
There is only one function t
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 da
ata/Gendata-java.base.gmk
59-$(MV) [email protected] $@
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 :
Build changes look ok.
/Erik
On 2018-05-22 08:25, Weijun Wang wr
Hello Magnus,
Very nice refactoring!
JdkNativeCompilation.gmk
line 126-127 looks a bit long. There is an extra space on 126. Also, why
not addprefix for adding -I instead of clunky foreach? Not that I care
greatly, but I usually prefer that construct.
Otherwise looks good.
/Erik
On 2018-0
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
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 sup
On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters wrote:
> Should I change the JBS issue title to match the PR title, or is it preferred
> for the PR title to change?
They need to match. You can either do it manually, or change the title to just
the bug number and the bot will change it for you.
On Thu, 17 Mar 2022 00:12:38 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
On Mon, 21 Mar 2022 16:29:25 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
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore
wrote:
> This PR contains the API and implementation changes for JEP-424 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.jav
On Tue, 22 Mar 2022 14:04:07 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Tue, 22 Mar 2022 19:07:12 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
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
1 - 100 of 125 matches
Mail list logo
