This looks good to me, but I would like to hear from someone who knows
the benchmarks to confirm that nothing relevant to the tests was lost
when introducing autoboxing instead of explicit constructors in any of
the cases.
/Erik
On 2020-04-20 04:51, Magnus Ihse Bursie wrote:
This patch addres
(adding build-dev)
Hello Alexey,
The SetupJdkExecutable and SetupJdkLibrary macros are designed to find
the correct source dirs automatically as long as they follow the
standard naming. In this case you are adding some extra with the
"common" dir as well as reusing some src dirs between multi
includes only incremental changes to
Lib-jdk.incubator.jpackage.gmk for clarity.
[1]
http://cr.openjdk.java.net/~asemenyuk/8242302/webrev.01/webrev.01/index.html
- Alexey
On 4/20/2020 1:17 PM, Erik Joelsson wrote:
(adding build-dev)
Hello Alexey,
The SetupJdkExecutable and SetupJdkLibrary
Looks good.
/Erik
On 2020-05-29 10:07, Bob Vandette wrote:
Please review this change that alters the make target “make-static-libs” to
produce static
libraries for ALL native libraries in the JDK. Prior to this fix we only built
a small select list.
Note: I had to change the functions JAWT_
Hello Igor,
In JtretNativeLibTest.gmk, lines 51-55 should probably be removed (or
adjusted if linking to libjvm is actually needed).
/Erik
On 2020-06-12 21:10, Igor Ignatyev wrote:
testing revealed that LingeredAppTest.java required some love, incremental
webrev w/ the fixes for LingeredApp
On 2020-06-15 08:12, Magnus Ihse Bursie wrote:
A few comments:
This seems like code copied from elsewhere:
57 # This evaluation is expensive and should only be done if this
target was
58 # explicitly called.
59 ifneq ($(filter build-test-libtest-jtreg-native, $(MAKECMDGOALS)), )
I do
mment, I don't know enough details to say if it's
expensive or not, yet if you insist and there is a consensus within
build team, I can remove the comment.
82 $(eval $(call SetupCopyFiles,COPY_LIBTEST_JTREG_NATIVE, \
Please use space after comma.
this again was preexisting in Jt
There are a lot of jtreg tests that use temporary files. These temporary
files add up over time and fill up the global temp directories on our
test systems. To tackle this, we should try to redirect these temporary
files into a directory controlled by the test framework. Jtreg does not
do this,
(re-sending this as it doesn't look like it was delivered)
There are a lot of jtreg tests that use temporary files. These temporary
files add up over time and fill up the global temp directories on our
test systems. To tackle this, we should try to redirect these temporary
files into a directo
On 2020-06-17 01:24, Alan Bateman wrote:
On 16/06/2020 18:44, Erik Joelsson wrote:
There are a lot of jtreg tests that use temporary files. These
temporary files add up over time and fill up the global temp
directories on our test systems. To tackle this, we should try to
redirect these
On 2020-06-17 07:43, Alan Bateman wrote:
On 17/06/2020 14:47, Erik Joelsson wrote:
I've tried to make this clearer in the comment.
http://cr.openjdk.java.net/~erikj/8213214/webrev.02/
I would prefer if you could move the notes/comment from L125-157 to
the bug report to avoid clutt
Doc changes look good.
/Erik
On 2020-07-06 18:10, Kim Barrett wrote:
I just noticed that doc/building.{md,html} describes minimum toolchain versions,
so also needs to be updated. Here’s the update, matching what’s now in the JEP:
full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
in
Hello Ningsheng,
Build change looks good.
/Erik
On 2020-07-23 01:02, Ningsheng Jian wrote:
Hi Vladimir,
Thanks for pointing out this. Yes, I missed that change in shared
code. I've regenerated the webrev, with GensrcAdlc.gmk file change
included:
http://cr.openjdk.java.net/~njian/vectorap
Build change looks ok, but why is it needed? You are fixing a bunch of
warnings in one part of the source and disabling them in another part.
Is there some other change incoming that will enable more warning
categories by default?
/Erik
On 2020-08-25 11:47, Joe Wang wrote:
Cc-ing build-...@o
triggered today? I
don't see any change enabling more warnings from the build.
/Erik
$.02, Roger
On 8/25/20 2:58 PM, Erik Joelsson wrote:
Build change looks ok, but why is it needed? You are fixing a bunch
of warnings in one part of the source and disabling them in another
part. Is there some
essibility html missing syntax reference).
-Joe
On 8/25/20 12:39 PM, Erik Joelsson wrote:
On 2020-08-25 12:21, Roger Riggs wrote:
Hi Erik,
org.w3c is in third party code that is not being updated. There is a
balance between
ignoring the warnings and doing a bunch of editing that would
over
Build changes look ok.
/Erik
On 2020-09-01 04:41, Aleksei Voitylov wrote:
Hi,
JEP 386 is now Candidate [1] and as we resolved all outstanding issues
within the Portola project I'd like to ask for comments from HotSpot,
Core Libs (changes in libjli/java_md.c), and Build groups before moving
the
On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote:
> continuing the review thread from here
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
>
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jt
On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote:
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hot
On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Wallnöfer wrote:
> This pull request is identical with the RFR previously sent for the Mercurial
> repository:
>
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
>
> I'm copy-pasting the comments from the original RFR below.
On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote:
> This is a continuation of
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have
On Fri, 18 Sep 2020 13:33:07 GMT, Erik Joelsson wrote:
>> This is a continuation of
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1
On Fri, 18 Sep 2020 20:32:36 GMT, Erik Joelsson wrote:
>> This is a continuation of
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1
On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote:
> This is a continuation of
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have
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 07:10:47 GMT, Bernhard Urban-Forster
wrote:
>> I assume you need the rest of the PATH on Windows.
>
>> I assume you need the rest of the PATH on Windows.
>
> Doesn't look like it actually. I've reverted it, thanks for catching it.
Thanks, I tried the updated patch and it wo
On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote:
> This patch is a REDO for JDK-8253208 which was backed out since it caused
> runtime/cds/DeterministicDump.java failed,
> see JDK-8253495. Since the failure is another issue and only triggered by
> this patch, the test case now is put on
> Prob
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote:
>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote:
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
>
> * adding support for Preview APIs (javac un
On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020c to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-October/60.html
> Bug: https://bugs.openjdk.java.net
On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz wrote:
> Minor updates, with no specification changes, to the documentation of Vector
> API.
>
> The compilation of the Vector module was updated to turn on doclint errors
> for >= protected documentation.
Build change looks ok.
-
Ma
On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad wrote:
> A microbenchmark with --enable-preview was added in JDK-8248135. This had the
> unintended side effect that we now had to always run with --enable-preview.
>
> With records out of preview, I think the best course of action now is to not
On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie wrote:
> With clang 10.0, the compiler now detects a new class of warnings. The
> `misleading-indentation` warning has previously been disabled on gcc for
> hotspot and libfdlibm. Now we need to disable it for clang as well.
Marked as review
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
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes for upgrading the CLDR data to version 38. The vast
> majority of the changes are simply the changes in CLDR upstream, and others
> are mainly test changes due to the locale data change.
Looks fine from a
Build change looks good.
/Erik
On 2019-07-24 15:24, naoto.s...@oracle.com wrote:
Hi Joe,
Thank you for the review.
On 7/24/19 2:57 PM, Joe Wang wrote:
Hi Naoto,
The method findNegativeSavings method in TzdbZoneRulesProvider.java
states that it "Find the minimum negative savings". While the
Build change looks good.
/Erik
On 2019-08-23 06:08, Claes Redestad wrote:
Hi,
please review this cleanup to untangle the old bytecode verifier
(libverify). It's currently linked and loaded eagerly and early during
bootstrap.
Webrev: http://cr.openjdk.java.net/~redestad/8230043/webrev.00/
Bug:
Hello,
The .ignore file is currently in regexp format so new additions should
probably be in that format. I don't object to ignoring .iml files.
/Erik
On 2019-09-15 23:33, Alan Bateman wrote:
I think the .ignore files are maintained on build-dev. Note that .idea
is already excluded and it
Hello Jan,
The build change looks ok, but I would recommend this construct for
copying the file instead:
$(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \
FILES :=
$(TOPDIR)/src/java.base/share/classes/jdk/internal/PreviewFeature.java, \
DEST :=
$(BUILDTOOLS_OUTPUTDIR)/gensrc/ja
Build changes look good.
/Erik
On 2019-10-08 08:27, Jan Lahoda wrote:
Thanks for the new code Erik!
A new webrev/patch that includes this better way of copying is here:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
Any feedback is welcome!
Thanks,
Jan
On 03. 10. 19 18:06, Erik
brev/patch that includes this better way of copying is here:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
Any feedback is welcome!
Thanks,
Jan
On 03. 10. 19 18:06, Erik Joelsson wrote:
Hello Jan,
The build change looks ok, but I would recommend this construct for copying the
fi
17:41, Erik Joelsson wrote:
Oh, you are absolutely correct, the dependency is missing.
We need something like this inside "define SetupInterimModule":
$$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
/Erik
On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
I can’t see how the compilation is
Hello Matthias,
This looks like an interesting change. If you want to enable this for
s390x, I'm ok with it. If it works out well, perhaps we can find a way
to expand this to other architectures.
Do you really want to set --print-gc-sections by default? I would assume
that makes the build qu
Hello,
On 2019-11-22 13:30, Vicente Romero wrote:
Hi all,
On 11/22/19 3:21 AM, Alan Bateman wrote:
On 21/11/2019 19:53, Vicente Romero wrote:
Hi,
I think I have covered all the proposed fixes so far. This is the
last iteration of the webrev [1], all the current changes are in
this one, t
On 2019-11-26 04:53, Baesken, Matthias wrote:
Erik, may I add you as a reviewer too ?
Yes.
/Erik
(adding build-dev)
Build changes look good.
/Erik
On 2019-11-20 09:37, Andy Herrick wrote:
I posted new composite webrev [7], and git patch [8] after pushing fix
for JDK-8234402 [6].
[7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/
[8] http://cr.openjdk.java.net/~herrick/821278
Correct, with the Microsoft toolchain there is no support for internal.
I don't know what happens to the build if you try to configure it that
way. Feel free to come up with a reasonable behavior.
/Erik
On 2019-12-04 00:06, Langer, Christoph wrote:
Hi,
I'm currently looking into native debug
DB file is produced.
Bob.
On Dec 4, 2019, at 9:11 AM, Erik Joelsson wrote:
Correct, with the Microsoft toolchain there is no support for internal. I don't
know what happens to the build if you try to configure it that way. Feel free
to come up with a reasonable behavior.
/Erik
On 2
uild/reference/debug-generate-debug-info?view=vs-2019
[1]
https://docs.microsoft.com/en-us/cpp/build/reference/pdb-use-program-database?view=vs-2019
-Original Message-
From: Erik Joelsson
Sent: Mittwoch, 4. Dezember 2019 15:46
To: Bob Vandette
Cc: Langer, Christoph ; build-
d...@openjdk.
Sounds good and looks good.
/Erik
On 2019-12-05 20:18, Henry Jen wrote:
OK, so I created an issue[1] for follow up for Windows build and reverted the
change in flags-cflags.m4, if nothing else, I’ll push without another webrev
pinging that I get an +1 from someone in build-de, Erik?
[1] http
Build change looks good.
/Erik
On 2019-12-11 06:54, Andy Herrick wrote:
Fix looks fine to me.
adding build-dev since even this simple a makefile change should be
reviewed by build-dev
On 12/10/2019 10:24 PM, Alexander Matveev wrote:
Please review fix [2] for jpackage bug [1].
- Changed b
Looks good.
/Erik
On 2019-12-11 10:46, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
- adds $(X_CFLAGS) to compiler command line.
Patch contributed by Arthur Eubanks (aeuba...@google.com).
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8235728
[2] http://cr.open
Build files look good.
/Erik
On 2019-12-24 19:22, Sergey Bylokhov wrote:
Hello.
Here is an updated version:
Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
Patch (2 Mb):
http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch
Fix: http://cr.openjdk.java.net/~serb/8235975/we
(adding core-libs-dev)
Change looks good to me, but would like input from at least someone in
core-libs.
/Erik
On 2020-01-14 06:07, Baesken, Matthias wrote:
Hello, the following change enables the link-time section-gc for linux .
gcc and ld support enabling "garbage collection" of unused
Given the discussion regarding lto on hotspot and the extreme increased
build time, have you noticed any difference in build times with this patch?
/Erik
On 2020-01-15 00:27, Baesken, Matthias wrote:
Hi Erik, thanks for the review and for forwarding , you are correct
corelibs-dev is probabl
In JDK-8235687 the MacOS bundle distribution of the JDK was changed to
conform to Apple requirements by changing Contents/MacOS/libjli.dylib
from a symlink into ../Home/lib/libjli.dylib to a copy of that file. The
problem with having a symlink there is that Contents/MacOS/libjli.dylib
is the de
Does anyone have an opinion on this?
/Erik
On 2020-01-31 07:31, Erik Joelsson wrote:
In JDK-8235687 the MacOS bundle distribution of the JDK was changed to
conform to Apple requirements by changing Contents/MacOS/libjli.dylib
from a symlink into ../Home/lib/libjli.dylib to a copy of that file
rect for everyone (hence the "something like"
wording) but I see your point. Changed it.
/Erik
Thanks
Christoph
-Original Message-
From: Magnus Ihse Bursie
Sent: Mittwoch, 5. Februar 2020 10:54
To: Erik Joelsson ; core-libs-dev ; build-dev ; Langer,
Christoph
Subject:
Looks good, but could you change the "version" field to "5.0", it should
work now.
/Erik
On 2020-02-13 08:50, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8238943/webrev.00
10 lines changed: 1 ins; 0 del; 9 mod;
Hi all,
could you please review the patch which changes jtreg ve
difference b/w .00 and .01
Thanks,
— Igor
On Feb 13, 2020, at 9:23 AM, Erik Joelsson wrote:
Looks good, but could you change the "version" field to "5.0", it should work
now.
/Erik
On 2020-02-13 08:50, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8238943
Hello Roger,
There is more to be removed in the makefiles.
This file should also be removed:
make/CompileInterimRmic.gmk
In make/Main.gmk, all the targets concerning rmic needs to be removed as
well as any dependencies declared that involves them. Searching for
"rmic" should find all relevan
, Roger Riggs wrote:
Hi Erik,
Please review a new webrev that adds the change to remove the interim
build parts.
(Passes Tier 1-3 of CI testing)
http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes-8241073-1/
Thanks, Roger
On 3/16/20 12:22 PM, Erik Joelsson wrote:
Hello Roger,
There is
vadoc into the
generated stub .java class
and added it to the repo.
- The NetBeans Jmx build script had targets to build the stubs, they
have been removed.
Thanks, Roger
On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote:
On 2020-03-17 14:17, Erik Joelsson wrote:
Hello,
That looks better
doc comments. I merged the javadoc into the
generated stub .java class
and added it to the repo.
- The NetBeans Jmx build script had targets to build the stubs, they
have been removed.
Thanks, Roger
On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote:
On 2020-03-17 14:17, Erik Joelsson wro
Looks good to me.
I love the WrapperGenerator using Vector and Hashtable!
/Erik
On 2020-03-19 09:53, Magnus Ihse Bursie wrote:
The buildtools (java tools needed to be run during the build) have
long been plagued by warnings, includuing deprecations and unchecked
warnings, which cannot be sile
Looks even better.
/Erik
On 2020-03-20 04:42, Magnus Ihse Bursie wrote:
On 2020-03-19 19:12, Remi Forax wrote:
Hi Magnus,
please try not to use @SuppressWarnings("unchecked") on methods, but
on local variable instead to reduce the scope,
you can introduce a local variable for that.
Aha, I d
Looks good.
/Erik
On 2020-03-23 10:56, Andrew Dinn wrote:
Could I please have a review for this trivial fix to the module make
file which ensures that javadoc is generated for new module
jdk.nio.mapmode created as part of the implementation of JEP 352. The
original patch added the module to the
Looks good.
/Erik
On 2020-03-23 12:03, Magnus Ihse Bursie wrote:
The build tools (small java tools that are run during the build to
generate source code, or data, needed in the JDK) have historically
been placed in the "make" directory. This maybe made sense long time
ago, but does not do so
Looks good.
/Erik
On 2020-03-26 06:58, Andy Herrick wrote:
Please review the fix to issue [1] at [2].
Simple makefile fix.
/Andy
[1]: https://bugs.openjdk.java.net/browse/JDK-8241400
[2]: http://cr.openjdk.java.net/~herrick/8241400/webrev.01/
I think the proposed signing mechanism makes sense based on my
experience signing and notarizing the JDK itself.
/Erik
On 2020-03-27 12:35, Andy Herrick wrote:
Please review the fix to issue [1] at [2].
This change enables notarization on Mac for dmg images and app-image
zip files.
/Andy
Looks good.
/Erik
On 2020-04-03 08:43, Roger Riggs wrote:
Please review the CSR[1] and changes to remove the RMI static stub
compiler (rmic).
RMIC was deprecated for removal in JDK 13 [3].
The components modified are:
- remove the jdk.rmic module
- remove the jdk.rmic man page
- remove all
unshuffle_list.txt looks good to me.
/Erik
On 2020-04-10 11:44, Igor Ignatyev wrote:
Hi Roger,
removal of applications/ctw/modules/jdk_rmic.java and changes in doc (assuming
.html was generated from .md) look good to me.
adding hotspot-runtime alias to bring attention of runtime team. I'm no
On Thu, 26 Nov 2020 20:58:38 GMT, Magnus Ihse Bursie wrote:
> For historical reasons, there exists a variety of different implementations
> of awk: awk (the original implementation), gawk (the GNU version), nawk (new
> awk, iirc) and the lesser known mawk.
>
> Things are complicated by the fa
On Wed, 2 Dec 2020 21:32:46 GMT, Anton Kozlov wrote:
>> I wonder if we should be "upping" that to something later.
>> 10.9 is over 7 years old and has been out of support for what - 4 years ?
>
> Interesting, I still able to run the build after this change on macOS 10.9.5.
> I use jdk image and
On Wed, 2 Dec 2020 21:57:15 GMT, Erik Joelsson wrote:
>> Interesting, I still able to run the build after this change on macOS
>> 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm.
>> libjli, libjava have one, and it's 10.9
>
> The current
On Wed, 2 Dec 2020 22:00:55 GMT, Erik Joelsson wrote:
>> The current intention is to be consistent with the min system version and
>> it's currently set to 10.9. If libjvm.dylib gets a different value, then
>> that would be a bug, but note that this could also va
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
>> wh
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 optional i
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote:
> Start of JDK 17 updates.
Build changes look good and I'm happy there are so few of them!
-
Marked as reviewed by erikj (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1531
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. Pl
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
On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020e to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-December/63.html
> Bug: https://bugs.openjdk.java.net
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 fol
On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote:
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new ca
On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie wrote:
> For java.base gensrc we do the following:
>
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java:
> $(CHARACTERDATA_TEMPLATES)/%.java.template
> $(call LogInfo, Generating $(@F)
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
/Applications/Xcode.app/Contents
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
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.o
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk16/pull/142
On Mon, 1 Feb 2021 16:17:35 GMT, Alexey Semenyuk wrote:
> "common" was perfectly enough until this change. Unfortunately we cant just
> drop new C sources in "common" dir because we don't want them to be compiled
> with g++. That is why need new common directory (applauncherlibcommon) for C
>
On 2021-02-01 10:38, Alexey Semenyuk wrote:
On Mon, 1 Feb 2021 18:24:23 GMT, Erik Joelsson wrote:
"common" was perfectly enough until this change. Unfortunately we cant just drop new C
sources in "common" dir because we don't want them to be compiled with g++. Tha
On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie wrote:
> We need to regenerate the exported nroff man pages to include the proper
> version string. This will also bring in some recent textual updates to the
> man pages.
Marked as reviewed by erikj (Reviewer).
-
PR: https://gi
On Thu, 4 Feb 2021 18:52:58 GMT, Phil Race wrote:
>> remove un-needed disabling now JNF has gone ..
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove condition that should have been fixed as part of 8257858
Looks good to
On Fri, 5 Feb 2021 17:44:21 GMT, Alexey Semenyuk wrote:
>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>>
>> The fix splits Linux app launcher in app launcher and launcher shared lib.
>> App launcher is pure C and doesn't have C++ code. App launcher lib
>> incorporates bulk of C++
On 2021-02-26 06:37, daniel.daughe...@oracle.com wrote:
On 2/26/21 7:55 AM, Vladimir Kempik wrote:
On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty
wrote:
Anton Kozlov has updated the pull request incrementally with one
additional commit since the last revision:
support macos_aarc
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Mon, 5 Apr 2021 17:06:24 GMT, Jim Laskey wrote:
> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be
> in the sources.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3343
On Mon, 5 Apr 2021 17:44:37 GMT, Jim Laskey wrote:
>> open/src/java.base/share/native/random/create_ziggurat_tables.c should not
>> be in the sources.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> One more file missing cop
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Java-based JIT compiler (Graal) from JDK:
>
> - `jdk.internal.vm.compiler` — the Graal compiler
> - `jdk.internal.vm.compiler.management` — Graal's `MBean`
On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Java-based JIT compiler (Graal) from JDK:
>>
>> - `jdk.internal.vm.compiler` — the Graal compiler
>> - `jdk.internal.vm.compiler.management` — Graal's `MB
1 - 100 of 368 matches
Mail list logo
