On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>>
On 22/05/2022 23:58, David Holmes wrote:
GHA tests a range of OpenJDK ports, not just the "mainstream platforms".
The existing linux-86 failures (and others) are due to the Loom
integration which only fully supports a couple of platforms and which
broke all the other ports upon initial
On Wed, 11 May 2022 12:47:08 GMT, Jaikiran Pai wrote:
>> src/java.base/share/native/libzip/zlib/gzwrite.c line 452:
>>
>>> 450: len = strlen(next);
>>> 451: # else
>>> 452: # ifdef __APPLE__ // ignore format-nonliteral warning on macOS
>>
>> Instead of patching 3rd party code to fix a
On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>>
On 10/05/2022 13:57, erik.joels...@oracle.com wrote:
Because of how much specific logic we need in configure for each
version of Visual Studio, we have generally kept configure support for
older versions of VS for a long time, to not unnecessarily limit
people. We removed 2015 and older when
On 10/05/2022 09:29, Baesken, Matthias wrote:
Hello, it seems jdk/jdk does not build any more with VS2017.
Should we still support this compiler ?
For the error see :
https://bugs.openjdk.java.net/browse/JDK-8286459
8286459: compile error with VS2017 in continuationFreezeThaw.cpp
In Oracle,
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>>
On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan
wrote:
> This test requires jdk8 to be available while running jdk tests. But
> JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test.
> The test vacuously passes just printing a message. There are already
On Thu, 28 Apr 2022 07:13:24 GMT, Matthias Baesken wrote:
>> src/java.base/windows/native/libnio/ch/wepoll.c line 159:
>>
>>> 157:
>>> 158: #undef _WIN32_WINNT
>>> 159: #define _WIN32_WINNT 0x0601
>>
>> This is 3rd party code and would prefer not change it if possible.
>
> Hi Alan, I agree
On Wed, 20 Apr 2022 01:03:23 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On Tue, 12 Apr 2022 10:24:47 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] -
On Mon, 11 Apr 2022 00:48:34 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On Thu, 7 Apr 2022 21:08:34 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On Thu, 7 Apr 2022 00:56:42 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On 28/03/2022 07:46, David Holmes wrote:
Hi Jai,
It isn't obvious to me that the bundled sources are actually intended
to build on macOS. There's no include of unistd.h to get the lseek
definition.
I think the context here is that Jai is chasing an issue that may be bug
in the libz on macOS.
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 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 16/03/2022 08:44, Magnus Ihse Bursie wrote:
:
If you have such strong opinions on the data files shared between
java.base and jdk.charsets/jdk.localedata, I propose we leave them in
make/data for the time being, clean up the associated mess, and then
work out where they actually should
Magnus,
This proposal does not address the previous concerns. As before, you are
proposing to put the data files used to generate the classes for
jdk.localedata and jdk.charsets into src/java.base and I don't think we
should do that. I really think this PR needs to be withdraw n or closed
On Wed, 16 Feb 2022 17:55:55 GMT, Tim Prinzing wrote:
>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> Tim Prinzing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix copyright date
Marked as reviewed by alanb
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
test/jdk/java/lang/invoke/MethodHandles/exeNullCallerMethodHandlesLookup/NullCallerMethodHandlesLookupTest.java
line 2:
> 1: /*
> 2: * Copyright (c) 2019, 2022, Oracle
On Mon, 14 Feb 2022 18:03:45 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>>
>>> 119: Class c = Reflection.getCallerClass();
>>> 120: if (c == null) {
>>> 121: throw new IllegalCallerException();
>>
>> Throwing
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
> 119: Class c = Reflection.getCallerClass();
> 120: if (c == null) {
> 121:
On Fri, 11 Feb 2022 23:25:44 GMT, Brent Christian wrote:
> Having a second thought, since this API expects to be called by a class
> loader, I think throwing `IllegalCallerException` to indicate this method is
> called by an illegal caller. This will need a CSR due to the spec change.
I think
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing
> copy. The user case failed to load zip.dll, since zip.dll is not set in PATH.
> This failure is after we get NULL from
On Wed, 26 Jan 2022 00:08:36 GMT, Alexandre Iline
wrote:
> JDK-8279636: Update JCov version to 3.0.12
Thanks, I can confirm that 3.0-12 works with the current main line.
-
Marked as reviewed by alanb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7218
On Thu, 23 Dec 2021 14:16:37 GMT, Erik Joelsson wrote:
> This patch adds the version field to .jcheck/conf. By doing this we can
> remove the corresponding configuration from the Skara bots, which in turn
> reduces the need for timing and general complexity of starting a new JDK
> release.
On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks wrote:
>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change java.security.manager to "allow"; filter
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote:
> Enable the security manager in rmiregistry's launcher arguments.
As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry
-J-Djava.security.manager=allow` are equivalent because rmiregistry sets the
default SM. Some
On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote:
> Exploratory builds indicate it is not currently necessary to exclude the
> doclint accessibility checks; this patch enables them.
>
> (Enabling the reference checks is left for future work.)
Marked as reviewed by alanb (Reviewer).
On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons wrote:
> Please review a patch to use snippets in the `java.compiler` documentation,
> instead of a mix of raw HTML and/or `{@code ...}`. The change is just about
> the presentation of the code fragments; there are no changes to the normative
On Thu, 25 Nov 2021 15:58:58 GMT, Julia Boes wrote:
> This change adds support for the `@toolGuide` tag in class-level API
> documentation.
>
> (A use case is the jwebserver tool, where the
> com.sun.net.httpserver.SimpleFileServer class provides API points for
> extension and customization
On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote:
>> The time to get JDK 19 underway draws nigh, please review this usual set of
>> start-of-release updates, including CSRs for the javac and javax.lang.model
>> updates:
>>
>> JDK-8277512: Add SourceVersion.RELEASE_19
>>
On Thu, 18 Nov 2021 07:44:05 GMT, Aleksey Shipilev wrote:
>> @shipilev not sure what you mean by "a flag on the Java side". The Java
>> code just queries the VM for the finalization enabled/disabled state and
>> uses that to control things.
>
> Yeah, "flag" is `Holder.ENABLED` here. I mean,
On 05/11/2021 19:15, Andrew Leonard wrote:
:
@AlanBateman @magicus thank you both for your guidance. I have now split this
bug into the 3 mentioned:
- GenerateZip: https://bugs.openjdk.java.net/browse/JDK-8276743
- Jar/Jmod content ordering: https://bugs.openjdk.java.net/browse/JDK-8276764
-
On 05/11/2021 11:39, Magnus Ihse Bursie wrote:
:
I agree with Alan's comment above. First of all, to be absolutely clear, I
think this is a very worthy goal, and much overdue. I'll do my best to help get
this implemented.
One suggestion is to separate out the issue of ordering of entries (in
On 04/11/2021 21:16, Andrew Leonard wrote:
This PR enables reproducible Jars, Jmods and openjdk image zip files
(eg.src.zip).
It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
ZipOutputStream's.
It fixes the following keys issues relating to reproducibility:
- Jar and
On 03/11/2021 16:34, Chaliasos, Stefanos wrote:
Thanks Alan,
I used the one that jtreg uses. The complete configuration of JCOV for
jtreg is:
```
DEFAULT_JCOV_SRC_TAG=jcov3.0-b07
DEFAULT_JCOV_SRC_ARCHIVE_CHECKSUM=c5c26085750628d58de275b3f50a7409300c0497
DEFAULT_ANT_VERSION=1.10.8
On 03/11/2021 15:12, Chaliasos, Stefanos wrote:
Hello,
I'm trying to compute code coverage for langtools in the JDK repo on a Ubuntu
18.04 machine using JDK 18 for the compilation. I have run the following
commands:
```
cd /home/user
git clone https://github.com/openjdk/jdk.git
cd jdk &&
On Tue, 2 Nov 2021 19:35:29 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On 23/10/2021 07:57, Thomas Stüfe wrote:
Hi,
when I crossbuild (for linux aarch64, using a devkit, building on linux
x64), for some reason I don't
get the classes.jsa generated inside the images directory.
My configure options:
On Mon, 4 Oct 2021 13:44:44 GMT, Richard Reingruber wrote:
> The following sentence in the JDWP Specification describing the Dispose
> command confuses resume with suspend [1]:
>
> All threads suspended by the thread-level **resume** command or the VM-level
> **resume** command are resumed
On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote:
> GenGraphs tool generates the module graph. It currently supports the
> configuration via javadoc-graphs.properties. However,
> `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only
> documents two properties. It should
On Fri, 24 Sep 2021 06:12:20 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request
On Thu, 23 Sep 2021 12:53:23 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request
On Thu, 23 Sep 2021 11:30:20 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request
On Tue, 21 Sep 2021 14:52:26 GMT, Aleksey Shipilev wrote:
> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions, let's
> mention them in `testing.md`.
>
> Current patch is my braindump, I am open for suggestions :)
doc/testing.html line 77:
> 75: tier1: This test group is
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20
On Wed, 9 Jun 2021 11:05:37 GMT, Jan Lahoda wrote:
> The ct.sym may contain classfiles referring to annotations that are not
> present in ct.sym (liek JDK's internal annotation `sun.misc.Contended`). If
> javac will try to load them (while discovering annotations for the purpose of
>
On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote:
> Please review the change to update to using jtreg 6.
>
> The primary change is to the jib-profiles.js file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVersion`
On Tue, 1 Jun 2021 15:21:33 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.
>>
On Mon, 31 May 2021 15:02:57 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.
>>
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
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
On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote:
> Are you suggesting that the patch doesn't need testing as it is ? It should
> be the same either way.
> It is very straight forward to run the automated tests across all platforms
> these days.
> I get the impression that no one is
On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote:
>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is
>> introducing bugs/technical debt/call it what you will. This should generally
>> be part of a
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.
>
On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>>
>>> 313: *
>>> 314: * @since 1.0
>>> 315: * @deprecated The Security Manager is deprecated and subject to
>>> removal in a
>>
>> Javadoc will prefix, in bold,
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.
>
On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon wrote:
> This PR updates the configuration files used to develop the JVMCI Java and
> C++ sources with mx and Eclipse.
Are you sure it make sense to have this dev config in the openjdk/jdk repo? I
would think this is something for the downstream
On Wed, 7 Apr 2021 14:40:48 GMT, Conor Cleary wrote:
>> This fix addresses the following warnings which were generated by building
>> JDK API documentation with the `-Xdoclint:all` option enabled:
>>
>>
On Wed, 7 Apr 2021 18:01:25 GMT, Conor Cleary wrote:
>> src/java.base/share/classes/java/nio/charset/MalformedInputException.java
>> line 45:
>>
>>> 43:
>>> 44: /**
>>> 45: * The length of the input byte sequence.
>>
>> Should this comment also refer to the character sequence?
>
>
On Wed, 7 Apr 2021 13:22:44 GMT, Conor Cleary wrote:
> This fix addresses the following warnings which were generated by building
> JDK API documentation with the `-Xdoclint:all` option enabled:
>
>
On 09/02/2021 11:18, Magnus Ihse Bursie wrote:
This is a re-post of a change that was posted as webrev prior to the
Github migration. It is not ready for integration as-is, since it
needs to be rebased to the current HEAD, and that is bound to be a
non-trivial operation after this much time.
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
On Mon, 25 Jan 2021 14:20:01 GMT, Andrew Leonard wrote:
>> A problem was found downstream with Eclipse OpenJ9 builds whereby since
>> JDK-8258411 they were unable to extend the module lists.
>> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to
>> enable the module
On Mon, 25 Jan 2021 13:08:53 GMT, Magnus Ihse Bursie wrote:
>> A problem was found downstream with Eclipse OpenJ9 builds whereby since
>> JDK-8258411 they were unable to extend the module lists.
>> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to
>> enable the
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
> @AlanBateman When I moved the charset
On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote:
>> Marked as reviewed by prr (Reviewer).
>
> This PR is not stale; it's just still waiting for input from @AlanBateman.
@magicus Can the CharacterDataXXX.template files move to
src/java.base/share/classes/java/lang?
-
On Wed, 16 Dec 2020 18:36:25 GMT, Magnus Ihse Bursie wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
On Wed, 16 Dec 2020 13:51:50 GMT, Magnus Ihse Bursie wrote:
>> The update to JRE_MODULES in Images.gmk resolves my comment above. However,
>> the naming for the configuration is still a bit odd, e.g.
>> module-sets-classloaders.conf should be something like
>> module-loader-map.conf as used
On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie wrote:
> In `Docs.gmk` there are some hard-coded links to online URL documentation and
> bug reporting locations. These should not reside in the make file per se, but
> instead move to the `make/conf` directory.
Okay.
-
Marked
On Wed, 16 Dec 2020 00:14:02 GMT, Magnus Ihse Bursie wrote:
>> Can any of `INTERIM_IMAGE_MODULES` , `HOTSPOT_MODULES` and
>> `LANGTOOLS_MODULES` be inlined in the appropriate .gmk file?
>>
>> `INTERIM_IMAGE_MODULES` is for building interim image. If it has to be
>> defined in a conf file, I
On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote:
>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`,
>> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good
>> overall.
>
> I think this is almost ready to be pushed, but I'd like to have
On Tue, 15 Dec 2020 18:15:28 GMT, Magnus Ihse Bursie wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie wrote:
> In `Docs.gmk` there are some hard-coded links to online URL documentation and
> bug reporting locations. These should not reside in the make file per se, but
> instead move to the `make/conf` directory.
This looks okay me to but I
On Tue, 15 Dec 2020 16:11:45 GMT, Magnus Ihse Bursie wrote:
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
>
On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK 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
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the
On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie wrote:
>> @mlchung If you don't have any strong preference, I implore you to accept
>> this change. I **vastly** prefer to move the data out of `make`!
>>
>> This is not just about Skara tooling. When working with make files, autoconf
>> and
On Mon, 7 Dec 2020 21:14:55 GMT, Joe Darcy wrote:
>> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:
>>
>>> 105: { 61, 0, Set.of(STATIC, TRANSITIVE) },
>>> 106:
>>> 107: { 62, 0, Set.of()}, // JDK 18
>>
>> This seems
On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie 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 interface. So
nothing to do with
On Fri, 4 Dec 2020 10:29:48 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 Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote:
> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago
> and supported three different Linux signal API's: sigset, signal and
> sigaction:
>
>
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote:
> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result
> that the legacy-jre-image builds a run-time image that contains the package
> and jlink tools. This seems to be an oversight as these tools should not be
>
On Mon, 9 Nov 2020 16:07:13 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:
>>
>> *
On Thu, 5 Nov 2020 17:14:16 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:
>>
>> *
On Wed, 4 Nov 2020 07:45:09 GMT, Alan Bateman wrote:
>>> The javadoc for copyFrom isn't changed in this update but I notice it
>>> specifies IndexOutOfBoundException when the source segment is larger than
>>> the receiver, have other exceptions been exam
On Mon, 2 Nov 2020 11:26:51 GMT, Maurizio Cimadamore
wrote:
>> I looked through the changes in this update.
>>
>> The shared memory segment support looks sound and the mechanism to close a
>> shared memory segment is clever (albeit a bit surprising at first that it
>> does global handshake
On Thu, 29 Oct 2020 14:13:40 GMT, Maurizio Cimadamore
wrote:
>>> @mcimadamore, if you pull from current master, you would get the Linux
>>> x86_32 tier1 run "for free".
>>
>> Just did that - I also removed TestMismatch from the problem list in the
>> latest iteration, and fixed the alignment
On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote:
>> Finally returning to this review that was started in April 2020. I've
>> recast it as a github PR. I think the security concern raised by Gil
>> has been adequately answered.
>>
On Fri, 2 Oct 2020 13:17:04 GMT, Michael McMahon wrote:
>> make/modules/java.base/Copy.gmk line 195:
>>
>>> 193:$(call MakeTargetDir)
>>> 194:$(RM) $@ $@.tmp
>>> 195:$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)
>>
>> This can be simplified. Cat takes
On 23/09/2020 11:29, Moshe Zuisman wrote:
Hi.
I have the following problem. We provide OpenJDK binary distro with our
product.
With the current version we provided JDK8u-b222
Customer comes with a list of CVEs and asks if they are fixed in distro, we
provided with our product.
For example he
On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote:
>> @dholmes-ora raises a good point. Hopefully there is a balance point between
>> a dozen different bugs / pull requests
>> each targeting one area and one bug / PR targeting a dozen separate areas. I
>> don't have a good general rule to
On 10/09/2020 10:44, Archana Nogriya wrote:
Hi,
I am requesting a proposal for the contribution to OpenJDK.
I have created webrev with my changes.
Moving to build-dev as that is normally where the linker options are
discussed.
I don't know if there is a significant need for Windows 32-bit
On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy
wrote:
>> Before this Enhancement can be formally reviewed, you will need a JBS bug
>> ID. If you are already working with a
>> Committer or Reviewer in the `jdk` project who has agreed to sponsor your
>> change, they can file the
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change
On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall
wrote:
> Hello, newbie here
>
> I picked JDK-8138732 to work on because it has a "starter" label and I
> believe I understand what to do.
>
> - I tried to update the copyright year to 2020 in every file.
> - I decided to change `@since`
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
On 04/09/2020 21:55, Aleksei Voitylov wrote:
Alan,
here is a simpler version which, for the two tests in question, refers
to a local helper class with a native method:
http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/
If there is a preference to avoid JNI, there is yet another
1 - 100 of 657 matches
Mail list logo
