On Wed, 1 Jun 2022 13:52:46 GMT, Adam Sotona wrote:
> LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option
> for all JDK launchers, including java launcher.
> JAVA_ARGS should not be defined for java launcher (in contrast to the other
> JDK launchers), and the command
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote:
>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
Marked as reviewed by erikj (Reviewer).
On 2022-05-12 04:58, Magnus Ihse Bursie wrote:
On 2022-05-12 13:17, Michael Hall wrote:
A solution like including a bundle identifier something like
net.java.openjdk.MYAPP.java would be possible at packaging time but
not at build time.
To fix this at build time you would need to generate a
On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change to the build system which now makes
> bundled zlib as the default for macos aarch64 systems?
>
> We have been running into various intermittent failures on macos aarch64
> systems for several
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote:
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand
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 Tue, 3 May 2022 07:10:58 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 Mon, 2 May 2022 06:25:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which addresses
>> https://bugs.openjdk.java.net/browse/JDK-8285915?
>>
>> With this change, the environment details collected by the failure handler
>> will now include the contents of the
On Fri, 29 Apr 2022 12:51:21 GMT, Jaikiran Pai wrote:
> Quick question - the path you note, is that even applicable for x64? I see
> that it has a "System32" so just curious.
Yes, System32 is not related to 32 vs 64 bit. As I understand it, that name was
introduced when moving from 16 to 32
On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285915?
>
> With this change, the environment details collected by the failure handler
> will now include the contents of the
On Thu, 28 Apr 2022 07:16:30 GMT, Matthias Baesken wrote:
> Hi Erik/David/Phil, we already have a good central place where we set the
> definition of WIN32_LEAN_AND_MEAN
>
> autoconf/flags-cflags.m4:460: ALWAYS_DEFINES_JDK="-DWIN32_LEAN_AND_MEAN
> -D_CRT_SECURE_NO_DEPRECATE
On Wed, 27 Apr 2022 14:57:41 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, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `make` directory, and accepted those changes where
> it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> Most of the fixes are in comments. A
On Thu, 14 Apr 2022 11:19:04 GMT, Claes Redestad wrote:
> This patch examines and optimizes `Wrapper` lookups.
>
> First wrote a few simple microbenchmarks to verify there are actual speedups
> from using perfect hash tables in `sun.invoke.util.Wrapper` compared to
> simpler lookup mechanisms
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 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] -
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] -
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] -
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 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 Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk wrote:
> Implementation of [JDK-8275062: "Allow jpackage create installers for
> services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
> CSR
Build change looks good.
-
PR: https://git.openjdk.java.net/jdk/pull/7793
On Tue, 8 Mar 2022 19:11:02 GMT, Ioi Lam wrote:
> This patch makes the result of "java -Xshare:dump" deterministic:
> - Disabled new Java threads from launching. This is harmless. See comments in
> jvm.cpp
> - Fixed a problem in hashtable ordering in heapShared.cpp
> - BasicHashtableEntry has a
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 Wed, 2 Mar 2022 14:30:43 GMT, Magnus Ihse Bursie wrote:
>> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting
>> this, together with a valid backend using `--with-hsdis`, will bundle the
>> generated hsdis library with the JDK.
>>
>> The PR also includes a
On Wed, 2 Mar 2022 13:12:52 GMT, Magnus Ihse Bursie wrote:
>> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting
>> this, together with a valid backend using `--with-hsdis`, will bundle the
>> generated hsdis library with the JDK.
>>
>> The PR also includes a
On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote:
> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting
> this, together with a valid backend using `--with-hsdis`, will bundle the
> generated hsdis library with the JDK.
>
> The PR also includes a refactoring of
On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote:
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
> null
Build change looks good.
-
Marked as reviewed by erikj (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7448
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, 10 Dec 2021 16:31:45 GMT, Roman Kennke wrote:
>> As a follow-up to #6375, this change refactors
>> java.io.ObjectInputStream.Caches#subclassAudits and
>> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead
>> of SoftReference, similar to what we did in #6375 for
On Fri, 10 Dec 2021 16:31:45 GMT, Roman Kennke wrote:
>> As a follow-up to #6375, this change refactors
>> java.io.ObjectInputStream.Caches#subclassAudits and
>> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead
>> of SoftReference, similar to what we did in #6375 for
On Thu, 2 Dec 2021 18:03:50 GMT, Andrew Leonard wrote:
>> my assumption was the recipe gets resolved later
>
> this was my understanding:
> https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
>
> This occurs after make has finished reading all the makefiles and the
On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard wrote:
>> Addition of a configure option --with-cacerts-src='user cacerts folder' to
>> allow developers to specify their own cacerts PEM folder for generation of
>> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>>
>>
On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard wrote:
> Addition of a configure option --with-cacerts-src='user cacerts folder' to
> allow developers to specify their own cacerts PEM folder for generation of
> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>
>
On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote:
> 8277429: Conflicting jpackage static library name
The problem arises when running the "static-libs" build, where every library
and executable is just linked into a static-lib for downstream consumers
(Graal).
-
PR:
On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote:
> 8277429: Conflicting jpackage static library name
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6485
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, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java
On Tue, 12 Oct 2021 11:16:51 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 Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy wrote:
> This is an initial PR for expanded lint warnings done under two bugs:
>
> 8202056: Expand serial warning to check for bad overloads of serial-related
> methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and "custom" variants to be handled
>
On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee wrote:
> Upstream a critical fix from the panama-foreign repo.
>
> See the prior review thread here:
> https://github.com/openjdk/panama-foreign/pull/558
>
> Testing: tier 1-2, local run of run-test-jdk_foreign.
Build changes look good.
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Fri, 11 Jun 2021 18:44:38 GMT, Leonid Mesnik wrote:
> jtreg failure handler uses native lib to implement getPid for preJDK9.
> Currently. it is not needed and might be removed.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4476
On Wed, 9 Jun 2021 00:42:35 GMT, ScientificWare
wrote:
>> This concerns [dtdbuilder
>> tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder).
>>
>> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`.
>>
>> So, in
On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare
wrote:
> This concerns [dtdbuilder
> tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder).
>
> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`.
>
> So, in `DTDBuilder.java`
On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov
wrote:
> I got rid of `realpath` usage as discussed in
> https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro
> instead, however there were quite a few problems with this macro, here's the
> example:
>
> $(call
On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote:
> Hi,
>
> The documentation of `CLinker::systemLookup` [1] says this:
>
>
> * Obtains a system lookup which is suitable to find symbols in the standard C
> libraries.
>
>
> However, currently it is not possible to look up common stdio.h
On Sun, 6 Jun 2021 20:09:32 GMT, Liam Miller-Cushon wrote:
> This change fixes a build error during the generation of
> `ScopedMemoryAccess.java` when the sources are readonly, by using `cat a > b`
> instead of `cp a b` to avoid propagating the permissions to the generated
> source.
Looks
On Fri, 4 Jun 2021 20:55:51 GMT, Scott Gibbons
wrote:
> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
> Also allows for performance improvement for non-AVX-512 enabled platforms.
> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>
On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov
wrote:
> I got rid of `realpath` usage as discussed in
> https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro
> instead, however there were quite a few problems with this macro, here's the
> example:
>
> $(call
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.
>>
On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote:
> 8267630: Start of release updates for JDK 18
Build change looks good.
Please be aware of the incoming change
https://bugs.openjdk.java.net/browse/JDK-8263468 which will add another version
field to version-numbers.conf, which may need to
On Wed, 2 Jun 2021 20:15:55 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
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 Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov
wrote:
>> 8267706: bin/idea.sh tries to use cygpath on WSL
>
> Nikita Gubarkov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8267706: Break long line in make/ide/idea/jdk/idea.gmk
We
On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov
wrote:
>> 8267706: bin/idea.sh tries to use cygpath on WSL
>
> Nikita Gubarkov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8267706: Break long line in make/ide/idea/jdk/idea.gmk
We do
On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov
wrote:
>> 8267706: bin/idea.sh tries to use cygpath on WSL
>
> Nikita Gubarkov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8267706: Break long line in make/ide/idea/jdk/idea.gmk
On Tue, 25 May 2021 16:37:30 GMT, Nikita Gubarkov
wrote:
> 8267706: bin/idea.sh tries to use cygpath on WSL
I think this looks ok, though I'm not very familiar with the details of this
code. I also very rarely use the idea projects. It would be good if some
frequent users could take this for
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 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 Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote:
> Please review the changes to the subject issue. java.util.Locale class has a
> long-standing issue for those obsolete ISO 639 languages where its
> normalization ends up in the obsolete codes. This change intends to flip the
>
On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library
On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote:
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
>
On Thu, 22 Apr 2021 20:59:22 GMT, Phil Race wrote:
> Delete some duplicates
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3642
On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote:
> Please review the changes to support CLDR version 39. The vast majority of
> the changes are purely data changes from Unicode. The only change affected in
> logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with
>
On Mon, 12 Apr 2021 17:18:36 GMT, Vladimir Kozlov wrote:
>> make/common/Modules.gmk line 68:
>>
>>> 66:
>>> 67: # Filter out Graal specific modules
>>> 68: MODULES_FILTER += jdk.internal.vm.compiler
>>
>> If we are unconditionally filtering out these modules, then why leave the
>>
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
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
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 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
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
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, 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
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
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
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
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:
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++. That is
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 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 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
>
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
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 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
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
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:
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 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.
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 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
>>
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
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 var
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 inten
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 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
1 - 100 of 359 matches
Mail list logo
